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?)

To win one hundred victories, in one hundred battles, is not the acme of skill. To subdue the enemy without fighting is the acme of skill.

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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

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.

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.

rved [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.

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?

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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?

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)

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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 f**k?

Okay well teh good news is it runs fine with the freely downloadableLinux resource bundle.

The bad news is that you need to go to FilePlanet or FileShack for that, which means eaither paying them or wiating in lien to use theirfree servers.

The seconds pecie of bad news is that *compressed* that is a 1.18GB download :/

I havent tried it with the demo because I cant find a Linux demo, only windows, and its really a pain for me to get Windows stuff over to Linux.

ANyway if that 1.18GB dl isnt a show stopepr for you I can make th rest of what yo uneed and ship it to you. if it IS a show stopepr then your going to hgave tow ait for a tiem weh I cn boot over to Windwos, install the demo, then boot back and copy the info over to Linux.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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().

After playing around a little, I settled with using Viev.setMinimumFrameTime(33) and implementing a WakeupOnElapsedFrames(0) behavior as my main loop timer ... no other system timer calls if possible (screws things up again). I'm running my odejava physics simulation at 30fps, so no visuals get lost anyway and there's enough time even for slower systems to keep up. Using WakeupOnElapsedTime caused stuttering and terrible hickups while operating swing components.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org