Blargh--setTransform, trying to fix building altitude
by Stephen Zepp · in RTS Starter Kit · 11/23/2004 (7:59 pm) · 4 replies
Ok, this should be easy, but it just isn't working. The goal is to fix certain buildings that are getting half-buried under the terrain.
Step 1: Fix the building marker
--since it's client side only, we have to start there.
---set up an RTSBuildingMarker field called "mZAxisTweak", with access methods, so scripter can set a human adjusted tweak to raise or lower the marker off the ground.
---over-ride the "hack" of 1.5 units in the Z axis when moving the building marker.
This all works. My building markers are at the right height (once tweaked in the Z axis), everything looks peachy.
Step 2: Correct server side building position
--this is the authoritative position, so it needs to be right.
--ok, we know what Z-Axis tweak is needed client side, but we have to get it server side, so send it as a separate parameter in the commandToServer('PlaceBuilding'). Did it, caught it, have the log file to prove it.
--now, should be easy to adjust the transform that the building has already been set to (%b.setTransform(%transform) has already happened, since the client kindly told us where the marker is). Wierdly enough, a second .setTransform(0 0 0 0 0 0) causes the building to shift in a really wierd way--diagonally, away from us.
Ok, Step 2, take 2:
--the client is already sending a position transform ($NewBuilding.getTransform), and the server catches it and uses it. So let's just tweak the Z component of that transform.
--(lots of string parsing to separate each word, add the two together, and send it). Been there, done that, got the log server side to prove it.
--ok, now the original %b.setTransform is using our "tweaked" transform that the client sent.
Building shows up at the client--half buried. %b.setTransform appears to completely ignore any z axis adjustments.
I figure it's clamped somewhere to that hard coded 1.5 value, but for the life of me I cannot find it.
@GG: Anyone remember if you hard code clamped it, and if so where? I've spent hours looking at every single setTransform in the entire engine (search in files is nice, sometimes), but no dice.
This is the last step for the building actions resource, and it sucks to be stuck so close to the end!
Step 1: Fix the building marker
--since it's client side only, we have to start there.
---set up an RTSBuildingMarker field called "mZAxisTweak", with access methods, so scripter can set a human adjusted tweak to raise or lower the marker off the ground.
---over-ride the "hack" of 1.5 units in the Z axis when moving the building marker.
This all works. My building markers are at the right height (once tweaked in the Z axis), everything looks peachy.
Step 2: Correct server side building position
--this is the authoritative position, so it needs to be right.
--ok, we know what Z-Axis tweak is needed client side, but we have to get it server side, so send it as a separate parameter in the commandToServer('PlaceBuilding'). Did it, caught it, have the log file to prove it.
--now, should be easy to adjust the transform that the building has already been set to (%b.setTransform(%transform) has already happened, since the client kindly told us where the marker is). Wierdly enough, a second .setTransform(0 0
Ok, Step 2, take 2:
--the client is already sending a position transform ($NewBuilding.getTransform), and the server catches it and uses it. So let's just tweak the Z component of that transform.
--(lots of string parsing to separate each word, add the two together, and send it). Been there, done that, got the log server side to prove it.
--ok, now the original %b.setTransform is using our "tweaked" transform that the client sent.
Building shows up at the client--half buried. %b.setTransform appears to completely ignore any z axis adjustments.
I figure it's clamped somewhere to that hard coded 1.5 value, but for the life of me I cannot find it.
@GG: Anyone remember if you hard code clamped it, and if so where? I've spent hours looking at every single setTransform in the entire engine (search in files is nice, sometimes), but no dice.
This is the last step for the building actions resource, and it sucks to be stuck so close to the end!
#2
11/23/2004 (10:36 pm)
Stephen, it's late and my brain is only at 10% capacity. Need the summary: did you get this issue fixed or do you need help figuring it out? :)
#3
11/23/2004 (11:34 pm)
Have you tried modifying the art to have a different origin?
#4
I fixed it by removing the forced "move us to sit on the ground" for units of class RTSBuilding. In retrospect, I'll probably change this to only apply to RTSGroundUnit or something similar.
@Ben: Actually, looking at the various in game behaviours for different models provided at different times is what led us to the change--as you may know by now, I'm a big believer in providing options, not assumptions. There was absolutely nothing wrong with the performance tweak I described above, except that IMHO it was too general--it makes perfect sense to me to clamp RTSUnits that move along the ground--no need for them to jump, no need for them to fall, etc. so you can gain a lot of performance.
The problem lies with other types of units (Buildings for us, flyers in the future, etc.). In our particular case, I elected to try to do this procedurally in code, rather than force a change of our/anyone else's art library (not that it's huge or anything, but I'd rather not force restrictions on artists if I can feasibly handle what they do procedurally). Changing the art to conform to the x-z plane was certainly a viable choice as well, just not the one I made.
11/24/2004 (4:20 am)
@Josh: it's fixed finally. You guys clamped RTSUnit position in RTSUnit.cc RTSUnit::processTick() to be projected with the "feet" touching the ground at all times. This includes RTSBuildings (and any RTSFlyer units someone may in the future derive). Based on the PROFILE_START(RTSUnit_Z) block, it was almost certainly a way to tweak some performance gains by not having to model gravity.I fixed it by removing the forced "move us to sit on the ground" for units of class RTSBuilding. In retrospect, I'll probably change this to only apply to RTSGroundUnit or something similar.
@Ben: Actually, looking at the various in game behaviours for different models provided at different times is what led us to the change--as you may know by now, I'm a big believer in providing options, not assumptions. There was absolutely nothing wrong with the performance tweak I described above, except that IMHO it was too general--it makes perfect sense to me to clamp RTSUnits that move along the ground--no need for them to jump, no need for them to fall, etc. so you can gain a lot of performance.
The problem lies with other types of units (Buildings for us, flyers in the future, etc.). In our particular case, I elected to try to do this procedurally in code, rather than force a change of our/anyone else's art library (not that it's huge or anything, but I'd rather not force restrictions on artists if I can feasibly handle what they do procedurally). Changing the art to conform to the x-z plane was certainly a viable choice as well, just not the one I made.
Torque 3D Owner Stephen Zepp
In any case, sorry for the noise here bringing up the issue--but then again, it helped me fix it, so I can't apologize too much!
Tomorrow we finalize the art hopefully, and finish up some refactoring and tweaking, and then the combined Supply Manager and Building Actions resource will be available.