Every behavior with wakeupCriterionOnElapsedFrames(0) , as a FPS counters and some interpolators, uses a kind of loop wich takes that 100% CPU. This is low priority thread, so others tasks are not affected. This kind of behaviors seens also to force a high number of FPS, even when is not needed.
There is some workarounds:
1) Limit the max FPS value, this way:
// simpleUniverse is your instance of SimpleUniverse // Up to 100 FPS or 1000ms/10ms. Time in ms. simpleUniverse.getViewer().getView().setMinimumFrameCycleTime(10L);
This workaround works fine for Win2k, up to 10ms or 100FPS; but on Win98, due a not so good timer, the minimum cycle time is 50ms, what gives you around 20FPS, even when using the same above setting. About Win2k/Win98 I can talk by my experiences, but I can not say about XP or other OS. As reported previously in this list, Linux also works fine with setMinimumFrameCycleTime.
2) Disable your fps counter behavior and use FRAPS (www.fraps.com) to count your FPS. If you are not using interpolators or other behaviors with wakeupCriterionOnElapsedFrames(0), you will see sometimes 0% CPU power and 0 FPS (static scene - no needs of redrawings).
3) Use Vsync on (vertical synchronization enabled). This way the 3D engine will not produce more frames than your video refresh rate, and this mean less work to do. There is another things here, as windowed 3D app doesnot respect VSync, but I guess you are going to use the new full screen modes avail in Java1.4 .
I advice you to have another JRE with Java3D DirectX. In some systems DirectX gives more FPS, and gamers are crazy for FPS hehehe.. DirectX and OpenGL works slightly different on some features, as lighting, transparency, multitexture, so is wise test both implementations.
Read the Readme of both implemetations. It has very important info about that release, as bug closed and still open.
more details about you system as OS, JDK version, ram, etc. helps
Alessandro
David Roberts escreveu:
Hi all,
I've been benchmarking java3d to see if its suitable for a project on your average pc, and I'm trying to understand the results.
4 Scenarios under 1.3.1beta OGL:
1 - Create 8 texture mapped spheres of step 128 and give jvm 100% cpu - result is 72fps. 2 - Create 8 texture mapped spheres of step 128 and give jvm 50% cpu - result is 36fps. 3 - Create 8 texture mapped spheres of step 256 and give jvm 100% cpu - result is 45fps. 4 - Create 8 texture mapped spheres of step 256 and give jvm 50% cpu - result is 22fps.
The scene is completely static and the only behaviour attached is an fps counter. There is a directional and an ambient light.
The view never moves, so, under these conditions, the cpu has nothing to caclulate, and the gpu should be doing all the work.
So, why is the number of frames rendered proportional to cpu available? All geometry and textures are already sent ot the graphics card, and no new calculations are being done (short of an fps behaviour).
I have your average P1.4 with an average nvidia ti4200.
What is the cpu doing? is it resending the geometry every frame? and how could that be dependent on cpu - should just be DMA calls? I suppose it could be recalculating bounds, but theres only 8 objects? Maybe its spending its time sorting through the geometry and seeing if some of the triangles are beyond the back clip, but I thought that was also delegated to the graphics card?
vot is going on in da cpu?
David Roberts a java coder... of sorts...
=========================================================================== 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".
