Terrain/Model Scale
by Wex · in Torque Game Engine · 08/13/2006 (6:50 am) · 5 replies
Hi, what's the unit-scale used between models and terrain?
I'm exporting my own terrain and models from a 3D package (both being in the same scene in the package), generating a mission file, and then loading it into torque. I've got everything exporting fine, though all the scales are off.
A terrain is made up of 256 by 256 squares, so what is the size of one of those squares in model-units? Also the terrain height seems to be on a different unit-scale to it's bredth and depth...
Any clarity on this odd system will be very helpful. Cheers.
I'm exporting my own terrain and models from a 3D package (both being in the same scene in the package), generating a mission file, and then loading it into torque. I've got everything exporting fine, though all the scales are off.
A terrain is made up of 256 by 256 squares, so what is the size of one of those squares in model-units? Also the terrain height seems to be on a different unit-scale to it's bredth and depth...
Any clarity on this odd system will be very helpful. Cheers.
About the author
#2
It's 8 by default.
08/14/2006 (6:34 pm)
SquareSize is the setting on the terrain that controls how many meters per grid square.It's 8 by default.
#3
I'm doing all my stuff programatically... Unfourtunately code doesn't have the ability to 'see what things look like' ;)
@Ben:
Cheers, found that, but that fact by itself it doesn't mean much to someone trying to work it out... (obvious what it means once you know though :) )
I worked it out this way... so for future reference:
1 x/y point in terrain = 8 z points in terrain. For example, if you go along one and up by 8 you'll have a 45-degree slope. Terrain points in the x/y are clearly whole numbers, but in the z they are not. In the TER file the height is multiplied by 32 before being rounded off to a whole number and saved. Example: If height is 13.56209 in your 3D editor you'll have to multiply by 8 first, giving you 108.49672; and then by 32 giving 3471.89504; rounded down this gives you 3471, which is the height value you save into the TER file. The end value should be less than 65535 (0xFFFF in hex, two 'full' bytes) which means the initial height value is from 0 to 255 (well, 255.9).
All models need to be scaled up by a factor of 8 in order to be in the same scale as the landscape. This includes their position in the scene. They also need to be offset by 1024 in both x and y as that is how much the terrain is offset by.
All these values are correct (AFAIK) with the original terrain setup; with SquareSize set to 8 (as Ben mentioned). If you mess about with that, then don't expect these numbers to be correct. :)
Hope this helps someone.
08/15/2006 (9:15 am)
@Jon:I'm doing all my stuff programatically... Unfourtunately code doesn't have the ability to 'see what things look like' ;)
@Ben:
Cheers, found that, but that fact by itself it doesn't mean much to someone trying to work it out... (obvious what it means once you know though :) )
I worked it out this way... so for future reference:
1 x/y point in terrain = 8 z points in terrain. For example, if you go along one and up by 8 you'll have a 45-degree slope. Terrain points in the x/y are clearly whole numbers, but in the z they are not. In the TER file the height is multiplied by 32 before being rounded off to a whole number and saved. Example: If height is 13.56209 in your 3D editor you'll have to multiply by 8 first, giving you 108.49672; and then by 32 giving 3471.89504; rounded down this gives you 3471, which is the height value you save into the TER file. The end value should be less than 65535 (0xFFFF in hex, two 'full' bytes) which means the initial height value is from 0 to 255 (well, 255.9).
All models need to be scaled up by a factor of 8 in order to be in the same scale as the landscape. This includes their position in the scene. They also need to be offset by 1024 in both x and y as that is how much the terrain is offset by.
All these values are correct (AFAIK) with the original terrain setup; with SquareSize set to 8 (as Ben mentioned). If you mess about with that, then don't expect these numbers to be correct. :)
Hope this helps someone.
#4
Reason I'm asking I can make height maps based on this idea and just import in to texture.
Please tell me if this is correct or if theres a better way to do this.
08/16/2006 (4:08 pm)
Just a quick question that hopefully you guys might know now we have maps of 256x256x8 is the the same as saying the map has a rez of 256x256 by 8dpi or an I looking at this the wrong way?Reason I'm asking I can make height maps based on this idea and just import in to texture.
Please tell me if this is correct or if theres a better way to do this.
#5
09/05/2006 (8:00 am)
Umm, dpi is to do with printing. So, I'm guessing you're wrong.
Torque 3D Owner Jon Paynter
Both models AND terrain are scaleable -- although scaling the terrain seems to create flakyness.