I have to agree with you on this. Are you using hprof to measure the time
involved? Im just curious because I profiled my project and found it
spending much more time here in GeometryArrayRetained.execute(). In fact my
transformations did not even come up as being time consuming enough to note.
Another interesting thing is to look at the threads that Java3d runs. One
of them is a transform thread, makes you wonder if when you call
setTransform is you are not just queueing the transform to be applied as
soon as the Java3d kernal can handle it.
The point of my original response was the age old question : Whose code is
wrong? I always operate under the assumption that my code is inefficient,
or incorrect when first I encounter a problem, especially a performance
problem. 19 times out of 20 I can solve the problem by changing my code.
Java3d has seemed to be complicated enough that the interactions within all
the pieces can make there multiple ways to do the same things. And some of
them may "play nicer" than others within the framework. Obviously
setTransform() is not slow in a general sense. All of our programs would
run like dogs if that was the case. If setTransform() was slow then Sun
would have tagged it a bug long ago. But in your specific example, you have
found it to be slow. As simple as your example seems, you are still doing
the animation in one way, while there are other ways to do it which perhaps
would work better. To really analyze what is happening I think you would
need to study the hprof output and especially look for thread contention.
1. Have you looked at the profile breakdown to see if setTransform() is
blocking your thread?
2. Have you tried reproducing this in immediate mode to see if you can make
the transformation calls at a faster framerate?
3. Have you tried different triggering behaviors?
4. Have you measured to see if your code is really getting executed on every
frame?
5. Have you checked to see if your particles are being rendered efficiently?
For example alpha channel blended writes can be slow.
6. What kind of perspective correction, mipmapping and minification,
magnification policies are you using for the particles? Is it possible that
Java3d is working harder than it needs to be?
7. Is it faster on a non-live scenegraph?
I am sorry to say that Java3d is not magic. The way you use it can heavily
impact its performance. You can produce 5 programs which do the same thing
and are "technically correct" but perform differently. For example, putting
a transformation on a texture. You CAN do it. So someone might read that
part of the API and start scaling their textures using a transform all over
the place. But what is it really doing? Is it telling the graphic card to
transform the texture coordinates or is it transforming then putting it to
the card. I have personally found that creating a wrappable texture then
using texture coordinates greater then 1 will render that associated shapes
MANY times faster than setting the TextureAttribute transform. But there is
not necessarily anything WRONG with Sun's code, it could be that in order to
handle the general case they needed to consider textures with transforms on
their attributes to be "new textures". Who knows. OR it could be a bug.
But its really hard to tell.
The best thing to do it to reduce the problem until you have eliminated
everything that is unrelated to the problem. Once you have it boiled down to
a simple case where you can show setTransform is slow, then Sun might
respond.
In answer to your question:
"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?"
The reason why I don't think you have seen a good demo is because of the
work involved to make one. The prototype code for my RPG client looks
gorgeous, but represents a huge amount of work and lots and lots of code.
To make a demo have the "wow" factor to really show off the engine would
require lots of nice textures, a framework on top of Java3d to manage the
textures, materials, etc. I believe Java3d is a real product. For a "4th"
generation hardware independent 3d api it is in some ways ahead of its time.
There are plenty of great products using Java3d, its just hard to find them
because Sun does not really seem to track them. Here is one :
www.roboforge.com This is a real product in beta and will be released in
November and looks to me to represent a showcase of Java3d capabilities.
Anyway, time for more coffee, see ya all later
Dave Yazel
----- Original Message -----
From: Labtaini, Fouad <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2000 7:21 AM
Subject: [JAVA3D] Why is TransformGroup method setTransform(..) is taking
too much time?
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".
===========================================================================
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".
