4 lines vs 12 lines with the original version !! And much clearer.. Of course it breaks a bit of API strict definitions but It could be really convenient. If there's no objection I may implement it.

Note about performances : implementation requires that Transform3D contains a "TransformGroup tg = null" field. This doesn't consume more memory as long as tg equals null, right ? And it would lazy-create it only when needed

Note about bugs.. If you call addChild(translate) two times it would fail. So the solution is to catch the IllegalScenegraphOperationException in the addChild(Transform3D t) method and to call the transform3d.getNewTG() method, which instanciate a new TransformGroup.. and then we would need a Vector<TransformGroup> in the Transform3D class

Then when you would call something like rotXYZ(), setTranslation() or setScale(), the transform3D would update the TransformGroup (transformGroup.setTransform(this)) automagically so there are no more surprises..

Rather often you have to update the transforms of your models (for many parts of the games that aren't static) to move things around.Usually this means having transform nodes as instance variables of "game objects" to keep a convenient access on them.

Rather often you have to update the transforms of your models (for many parts of the games that aren't static) to move things around.Usually this means having transform nodes as instance variables of "game objects" to keep a convenient access on them.

Every method would return the same StaticModel, and allow for compact chained commands.

That way the API remains compatible, and we have a nice "core" utility for initializing simple models (that can be extended to include transforms as well)

What do you think ?

Lilian

OK for the StaticModel thing, but my idea :- let the transform groups visible : you can not use addChild(Transform3D t) and let the Vector<TransformGroup> to null- works too for dynamic thingies : just keep references like you did with TransformGroup.. the thing is you don't need to recreate Transform3D each time (object creation/destruction is waste of time).So both would be good.

I'm very for code compaction in the case of using TransformGroug/Transform3D.

How about a method to rotate/scale without loosing translation/scaling, since it can be done in one transformationmatrix.[/li]And I support the idea to link a Transform3D in the other direction with it's TransformGroup to save code lines like "tg.setTranslation(t)".

And of course an overloaded method with a boolean flag "setToZero" for each of the other translate/rotate/scale methods indicating if the translation/rotation/scaling is lost with this method (rotatin deletes translation and scaling).

I'm very for code compaction in the case of using TransformGroug/Transform3D.

How about a method to rotate/scale without loosing translation/scaling, since it can be done in one transformationmatrix.[/li]And I support the idea to link a Transform3D in the other direction with it's TransformGroup to save code lines like "tg.setTranslation(t)".

And of course an overloaded method with a boolean flag "setToZero" for each of the other translate/rotate/scale methods indicating if the translation/rotation/scaling is lost with this method (rotatin deletes translation and scaling).

Hmm... Good question. I think (scale->rotate->translate) is the most common order in use, so that only the group itself is scaled by some factor, then rotated around its own axis and finally all this is simply translated.

But maybe you could tell the order by an (optional) parameter in a Transform3D-contructor with a default of (scale->rotate->translate).

Seems a bit complicated.. I prefer the idea of a StaticModel, like arne suggested.

I don't think these two ideas rule each others out. I understand this StaticModel thing the way, that it is for transform initialization. But combined with my idea you could dynamically change the scale, translation and rotation on one object without affecting the others and control the transform order.

And I don't think it is really complicated. It will be more code in the Transform3D class than there is now, of course. But Bor the user of this class it will be quite simple.

Seems a bit complicated.. I prefer the idea of a StaticModel, like arne suggested.

I don't think these two ideas rule each others out. I understand this StaticModel thing the way, that it is for transform initialization. But combined with my idea you could dynamically change the scale, translation and rotation on one object without affecting the others and control the transform order.

And I don't think it is really complicated. It will be more code in the Transform3D class than there is now, of course. But Bor the user of this class it will be quite simple.

Maybe it's OK, but I think there are already many many methods in the Transform3D class it would be useful to review them..

Maybe it's OK, but I think there are already many many methods in the Transform3D class it would be useful to review them..

Hmm... OK, seems like most od these methods are already there. So my only two suggestion that remain are, to make most methods not final to allow effective extensions. And to add some constructors that mirror the set(...) methods that exist in this class.

Why don't you hide the "man in the middle" class that is Transform3D? The Xith3d scenegraph as a lot of "middle-man" classes that are allways present in the code (an heritage of java3d) but most of the time we don't need them to be there and it's not just TransformGroup/Transform3D but thats another subject.

I this this would have been nive in the beginning of Xith3D. Now it would be nice as an addition, because it would brake several existing Xith3D games out there. This "objTranslate.setTranslation(new Vector3f(-2f,-5f,0f));" thing (and all the other methods taken from Transform3D) would just create a Transform3D instance in the TransformGroup if it doesn't exist and set the translation on it.

Watch the setRotation(Matrix3f), setTranslation(Vector3f), setScale(float) and set(Quat4f, Vector3f, float) methods of Transform3D. They are doing what you want. Of course they would have to be copied to the TransformGroup class to fulfill your plan.

This seems to be more complicated, but it is just more flexiple. If you want to add a scale you couldn't use your method. And it would maybe blow up the already large inferface.

I suggested earlier to add a "scale(float)" method, which would do exactly what your setScale(float) method does. But I accepted, that setScale(getScale()*s) is more flexible and not that much shorter.

@Qudus : the "nive" word doesn't exist and "brake" is spelled "break" Sorry for late english lessons

So Qudus is right, just hiding the Transform3D class would break compatibility with existing games.BUT kevglass pointed out that "Xith3D guys are always afraid to lose phantom users by breaking backward compatibility.. It's not even 1.0, so API Changes are to be expected".. And I agree with him...

*However*, it happens that phantom exists, phantom users at least.. So it's not a good idea..

I already did something about improving TransformGroup/Transform3D, it's called... Transform ! It's the org.xith3d.scenegraph.Transform class, which you can find browsing online the toolkit CVS...

BUT it's not sufficient at all and it was in the beginning just intended to permit to transform objects in the constructor (hence the Transform-kind enum)..What would be fine (and I'm all ready to do that) is (just picking ideas everywhere) :- To modify the existing org.xith3d.scenegraph.Transform class to suit our, i-want-useability users , needs- To decide that translations are defined by Point3f- To decide that rotations are defined wether by Vector3f, wether by Quat4f, wether by AxisAngle4f- To decide that scale is defined by a Tuple3fWhich would permit us to provides different constructors :

1

newTransform(Point3ftranslation);

1

newTransform(Quat4f/Vector3f/AxisAngle4frotation);

1

newTransform(Tuple3fscale);

(maybe there's a conflict between translation and scale, in which case we should provide constructors with - 3 floats for x-scale, y-scale, z-scale and - 1 global float for scale)- To add setTranslation/Rotation/Scale methods- To add addTranslation/RotationScale methods- To add addRotationX, addRotationY, addRotationZ methods

setRotationPart() method seems just impossible to do to me.. in any case you would end up keeping 3 objects (one for translation, one for rotation, one for scale) and doing the - matrix initialization with translation - multiply with a rotation matrix - multiply with a scale matrix and even you don't know if its the right order...With the solution I suggest you could do :

And, last idea but not least :- Provide method like transform(Point3f p) - returns Point3f which transforms a point by the current transformation..

That would make the Transform class useful not only for the scenegraph but for the whole game.. I remember when I was younger I spent time to learn how rotations in 2D-space worked.. I finally found out the sin(), cos() functions were actually useful.. If Transform would have permitted me to do :

1 2 3 4 5

Point3fmyHeroPosition;// I handle the keyboard input and find out there's a "myHeroDisplacement" displacement to apply// and a "myHeroAngleDelta" angle to change by(Transformtrans = newTransform()).setTranslation(myHeroDisplacement).addRotation(0f, 0f, myHeroAngleDelta);trans.transform(myHeroPosition);

Note 1 : of course we should also provide Transform.transform(Point3f origin, Point3f result) vecmath-like methodsNote 2 : we could have instead of the setTranslation/Rotation... and addTranslation... methods have a identity() one and just translate(), rotate() and scale() ones. That would be just as wellNote 3 : cascaded calls imply that setTranslation()/translate() methods return the org.xith3d.scenegraph.Transform object.

first of all I think, it's not so important what constructors we will supply, because a Quad4f can always be transformed into a Matrix3f...no for performance it's more important what kind of structure we want to keep internally (for rotation, translation, scale). Options would be:

Matrix4f (like in Transform3D)

Vector3f (translation)- Matrix3f- Quad4f - Scaling would have to be done by another Vector3f (for non uniform scales - e.g. scaling only along the X-Axis)

a Vector3f for rotation is next to useless, because one can't keep all rotation-information in it. As a constructor argument this would be nice.

The problem by using matrices is, that getting the scale is not an easy thing (because it doesn't need to be saved outside the matrix), but on the other hand multiplying two Matrices (e.g. when applying a Transform on top of another) is very easy instead of doing that whith everything saved seperately.

And one thing, which I think is very important. With our datatypes we should as often as possible try to accept Tuple3f, because sometimes, the methods of Vector3f are also needed for a Point3f, so this would mean only stupid object creation.So because of this problem it really might be wise to have something like Transform3D, but not as a class (which is actually only imitating Matrix4f) but as an Interface, so the most speedy version can be used for each different situation.

So because of this problem it really might be wise to have something like Transform3D, but not as a class (which is actually only imitating Matrix4f) but as an Interface, so the most speedy version can be used for each different situation.

Yes, this is really cool. But for convenience, there should be some ...Impl classes for the most common implementations either in the tk or in the core.

I have to say that im looking at the Xith3d engine code at the moment to know how im going to build my own engine. Im probably going to change everything including the vecmath api that is a little confusing for me (the method naming) and doesn't support much about nio buffers. I also want to make the render process more independent of the scenegraph and the engine sheduler and task manager more independent of the renderer (that is the renderer is not the engine controller). So im planning to change everything however i understand if you want to keep it backwards compatible. I think this is possible without removing any methods from the older classes.

So to keep backward compatibility my revised sugestion would be:

- Create a new class called Transform and expand it with a new hierarchy of transformations.

I have to say that im looking at the Xith3d engine code at the moment to know how im going to build my own engine. Im probably going to change everything including the vecmath api that is a little confusing for me (the method naming) and doesn't support much about nio buffers. I also want to make the render process more independent of the scenegraph and the engine sheduler and task manager more independent of the renderer (that is the renderer is not the engine controller). So im planning to change everything however i understand if you want to keep it backwards compatible. I think this is possible without removing any methods from the older classes.

Do you mean you want to adapt the Xith3D engine to your needs (=contribute to it) or do a separate project ?

If there's too much issue with backward compatibility you can do a fork (Xith 2 ?) and I'd be happy to join. BUT that's just an idea probably even not good..

Do you mean you want to adapt the Xith3D engine to your needs (=contribute to it) or do a separate project ?

If there's too much issue with backward compatibility you can do a fork (Xith 2 ?) and I'd be happy to join. BUT that's just an idea probably even not good..

I haven't commited to any design yet. Im mostly trying to learn how Xith3d works in deep and then do my own engine with the most flexible design. My engine is planed to be open source and flexible enough for most games including complex crpgs with their own unique char systems. Im also building some free pd content (models and textures) that can be used by anyone for a generic phantasy seting so my time is a bit divided by moding and coding. I can post something here when i have it. At the moment im changing vecmath tuple class completely. I will post my ideas in another thread in these forums.

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