Collision tagging issue: tags causing scaling?

Fixer · August 9, 2006, 4:25pm

Hi all!

We have observed an odd interaction between the maya2egg tool, the ObjectType egg tag, and the loader. I’ll walk the whole way through, hoping someone can shed some light on what causes what we’re seeing.

We created a box in Maya with a simple texture. When we went to implement collision detection, we decided to use the ‘tube’ object tagging (via the eggObjectFlags.mel script) to encapsulate our boxes. We wanted to preserve the visible geometry, so we added a new tube type, youtube, defined thusly:


egg-object-type-youtube            <Collide> { Tube keep descend }

Applying the tube type to the model worked fine in terms of collision on this and many other models, with one problem: the resulting box is much smaller than it should be. Drawing the collision object shows it is the right size (relative to the original), but the visible geometry has been scaled down.

I cracked open the egg file, and this is what I saw a few lines down:

<Group> necessary_crate {
  <Transform> {
    <Matrix4> {
      2.7182 0 0 0
      0 2.7182 0 0
      0 0 2.7182 0
      -0.000335421 0 -0.00211186 1
    }
  }
  <ObjectType> { youtube }
  <VertexPool> recessary_crateShape.verts {

My modeler swears up-and-down that the transform shown isn’t his doing (though I’m going to have him dump Maya history as soon as he gets a chance to attack this problem again). When he removes the ‘youtube’ tag in Maya and eggs the file again, neither the transform statement nor the tube geometry appear. Additionally, if I manually delete either the transform or the youtube object-type directive from the egg file, the box is the correct size (of course, without the youtube, it doesn’t have its collision shell).

So I’m seeing two weird side-effects to using this tag:

A transform is attached that I don’t think comes from our model (this has yet to be determined)
Removing the youtube object type directive in the egg file—but not the transform—seems to remove the effect of the transform.

Can anyone shed light on these interactios? The more I play with egg files, the less I think I understand

Take care,
Mark

drwr · August 9, 2006, 5:48pm

OK, this is pretty weird. I think there must be two different bugs going on here.

The first one can only be a Maya bug. I can (reasonably confidently) assure you that maya2egg doesn’t treat a transform with any special care when a node has an egg tag vs. when it doesn’t. (There are some special egg tags, like “billboard”, that it does treat as a special case with respect to transforms. But I can promise you that “youtube” isn’t one of these special cases. And in any case, if a node has a transform, it will be output into the egg file.)

It’s just possible that it’s a user error with respect to the command-line options. For instance, if you convert the file as an animated character (-a model), then it will throw away many of the transforms. Are you sure you’re using the same converter options both times?

The second error, which is causing the object to appear to be too small–I’ll bet you a dollar that you have some Python code that is finding a particular node by name, then setting its scale to 1. Try this: load up the model in isolation, for instance using pview, and then see if the object is the right size. I bet you it will be.

When you have the “youtube” object type, it will create a slightly different object hierarchy (because there are now more nodes here–the visible geometry as well as the collision geometry). Panda will optimize this more complicated hierarchy differently than it will a simpler hierarchy with only visible geometry, and the actual transform described in the egg file may end up on a different node. In fact, it’s entirely possible that in the absence of the object flag, the transform may be optimized completely away, since there is not a flag (which would be the key to tell Panda that the transform should not be optimized away).

So: with the “youtube” flag, Panda will preserve the transform, since it has to. But without the “youtube” flag, Panda will apply the transform to the vertices and remove it from the graph, as an optimization, since it can. But then you combine this with Python code that arbitrarily zeroes out the transform. When you zero out a scale of 2.7182, you will make the object smaller by a factor of 1.0 / 2.7182!

David

Fixer · August 9, 2006, 6:02pm

This sounds like a great springboard for further investigation; I’ll work with our modeler to try some sanity-checks on the maya => maya2egg path and see if we can make the issue reproducible in a general sense.

Unfortunately, I’m not doing any explicit scaling. Here is the entirety of my sanity-check code, which I used to compare the two objects:

import direct.directbase.DirectStart
from direct.showbase import DirectObject
from pandac.PandaModules import *
from direct.interval.IntervalGlobal import *
from direct.gui.DirectGui import *
from direct.gui.DirectGuiGlobals import *

loadPrcFile("config.prc") #defines youtube

bounded=loader.loadModel("necessary_crate_model")
unbounded=loader.loadModel("necessary_crate_model_nobounds")

bounded.reparentTo(render)
unbounded.reparentTo(render)
unbounded.setX(2)

bounds=bounded.find("**/+CollisionNode")
bounds.show()

run()

When running this (after a little camera-dragging), I get the following view:

Deleting either the Transform or the ObjectType from necessary_crate_model.egg causes both boxen to be the same size.

We’ll keep hammering at this from our end; if you have any other insight, please let us know. Thank you greatly for the help!

Take care,
Mark[/img]

drwr · August 9, 2006, 6:09pm

Hmm, can you give me a link to your entire egg file?

David

Fixer · August 10, 2006, 2:18pm

Unfortunately, I’m having a bit of difficulty right now getting it somewhere that it can be publicly viewed. However, me and our modeler took a second look at the problem this morning, and here is what we found.

The mysterious scaling transform had been applied by him to the crate model, so it was “legitimate.” What appeared to happen was that when the ‘youtube’ object type was specified, the youtube ‘captured’ the transform without passing it on to the visible geometry when that was created. So the tube capsule was transformed correctly, but the transform wasn’t applied to the visible geometry that had been kept. Hence, the tiny box; it’s actually a box scaled to 1-1-1, while the tube surrounding it picked up the 2.7-2.7-2.7 transform.

The solution was to freeze the transform, forcing Maya to apply it directly to the geometry. Incidentally, {none} also did not exhibit this capturing behavior; the Transform was applied directly to the visible geometry when ‘none’ was used.

I’m wondering if we’ve perhaps stumbled across a bug in either the Tube collider or the interaction of “keep” with Tube. My assumption would be that ‘keep’ should apply whatever transforms it picks up to both the collision it generates and to the original visible geometry. Maybe that isn’t the case in this set of configuration options?

Thank you for all your help on this issue!

Take care,
Mark

drwr · August 10, 2006, 4:27pm

Right, that sounds like a bug in the egg loader. I did not observe this behavior in my own tests, but I think I may have found and fixed this bug previously (and I’m running with the latest CVS version of Panda, of course). If that’s the case, it should be fixed with the next major release of Panda.

David