Constant frame rate problem

Hi,
I am restricting the frame rate of Java3d thread, by calling
Thread.sleep(SLEEP_TIME);

in each frame render inside a Behaviour instance.

1)Is this the right way for not allowing Java3d to use all the processing power.

  1. When i call Thread.sleep which thread sleeps. Becouse if i increase the sleep time, some operations (which are not related to Java3d) becomes slow, as if their threads are sleeping too.

  2. Is there method or way in Java3D , like setFrameRate(30);

  3. Is there a mthod or way in Java3D, like
    renderOnce();

Thanks.

I haven’t looked at how things have changed over the last few versions, but this is how I remember it working: Java3D will render as many frames as it can, whatever else is happening. You can’t limit the framerate, so don’t try to- if your application needs more power Java3D will render fewer frames so just make sure your behaviours know how long it is since the last frame was rendered and use that to judge how much you need to do (I’m not very up on interpolators, but I think you can use these in a similar way- maybe I dreamed that, though ) rather than telling it when to render a frame. The standard render-loop is rather different from the Java3D architecture.

1)Is this the right way for not allowing Java3d to use all the processing power.

no, not really. you should probably set the minimum time between frames for your view … canvas3D.getView().setMinimumFrameCycleTime(33);

  1. When i call Thread.sleep which thread sleeps. Becouse if i increase the sleep time, some operations (which are not related to Java3d) becomes slow, as if their threads are sleeping too.

don’t do that.

  1. Is there method or way in Java3D , like setFrameRate(30);

see answer to 1)

  1. Is there a mthod or way in Java3D, like renderOnce();

why would you ask? search the documentation, you’ll have to study it anyway because yes, there is such method.

the thing with java3D is that it only renders continuously when there is something changing in the scenegraph. create a simple scene with a ColorCube and you’ll see your CPU at 0% load all the time. the problem is the behaviors in java3D like interpolators and view manipulator which are waking up on WakeupOnElapsedFrames(0) … that is as soon as a frame is rendered … it’s basically an endless loop.

the solution for this is writing your own behaviors that wakeup on time elapsed instead, or constraining the render speed of your views as described in 1).

[quote]the solution for this is writing your own behaviors that wakeup on time elapsed instead, or constraining the render speed of your views as described in 1).
[/quote]
Or having your behaviour check how long it is since it was last called and act appropriately.

canvas3d.getView().setMinimumFrameCycle(fps);
works fine and frame rate is almost constant. However, now other threads in my application cannot have enough time to process their tasks. Even i set the priority of my other thread to max priority, it still cannot have enough time. Is there a way to restrict the priority of Java3D thread.

Yes there is, use this:

VirtualUniverse.setJ3DThreadPriority()

1 = minimum, 5 = normal, 10 = maximum

canvas3d.getView().setMinimumFrameCycle(fps);
you are not a friend of reading the docs, are you? you use setMinimumFrameCycle(milliseconds); not to set framerate, but the minimum time the renderer waits before rendering another frame.

Is there a way to restrict the priority of Java3D thread.
as I already told you, don’t f*ck around with java3d’s threads, it will cost ya! all frame-dependent operations should be executed inside of a behaviour, that way you are guaranteed they will finish before another frame is rendered.

Thanks for fixing my mistake about frame rate. Anyway, iin the thread priority topic i think, i could not make myself clear about how i used Java3D. In my application Java3D is not a main part, it is only one of 4 main parts, so i dont want it to get all the process power selfishly, and enable other parts to do their jobs. So implementing things in behaviour classes is not an option.(Ofcourse i am doing Java3D related tasks in behaviour classes).

I used canvas3d.getView().setMinimumFrameCycleTime(cycleTime:). and VirtualUniverse.setJ3DThreadPriority(4) to make its thread not important and to let it render as performance lets it.
In that case, not only Java3d thread priority is set, but also Awt Thread is made slow too much. I gues Java3d is somehow related to Awt Event Thread.
And after i looked at the source code of Java3D, i realized that it also changes the priority of the current thread that is calling it. The current thread is Awt Event Queue Thread.

So to fix this, after setting the priority of the Java3D thread, i called this line.
Thread.currentThread().setPriority(Thread.NORMAL);

Is this approach the right approach?

Second, sometimes application gets an exception (from Awt Event Queue Thread), and Java3D crashes. Canvas3D does not render anything after this point. Is this a bug of Java3D. Becouse exception and Java3D are not related to each other.

Although I am not very sure if it is beacouse of Java3D but , i started to believe that Java3D threads are not working well with the other threads in the application.
Thanks,

I repeat… do not f*ck around with java3d’s threads!

You still don’t understand how it works. Java3d won’t simply starve other threads, unless you change something in the scenegraph continuously. It simply renders a single frame to the frame buffer and does nothin until a change occurs (a behavior wakes up or you change something in the scene from outside which is you asking for trouble).

any code you place into a behavior is executed while java3d is waiting for it to finish. they don’t compete for resources. what ever you do, update your scene using a behavior.

Behaviours; number 1 in the list of things about Java3D that people just don’t get.

I am always updating scenegraph in a behaviour class, so i guess this is not a problem, but i was thinking that Java3D was handling all things in a thread safe way.
From what i undersand from the answers, if canvas3d crashes becouse of an Awt Event Queue Thread exception, this means some code updates scene graph other than behaviour classes. Is this what you are saying? In that case, i will recheck all the code for this case. Although i am almost sure that all the updates in the scene graph are from the behaviour classes.

Only place that i didnot use behavour is when a new object should be added to the scene graph. In that case, i am creating the 3d object in another thread and adding it directly to scene graph. Is this a wrong implementation. Do i need to store the commands to be handled in a behaviour class later?
Thanks

Always use a behaviour to do anything to your scenegraph.

If you’re in a restaurant, you don’t wander into the kitchen to fetch your food out of the oven regardless of whether or not it’s cooked. Think of behaviours as the waiter in the restaurant of Java3D - you tell them what you want and they take it to the kitchen to be sorted out…

Then dont use Java3D. Sorry, but this is not at all what J3D is desigend to do. J3D is an execution framework, your app code should be executing as behaviors (typically as WakeOnFrame(0) behaviors.)

[quote]Then dont use Java3D. Sorry, but this is not at all what J3D is desigend to do. J3D is an execution framework, your app code should be executing as behaviors (typically as WakeOnFrame(0) behaviors.)
[/quote]
I hope you are not speaking for Java3D developers, becouse i cannot understand why Java3D restricts itself just to be only module in an application. Anyway i used lots of 3d engine and i did not see such a case in others. And i believe that what you say is not right.

Are you saying that an exception in EDT causes the Canvas to freeze ? That shouldn’t really happen with Java 3D 1.4.0 and later. If you’re using a pre-1.4.0 version, I’ve a workaround here:
https://java3d.dev.java.net/issues/show_bug.cgi?id=78

And how do you “add” that new object to the scenegraph ? By “attaching” a BranchGroup at runtime ? If so, then you should most certainly be doing that on a Behavior callback since, as per the API contract, attach/detach of a BranchGroup isn’t MT safe.

Are you saying that an exception in EDT causes the Canvas to freeze ? That shouldn’t really happen with Java 3D 1.4.0 and later. If you’re using a pre-1.4.0 version, I’ve a workaround here:
https://java3d.dev.java.net/issues/show_bug.cgi?id=78

yes what i am saying is that. I am using Java3d version ‘1.4.0-build5-experimental 24 Jun 2005’
Andi got this exception:
Exception in thread “AWT-EventQueue-0” java.lang.ClassCastException
at javax.swing.LayouComparator.compare(Unknown Source)
at java.util.Arrays.mergeSort(Unknown Source)

After this exception, Java3d rendering freezes.

Maybe you could try using the final version of 1.4 (1.4.0_01 is the latest I think) instead of an early version?