Ahhh crap. I was afraid of something like that. I wish I would've went with cal3d in the first place myself. grrrrr I actually chose it because I saw that Delta3D was using it, so it must have some benefit. Since I don't use any of the contact translation, though I don't think I get much benefit, except the creation of the osg geometry. I have had problems LODing, switchable objects, and access to animation speed. I've resorted to hacking away at ReplicantBody, though. Are you saying that these calls are pushing the vertices onto the GPU? cal_renderer->getVertices((float *) m_geometry->getVertexArray()->getDataPointer()); cal_renderer->getNormals((float *) m_geometry->getNormalArray()->getDataPointer()); Any OSG experts know how I can get the cal3d vertex arrays jammed into OSG efficiently? Thanks a lot David for the info... even though it was so disappointing.
Zach _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Guthrie Sent: Wednesday, April 18, 2007 15:30 To: osg users Subject: Re: [osg-users] cal3d lod The problem with rbody is that it's pushing all of the vertices to the GPU every frame. Using a display list stops the animation because it's precompiling the vertices onto the GPU, so it doesn't change. Using display lists would only help for a stationary character. You can write the vertices straight to a vertex buffer and see some performance benefit, but I don't think rbody supports that. We are currently removing rbody from our engine (Delta3D) to use cal3d straight. Partly so that we can control the rendering. If you want to see more characters and you use a vertex buffer, you can do things like only updating the animations on timer somewhat less than the frame-rate, which will allow a vertex buffer to not be written to the card every frame. Another option is to do hardware skinning where you only use cal3d to update the bone positions and have a vertex shader use the bone positions to move the vertices of static pieces of geometry in the GPU. On Apr 18, 2007, at 3:06 PM, Zach Deedler wrote: PROBLEM I want more people in my scenes rendering at 60 Hz. INVESTIGATION 1. Well I spent all this time putting in LODs, but I didn't get spectacular results. :( I render a man model, and looked at the stats. High level LOD 3497 vertices 0.5 Draw time Low level LOD 805 vertices 1.0 Draw time The draw time is the draw time of the actual model (I cancelled out the 0.5 draw time of drawing nothing) 2. Stopping his animation doesn't improve the stats. 3. Removing the textures doesn't improve the stats. 4. Rendering a non-cal3d model of 4837 vertices gives me 0.25 draw time. 5. If I tell the geometry of the rbody Submesh to setSupportsDisplayList(true), the man no longer animates, but the draw time goes to 0.2. QUESTIONS 1. Where is all the draw time being spent for cal3d/rbody? 2. What can I do to reduce the draw time? 3. Any suggestions on how to find the performance bottleneck? For now, I'll continue to hack away. Thank you. Zach -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Ciger Sent: Wednesday, April 18, 2007 14:25 To: osg users Subject: Re: [osg-users] cal3d lod -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy L. Moles wrote: > Palle Raabjerg and I rewrote most of the Cal3D exporter for Blender > (he as a Google SOC project and myself just out of curiosity) that is > currently in Cal3D SVN (I also put up the new funky website!). I > didn't write any of the LOD code however, and I can confirm it is > certainly not in a working state at the moment; I do plan on revisiting it eventually. > There isn't a lot of activity lately unfortunately, but I don't > believe the project is dead... > That's a good news - that exporter could use some love. I have also a similar waiting project there - to finish a BVH skeleton and animation loader for Blender. There are some really nasty and non-trivial issues there so I cannot blame you for the Cal3D one - I have seen the code when I needed a converter for our in-house animation format to Cal3D and it is certainly not a piece of cake. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGJmJ0n11XseNj94gRAtSbAJ0dc6s93SQSeDCOuno/nje55etdngCeNa62 Vl+RKgDdS6TKwBXzBgb0a0U= =xU0R -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
