[Bf-committers] Gameengine - ODE and Python

[Patrick]

   Sounds like you're making good progress Kester!  On the viewport 
culling, I plan on having a layer for some sort of tree such as 
quadtrees etc, but using the collision functions isn't a bad idea.  It 
only adds one more thing to the collision list, and no extra sorting of 
objects in the scene is needed.  I'm curious, does ODE do any sorting on 
its own?  If it doesn't it might be a good idea to use quadtrees or some 
sort to keep the amount of objects checked against each other down and 
keep physics speed up.  Would it be feasable to do this in blender, or 
maybe it would be better to add it to ODE itself?

   If I were to use a collision box, we'd have to add an actuator or 
something that's called "cull objects" which would basically only render 
anything thats touching the object.  Or maybe we could use a "sector" 
button like the enji system had.

Good ideas, and less work for me, although I'm still going to see if I 
can make what I have work for now.

Kester Maddock wrote:

>Hi all,
>
>Progress report:
>
>I gave up on the gamekit games - in ODE, objects are solid, whereas in SOLID, 
>objects are hollow.  eg if you are trying to use a cube as a room, anything 
>you put in the room will be ejected, at high speed.  That means, to use the 
>game engine you need polygon collisions. :)
>
>So I wrote those.  The mesh collision code is different between SOLID & ODE, 
>in SOLID you send the vertices OpenGL glVertex style, while ODE uses 
>glVertexPointer style.  Currently, I'm extracting them from the mesh class 
>and creating my own vertex arrays, but this could be rolled into the mesh 
>class and also used to fuel GL vertex arrays.
>Currently, only sphere - mesh collisions work, but they appear to work pretty 
>well.
>So, back to the game kit.  I am using the bounding box type in edit buttons to 
>define collision geometry - currently box, sphere or polyhedra. To get 
>existing games to work, you need to set a lot of objects to polyhedra, and 
>set ODE as the physics engine in world buttons.
>Also, you need to watch polygon normals.  The collision restitution happens 
>along the normal, so if it's backwards, it doesn't work too good.
>
>On performance:  according to the debug properties, I'm spending 50% of my 
>time in 'overhead.'  The major performance killer here is mipmaps - turning 
>them off helps quite a bit.
>Some performance stats (Ctrl-Alt-T):
>Under Valgrind:
>	2924
>	6509
>Software Rendering
>	316
>	865
>Accelerated:
>	35
>	88
>
>With respect to viewport culling:  I think it would be easier to attach a 
>collision sensor to the camera, and record every object that collides with 
>it.  Then you just step through and render.  Since ODE has no cone geometric 
>primitive, you could do a proof of concept using a cube or cylinder as the 
>culling object, or write a cone primitive. :)  A cone primitive needs to be 
>written anyway, to deal with the radar sensor.
>
>A couple of other ideas:
>
>It would be possible to build a scenegraph from the parent relationship.  This 
>could be used to cull objects from the collision candidates and the view 
>candidates.
>
>It would be good for Blender to be able to more accurately define the 
>collision primitives, eg for armatures.  This would be cheaper for most 
>things than a full triangle mesh, and accurate enough for a game world.  Hey, 
>wait, there is already a bone deformation distance, and weight.  Maybe I 
>could use those. :) It would also be good if the joints between armature 
>bones could be specified, that way elbows would always bend the right way 
>etc.  They could also model eg the suspension in a car etc.
>
>Later for now.
>
>Kester
>  
>