Exporting Current Model with new pivot point

#1 The pivot location of the "bounds" object is essentially a location coordinate that Torque uses to position your model in the game (the origin of the pivot point is placed at the current ground level). This is why you want the pivot location to be at your objects feet, if it is moved, you will cause your character to sink or float above the ground (depending on how you move it).

If you are trying to rotate your object you should try to setup (or choose) a node at the characters center of gravity and have the skeletal deformation system linked to that.

Regarding your missing objects, are there any clues in your dump file as to objects that were excluded from exporting? Have you checked your CFG file to see if it's ignoring anything that might be needed for exporting? Are you sure that the original file exported and worked fine before you modified it?

Logan

#2 The relationship of the collision box to the pivot point is completely programatically determined; there's no need for the model to sink into or float above the ground, unless of course you want it to do that. :-)

I'm the guy using the modified model that Greg produced. The change in the pivot point is necessary for our purposes. However, the lack of bip info in the exported model, which causes almost all the animations to fail to register, is very annoying. Does anyone know why the bip nodes would not be exported? He's using the provided dtsScene.cfg, with the max4 exporter downloaded from a link in the documentation.

If anyone has successfully modified the player.max file and re-exported it from max4, could you walk us through the export steps?

#3 Heh... turns out that it's more than just "annoying". There are certain actions -- like impacting the ground at high speed -- that are causing the application to segfault with nonsense values in a TSSequence var, and I'll bet that's because it's assuming that certain animations exist (and in the newly re-exported player model, they don't).

Hope someone can help.

#4 What does the .cfg have on it's never export list? Many of the 'default' ones have Bip01 on the NeverExport list.

#5 It's the config in fps/data/shapes/player. Yes, Bip01 is on the NeverExport list. Since it wasn't followed by a wildcard character, and since I kinda assumed that the export config file provided for the player model would actually work :-), its presence didn't worry me.

But I don't know squat about modelling or exporting. If NeverExport-ing Bip01 also affects all the nodes under it in the hierarchy, that would be bad. Maybe Greg should try deleting it from the config file. Or just commenting out everything in the NeverExport list for now.

Does anyone have a verified-as-functional-for-the-default-player-model dtsScene.cfg that we could look at?

#6 Hmm, well, although that certainly might be worth a try, I don't have high hopes for it. In the exporter code, ShapeMimic::snip is the member function that culls out a node (named nodeMimic), and it sports the following comment:

// get rid of nodeMimic, bring children up to nodeMimic level
    // they will sit between nodeMimic's siblings

So at first glance it looks like NeverExport-ing a node does not get rid of the hierarchy beneath it, if it's working as intended.

#7 Ah, now I understand.

The reason why your animations are not loading is because the base shape (the new DTS you exported) does not have nodes that are in the DSQ files.

If the DSQs contain nodes that are not in the base shape, they will not load. If you open the console in the showtool it will usually tell you which animation failed to load and which node it is choking on (usually).

If I had to guess, I would say that 'collapse transforms' in the exporter parameters rollout is checked. It sounds like you are using the old player model (the segemented mesh one) that would collapse the nodes if this was not unchecked.

You can verify this by looking at the shape heirarchy in the bottom of the dump file. If collapse transforms was checked, then it will collapse the shape down. The only nodes left will be the ones in the always export list if the .cfg you are using.

I don't have that particular .cfg, so you might also have to change one of the parameters in the .cfg file you are using.

If it is in there, make sure

Params::CollapseTransforms

has a - and not a + before it.

If you do this, your shape should export and load all the aniamtions in the showtool. The majority of the movement animations will 'pop' the character up so that his feet are at chest level.

Joe

#8 > The reason why your animations are not loading is
> because the base shape (the new DTS you exported) does
> not have nodes that are in the DSQ files.

Yep.


> If I had to guess, I would say that 'collapse
> transforms' in the exporter parameters rollout is
> checked. It sounds like you are using the old player
> model (the segemented mesh one) that would collapse
> the nodes if this was not unchecked.

Hmm. I think that Greg has tried it both with and without that option enabled, but we'll look again.

BTW if fps/data/shapes/player/player.max is the "old player model", does that mean there's a new player model available somewhere? Do tell. :-) We'd certainly want to give the newer version a try if there is one.

Just FYI, this is fps/data/shapes/player/dtsScene.cfg in its entirety:

AlwaysExport:
eye
cam
mount0
mount1
jetnozzle0

NeverExport:
Bip01
Bip01 L Finger*
Bip01 R Finger*
Dum*
submesh*
Bip01 L Toe*
Bip01 R Toe*
Gun256
case right
guide right
case left
housing left
disc
housing right
sensor
handle_disc
second hand hold
guide left
generator
hideGun256
start01
root 128
energy 128
endcap 128
sensor 128
barrel 128
mountpoint

=Params::T2AutoDetail 250

Anyway it sounds like you have some good info, so I'll see if I can flag Greg back into this thread.

#9 Joel wrote:

"Hmm. I think that Greg has tried it both with and without that option enabled, but we'll look again."
----------

Look again,I am 99% sure that this is the problem.

There is a single mesh player model example (3DSMAX4 only) that comes with the MAX2DTS documentation that can be found here:

www.garagegames.com/docs/torque/tools/max2dts/index.html

This will show how to do a single mesh player (if you want to stay with segmented meshes it won't do you much good).

#10 The only reason we are currently using a segmented mess is that it is the default model that comes with Torque. I did make sure that the collapse transforms box was unchecked but there is obviously either more to it them I'm doing or I'm missing another step somewhere. Here is what I do:

1) Open the default player.max shape in 3ds Max 4
2) Load the exporter
3) Open the Parameters flyout and uncheck Collapse Transforms.
4) Load the .cfg file that comes with Torque (as above in Joels post)
5) Open the Utilities flyout and press Export->Whole Shape.

Seems simple enough but doesn't work :|.

Alc

#11 You don't need to load the .cfg, it uses the .cfg that resides in the directory where the max file is.

I have no idea why it is not working for you.

I just recreated the steps you just went through, and it and it worked fine for me. I moved the bounding box pivot to his chest, re-exported, and it worked.

Checked collapse transforms. Exported fine, loaded with only the jetflare and damage sequences.

Error in the console gives me:

Sequence inport failed, "Bip01 Pelvis not found in base" shape, etc....

Go to your dump file, and look to see what the shape heirarchy is (it is down near the bottom of the file).

If it doesn't show the whole skeleton, then your transforms are getting collapsed out.

Also check at the top of the dump file to make sure it is using the .cfg you thinking is using. If the collapse parameter is set to true in the .cfg that is getting used, it will override the checkbox.

Also, try exporting with collapse transforms unchecked and with the .cfg removed from the directory where the MAX shape resides.

#12 Well....I got it working. It was the .cs file. Had the wrong shape name in the for the baseShape. Ouch that one hurt.

Alc

#13 Cool. I am glad it worked.

For future reference. You can verify the shape structure by reading the dump file.

You can verify the .cs is loading by reading what is written into the console when the shape loads.

A great number of other questions that y'all may have can be answered by reading the documentation at the link I posted above or by reading the exporter FAQ that Logan is working on.

Joe

#14 Wee, the joys of distributed development. Greg sends me a model, I tell him about a problem, then he probably fixes the problem in his version of the model (unknown to us) with that collapse-transform thing but still doesn't see the animations because of his .cs file, meanwhile I'm making suggestions based on the assumption that the first problem is still the problem.

Heh. Thanks for your help, Joe. Onward!

#15 Joe, we seem to still be having some problems. If it wouldn't be too much trouble... for comparison purposes, could you give us a download link to a .dts player model that has had the pivot point raised, along with any associated files (config file, dump file)?

Greg had moved the pivot point up by 1.719 units, which seemed to be a good location. We don't need a pivot point EXACTLY in that spot of course, just about there, as long as you let me know where it is.

If this is easy for you to do, I'd appreciate the favor... if not, no worries, we'll get it eventually. :-)

#16 I can recreate this for you (I didn't save my test).

I am running out for a meeting in a few minutes, so I won't get to it until later.

What is the nature of the problem? If you can fill me in a little more as to what you trying to figure out, I might be able to shed some light on the problem and/or construct a shape file/DTS that will either solve (or help illuminate further) the problem.

Also, I would need to know the process used to raise the players pivot.

Was the bounding box center simply moved up using 'affect pivot only'?

#17 I don't know about the process used to raise the pivot point, sorry. What are the various options and what are their effects?

As for the problem now, well, there are a few problems that I'm seeing when I use the latest version of the model and go to third-person view. One that leaps right out at me is that only the chest, pelvis, thighs, and upper arms of the model are visible. :-) Then if I start running in any direction, I see a couple more oddities:

- The model turns to face 90 degrees to the left of my actual view angle.

- The external view perspective point significantly drops in altitude.

(None of these problems happened with the previous attempt at the model, the one that was lacking animations.)

Now, it's certainly possible that some of these problems have to do with the player code, not the model. Inside player.cc I've adjusted the relation of the collision box to the pivot point, and changed the relative spot compared to the pivot point where the code looks for ground contact when determining where to place footprint decals. I didn't see any other adjustments that I thought needed to be made, but it's quite possible I missed something, as I am not entirely "one with" the animation-related code yet. However it does at least seem odd to me that changes to the pivot point or the collision box could (for example) make the model's head disappear, so I'm thinking there must still be a model problem.


Some random factoids from examining the .dts files themselves:

In a hex editor you can see a series of strings at the end of a .dts file, which appear to be labels for its content.

At the end of the original player.dts model, there's a series of strings beginning with "Detail", then a series of strings mostly beginning with "Bip01", then a series of strings beginning with "Submesh", and finally the names of the animations "Jetflare" and "Damage".

The previous attempt at re-exporting the player model was missing most of the second group of strings, including all those that began with "Bip01". This is what made me think that it was missing certain info necessary to the animations.

The file for this latest attempt, though, contains all the strings from the original player model and a lot more... it looks like this file must include even the nodes that the config file says not to export, like "Dummy06" and "Bip01 L Finger 01". Among the Bip01 strings there are also scattered some Submesh strings that weren't included in the original player file, like Submesh_lhand145. So, it's certainly not missing anything as far as this indicator is concerned; maybe it's got too much of something, overflowing some hardcoded array size when loaded into the app? Dunno.

BTW, for what it's worth, the filesize of the original player.dts model is 92 kB. The first attempt at re-exporting the model with the new pivot point was 141 kB. This latest attempt is 113 kB.

#18 I am assuming that moving the pivot point is the way it was done. There aren't that many other ways to do it, but I just want to be able to re-create the shape as accurately as possible, so I thought I would ask to make sure. Seeing as y'all are having so many problems, I thought it would be safer as we don't overlook something very simple.

One the first problem, are you saying that the shape is dissappeared, or that it is off the top of the screen? I test exported a new shape and the characters head is off the top of the screen.

If this is what you are talking about, then the problem was moving the pivot point. The animations are aware of their offset from the bounds pivot, and since it is now at his chest, it is popping the character up 1.719 meters (the same offset it was from the bounds pivot when the pivot was at the base) That is the way the system works, and is probably just a by-product of what you are trying to do (i.e. moving the pivot point of the player)

Mine does not turn 90%.

This is a side result of not using the .cfg at all. I did a test (re-exported without a .cfg) and I get the same results. (character turned 90 degrees when you run)

The external point of view drops in altitude because it is trying to keep the boundig box kind of centered, and since the character is now elevated by 1.719 meters, he is now outside the top of the box. What you did in code may have made it better or worse than it looks on my machine, which is pretty strange, you are basically looking at his butt centerd in the screen in Third-person

On the DTS models. The first export had the correct nodes (sounds like) the second sounds like they were collapsed out, and the last attempt has ALL the nodes in (exported without a .cfg). It will guarentee that all the nodes are in there. It appears that the Bip01 node has a rotation offset that doesn't match the animations, so it rotates it 90 degress when animated. When put on the never export list, it isn't a problem, but with it in ther, it appears to be causing problems. Strange, but not a big deal, just go back to using the .cfg.

The rotating problem is fixable by using the .cfg to export. Remember to uncheck collapse transofrms. The others sound like the a by-product of moving the pivot point of the bounding box to his chest.

In order to get this to work properly, you are goign to need to re-export all the animations so that the pivot of the bounds is in the same position in the animation sequences so that the characters offset from the bounds node is the same in all the files.

The file size chages can be for a number of reasons, different versions of the exporter, different structure in the file, different things in the shape stucture in the DTS. Fairly normal thing to happen. I would not worry about it unless the file size grows to a couple of MB.

So, I can re-create any of these shapes for you so you can test it, but I just need to know which one you want? I am assuming that you want the one that is as correct as possible. I can do that, but it is stil going to be 'broken'.

Do you mind me asking why you are moving the bounding box pivot?

#19 > One the first problem, are you saying that the shape
> is dissappeared, or that it is off the top of the
> screen?

Parts of the model are gone, missing, vamoosed.

The entire model (what there is of it) is still visible on the screen in third person view. Remember, I've adjusted the relationship of the collision box to the pivot point (moved it down) so that the model will still have its feet touching the ground. From the user's point of view, there should be no visible difference in the model's appearance or behavior as long as it is still running on the ground doing the normal things that one can do in the TGE demo.


> Mine does not turn 90%.

Well, that's good to hear. :-)


> Do you mind me asking why you are moving the bounding
> box pivot?

Not at all.

In our game characters are not restricted to being ground-bound, and once in the air they can be rotated by the user to any orientation.

The problem with the default player model is that the pivot point is, well, the pivot point. :-) This is fine when the only thing that the model does is change yaw angle, as in the TGE demo, but when you can also change the body pitch and roll, the fact that the model is rotating around a point between its feet looks terribly wrong. The rotation axes need to all pass through the center of mass of the model (more or less) instead.

From what I know about the models, which is admittedly very incomplete, it sounded like the thing to do would be to move the model's pivot point. And the initial results seemed to bear that out, with the only problem being that the bip info had not been exported. It's possible of course that this is the wrong approach for some reason that I don't know about yet.

#20 If the parts are missing, they might be outside of the bouning box and the engine has stopped drawing them. This is a guess, but it isn't happening on my machine, and this is probably related to the code you put in.

The animations are refencing their offset from the bounding box they were exported with. Since they are now 1.7 meters higher (their offset from bounds pivot) they are actually popped up. It may not look like it, but if you look at in the showtool, you will see them pop up in the air when you look at each animation individually in the thread control panel.

When I load the shape, the bounding box pivot is by default dropping to the ground. The animations are popping it back up to ground level, so it looks normal, but the boundingbox offset has screwed up the the camera and is exhibiting other weirdness (most noticable in the jump).

In the game, since one of the animations is always is always playing, (and they are all offset) it is not noticable, but the offset is there.

If you need the pivot to be at the characterts center, you are probably going to have to redo the animations so that they also have the new adjusted pivot before these odd behaviors go away.

You are in undiscovered country. I am only speculating what might be happening. I can give you a new shape, but the best thing to do would be to export the shape you have, with the new pivot. make sure you are using the correct config file (it is the one in the directory where the max file is)

Export with collapse transforms off, and to make sure there are no script errors, export to player.dts and use the default player.cs.

Check the dump file to make sure the .cfg was used, and then check (in the showtool) that the proper .cs was used and loaded the animations.

If no config was used, the character will turn 90 degrees, if the standard config was used, and collapse transforms was ON, the animations won't load (check the console to make sure it was trying and failed, choking on the Bip Pelvis node)

If the config file was used and collapse transforms is OFF, then it will export, the animations will load (again check the console) and it shoudl work.

In show, the animations will pop the character up into the air. The file is correctly exported, the popping is a by -product of the pivot adjustment y'all did.

At the moment, I can't think of anyway to fix it except re-exporting (essentially re-doing) the animations with the new pivot point.

Maybe your code can acount for the offset without re-doing all of them, but I would venture to guess that it is likely that such adjustments are going to screw thingsup in strange ways (like making him the headless player)

If you send me your .dts (email it to me) I can take a look and I can export and send you theDTS I exported whichever way you want, but my results should be the same as if you re-export ( I would be happy to do it so you can compare to see if there are differences)