Slow compared to Quake II, where I got my models from. I have no direct comparisons, but the framerate is certainly slower than a much bigger Quake level.
Yeah, the next thing I would look into would be some kind of BSP implementation. That was a bit beyond the scope of my project. I had the back clip distance set fairly short though, and set the levels out so you couldn't see that far adhead, so I don't know how much difference that would have made. I have used Sun's picking utils for collision avoidance as well, which create objects, which probably slows it down a little. I think some LOD's would have made a difference too - Quake has several versions of each texture, while I was using the biggest all the time. For the biggest level (tiny by Quake standards), I had to put memory allocation up to 128MB to run it. Once I've handed my report in, I'm going to go back and see if I can do some of these optimisations, which should get me a better comparison. Alan Hudson wrote: >When you say slow compared to C++ does that mean you implemented similar >code in both, or just running the sameish models in a quake-style >engine? The biggest difference in those engines is typically they >implement BSP or octree based culling routines. For indoor scenes this >makes a huge difference. > >We've been running Xj3D against other VRML browsers and we compare >favorably. For mostly polygon worlds, ie few textures we are equal. >For heavily textured worlds we are about 10-20% less. The difference is >in memory consumption. Java3D uses more. I think thats mostly image >related. > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
