Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  ASE Loader group support proposal  (Read 2394 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2003-11-30 02:57:54 »

How do you want to see group's implemented?

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 model
getNamedNodes() 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?

Vote away Smiley

Will.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #1 - Posted 2003-11-30 05:58:16 »

Quote
a) Does anybody object to the implementation of GROUP support in the Xith3D ASE Loader?


I think nobody will object. At least not me.

Quote
b) To those who would like GROUP support - does this proposed implementation suit your needs?


I thought abouth GROUP nodes to be named BranchGroups in scenegraph, so then scenegraph combined not only from TGs, but also BranchGroups. But I also have nothing against some convenience methods.

So generally +1.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Jens

Senior Member




Java for games!


« Reply #2 - Posted 2003-11-30 07:21:16 »

I'd like to see GROUP support, of course.  Smiley

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.

Xith3D Getting Started Guide (PDF,HTML,Source)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #3 - Posted 2003-11-30 08:53:12 »

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 discarded
HashMap 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 culling
TransformGroup 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.

Will.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #4 - Posted 2003-11-30 11:41:55 »

Quote
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.

If I am wrong - just forget my comments and treat them as +1 vote.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #5 - Posted 2003-11-30 23:39:22 »

Yuri,

Your English is quite good - I was just a little muddled.  I think I understand what you mean now and that is what I want too.  I'll to do some testing to see more clearly what our choices are.

I really want to find a solution to this as it will make some areas of my program much easier to write and make them more customisable.

Stay tuned...

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #6 - Posted 2003-12-04 22:56:34 »

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_POS 48.2319 18.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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
        *HELPEROBJECT {
                *NODE_NAME "Group01"
                *HELPER_CLASS "Dummy"
                *NODE_TM {
                        *NODE_NAME "Group01"
                        *INHERIT_POS 0 0 0
                        *INHERIT_ROT 0 0 0
                        *INHERIT_SCL 0 0 0
                        *TM_ROW0 1.0000 0.0000  0.0000
                        *TM_ROW1 0.0000 1.0000  0.0000
                        *TM_ROW2 0.0000 0.0000  1.0000
                        *TM_ROW3 -5.7069        1.1255  -0.3690
                       ---> *TM_POS -5.7069 1.1255  -0.3690 <-----
                        *TM_ROTAXIS 0.0000      0.0000  0.0000
                        *TM_ROTANGLE 0.0000
                        *TM_SCALE 1.0000        1.0000  1.0000
                        *TM_SCALEAXIS 0.0000    0.0000  0.0000
                        *TM_SCALEAXISANG 0.0000
                }
                *BOUNDINGBOX_MIN -76.9889       -16.2177        -13.6531
                *BOUNDINGBOX_MAX 65.5750        18.4686 12.9151
        }


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.

Cheers,

Will.

Offline Preston

Senior Member


Medals: 4



« Reply #7 - Posted 2003-12-05 05:28:37 »

Sounds well. :)

It's a bit similar to the architecture of the Lightwave format my import has to battle with.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #8 - Posted 2003-12-05 10:24:10 »

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.

This addition resolves Issue #22.

Tomorrow I am going to work on the pivot stuff mentioned earlier.

Will.

Offline kevglass

JGO Kernel


Medals: 152
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #9 - Posted 2003-12-05 10:30:32 »

Does ASE also support the KeyFramer chunk from the 3DS format?

If you're going to implement the pivot it might be cool to be able to use the keyframes to step through predefined animations aswell...

It might also be nice if we could common up the interfaces between the 3DS loader and the ASE loader since they should support the same functionality.

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2003-12-05 10:55:03 »

I believe it does support animation but I haven't looked into it yet.

A common interface would be nice, how different are your coding methods to David's?

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2003-12-06 03:49:12 »

Just an update for those interested - pivot points have been implemented for geometry now all that remains is pivot point support for the groups Smiley

I'll hopefully post a build tonight so people can test for compatability.

Will.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (24 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (58 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!