In my code, I am currently animating objects by using TransformGroup trees (many of these objects are Tanks, and other mechanical devices). I.e. I have the tank turret, which has it's own TG, and belongs to a TG of the Turret and the Hull. This way the turret can rotate by itself but when the Hull moves, it goes with it.

Now currently, I build my tree from the getNamedNodes method (which is why I added that method) but I would like to be able to have tree building done automatically by using the groups.

So we've already got (method of AseFile):getModel() which gets the whole modelgetNamedNodes() which gets a Hashtable of all named nodes

I propose:TransformGroup getTransformGroupTree() which would return the entire tree of groups. Note it's possible to have two roots to this tree (in the model) which would both be in the one root TG. To get around that problem, we could also have a method such as:Hashmap getGroups() which would return all branches in the tree, ie. it would be possible to have two unconnected trees in the one ASEFile.

Current methods of ASEFile would not change (ie. these changes are fully backward compatible).

I am volunteering to implement these proposed changes.

My questions are:a) Does anybody object to the implementation of GROUP support in the Xith3D ASE Loader?b) To those who would like GROUP support - does this proposed implementation suit your needs?

One question: Are Ase-GROUPs always equivalent to TransformGroups in the scenegraph?

Some thoughts: getModel() should return the whole scenegraph of the model, which means it should use the GROUPs to add additional TransformGroups. This implies that the two additional methods, you proposed, are really only convenience methods. Usually you will use these methods to directly access a TransfromGroup (for instance a group "turret" for the turret, the main gun and the hatch), that's why I think a method like getNamedGroups() may be good.

Yuri - I'm not sure if I am reading you correctly, but are you suggesting having support for both a BranchGroup tree and TransformGroup tree?

The uses I see for a tree of BranchGroups (which I hadn't thought about until now) is that one could detach and reattach the branches of the tree - maybe used in some optimisation method. Is that how you see it? Of course this can also be done with a TG tree as well but if you don't need to transform the branches then a BG would be fine.

the getGroups method probably should return a HashMap of BranchGroups I guess - allowing someone to construct their own tree out of the branches.

Jens - Since GROUP is currently not supported - I guess your proposed idea wouldn't affect any legacy code (because currently legacy ASE files can NOT contain GROUP objects and work properly). But I now think that the answer is "No", GROUP's aren't always meant to be TG's - it is only one use of them.

Taking into account these comments what do you think of a slightly revised spec?

getModel() returns a flat BranchGroup (as it does currently) with the exception that all Nodes in GROUP's which were previously just ignored are present. This shouldn't break legacy code.getNamedNodes() Unchanged except that as for getModel - there will be also Nodes which were previously discardedHashMap getNamedGroups() returns a HashMap of all named groups (as BranchGroup nodes). Note: This HashMap will contain the root group(s) and recursivly their subgroups (if any).BranchGroup getBranchGroupTree() returns BranchGroup tree - can be used much the same as getModel() except it's in a tree structure so it can also be used for cullingTransformGroup getTransformGroupTree() as for getBranchGroupTree except they are TransformGroups which is handy for animation.

Ultimately the changes are that nodes previously discarded due to them being in GROUP objects will now be included in existing methods, and there will be several additional convenience methods to help maintain the group structure from the model into the scenegraph.

I'm not sure if I am reading you correctly, but are you suggesting having support for both a BranchGroup tree and TransformGroup tree?

Will, sorry for my English - it's not good enough...

I am not so familiar with ASE internals and what I was guessing is that there are objects with some positioning info associated (so the are in TGs) and groups are only for logical grouping. If so, then it seems to be logical to place everything in the same tree - I mean both BGs and TGs - and provide some convenience methods to access them separately.

I will be working on coding this tonight, I have already done some digging into the well documented *cough* ASE format regarding pivot points.

My use case is as follows. Essentially I am using fairly basic animation based on joints. The classic example of this is a human figure - with the arms attached to the body, and the legs etc.

Currently the ASE loader just loads in all the geometry relative to the origin. For example, if you have a box at (10,10,0) in your scene, it will be loaded in at (10,10,0). Attempts to rotate that box will result in it orbiting around the origin instead of rotating in place.

What I wish to do is load the box in relative to _its pivot point_ which is normally the center of the box or an arbitrary pivot point set in MAX, then translate the box to (10,10,0). This way if you rotate the parent TG - it orbits, but if you rotate the child TG, it rotates in place - what we want.

Fortunately the ASE format supports this. I managed to find the attribute (*TG_POS) and it is used like so (example):

1

*TM_POS48.231918.4686 -0.3690

That indicates that the model's pivot is at (48,18,0). This is currently ignored by the ase loader however.

To achieve the desired behaviour using the current loader you would need to have all your "limbs" in separate ASE files - all positioned relative to the origin to the get your desired pivot point.

Adding this support in is not trivial - it changes the BranchGroup that the getModel() method would return. Instead of the BranchGroup simply containing the geometry it would need to contain some TG's so that everything is in it's correct place. The only way around it would be to convert the Geometry in the TG's to the branchgroup but I'd rather avoid having to do that if possible.

Will anyone mind if the BranchGroup that they currently get using hte getModel() method has a few child TG's in it? provided that the resultant BranchGroup appearance wise is essentially unchanged.

Now has nothing to do with groups. They are slightly more tricky pivot wise. As there are no attributes to the *GROUP node, but the group's pivot _can_ be exported as a helper object. This looks like so:

NB. To export the helper objects you must have that ticked - this is currently _not_ the default setting as recommended by the GSG. Indeed I was quite lucky to have stumbled upon it.

Each object in the group retains it's original TM_POS - therefore if the concept of groups isn't implemented nothing would change. I however would like to implement groups which was the original purpose of this thread -but now I would like correct relative translations as well. As such, I will be adding support for the *HELPEROBJECT as well.

I shall illustrate an example using a human.

The human has a body. Attached to it are two legs and two arms (due to an unfortunate accident the head and other body parts are missing). The arms have hands, and the Hands have fingers.

The TG tree is like so:

1 2 3 4

Body___Arm_____Hand_______Fingers

In MAX and the ASE file, the fingers and palm would be grouped together into the Hand, which would be grouped with the arm and finally the body.

Using getNamedNodes, it will (if I make those changes) be possible to waggle the fingers. Using getNamedGroups, it will be possible to move the hand at the wrist or the arm or the entire model.

Before I charge ahead - are their any suggestions or comments regarding this idea?

If there is strong objection to these modifications in the current ASE loader I can fork the code - but I'd rather not do that and I can't see how anyone would be disadvantaged by the changes.

Needless to say, I am not just going to merrily commit my changes - I shall post the modified code which people can test with their current code - and I'll do up a few test cases. Once there are no issues then in it will go.

Stage one is complete and in CVS. The ASE loader now supports *GROUP nodes (and the *HELPEROBJECT if it is a child of a *GROUP).

You MUST export the helper objects form max if your group is to be named (The Ase loader doesn't currently read the name of the group from the *GROUP line). In the future this node will also be used to get transform data.

A new object, AseGroup which extends AseGeom has been created. It overrides two methods, getShape which will return a TransformGroup containing all Child geometry and groups, and parse which can read *HELPEROBJECT nodes as well as child groups.

Small changes (five lines) were also made to AseFile to add *GROUP support and AseNode to tweak the debug flag.

All changes are totally backward compatable So long as your object doesn't have any *GROUPS you should notice absolutally no change. The only reason for problems would be if you previously had *GROUP nodes which wern't displaying but now are (and you don't want them there). The answer to this is simple - just delete the geom data.

A very simple test, Xith3DAseGroupTest has been created to demonstrate this patch.

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