Java3D and frame updates

I’m just starting to learn Java3D, so please be patient if I ask stupid questions.

I have a bunch of objects to be drawn to a Canvas3D, but first their positions and rotations need to be updated. As I understand it, if I call a method in the object that changes its associated Transform3D, the Java3D renderer will immediately render the change. What I would like to do, however, is to first update each object, and then render all the objects together.

I have looked at the documentation for immediate mode, but I must admit I find it rather confusing. It also seems that the Behaviour class could do what I want; but that means giving the graphics engine, rather than my game engine, control over when my objects are updated, and I’m not happy with that idea.

Do I need to extend the Canvas3D class and explicitly call its rendering methods, and if so, in what order? Can I use stopRenderer() and startRenderer() methods to stop the graphics engine while I do my updates, or would that involve fantastic amounts of overhead? Is there a good tutorial out there? Should I be using an offscreen buffer, perhaps? (I found the documentation for that rather difficult to follow also. Perhaps someone could simplify it for me?)

The easiest way to go is to put all updates into a Behavior and run it with a suitable WakeUpOnXXXX policy.

Im having the same problem … Can anyone tell how can we solve this problem !!!

My e-mail is :birinhos@hotmail.com

The problem is very well explain in this post :

http://archives.java.sun.com/cgi-bin/wa?A2=ind9906&L=java3d-interest&F=&S=&P=127314

I allredy contact the author and he tell-me that never resolve the problem…(since 1999).

This is a common Java3D issue as it lieks to do things asynchronously.

The answer is a WakeupOnFrame(0) behavior.

This behavior is gauranteed to be called synchronously with frame update.

Edit: note that not everything has to be synchronous ina game. Generally synchronicity is only an issue when dealing with collision. Im intending to run my particle systems asynchronously because they are all really just visual candy.

Synchronicity is always important when relations between object are concerned. E.g. a camera following an object. It is bad when camera and object positions are updated in different frames.

This has the ugly side effect of (a) 100% CPU-usage + very uncoherent frametiming! Not good for smooth animation. This always has been a major issue in the development of FlyingGuns.

Im not sure I follow, maybe Im misunderstandiong something.

Games typically burn all the CPU they can. they also typically vary wildly in frame rates-- watch the FPS on any version of Quake (1-N).

[quote]Games typically burn all the CPU they can.
[/quote]
… which I think is bad style, but thats not the point here…

The framerats may vary, but not on a per-frame basis. Means: measuring the time needed for the last frame give some expectations for the frame coming next. Not exactly, but roughly.

This normally is the deltaT that is used to propagate motion/animation. It is measured from the last frame but used for the calculation of the next frame. This can only work if last and next are correlated somehow … that’s whats I was calling ‘coherence’. Coherence is important for smoothness.

In Q[n], mayby turning the avatar causes a sequence of frametimes like [10,10,12,13,13,15,17,17,17,19,20] which means cutting the FPS to half.

In Java3D, I observed [12,12,12,197,12,63,12,10,10,11,10,10,12,164,10,10…] which still gives a nice framerate but make any animation choppy, esp. those motivated by physics (a looong dT can tense a spring badly).

See the point? It seems the unpredictable times are not caused by GC. I assume it is the multithreaded nature of Java3D, whith some threads kicking in here and there.

We had a prototype of FG running the singlethreaded Xith3D engine … and it was absolutely smooth.

What I find suspicous: look at the HelloUniverse example with the spinning cube. Look closely. It is not smooth!

In FG, I fooled around with that a lot (and it is very annoying). I found that thing get better when framerate gets throttled either by WakeupOnElapsedTime or by setMinimumFrameTime().

Is it freeing some CPU resources for other threads to run not disturbing my gameloop so much?

Things got better, yet not good. Additionally I had to introduce a smoothing timing framework which can grow counterproductive on certain configurations … bah. Ugly.

In the end, FG still isn’t smooth. And I hate that. It gives bad reputation to the game and to Java itself. Unfortunately I lack of resources, knowledge and tools to really analyze the problem. Someone should.

Hmm. Im not sure what was causing such wide variation in frame rate, but it doesnt seem to be a general problem. Ive seen a great many Java3D games (such as all Shawn Kendall’s work) and noen of them have seemed choppy or shown that kind of variation. Is this rendering the same scene or were you wildly changing what was on screen at the time?

can anybody send an simple example of using WakeupOnFrame(0) tecnic … ??? ???

(i think I understand the tecnic but I need some example in Java3D…)

by the way … can we get the coordenate int X , int Y on the screen(canvas3d) having an Point3d (coodenates) in the universe

Point3d ---->to----> (X,Y)

tanks

Look at ChaseCameraBehavior in the JNWN project.

I just wrote that code yesterday :slight_smile:

Also, if you want to understand behaviors, read the J3D tutorial on the java3d.dev.java.net site. Alternately the J3D spec is availabel in book form and has all the info, albiet in a mreo eference-orienetd form.

Edit: Note that ChaseCameraBehvior is a sub-class of ViewPlatformBehavior, which is a special kind. Unless you are trying to write camera behaviors yo uwant to sub-class Behavior instead. All the wake up and processing stuff though is pretty much the same.

ViewPlatformBehavior only makes sense when ViewingPlatform is used a utility to setup a universe, right?

BTW, what is the difference between PlatformGeometry and avatar?

Both seems to be BranchGroups and added to the same TransformGroup?

No, there is not much changed in the scene and as I said, even HelloUniverse seems to be unsmooth in that way.

Unfortunately, my new machine is THAT fast, that the effect is hardly percievable. So I need to setup a suitable environment for further measurements first.

Yes, I saw Shawns stuff on J1 2003 and talked to him about that. We fully agreed about the way the gameloop has to be driven in Java3D.

The has been the artifact that his stuff performed really well on the J1 demo machine, whereas FG dropped to about 20FPS on a hardware that was good for 100FPS. So I assume something is wrong with my setup, but I cannot figure out what it could be.
I’m not using SimpleUniverse but my own setup. Can I make something wroing there? (de.hardcode.threed.frame)

Hm. I woudl be surprised if anything you coudl do there woudl make that much of a difference but i always strt from SimpleUniverse myself.

What kidn of machine is this? if this is Linux have your run glxgears or something similar to prove that you are really getting hardware accelerated 3D from your card? because thats what an order of magnitude difference liek that sounds like to me-- software rendering.

Ona modern video card glxgears should report frame rates of somewhere around 10,000 fps. If you see hundreds, your doing software render.

Please don’t think I’m stupid. I’m working with 3D hardware since the days of voodoo and DX3.

And no, IIRC the demo machine was your personal laptop. Windows.

Off topic: here is the Linux story!

FlyingGuns ranked second in last years java gaming contest. The price has been a PC and a JavaDektopSystem2. 6 month later, the PC has been delivered. 9 month later, I received the JDS2. Had to pay $25 customs/taxes for that $50 software.

First, I had to contact Sun support to make the installer work. Switch to text mode early, switch off ACPI - otherwise the installer just crashed.

Next step … surprise surprise … my PC obviously has no harddrives! Linux/JDS (which is a historic SuSE8.1) and SATA/RAID0? No way. The support asked for cryptic info, so I preferred to buy an IDE disk ($100).

Now, installation started. Surprise surprise … my PC obviously neither has a graphics card nor a monitor. Grmpf. I get a desktop 640x480 in 16 colors. Tried to start mozilla there for www.nvidia.com. Mozilla crashes on that site. Maybe nvidia expects browsers to support at least 17 colors.

Back to windows, google, read … hard stuff. Following some descriptions on howto install NVidia drivers. All of them cryptic of course (install kernel sources, make this make that …). WHERE IS THE SETUP.EXE?? Support tells me to follow the guide for SuSE8.1 (there is no hint otherwise on which Linux JDS is based!). Ok, following this instructions (‘make install’) halts the machine. Completely. Finished. Reset-button.
Desperately I followed instructions for SuSE8.2 … and surprise surprise … I get a 1600x1200 desktop!! Looks nice!
Unfortunately, no 3D hardware support. Gears crashes with something like ‘libGL.so.1. missing’. I installed MESA GL which makes gears run, yet still without hardware.
I looked around a bit, managed to link the supplied NVidia libs … GLX missing! What the fuck?

Now I’m waiting for the answer of the support guys again.

Getting a free JDS can be a very expensive experience…

I cannot honestly recommend JDS for 3D development today.
The back-version kernel is too much of an issue. Hopefully at
some point that will chnage.

And I can’t say any more then that for obvious reasons.

The Sun support guys are really brave: with some special NVidia driver version I have 3D now!

jake2 and wurmonline are really smooth (in fact jake2 is a bit smoother :slight_smile: ).

FlyingGuns starts with 60fps (synced) but after a couple of seconds succeedingly drops down to 10fps. Sigh. I cannot tell wether Linux, Java3D or FlyingGuns is responsible for that…

Does somebody have another link to a webstartable Java3D app at hand?