Since every Body is talking about Java3D using hardware acceleration (HW) through OpenGL I was wondering why there is a big performance difference between native OpenGL and Java3D. I posted two applications (see my previous Mail from 08/25) one using native OpenGL and another using Java3D and if you have hardware acceleration on your machine you'll notice the difference two : just run both programms.... I got only two answers : - One saying that Java3D is not using any hardware acceleration. Maby Java3D is using some partial HW only or there is some serious synchronisation problems in the Java3D engine. We can only keep guessing since nobody from the Java3D team seems to be concerned ):-. - the other one : >>One thing that Java3d does that makes calculating performance difficult is >>its handling of behaviors. In other words, just because its running at a >>certain framerate does not mean that is the fastest frame rate it can do. If it's true This is a bugy behavior. If Java3D can do faster then it should. >>I think J3d is applying some sort of optimization to determine if anything is >>changing to determine whether to make a new frame. Preventing from getting faster result is no optimisation in my opinion. >>The other thing is that your behavior might not actually be called according to your criteria, I >>have found J3d to be liberal about deciding to call it, especially a wake up on elapsed time. If there is a bug in the Behavior or wakeup creteria could some one from the Java3D team confirm it ? Is it going to be fixed some when? >>In several cases I have found using seperate threads to update my transforms >>produce smoother, faster transformations. This could be relevant only if your updating different objects that are not dependant from one onother. If you start a thread to transform to position 1, and if your machine is fast enought then you ' ll probably start the second thread to transform to position 2 before the transform to position 1 is done. And you probably could get the thread 2 done before thread 1 means you go to position 2 and then to position 1. Since that is not what you want so you'll end up blocking thread 2 until thread 1 is done. So if the threads need to work in a batch manner you do not need to spawn them in threads. Do you? >>The other thing, if there is a real problem with the transformation time, try another approach entirely. >>Build your pool of particles, and set their transformations, then put them >>in a switch node and animate by flipping children on and off. >>You really have the same memory overhead, but the particles arnt "moving" really, you >>are just makeing them look that way. this could work in cases where you know where your objects will be, but if you don't know where the objects are? Think of particles moving depending on where the wind direction is and it's blow power. Beside of all this, transformation is a big part of computer graphic and most of the new cards on the market support Hardware TL. So we need to use transformation and there is no reason why it had to be slow in Java3D. So again why is TransformGroup method setTransform(..) is taking to much time? (see my privious mail for more informations.) I didn't see till now any really good loocking full with action demo arround in Java3D? This make me think: Is Java3D ment to be only for education purpose as a starting point to learn 3d computer graphics? What are the plans for this api? what do we have to expect from it? Kelvin Chung, Dan Petersen, Doug Gehringer any comments? =========================================================================== 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".
