What's the purpose of emptySquares?

#1 Think of them as holes in the terrain.

Say for example you have a DIF that goes into the terrain and has a basement or underground tunnel. If you do not define the emptysquares Torque will render the terrain inside of the DIF and prevent a player from going down into the basement or tunnels that you have made.

#2 OK. What would these values represent from emptySquares = "443522 443778 444034"; ? These would be a lot of holes....

#3 I think I was misunderstood. In the mission file - flat.mis - under the dataBlock TerrainBlock there is a field with the following data - emptySquares = "443522 443778 444034"; In this contents - What's the purpose of emptySquares?

#4 You were not misunderstood. emptySquares signifies to the terrain engine which 'square's of the terrain to not draw/collide against.

I believe it is space deliminated, so in your case you have 3 squares that will not show up on the terrian.

#5 @Robert
Sorry - I do not see where you get 3 squares from.... If you are getting that info from these values (emptySquares = "443522 443778 444034";) could you please explain how. You are correct to say that there are 3 squares not showing up in the mission because I see 3 white spaces. Thank You Jesse.

#6 There's three blocks of numbers... three squares...

#7 OK. How is each number interpreted? (For example, in the first number has embedded values for x and y)..
Chris thanks. Jesse.

#8 Each value is a mask representing the position within the terrain grid. Think of the terrain as a 256x256 image with each pixel representing the height value of a particular square within the terrain.

Say pixel 0, the very top left most pixel in an image represents square 0 in the terrain and pixel 65535 represents the last pixel, the very bottom right most pixel.

Each value is packed by offset within the grid, and the number of runs or 'squares' that are affected by the empty flag.

443522:
offset = 443522 & 0xffff
runs = 443522 >> 16

For this value, you have empty squares starting at grid 50306 and going to 50312.

#9 Also for reference the terrain is 2048x2048 in size, world size. Now the terrain is represented by a 256x256 grid and is 8x8 BIG blocks on each side, hence 2048/8 = 256. Each BIG block is, I think, 4x4 squares, and each square happens to be 8 units in size, as is denoted by the squareSize value.

This gives you 8 BIG blocks * 4 squares * 8 size = 256

#10 The decimal value 443522 is 0x6C482.
0x6C482 & 0xFFFF = 0xC482 (an AND bit wise operation) which is 50306 the offset.
443522 >> 16 = 6 is the runs.

Are there 7 squares inclusively or only the 6?
@line142(terrData.cc) for(U32 j = 0; j < run; j++)
thus up to square 50311.

Last question:
Can emptySquares be assigned a empty string where it would represent NO emptySquares?

Many Thanks Jesse.

#11 Let me see if I fully understand the following:

(1) If the squareSize is set to 8, then the world area is 2048 x 2048 world units (wu).
(2) The grid of the world area is 256 x 256 = 65,536 squares.
(3) Each square is 8 x 8 wu.
(4) Thus 256 squares x 8 wu/(square side) = 2048 wu.

Does the squareSize = 8 represent line (3)?
Please any comments....

Jesse.

#12 Only 6 runs, 0 to 5. The emptySquares value can be an empty string and thus no empty squares will be visible. There is also a max of 100 runs total (or per value I can't remember).

It's been a while but I believe so yes, I am fairly certain squareSize represents the wu of an individual square. Changing this value is the easiest way to affect the look of the terrain. Though you need to be careful about the values you enter, and that those values will affect the overall wu size of the terrain so that needs to be accounted for as I don't think it is automatically.

The other way to affect the terrain, is much harder, which is to change the blockSize or blockShift of the terrain. This affects how large the terrain grid is or how it is read from a data set (bitmap). The difficulty in changing these values is that not all areas of the terrain use the terrData.h enums/constants and when they do sometimes it's not always the correct one they should be using. The other problem, once that is all sorted out, is getting the changed terrain to load a terrain. Since if you were to change those values, no terrain made with the old values will load correctly, and since you can't load any of the old terrains you can't edit one to make one that will work with the new system, it's a lovely catch22. I do not recommend fiddling with the values found in terrData unless you know (sorta) what you are doing.

#13 Also, I'm sorry but I got a few things mixed up here. A more accurate description of the various values of the terrain can be found here as that was written much closer to when I finished looking at a bunch of terrain code it is most likely contains the more accurate definitions.

#14 In the other tread, you quoted: "So, given this information we can see that a TerrainBlock is exactly
squareSize(8) * blockSize(Square(32) * blockShift(8)) or 2048x2048 in size."

Was this taken from the code or is this your definition? That is to say blockSize = 256. I am asking because when I see square(32), I am thinking 1024. If my thinking is correct, then 8 * 1024 * 8 = 65,536 squares.

With the point of view of the squareSize = 8, is there 65,536 squares on the grid of 2048 x 2048 wu?

You continue to say in the same tread:
"A Block and a TerrainBlock are the same thing, essentially. I've just seperated the two because for me, it makes more sense to say that a Block represents a heightfield of 256x256 and the TerrainBlock represents the world geometry of the terrain which is 2048x2048

If you want to see how the world terrain geometry and the heightfield relate to each other go into your favorite photoshop-like program, and make a 256x256 greyscale image. And then import that image via the Torque Terrain Editor.

I guess you could say that given the TerrainBlock is made up of 32x32 squares with each square containing a 8x8 sub-blocks that each sub-block would be a single pixel within that 256x256 image."

Let me try again to see that I MAY understand:
The number of squares is always constant (65,536 squares), so indicated by blockSize(Square(32) * blockShift(8)). I assume blockSize can only be altered within the code. What does change is squareSize which is only the number of world units (wu) -size - for each "sub-block". So if squareSize is changed to 16 for example, there is still 65,536 squares per block but the size of the sub-block is 16 wu. Thus giving an area of 4096 x 4096 wu.

Thanks Robert - you have been very helpfull

Jesse.

#15 Of course, the above is only mere speculation. To comfirm that there is 65,536 squares, I did the following:

(1) I set flat.mis not to tile and I counted 64 texture squares on edge.
(2) Next I tried setting Terrain to a brush size to one (1) and I counted a 4 x 4 grid of 16 squares.
(3) Opened texture checkerboard2.png is 2 x 2 texture squares. Thus is 8 x 8 grid of 64 squares.
(4) The Orc was placed within a square for comparison, it seems that each square is 8 x 8 wu. So 64 x 4 x 8 = 2048 wu.

Finally I see on one side 64/2 = 32 big blocks with 8 squares on edge in each block giving 256 squares on edge. Thus 32 bigBlocks (for texture) x 8 squares/bigBlock x 8 wu/square = 2048 wu.

Thus 256 squares x 256 squares = 65,536 squares...OK, I think I got it!?

Well I guess I spent enough energy on counting squares...I'm squared out.

Jesse.