Playing with RTSBuildings--bounding box question
by Stephen Zepp · in RTS Starter Kit · 11/12/2004 (7:33 pm) · 7 replies
The bounding box for the example shape provided for building placement is hardcoded as part of the datablock (which is cool).
What technique did you use to determine appropriate values for the bounding box? Provided by the artist, calculated via showtool or something, or WAGS until it looked good? :)
This is related to an issue with player driven building placement that has always nagged me...how does the code "know" how high to place the building?
In other words, what are the (common) reference point(s) from a programmer's perspective that you can use to manipulate a shape in game? In the world editor for example, you use the center of the shape as your grip point. Is there a relatively easy way to grab the outer extent of the shape, including the distance from the center point to the floor/bottom of shape?
What technique did you use to determine appropriate values for the bounding box? Provided by the artist, calculated via showtool or something, or WAGS until it looked good? :)
This is related to an issue with player driven building placement that has always nagged me...how does the code "know" how high to place the building?
In other words, what are the (common) reference point(s) from a programmer's perspective that you can use to manipulate a shape in game? In the world editor for example, you use the center of the shape as your grip point. Is there a relatively easy way to grab the outer extent of the shape, including the distance from the center point to the floor/bottom of shape?
#2
boundingBox = "10.0 10.0 3.0";
Those number were calculated somehow to fit the example building that was provided with the pack.
I'm playing with a couple of much larger .dts buildings that I have lying around, and from experimentation I've learned that this box is used as the region to "select" the building with a left click, but with my much larger building, it's (obviously) only a very small section that is clickable with the above bounding box. I was wondering if there is some little technique you used when deciding on those values above--best guess based on trial/error, did the artist provide it for you, or can it be extracted procedurally from the .dts itself somehow?
On the second part, I'm trying to get a better feel for how the code works so that I can make the "place building" functionality a lot more flexible for our project. One of the things that I've noticed is that with my much bigger .dts shapes, a good 1/3 to 2/3s of the building is underground when the building is placed. I'm guessing that I don't know how to calculate the distance from the center of the .dts to the "bottom" or "floor" of the .dts, so I can give the building's center a high enough altitude so the floor aligns with the terrain.
So, the base question is:
Is there a method somewhere or a technique to be able to calculate the distances from the center of a .dts to it's "farthest rendered surface/point/whatever it's called". If I'm not explaining the question well, let me know and I'll try to draw a small graphic to explain it visually.
11/13/2004 (4:15 am)
In /server/scripts/items/building.cs, at the top, there is this line:boundingBox = "10.0 10.0 3.0";
Those number were calculated somehow to fit the example building that was provided with the pack.
I'm playing with a couple of much larger .dts buildings that I have lying around, and from experimentation I've learned that this box is used as the region to "select" the building with a left click, but with my much larger building, it's (obviously) only a very small section that is clickable with the above bounding box. I was wondering if there is some little technique you used when deciding on those values above--best guess based on trial/error, did the artist provide it for you, or can it be extracted procedurally from the .dts itself somehow?
On the second part, I'm trying to get a better feel for how the code works so that I can make the "place building" functionality a lot more flexible for our project. One of the things that I've noticed is that with my much bigger .dts shapes, a good 1/3 to 2/3s of the building is underground when the building is placed. I'm guessing that I don't know how to calculate the distance from the center of the .dts to the "bottom" or "floor" of the .dts, so I can give the building's center a high enough altitude so the floor aligns with the terrain.
So, the base question is:
Is there a method somewhere or a technique to be able to calculate the distances from the center of a .dts to it's "farthest rendered surface/point/whatever it's called". If I'm not explaining the question well, let me know and I'll try to draw a small graphic to explain it visually.
#3
The first...my short term goal is to find out how high to place my (much larger) building, procedurally if possible based on info from the .dts itself.
11/13/2004 (4:17 am)
Quote:Are you asking how we figure out how high to place the buildings, or how we relate mouse input to building position
The first...my short term goal is to find out how high to place my (much larger) building, procedurally if possible based on info from the .dts itself.
#4
I'm back to this issue again, and trying to nail down a good fix.
As we saw with some buildings, depending on how units were modelled, we see some units where their location.z value is the "feet" of the model, but we also have some models where the location.z value appears to be the center of the model. This causes some units to be half-way sunk into the ground, since in RTSUnit.cc we clamp the z axis position of a unit to be < .01f of the terrain "altitude".
What I'm trying to figure out is how this relationship between location and the .dts occurs. In other words, why for some models do they clamp to the terrain with their feet, and why in other models to they clamp to the terrain with their "center"?
In stock TGE, it appears that we have a PlayerData variable called "boxSize", which apparently holds the dimensions of the bounding box of a .dts which I'm guessing is either set manually by the artist, or is calculated when the .dts is loaded. Unfortunately, we do not have that variable in RTSUnitData.
How can I find:
1) Which part of the .dts is the "attachment point" for how a setTransform/getTransform interacts with the shape? Is it always the origin (center point) of the shape?
2) How can I calculate the offset I should use to make sure all shapes, regardless of how they were defined by the artist, clamp properly to the terrain? As I mentioned above, units supplied with the RTS pack clamp with their feet on the ground, but units made by my artists are clamping with their center "on" the ground.
BTW, when these units with the problems are loaded into stock TGE, they work perfectly, so I know the information is in the model itself, I just can't find out why RTS SK code isn't reading it, or where it's reading it to if it is.
12/21/2004 (2:08 pm)
Interesting how you can go full circle!I'm back to this issue again, and trying to nail down a good fix.
As we saw with some buildings, depending on how units were modelled, we see some units where their location.z value is the "feet" of the model, but we also have some models where the location.z value appears to be the center of the model. This causes some units to be half-way sunk into the ground, since in RTSUnit.cc we clamp the z axis position of a unit to be < .01f of the terrain "altitude".
What I'm trying to figure out is how this relationship between location and the .dts occurs. In other words, why for some models do they clamp to the terrain with their feet, and why in other models to they clamp to the terrain with their "center"?
In stock TGE, it appears that we have a PlayerData variable called "boxSize", which apparently holds the dimensions of the bounding box of a .dts which I'm guessing is either set manually by the artist, or is calculated when the .dts is loaded. Unfortunately, we do not have that variable in RTSUnitData.
How can I find:
1) Which part of the .dts is the "attachment point" for how a setTransform/getTransform interacts with the shape? Is it always the origin (center point) of the shape?
2) How can I calculate the offset I should use to make sure all shapes, regardless of how they were defined by the artist, clamp properly to the terrain? As I mentioned above, units supplied with the RTS pack clamp with their feet on the ground, but units made by my artists are clamping with their center "on" the ground.
BTW, when these units with the problems are loaded into stock TGE, they work perfectly, so I know the information is in the model itself, I just can't find out why RTS SK code isn't reading it, or where it's reading it to if it is.
#5
Here's the scoop:
Stock RTS-SK makes an assumption that units should always be clamped to the terrain. This assumption as far as I can tell is made primarily so we can rip out all the performance heavy cycles for gravity, jumping, terrain collision in the Z axis, and whatever else Player.cc has to do in the Z dimension. It works ok, except for the fact that the implementation also makes an assumption of some sort (I haven't figured out exactly what that assumption is yet, but it's there) about the way the artist either positions, or exports his objects.
Here is a more robust solution:
In RTSUnit.cc, processTick(), search for the following as a marker:
PROFILE_START(RTSUnit_Z);
Now, scroll down until you find:
and replace it with:
For all of my test cases, this has solved the clamping to terrain issue with any type of unit model (origin-centered or origin--feet).
12/21/2004 (3:26 pm)
I need my own personal forum! Don't ask me how, but every time I post a question here, I wind up answering it myself shortly thereafter.Here's the scoop:
Stock RTS-SK makes an assumption that units should always be clamped to the terrain. This assumption as far as I can tell is made primarily so we can rip out all the performance heavy cycles for gravity, jumping, terrain collision in the Z axis, and whatever else Player.cc has to do in the Z dimension. It works ok, except for the fact that the implementation also makes an assumption of some sort (I haven't figured out exactly what that assumption is yet, but it's there) about the way the artist either positions, or exports his objects.
Here is a more robust solution:
In RTSUnit.cc, processTick(), search for the following as a marker:
PROFILE_START(RTSUnit_Z);
Now, scroll down until you find:
if (mFabs(location.z - height) > 0.01)
{
location.z = height;
setMaskBits(MoveMask);
}and replace it with:
Box3F cBoundingBox = mConvex.getBoundingBox(getTransform(), getScale());
if (mFabs(location.z - height - (cBoundingBox.len_z())/2.0f) > 0.01)
{
location.z = height + (cBoundingBox.len_z()/2.0f);
setMaskBits(MoveMask);
}For all of my test cases, this has solved the clamping to terrain issue with any type of unit model (origin-centered or origin--feet).
#6
12/21/2004 (7:49 pm)
Thanks, Stephen. Another tickbox for the todo list... :)
#7
It took me about 4+ hours to dig through the code, comparing it to stock TGE, and stepping through line by line trying to figure out exactly what was causing this.
I opened up the new show tool pro, looked at the "bot.dts", looked at the "swordsman.dts" (custom model), and knew the root problem, and had a solution ready to be implemented in tested in oh, say, 3 minutes tops.
As it turns out, I was correct--all of the .dts models (3 units, plus the building) have the "bottom" of the model placed on the horizontal origin plane (X-Y plane). My custom models have the center of the model itself at the origin, with a node defined as a pivot point at the feet, where the artist intended the .dts to interact with the terrain. This became supremely obvious as soon as I could see the two .dts shapes against an origin grid with nodes visible.
Don't keep beating your head against lines of code when you're dealing with dts shapes guys...buy the TShowPro! Even if I only made $10 an hour, it payed for itself in the first 4 minutes I used it.
12/22/2004 (3:14 am)
Mini-plug for the new Torque Show Tool Pro:It took me about 4+ hours to dig through the code, comparing it to stock TGE, and stepping through line by line trying to figure out exactly what was causing this.
I opened up the new show tool pro, looked at the "bot.dts", looked at the "swordsman.dts" (custom model), and knew the root problem, and had a solution ready to be implemented in tested in oh, say, 3 minutes tops.
As it turns out, I was correct--all of the .dts models (3 units, plus the building) have the "bottom" of the model placed on the horizontal origin plane (X-Y plane). My custom models have the center of the model itself at the origin, with a node defined as a pivot point at the feet, where the artist intended the .dts to interact with the terrain. This became supremely obvious as soon as I could see the two .dts shapes against an origin grid with nodes visible.
Don't keep beating your head against lines of code when you're dealing with dts shapes guys...buy the TShowPro! Even if I only made $10 an hour, it payed for itself in the first 4 minutes I used it.
Associate Kyle Carter