Apparent Depth ordering, manual movement

Apr 23, 2010 at 7:34 PM
Edited Apr 23, 2010 at 7:56 PM


I'm using Henge3D (Thanks!) in one of my projects and I'm running into two issues:

1)  This may reflect my ability with 3D / XNA in general, but I'm having trouble attaching textures to models that are physics simulated.  Some models when loaded just appear to "freeze".  Is this a limitation or am I doing something wrong? ...

2) I am moving an object manually by Freezing the object, allowing the user to displace it, then unfreeze it.  This is working great, however, there appears to be some depth ordering issues (what appears to be in front of what).  This is probably not related to manually moving it about, but.. .  The depth order appears to depend on the order they are added to the simulation.  Any Ideas?  (Willing to code, but not sure where to make changes)

<UPDATE>  Using a SpriteBatch disables the depth buffer.  Manually disabling and re-enabling the DepthBuffer fixed issue <2>

Still working on attaching textures...





Apr 23, 2010 at 9:07 PM

I'm a novice at graphics-related stuff (XNA or otherwise) but I'll try my best to help. There's always the chance that it is in fact some kind of bug in the library, but it's hard to imagine how a texture might affect physics. Actually, in one of my earlier demos I had a textured cube (from blender; that took HOURS to figure out) and it seemed to work. In that case, the texture was just part of the model while it was imported. Are you using a different method to attach a texture?

Apr 24, 2010 at 1:45 AM

Thanks for getting back to me!

I've tried two methods of attaching textures:

1) Use an existing model with a texture define in the model, then import the model.

2) Use a plain small_cube model (from the holodeck example) and try to attach a new Texture2D to the cube (Mesh.Effect.Texture = SomeTexture2D)

In the first case, the model just sits there in space, not responding to forces

In the second case, the model just seems to show the mean color or such, but not actually a texture (regardless of the size of the texture. 


This may just take some time for me to figure this out, but if you have successfully attached a texture to a model and applied physics to it, I'd love to know about what you did.

Apr 24, 2010 at 3:21 AM
Edited Apr 24, 2010 at 3:22 AM

My theory for the first case is that the "shape" attribute is being lost when small_cube.fbx is edited in a modeling program. The only one I've used is Blender, and there's a section called "logic properties" or "logic attributes" or something similar (been a while since I've had it installed). If the "shape" attribute is missing, it will assume that the physics object is a tri-mesh, instead of a polyhedron. Physics meshes always have infinite mass and are immovable since they're strictly for environment.

In the next release, there will be a setting on RigidBodyModelProcessor called DefaultShape that will allow you to indicate that the meshes in the model should be treated as polyhedra, regardless of whether the "shape" attribute is present. I suspect that this may fix the problem if you aren't able to set the attribute in your modeling program. One way to test this theory would be to open small_cube.fbx and make some change unrelated to textures, save it, and import it again. If it still won't move, it's likely that the attribute is lost.

For the second case, Henge3D doesn't modify any of the graphical rendering properties of a mesh (in fact, it doesn't even use the Model or Mesh objects at all; it has its own internal structures that are built by the pipeline). It might be best to try the Creator's Club forums to see if someone can help you with applying textures at runtime. The Holodeck app uses a tiled texture to create the yellow squares on the walls, so maybe you can take a look at the properties it sets. It's been too long since I've messed with BasicEffect and stuff, so I've forgotten a lot.


Apr 27, 2010 at 12:53 AM

Alright, thank you for the info!  I really appreciate the advice and the 3D physics you dev'ed.