# correct me if im wrong...

This topic is 4674 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

if((avg.x >= BoundingBox.min[0]) && (avg.x <= BoundingBox.max[0]))
if((avg.y >= BoundingBox.min[1]) && (avg.y <= BoundingBox.max[1]))
if((avg.z >= BoundingBox.min[2]) && (avg.z <= BoundingBox.max[2]))

...but lets say the point is named "avg" and it passes all of these tests it should be within the boundaries of min and max right?

##### Share on other sites
Yes. Axis-aligned bounding box.

##### Share on other sites
I take it you are having trouble with it?

Perhaps you need to consider any translation ie move the bounding box with the object it bounds?

##### Share on other sites
FYI:
Indexing x,y, and z values can get you into trouble. I'm particularly refering to .min[0] and .max[0]. You can run into some nasty bugs that will take you forever to find. Heres some of the stuff i've run into :)

- indexing inconsistency
You can accidentily do something to the effect of:
min[0] = 0.0f;min[2] = 0.0f;min[3] = 0.0f;

You can easily notice the problem when the code is on its own. However, when its embeaded within a large piece of code finding it becomes a lot harder. The main reason is because the code is perfectly legal. Distorted values or odd logic are about the only indications of error. In some cases you will get a buffer overflow (ie illegal operation), but dont count on it.

- buffer overflow
Lets say, for example, you decide your going to initially have x,y,z and later decide to add q,r,s,t. That means you will have elements 0 - 6. Then you later decide that you dont want q,r,s,t. That means that you have 4 index values in your code which shouldnt be there. In a worst case senario the program crashes because it attempts to access memory that is not allocated (ie vertex[5] doesnt exist). If it is allocated the program will continue normally using whatever value is there. In either case, the indices need to be removed. The problem is, the syntax is perfectly legal, so you really have no effective means of hunting them down other than looking through lines and lines of code.

- uninterpreable code
Maintaining code that uses indices is particularly difficult because you have to see the context the indices are used, which is sometimes not possible. A good example of this type of problem is code like this:
// 0 = min_x// 1 = max_x// 2 = min_y// 3 = max_y// 4 = min_z// 5 = max_zfloat bounding_box[6];// and in some function far far awayfloat y = 0.5f;if( y < bounding_box[2] || y > bounding_box[3] )   // do stuff

Notice how difficult it is to determine what is going on, and imagine how harder it would be if the documentation about the index assignment wasnt there. Even if you did have the documentation, its still pretty difficult to even determine if the check is to see if the point is within the bounding box or outside (in this case, the statement returns true if the point is outside). This not only makes it hard when your writing the code, it makes it very hard to debug and maintain.

Fortunately, you've already illustrated a good solution in your code. It is much better to use vertices that look like:
typedef struct vertex{   float x;   float y;   float z;}vertex;

This way, you force an association between the value and its meaning, making the code clearly ledgible. This solution works best in most cases and really only has one limitation; every value must have a clear definition. However, there are few instances where something like this wouldnt work.

Heres an example. Lets say you were defining an environment. You have an array that contains all animals, plants, people, buildings ect. Each element in the array is an array of floats, which define the properties of the entries. Problem: each entry type will have vastly different properties. Solution: just use the floats differently for each type (think of this as a poor mans polymorphism). So for example:

Humans:
// 0 - weight
// 1 - width
// 2 - height
// 3 - depth
// 4 - money

Trees:
// 0 - number of leaves
// 1 - number of fruits
// 2 - unused
// 3 - unused
// 4 - unused

Now we can store a vast amount of different types of things using the same struct, making it really easy to add more types later on. Namely:
typedef struct entity{   float properties[5];}entity;

And we can easily expand the number of properties by increasing the number 5 (and this wont effect any other types). However, we still run into the problems previously mentioned. To get around this problem, just use #define. So for a human, instead of using 0 for weight you would:
// human.h#define HUM_WEIGHT 0// ... and later on...entity human;human = entities;// A lot easier to read nowhuman.properties[HUM_WEIGHT] = 150;

I think this post kinda got out of control :) But I hope it helps,
- llvllatrix

##### Share on other sites
i dont know whats going on with my program. i have a vector of polygon classes which hold the vertex structs. in the polygon class nothing is indexed, they are all straight values. my problem is whenever i test a vertex to see if it is within the bounding box none of them EVER pass. its very bizzare. i just hope i dont end up trashing the sorting function and start over.

as for the bounding boxes, i am placing them within 3d max around my map, so im sure theyre in the right place. the values for min and max are correct too because in my program i have a debugging option to display the bounding boxes and they show perfectly fine.

im probably just going to have to go over it all with a fine-toothed comb...ARGH!

##### Share on other sites
Have u tried drawing the points in the debugging mode?

Quote:
 im probably just going to have to go over it all with a fine-toothed comb...ARGH!

haha, sometimes you just have to :) I went through the same thing when I did an implementation of an octree. These kinda systems are just finiky that way.

Cheers,
- llvllatrix

##### Share on other sites
Quote:
 Original post by llvllatrixHave u tried drawing the points in the debugging mode?

which points are you refering to? the bounding boxes draw ok with the lines on and the rest of the mesh displays fine too.

##### Share on other sites
Quote:
Quote:
 Original post by llvllatrixHave u tried drawing the points in the debugging mode?

which points are you refering to? the bounding boxes draw ok with the lines on and the rest of the mesh displays fine too.

The points you are testing against your bounding box. I would grab the values of the points just before the test and display those.

##### Share on other sites
Quote:
 The points you are testing against your bounding box. I would grab the values of the points just before the test and display those.

im testing all of the points, used in the mesh, against the limits on my bounding boxes

##### Share on other sites
i just thought i would let you guys know what happened. when i was reading in the bounding boxes from the file, the z max and min values were swapped. 3ds max has a VERY difficult and different coordinate system than OpenGL.

##### Share on other sites
In response to ||v||atrix, I believe using an enum to keep a list of named indices is a better than using #defines.

enum{ HEAD, TORSO, LARM, RARM, LLEG, RLEG, LFOOT, RFOOT, NUM_BODYPARTS // Keep this as the last enumeration};struct entity{... some_base_class properties[NUM_BODYPARTS]; // This array will automatically...                                         // stay updated as body parts are};                                          // added to the enumentity human;human = entities;human.properties[TORSO];

##### Share on other sites
Quote:
 Original post by Anonymous PosterIn response to ||v||atrix, I believe using an enum to keep a list of named indices is a better than using #defines.*** Source Snippet Removed ***

Wow, I never thought of that. Very nice :)

Cheers,
- llvllatrix