I’m used to putting " { Polyset keep descend }" inside my groups in egg files manually to make them use collision (until I have proper collision geom). I tried this in a nice 38mb egg today, and only some of it worked. It looked like all the transformed subobjects’ collision was not properly transformed.
This code generates correct collision data:
from panda3d.core import NodePath,CollisionPolygon,CollisionNode,GeomVertexReader,BitMask32
groundMask=BitMask32(0b1)
# from FenrirWolf via https://discourse.panda3d.org/t/geomnode-vs-collisionpolygon/6757/3
# modified by Craig Macomber
def rebuildGeomNodesToColPolys (incomingNode,relativeTo=None):
'''
Converts GeomNodes into CollisionPolys in a straight 1-to-1 conversion
Returns a new NodePath containing the CollisionNodes
'''
parent = NodePath('cGeomConversionParent')
for c in incomingNode.findAllMatches('**/+GeomNode'):
if relativeTo:
xform=c.getMat(relativeTo).xformPoint
else:
xform=c.getMat().xformPoint
gni = 0
geomNode = c.node()
for g in range(geomNode.getNumGeoms()):
geom = geomNode.getGeom(g).decompose()
vdata = geom.getVertexData()
vreader = GeomVertexReader(vdata, 'vertex')
cChild = CollisionNode('cGeom-%s-gni%i' % (c.getName(), gni))
gni += 1
for p in range(geom.getNumPrimitives()):
prim = geom.getPrimitive(p)
for p2 in range(prim.getNumPrimitives()):
s = prim.getPrimitiveStart(p2)
e = prim.getPrimitiveEnd(p2)
v = []
for vi in range (s, e):
vreader.setRow(prim.getVertex(vi))
v.append (xform(vreader.getData3f()))
colPoly = CollisionPolygon(*v)
cChild.addSolid(colPoly)
n=parent.attachNewNode (cChild)
#n.show()
return parent
I would expect the loader to do something like this for { Polyset keep descend }, but apparently its not. Is this a bug, or intended for some reason? Perhaps there is something odd about my egg file? Visible geom works fine though.
Incase its relevant, this egg was made with Google-ScketchUp->dae->blender->chicken->egg
Hmm, you mean you put the tag at the top of the egg file, and it doesn’t handle the transforms below it? It’s true, I don’t think we’ve ever considered that case.
The thing is that the tag is meant to be placed at the point in the scene graph where you expect the collision objects to be generated. Everything below that is just vertices that define the shape of the collision object. Individual collision objects are not supposed to be very complex, so it never occurred to us that you might want to have an individual collision object that includes several nested transforms internally, and the egg loader doesn’t support this.
If what you want is to create many individual collision objects, each one under a different transform, then you’re supposed to repeat the tag under each individual transform.
I agree for the purposes of conveniently tagging an entire file to be used with collisions, this is not very convenient, and it wouldn’t be hard to make it support this form. We just never thought of it. You could add it as a feature request to launchpad. Still, you do want to be careful that you don’t create too much complexity in a single collision object, if performance matters at all to you.
Would this piece of code enable me to create collision geometry for a tiled terrain engine using either the geomip or heightfield tesselator tiles. This right now is a big need for me as I want to be able to collide the terrain and be able to pick points on it for terrain editing functions similar to the “god mode” terrain editor in Sim City 4. As Panda exists right now there is no way to create collideable geomip tiles or even mark an existing tile as an “into” object.
I just keep putting one hind paw in front of the other, hopefully one day they’ll quit falling thru the ground.
If you look here: github.com/Craig-Macomber/Panda … ry.py#L156 you will see that this very code was used by my tiled terrain engine to generate collision from a geomip terrain. I don’t recommend using it with non brute forced geomip since it changes over time.
That was the first use of this code, though now I use it with this code: github.com/Craig-Macomber/Panda … til.py#L62 to build optimized oct-trees of collision data from visible geometry. This code is tuned for good performance with both large polygons, and high counts of smaller ones. It should work well with no adjustments for scale since it scales based on the over all bounds, and builds the tree to an appropriate depth. I threw a 100K poly map or so at it and it worked well.
Just tried out your new code, now I need to integrate it with my engine… fortunately this should be as easy as replacing one module. And I’ve tried it with the new multithreading config option and that now works as well. This should be good for solving my terrain collision issues. Of course the last and probably worst thing will be integrating Animate Dream’s multilevel and slope based texturing renderers into this, then I will have the terrain engine I need and will be able to finally move on to adding my DBPERSIST database scheme and P2P networking.
Is there any particular advantage to GitHub over say Google Code? I’m still looking for somewhere to put my version so you all can see it.
The more relevant question is which version control system you prefer using. I don’t have experience with all of them, but I like svn for its simplicity, and git for its features and speed. The panda repository uses cvs, but in my honest opinion it was rendered obsolete by svn a decade ago. Some people like bazaar or mercurial. Assuming you prefer git as do Craig and I, you may also find github’s interface a bit friendlier. Feel free to email or PM me. I don’t want to side track this thread further.
That may be newer, and also has a handy function for taking the resulting nodePath and making an octTree out of it. I use them together to generate collision for my entire map (100+K triangles or so), and it works great.
I didn’t request the feature/change, so I don’t think anyone did.