collisions and scaling

Scripting Issues
1

hey, ive managed to use the modified eggoctree by mindstormss to create a collision model based on my geomipterrain, but the collisions always seem to happen far above the surface, after much testing and manual reading, ive decided its because collisions dont use scale properly (as mentioned in the manual somewhere). since geomipterrain makes my terrain almost completely flat (i have to scale z by a factor of 100 to get it looking about right) scaling is pretty much nessessary…

so how do i get my collision model to be the correct size without scaling it?

or is there another way around this? i’d prefer not to have to mess with the eggoctree code but i guess if i could make that take scale into account when generating the model, id prefer a simpler way though…

EDIT: the terrain is precedurally generated, so i cant just create it beforehand :wink:

2

Collisions and scale are an iffy mix. I’m not sure at what point it breaks down, but it’s mentioned in the manual and video lectures that not all scaling is honored by the Panda3d collision system. (I am guessing different solids apply/ignore scaling depending on the test they are performing, or maybe it has something to do with the BV caching.)

If you are generating a collision mesh from a GeoMipTerrain and then using octreefy to turn that into CollisionPolygons, you will need to perform a flattenLight() upon the mesh before passing it to the octreefy script. IIRC, octreefy doesn’t honor scaling and assumes a 1-to-1 mapping between raw vertice data and object coordinates.

I am using a modified GeoMipTerrain which contains a Z-axis scale built into the mesh generation, so that performing any post-generated scaling is unnecessary. (I found this was required in order to correctly generate normals.) But in your case, your collision mesh will need to have its scaling applied first.

3

brilliant, i never “got” what flatten actually did before, excatly what i needed, thank you.

4

From the API reference of NodePath:

FlattenLight():  Lightly flattens out the hierarchy below this node by applying transforms, colors, and texture matrices from the nodes onto the vertices, but does not remove any nodes.

FlattenMedium():  A more thorough flattening than flatten_light(), this first applies all the transforms, colors, and texture matrices from the nodes onto the vertices, and then removes unneeded grouping nodes--nodes that have exactly one child, for instance, but have no special properties in themselves.

FlattenStrong():  The strongest possible flattening. This first applies all of the transforms to the vertices, as in flatten_medium(), but then it will combine sibling nodes together when possible, in addition to removing unnecessary parent-child nodes. This can result in substantially fewer nodes, but any nicely-grouped hierachical bounding volumes may be lost.

The manual covers some of this, but I don’t think in such detail.

It’s taken me a while to get used to the flattenXXX concepts, because I’ve never used an engine that has tried so hard to cache as much as possible. But these operations directly manipulate the optimization that Panda3d performs upon nodes in order to speed things up. It’s pretty critical to understand this.