Michael Cook’s Place

Bits of Genius in a Sea of Mediocrity

Michael Cook’s Place Random Header Image

Java3D Alpha Gotcha

November 2nd, 2007 · No Comments

I have been working on a little program at my work in my spare time for a while now. Quite a while. It’s a visual display of what one of our system is doing in 3D. For experience and education, I’m writing it with Java3D.

There is one problem that has been stumping me for 6 weeks (I only get to work on this for an hour or two a week, usually). I’ve avoided it some but it was driving me crazy.

The Setup

Java3D has these nice little objects called Interpolators. These let me tell Java3D to handle most all of the animation. In my case, I’m using a PositionPathInterpolator. Just tell it all the points, the time indexes (normalized), and it moves things for me. Saves tons of work. Only one problem… I couldn’t make it work.

The Problem

The symptom was very easy. It didn’t work. The objects didn’t move. Didn’t matter how simple I made it. Just a cube and this, and it wasn’t working. You use an object called an Alpha to tell Java3D how to animate things (timeframe wise). If I set the loopCount to -1, the Alpha would loop constantly, as expected. If I set it to anything else, it wouldn’t move. Didn’t work at 1, 3, 7, 10, etc.

The Solution

The answer was there the whole time (of course) but it was very poorly documented. I looked a couple of times but I was never able to find it. The problem is that the two parameter constructor that I was using is nearly useless. Here is the constructor:

Alpha(int loopCount, long increasingAlphaDuration)

IncreasingAlphaDuration is the amount of time (in milliseconds) that it takes the Alpha object to go from the value 0.0 to 1.0 (it’s full range).

So what’s wrong with that? You can’t use it. You see there is a very important parameter that isn’t included in that constructor. Two of them. These are the TriggerTime and the StartTime. An Alpha starts its work when TriggerTime + StartTime > CurrentTime. The problem here is that the TriggerTime defaults to 0 (it seems), and the StartTime defaults to the system start time (when the computer was booted).

What this means is that if you have an Alpha that is supposed to last 2 minutes, and you want it to start immediately, you won’t see an effect if your computer has been on for more than 2 minutes. Since the StartTime + TriggerTime + increasingAlphaDuration barrier has passed (when the animation would normally end)… the Alpha does nothing.

You can set these two parameters (you only need to set one, really) with standard setter methods. You can also use one of the long constructors (they use 6 or 10 parameters).

Suggestion Sun Won’t Read

I doubt that Sun reads by little blog, especially since I haven’t posted this kind of stuff here before. There are a few ways this could be fixed.

  1. Default StartTime to now - Would work well, but break all backwards compatibility
  2. Add constructor parameter - This would fix it, because it would make the behavior very obvious
  3. Warn people in the documentation - The most obvious of all, you could add a bit to the top of the JavaDoc on the Alpha class that this happens

Any of those would have been greatly appreciated.

Tags: Programming

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

You must log in to post a comment.