Bug with TVMesh->GetBoundingBox()

[sybixsus]

TVMesh->GetBoundingBox seems to be incapable of returning small values. It's as if the results are being rounded up to the nearest unit.

For example, with a very small mesh, it reports the min and max boundings as :

Min: -0.5,0,-0.5
Max: 0.5,0,0.5

This is just wrong. The mesh is considerably smaller than 1.0 wide and 1.0 deep and it is most certainly not 0 tall. That would make it completely flat and square and it's nothing like that shape. It *is* much smaller in the y dimension than in other dimensions, and I believe that the two larger dimensions are being rounded up and the lowest dimension, the y axis, is being rounded down to zero.

[Hypnotron]

there's almost certainly a bug in your code here.  I suggest you step through it and monitor the values of the bounding volume and see when it is exactly that they are turning from bad to good.

[sybixsus]

Monitor what? I don't keep the values. I get them, I display them, they're wrong. If I was doing anything bizarre to the mesh, it wouldn't be displayed correctly, and it is.

[Hypnotron]

maybe you should post some code or the mesh you are simply loading and immediately checking the bounding volume of and finding the values to be wrong.

I use tv's bounding volumes extensively and with the possible exception of minimeshes which I havent gotten back around to verifying just yet, they work fine for actors and meshes.

[jviper]

I can verify that the boundings do work, because I wrote a system (and I did not have to keep trak of anything) to not only get the boundingbox , but set the bounding box explicitly. I was able to set the boundingbox, and verify that the values I was getting out were close to the values I was getting out. I was able to do the same with the boundingsphere.

Now, I have a question: do you call computeboundings before you called getboundingbox? I'm thinking you should do it if not everytime you make a change to your mesh, but everytime before you call your getboundingbox/getboundingsphere. Perhaps that will help.

[sybixsus]

If the boundings didn't work at all, ever, then I'm quite sure it would have been found before now. The fact that they work most of the time doesn't really help me though. I'm posting what I know in the hope that it rings a bell with someone else and we can get somewhere, or that someone knows what would make bounding boxes go wrong, and that can get us somewhere. It isn't actually a showstopper for me, I can code around this quite easily by writing my own. I just thought I should report it now because I won't want to ( and may not be able to ) come back and experiment with it once I've coded around it.

I have about 5MB of source, so I can't imagine asking Sylvain or anyone else to filter through that is going to achieve anything. The meshes aren't mine to share although I could try creating a similarly sized mesh and see if it affects that too.

Yes, I always call ComputeBoundings() immediately before GetBoundingBox(). I'm pretty sure I don't do anything that requires it ( it works fine on bigger objects and actors ) but it was the first thing I did when I suspected something was wrong.

[jviper]

How about SetMeshCenter(0, 0, 0)?   

[sybixsus]

Well I don't want to celebrate too soon in case I've made a mistake but at first glance, if I add in SetMeshCenter(0,0,0) before ComputeBoundings() it seems to be reporting the correct bounding box. I'll have to get the other computer fired up and run 3dsmax to be 100% sure, but it looks much better.

I guess now the question is what does SetMeshCenter do and is it going to cause me any other problems? I'm thinking particularly because I was very careful to export some meshes such that they are not centered as I want to align them with other objects.

[jviper]

Yeah, it was somthing I noticed in my BoundingBox property code, and didn't renember why it was there until now. Go figure.

By the way, this SetMeshCenter is supposed to transpose all your verticies in local space so that the point where it rotates about changes. But it's tranposition (relative), so called SetMeshCenter(0,0,0) should do nothing, or so we thought. But the function is primarily used to change where your mesh rotates about. Now as  to why it works, no clue. That kind of doesn't make sense to me and based on my knowledge, I'd say it's a bug. There must be somthing that gets done when calling this function that the computeboundings function is simply missing.

[EagleEye]

Honestly, my first guess as to the nature of the problem is that the values you're having the bounding box size go in to is not a floating point data type, thus the rounding.

Don't use Ints, use Single... If you are using a function call to return the "get bounding box" values, make sure the function type is a floating point type, not an integer.

This is why posting the code that is generating the problem is usually a good idea, so we can knock out these kinds of possibilities quickly.

[sybixsus]

Javin: Thanks for the clarification on SetMeshCenter(). I was hoping you were going to tell me that the values were relative, and you did, so hopefully it won't change anything. Indeed it's an odd behaviour, but hopefully it won't present me with any further problems. I'll leave this thread here and let Sylvain or DarqShadow decide whether the occasional need to call SetMeshCenter for boundingboxes to update warrants any changes to the engine. Thanks again for the solution to this.

EagleEye: You could have knocked out these kinds of possibilities by realizing that 0.5 is not an integer value

[jviper]

I think he meant what you use as the ByRef argument (since the function uses ByRef to return the values)