Up until now I've been using 3D models from the XNA samples as placeholders in my game but now I want to create my own models.

So as a test I've created a simple0 ball (sphere) which is approximately the same size as the asteroid placeholder model I had been usign up until this point. The problem though is that the radius of the BoundingSphere returned by m_Model.Meshes[0].BoundingSphere.Radius for my ball is compeltely wrong.

For the asteroid the radius I get is 1525.52136, but for the ball its 4.00001

Any idea why the radii are some different even though the models are the same size (give or take 10% max)?

Is the BoundingSphere radius actually calculated by XNA, or is it stored in the X file?

Thanks for your help
Ben

Hmmm, ok I might have an idea why this is happening but I still don't know how to fix it.

Basically, if I look in the X file for the asteroid the vertex co-ords a roughly in the range -1500 to +1500, but in the X file for the ball the co-ords are roughly in the range -4 to +4 even though in Mod Tool I resized the ball to be the same size as the asteroid and indeed in the game they appear the same size.

I notice that at the top of the ball X file is the following:


So what I think has happened is that when I resized the Ball in the editor, instead of actually changing the vertex information, it kept the vertex info as it was and stored a tranformation (Scaling) matrix along with the object so that it would be scaled to the size I wanted.

Whilst the above seems to work for displaying the ball (As its shown in the correct scaled size), the XNA BoundingSphere routine seems to just look at the raw vertex info and doesn't apply the scaling to it.

So, does anyone know how to fix this? Ideally by getting the vertex info in the X file to match the final co-ords without requiring a transform to be applied, or by getting XNA to calc the BoundingSphere correctly?

Thanks for you help
Ben

The bounding sphere (like the vertex position data) is in the local object space coordinate system of whichever mesh it refers to. If your mesh has a non-identity transform on it, you must apply that transform if you want to move the bounding sphere into world space (the same as how you have to include the model bone matrices when you draw the object).

You can use BoundingSphere.Transform to compute the transformed bounds.

Thanks Shawn,

The problem is that my vertex data doesn't actually seem to change at all if you scale the object (In Mod Tool). Instead the vertex data values remain exactly the same and a transform matrix is stored int he X file to scale the vertex data accordingly.

Thats not what I want... if I scale my ball in Mod Tool then I want the vertex information itself to scale.

I guess this has become more of a Mod Tool question that an XNA question.

Thanks
Ben

Most modelling packages will have some kind of "flatten transforms" option in their UI. I'm not familiar with XSI but I'd be surprised if it didn't have something along those lines.

I'm not sure how good an idea it would be to rely on this, though. If your game code assumes the transforms will always be identities, it's going to be quite limited as to what different models you can use with it, and you'll have strange problems if you don't construct your models in a very specific way to make sure this is always valid. It will be a lot more robust if you write your game code to deal with arbitrary transforms, so it can work correctly no matter how the model was constructed.

If you don't want to do that at runtime, you can also flatten transforms in the content pipeline.

Thanks again Shawn, although I do have to admit that you lost me there a bit. I'm not sure what the problem is with constructing the objects in the correct size in the modelling package so that they don't need to be scaled prior to rendering in my XNA project.

Thanks
Ben

In most modelling packages and 3D file formats, the position of an object is a combination of the raw vertex position values plus all the transforms that have been applied to those vertices. The transforms are stored separately to the model data, and when you move an object in the tool, that will usually just affect the transform and leave the vertex data unchanged.

If you write your game code to assume the transform will always be identity and just use the vertex data, this will only work for models where the transform is indeed identity. That is going to be fragile, because it will be easy to make files which look fine in the modelling program, but don't work in your game, because the game is only using part of the full set of data in the 3D model file.

If you want to make a robust game that can handle any valid model, you need to take into account all the data in the 3D file, and not just ignore an important part of it. You could do this at runtime, or inside your content processor. Or you could just decide to ignore the transforms, but then you will be unable to handle many valid 3D model files.

Thanks for the explaination Shawn,

I didn't realise 3D models were stored like that. I assumed it was just like with 2D graphics... i.e. if I open an 800x600 JPEG and resize it to 400x300 and save it, I wouldn't expect the saved file to still contain the original 800x600 data and a value saying that the image should be scaled down by 50%. :)

The issue with storing the 3D graphics with a non-identity transform is that you have to waste prcoessing time transforming it to the right size. I guess this isn't too bad as a one off hit at load time though.

Thanks again
Ben

Ben:

The issue with storing the 3D graphics with a non-identity transform is that you have to waste prcoessing time transforming it to the right size. I guess this isn't too bad as a one off hit at load time though.

If you do this in the content processor like in the blog post I linked above, there would be no runtime or load time hit: you can flatten out the transforms while building your content.

Often, though, it's actually useful to have this data at runtime (which is why we don't flatten it by default). For instance in a complex model with joints and pivots it can be important to have each piece in a different local coordinate system.

In practice the overhead of handling this at runtime is vanishingly small, because all 3D models must already have a transform attached to them to position them in the world (you can't draw or collide against an object correctly if you ignore it's current position and which way it is facing, after all!). Thanks to the magic of matrix math, you can just pre-multiply the bone transform in with that object transform matrix, after which your actual collision or drawing code doesn't need to change at all.