Blender 2.33 Re-enables Game Engine 198
fforw writes "One and a half year after becoming free software, the Blender Foundation has released
a new version of
Blender which finally enables the game engine again.
When Blender became free software. the game engine had to be disabled because SOLID, the collision library was not free software. After SOLID's author Gino van den Bergen changed his mind, Blender has now restored all functionality from the closed-source period."
and another thing for newbies to learn (Score:4, Interesting)
A welcome addition - not just for games (Score:5, Interesting)
This is really good news (Score:5, Interesting)
It actually gets even deeper when you combine the python scripting with the game engine, as opposed to using the built in object functions. The games can get really complex, and with the inverse kinematic options for human body(mapping theh way the human joints move), it makes for some really interesting possibilities. Personally as I am learning python now, I may go back to the blender engine, and see what havoc I may be able to create.
Collision detection (Score:5, Interesting)
Good collision libraries are fun. I've written one, as part of Falling Bodies. [animats.com] I think I was the first, back in 1996-1997, to use axis-oriented bounding boxes with GJK, which is what SOLID, and everybody else, uses now.
Lin and Canny are the ones who really cracked this problem. Before Lin and Canny, algorithms for collisions in a space with N objects with M faces each were O(N^2) * O(M^2). They got that down to slightly worse than O(Nm), where Nm is the number of moving objects. Very clever.
I-Collide [unc.edu] was the first generally available package for this. The original version was in LISP, which was translated to C, retaining much of the LISP style. They used axis-oriented bounding boxes with a linear programming package. This had some problems with numerical error, and the linear programming package was rather bulky. But it demonstrated, back in 1996, what was possible. Then everybody (well, the half dozen or so people into this stuff) went to work and built better systems.
Actually, collision detection is a pain to code, but well understood today. Collision response, the actual physics, is much harder.
The end result of all this is that games can now have really big worlds with working collision detection.
Re:Collision detection (Score:3, Interesting)
SOLID is a nice library, but its license terms are still unfriendly to commercial products. The author wants a couple thousand dollars to license it for even a shareware game, which is just silly when ODE is free under a BSD-style license. ODE's collision subsystem isn't quite as, well, solid as SOLID, but it's good enough for many applications.
Is .3ds support still omitted? (Score:1, Interesting)
I mean, what's the point of using a 2nd rate app that can't even import a commonly used file format?
Re:what about Undo? (Score:3, Interesting)
Re:Game engine = worst...idea...ever (Score:4, Interesting)
Re:Game engine = worst...idea...ever (Score:3, Interesting)
Bring it on! (Score:3, Interesting)
We should thank this guy... (Score:1, Interesting)
Anyone know where to find him & maybe send him beer money or something nice?
Re:Game engine = worst...idea...ever (Score:3, Interesting)
Lightwave vs Blender vs Max (Score:4, Interesting)
Re:Collision detection (Score:2, Interesting)
Re:and another thing for newbies to learn (Score:4, Interesting)
(That was a joke for those who wish to report me to the purity patrol.)
I needed to have interactive design students look at something they had never seen - so I gave them Blender. Half had used 3D Studio Max. The rest, just Adobe and typical high school student fare. There were 17 students. They had to write a tutorial on creating an object that wasn't just a primitive.
Half of the 3D Studio Max users loved it, the rest were irritated, but found it usable. There was only one student who copped out of the assignment and the rest *really newbies* were able to do a credible job.
The general consensus was that the interface was different but good if you are a macro stroke user and a pain if you use menuing. I think they were saying 'different' compared to things like Photoshop. Of course 3D is a different interface, so their expectations could not be met. As with anything else, everybody has an opinion! Mine is, as we all know, irrelevant and uninformed, so please, I have a headache. Curtman, I obviously have no idea about Soft Image and others. I can't even remember the name of the first one I used in the mid eighties. I am still amazed by meshes.
What I can't believe is that Photoshop users think that there have been these great leaps forward in bitmap editing programs because they no longer have to open Illustrator to make type flow on a path. Maybe Zanax would help.
Re:Collision detection (Score:3, Interesting)
Very cool. I'm Matt Spong, lead developer/CTO of Elemental Productions. We're a game company, about 1.5 years into our first project (multiplayer RTS type, Win32/OS X/Linux, potentially Xbox). I'm in charge of coordinating development of the engine, as well as writing a majority of it.
Physics simulation is something that's really caught my interest over the course of writing this engine - I'm actually thinking of going back to school for a degree in Physics or Math (got about halfway through a CS degree then left to ride the bubble because I was tired of spending time and money to get a degree for something I had been teaching myself since I was 8) and going into computational physics research stuff afterwards. That way I can actually get a degree that will teach me something, instead of me teaching the professors the intricacies of C++ templates
I prefer spring/damper simulators, because you can handle frictional contacts right and you don't have the zero-time bounces (the "boink problem") of impulse/constraint systems. The CPU load is higher, but that's less of a problem than it used to be.
I've always had some stability issues with spring/damper systems - they seem to me to be a little sensitive to floating point errors when you create very stiff springs. The approach I took with our simulator was to treat contact points as a kind of joint that would be created when the objects touch and destroyed when enough force was applied to overcome the frictional forces holding the contact in place (with some specialized versions of the contact joint to handle things like sliding, etc). When they are in place they work like any other joint, constraining how the objects may move in relation to each other. And the zero-time bounce problem goes away, because the objects will be joined with a resting joint, which keeps them from moving at all unless enough force is applied to break the joint.
This has worked out pretty well in practice, because it allows the entire physics system to be build up into one hierarchy. That way we can cut down on the calculations quite a bit, also, since we can figure out solutions for bigger groups of objects at once. It seems to be a good way to structure the world that makes some things that would otherwise be a hassle a little easier.
I have to admit, I don't know the current state of the art in the physics simulation field, because I've only gone out and read up on things I couldn't figure out myself (and after re-learning calculus and matrices and some of that nastier math, I figured most of it out on my own). So it's very likely that a lot of what I've done in the simulator is not the best way of doing things, and also quite different than other engines may do them. But it seems to be working fairly well (it'll do basic rigid body physics, rotational/sliding/ball-and-socket joints, contact joints, springs/dampers (linear and rotational), pretty basic cloth stuff) and it doesn't really have stability or performance issues. I went to SIGGRAPH last summer and sat through a couple lectures about computational physics stuff (including a really good one by the Pixar guys), and I've got plans to work on fluid simulation in the near future (I want to get in-game explosions modelled as realistically as possible... actually simulating them would be cool).
So like I said, this is something that's caught my interest, and possibly something I may pursue in the future. I'd like to focus all my attention on this sort of thing, at least for awhile, instead of it being another side project, competing for time with the rendering engine and the AI and the rest of what makes a game.
A good test of a physics system is the spinning top. That's easy to set up. The base should roll around a little (it has a nonzero diameter), the top should precess, it should recover from small dist