Page 1 of 1
bf-blender / linux (2004/04/06) w/ gameengine
Posted: Tue Apr 06, 2004 1:51 pm
Since we are behind compared to the win users
and I wanted to try out the new AO and the new textures I compiled a build for myself, and I'm sharing it. No game engine, I couldn't get it to work, but working on it, I'll change this post if it compiles.
For changes see yesterdays windows topic.
One more thing: I can't guarantee that it's working or even not going to damage anyone's system. It works for me, hope it's working for you.
Posted: Wed Apr 07, 2004 5:00 pm
Ok, I got the gameengine working, however, no ODE, can't compile with it. I also have trouble with fmod and quicktime (is is even possible?), so if someone could help me, I'd be happy (I know this isn't the forum for that, but still
) The game demos found on the frontpage are all working for me. Unfortunately I don't know anything about the gameengine, so I don't know how bad missing ODE is, just tell me if I shouldn't do this.
Posted: Wed Apr 07, 2004 6:26 pm
Erufailon wrote:no ODE, can't compile with it
Code for this is broken now, with the restitution of Solid. (Sumo Physics)
Posted: Thu Apr 08, 2004 3:34 pm
> Code for this is broken now, with the restitution of Solid. (Sumo Physics)
Hopefully ODE get's integrated as the dynamics library in the near future, with SOLID as the collision detection library.
I created quite a few game demos when briefly working for NaN, and the main issue was always the fact that any dynamic ( ie moving ) physical object could only have a spherical proxy for collision detection and resolution ( although it could be checked against any arbitrary geometry ).
If this was resolved, allowing for spherical, OOB, AABB, convex mesh and possibly even concave mesh ( will be slow ) proxies for dynamic objects, the Blender game engine would rock! I'm not sure if this was an issue with the SUMO dynamics library only being able to handle spherical resolution.... does anyone have any info on this?
I think enough people had issues with this feature, that backwards compatibility of the physics capabilities aren't that important. Everyone I know who were using it had a number of issues with SUMO etc. I definitely look forward to seeing how the physics side of things progress over the coming months.
On a side note, what would be especially cool would be if this information could be fed back into the animation package, to allow for physical scenes to be animated. I'm sure a quick Python script would sort this out, but if it was available as an integral part of the package, this would rock! ( Note that with the current implementation of the physics, it's impossible to even set up a stacked wall of bricks, as each brick could only have a spherical physical proxy, so it's something that definitely needs to be addressed if possible ).
Posted: Thu Apr 08, 2004 3:54 pm
Good ideas Mal, sounds sensible.
Posted: Thu Apr 08, 2004 8:37 pm
O yes, I'm all for that physics engine for animations thingy, that would rock!