next »

[Marvin Fröhlich]

I have renamed TransformNode (the interface implemented by TransformGroup and View) to Transformable. This named matches much better, what it actually is.

Marvin

[Marvin Fröhlich]

The HIAL events now use event classes instead of many plain parameters. Have a look at InputAdapterRenderLoop about how they are to be used now.

Marvin

[Marvin Fröhlich]

I have moved the bounds system to JAGaToo. Therefore some imports may have changed.

Marvin

[Marvin Fröhlich]

I have modified XPAL's Collision class to work through getters. It is a bit more Java-like and in the same way I could add some convenience getters to get the scaled, inverted or scaled-inverted collision normal. This way a wall-sliding-collision-listener is shrinked down to these lines:

Code:

if (collision.getCollideable2() == collAvatar)
{
    Tuple3f pos = collAvatar.getPosition();
    pos.add( collision.getScaledInvertedNormal() );
    collAvatar.setPosition( pos );
}

Marvin

[Marvin Fröhlich]

I have moved the org.jagatoo.spatial package from JAGaToo to OpenMaLi. I'm very sorry for my stupid decision some weeks ago to move it from xith to JAGaToo. It certainly belongs to a math lib like OpenMaLi. I've also moved Ray3f to OpenMaLi.

This won't effect very most of you. But if it does, you'll get 99% of it fixed by replacing "org.jagatoo.spatial." by "org.openmali.spatial.".

Marvin

['n ddrylliog]

The "Transform" (not Transform3D), now use radians everywhere, instead of degrees.

Please use FastMath.toRad() to convert from degrees to radians and FastMath.toDeg() to convert from radians to degrees.

[Marvin Fröhlich]

The way XPAL's stepping works has changed.

The step() method now takes a long instead of a float, which is the number of microseconds to step.

So you either call:

Code:

world.step( micros );

for each world. Or:

Code:

simEngine.step( micros );

which steps all worlds.

But there's also a much better / more convenient way :

Code:

renderLoop.addUpdatable( simEng );
or
renderLoop.addUpdatable( world );

Which does everything automagically. You don't even have to store the world- or SimulationEngine instance anywhere anymore.

The reason for this change is, that the step-size must depend on the frame-time, but at the same time should not exceed a certain value to guarantee good precision.

To improve precision, you can call:

Code:

world.setMaxStepSize( 500L );

or

Code:

simEngine.setMaxStepSize( 500L );

which is the same, but for all worlds.

Marvin

[Marvin Fröhlich]

I have ported Xith3D's logging system to JAGaToo. And at the same time I've cleaned it up and improved it.

So, if you want to see some logging output, you'll have to register a LogInterface implementation at the LogManager. You can either access the LogManager's singleton instance through LogManager.getInstange() of Log.getLogManager().

A LogInterface implementation has to know a log level and a LogChannel mask. If you don't define anting of that, you'll use LogLevel.Regular and all channels.

Xith3D uses the channel to be retrieved by X3DLog.LOG_CHANNEL and of course JAGaToo's one (JAGTLog.LOG_CHANNEL). If you want to use the logging system for your own game (which I suggest), you should either use the Log class (from jagatoo) to produce logging or write a class similar to X3DLog, which is a shortcut, that always uses a certain LogChannel.

Marvin

[Marvin Fröhlich]

There were two duplicated methods in TransparencyAttributes to set the BlendingMode: set/getTransparenceMode() and set/getMode(). I decided to keep set/getMode().

Marvin

[Marvin Fröhlich]

I had to move the xith3d primitive shapes to the core to commit the JOPS implementation. I took the opportunity to rename the package from org.xith3d.shapes to org.xith3d.scenegraph.primitives, which is a whole lot more intuitive, more correct and more neutral than .shapes or .geometry.

the only thing to do in your projects is to do a simple global text-replace or "org.xith3d.shapes." -> "org.xith3d.scenegraph.primitives.".

Marvin

[Marvin Fröhlich]

I have removed VirtualUniverse and Locale classes, since they weren't (really) used anymore. Should not make a big difference for you.

And I have eliminated to 1:1 relationship between BranchGroup and RenderPass. This makes it possible to attach the same BranchGroup to multiple RenderPasses (with different configs). This is especially useful for quad-viewport-apps (example: org.xith3d.test.ui.QuadViewportTest). (And it was necessary for the group-bound-render-to-texture.) Well, this is not really an API change in a way, that forces you to update your code.

Marvin

[Marvin Fröhlich]

I have ported Xith to OpenMaLi's vecmath2, which is an improved vecmath. It is more java-like, such as it uses getters/setters for all its fields. This allows for tracking changes in the values.

There is no Color4f anymore. Color3f and Color4f have been merged into one class (Colorf). Use the class as if it were a Color3f or Color4f. It is automatically detected, if the color has an alpha value or not. To query, if a certain instance has an alpha value use the hasAlpha() method.

To port your project(s) to the new xith/openmali, you'll have to do the following:

• Do a global text replace of "org.openmali.vecmath." to "org.openmali.vecmath2.".
• Do a global text replace of "Color3f" to "Colorf".
• Do a global text replace of "Color4f" to "Colorf".
• Do a global text replace of "AxisAngle4f" to "AxisAngle3f".
• Do a global text replace of "Quat4f" to "Quaternion4f".

Now some real work begins.

• Change the direct field access to .x, .y, .z and .w to getX(), setX(), etc. (for tuples)
• Change the direct field access to .x, .y, .z and .w to getRed(), setRed(), etc. (for colors)
• Change the direct field access to .x, .y, .z and .w to getA(), setA(), etc. (for quaternions and planes)
• Change the direct field access to .m00, .m01, etc. to m00(), m01(), etc. (for matrices)

When you change the direct field access, you should make use of all the various convenience methods like this:
old:

Code:

vec.x += 1.23f;

new:

Code:

vec.addX( 1.23f );

I have checked each testcase in xith-tk and they all work. Please post in the support forum, if anything is causing problems.

I have some xith-user's projects in my workspace, which I have ported to the new xith/openmali in just a few minutes. So don't be afraid to port .

Marvin

PS: I will update all the documentation the next days.

[Marvin Fröhlich]

I have refactored several classes into new/better packages. If you're using one of them, just press CTRL+SPACE in Eclipse to let it add the new import.

Marvin

[Marvin Fröhlich]

I have merged the xith3d and xith-tk projects into xith3d.

You won't need a xith-tk.jar file anymore. All you need to change, if you're working with SVN, is to not link with the xith-tk project, but with the xith3d project.

xith-tk now contains demos and testcases only. So for running your own project you only need xith3d.

Marvin

[Marvin Fröhlich]

I have changed the default TimingMode of the RenderLoop from MILLISECONDS to MICROSECONDS. This way some animations are a lot smoother, since the full float-precision is used.

The prepareNextFrame() etc. methods and all the relevant ScheduledOperation/Animatable/Interval methods have an additional TimingMode parameter, that tells you, how the gameTime and frameTime are to be interpreted. Use the TimingMode.getMicroseconds(), TimingMode.getSecondsAsFloat(), etc. methods to convert the gameTime and frameTime to what you need.

I have renamed the executeOperation() method to update() and ScheduledOperation now extends Updatable. This a cleaner API design.

AngleInterpolator and DistanceInterpolator both use micros now instead of millis. So be aware of that.

I have updated all the examples in xith-tk to the new API. So have a look at them for reference.

Marvin