|
I thought you guys were in the beta program?
And I also thought this was solved in the upcoming release? In particular
I think the documented bug was that updates to the view transform and scene
graph where not synched. Are you describing another problem?
I know I used to have jitters of various kinds
until started putting messages into a queue, then processing all the scene graph
changes in a single wakeuponelapsedframes(0). Of course you are right,
this does not solve behavior issues. In particlular I was solving the
viewtransform/scenegraph change issue.
Is this what you are talking about or are you
referring to something else, and has Sun agreed its a problem.
And... isn't there a dev chat soon?
Dave Yazel
----- Original Message -----
Sent: Tuesday, September 26, 2000 6:58
PM
Subject: [JAVA3D] Behavior and Render
thread synchronization problem
To start off, I have brought up this topic twice before on this
list
.
A few people supported and a few were very against it.
However, our project has reached a point where we MUST have correct sync
between the behaviors and render per frame.
Now we have completely
implemented our own behavior management system already. However this
system currently gets it's update from a Java3D behavior that is trigger by a
WakeOnFrameElapsed = 1.
So, for our behaviors everything seems to work
fine but there are times when we still need or would like to use standard
Java3D behaviors, such as Billboard or the utils-KeyNavigator behaviors.
Therein lies the problem. Because these multiple Java3D behaviors
throughout the graph are NOT guaranteed to be updated "atomically" before the
render, jitter becomes a way of life.
Unfortunately, our project has reached a point where we can no longer have
jitter in our demos.
So we are about to insert our behavior execution into
a Canvas3D object that will call our update in the pre-render. This will
make sure our updates get done before the frame. This does not fix the
normal Java3D behaviors - Billboard etc. so we CAN NOT use them. We are
force to rewrite any Java3D behavior we wish to use to work in our
update. Additional, we will be writing our behavior management code to
run threaded, so on our multi-processor systems we will get processor
utilization. If you guys are interested I can explain how we are
multi-threading AND synching (I'm sure you guys understand this, just other
people on the list posted it can't be done).
The point of this detail explanation is that it is extremely disappointing
that we must do this at all! It is ridiculous to have to reimplement the
Java3D behavior system and behaviors and/or remove then from the graph to get
correct execution. A simple sync option should exist in the View class
that guarantees this execution. And it's not particularly difficult to
implement, at least not how we do it.
On a side note, we have done this
for years using SGI's Performer, and it is a must for many, many 3D apps.
Is this the only option. Any suggestions on a better work around
would be greatly appreciated?
___________________________________________________________
Shawn
Kendall
Full Sail Real World Education
Course
Director
3300 University BLVD
Real Time 3D for
Gaming Winter Park FL 32792
[EMAIL PROTECTED] http://www.fullsail.com
___________________________________________________________
| 