Larian Banner: Baldur's Gate Patch 9
Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
As I said above, I just figured out the first chunk of the file, which is an array of (x+1).(y+1) floats.
I released my source code in the zip. Just download it and have a look at the algorithm. It's the best "documentation" you can get. But there really isn't more than what I said: a replacement of each float in the chunk by a new height value. The range (in meters) between the lowest and the highest point can be defined in the tool. If you want small hills, put the height of the white pixels to 20 meters (that's the default value). If you want larger mountains, put it to 200 meters.

The reason for the "+1":
DOS terrains are made of rigid tiles, each tile being rendered on screen by 4 coplanar quads (2x2). You can choose a different texture per quad which makes a smooth blend of 4 textures on each tile, but you can only choose the height of the tile borders (so, once every other quad). When you define the size of the map in the engine, you choose the number of quads / textures. And the number of tiles is half that. The heights that are stored in the data file are the heights of the vertices between tiles, not the tiles themselves. So if you choose a terrain of 1000x1000 in the editor, it is made of 500x500 tiles and those tiles have 501 borders (499 being shared between 2 tiles and 2 being the map borders).
If you're still not convinced, take a chess board. It's made of 8x8 squares and from one border to the other, you have 9 lines. That's a total of 81 intersections (9x9).

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I'm convinced no worries I just need this little graphical explanation to get a better grasp on the material. This is excellent wiki material maybe someone with wiki admin rights could add this to the wiki with those other file formats. Thanks for the response, I'll see if I can finish the l3DT import this evening (depending if I'm gonna play DOS or not smile )

Joined: Jul 2014
K
stranger
Offline
stranger
K
Joined: Jul 2014
Originally Posted by Chriskang


The editor copies the "terrain.data" file in several different locations. The "original" version that is open by the editor and copied everywhere else is here:
\Divinity - Original Sin\Data\Editor\Mods\ModName\Levels\LevelName\Terrains
You should NOT edit the copy that is here:
\Divinity - Original Sin\Data\Mods\ModName\Levels\LevelName\Terrains


Ugh, thanks, completely missed that little detail in the tool.

Last edited by Kilrogg; 23/07/14 12:24 PM.
Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I'm almost finished with my L3DT import. It imports fine only my scale is way of, once I fixed this do you mind if I open source this on my github account ? I'll be sure to mention you and later on improve on it to re-incorperate your original work in it (atm I replaced most of it to fit my needs)

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Well I managed to find my height bug, it was actually high school math ... if you're my age you tend to forget some of the more basic stuff. These are the results:

Source
=======
[Linked Image]

Result
=======
[Linked Image]

Now this is all great and stuff, just not good enough. What I like to do is use the climate file of L3DT and match the climates with DOS textures and autotexture the entire thing as well. However for that I need more information about the .data file. I don't have the time to figure that out myself right now due to real life, so I hope someone else can figure this out. Meanwhile once Chris allows me I'll opensource this on my github. Well after I reincorperated his original code, I'll do that this evening.

Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
As I said before, the tool is public domain. You can do anything you want with it, without even asking for my permission. And you don't have to give credits.
So please, release your code on github.

May I see what a "L3DT climate file" is? I just had a look at the second chunk in terrain.data (which contains textures) and it doesn't seem overly complicated: each terrain layer just contains a list of all the triangles that are painted with this layer's texture. If you can decompose your climate file in texture layers with one grayscale image per layer, you should have no problem importing it in DOS.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Basicly a climate file in L3DT is an xml file that describes how texturing should appear at certain elevation ranges

http://www.bundysoft.com/docs/doku.php?id=l3dt:formats:specs:cli.xml

Now there is also an attribute map in L3DT

http://www.bundysoft.com/docs/doku.php?id=l3dt:formats:specs:amf

This maps landtypes on each pixel in the heightmap. So what I have to do is read all landtypes in the attribute map, create a UI for it in the tool where we would say:

landtype_a = dos_texture_1
landtype_b = dos_texture_2
etc...

Then on processing, I would have to go over each pixel in the attribute map get the landtype and paint the dos texture on that pixel. Now this is what I would do when the heightmap is a 1:1 in size. Our size is half the size of the real map, so I guess I would have to paint the texture twice. I don't have a good solution in mind for that one yet.

The good part is I already wrote the libraries to read the attribute map the resulting data looks like:

Code
AmfFile
=======
  public ushort width;
  public ushort height;
  public List<AmfPixelInfo> pixels = new List<AmfPixelInfo>();
  public Dictionary<byte, List<byte>> uniqueLandTypeIdProClimate = new Dictionary<byte, List<byte>>();

AmfPixelInfo
=============
  public uint x;
  public uint y;
  public byte landTypeId;
  public byte climateId;


I hope I'm making sense here, since I find it hard to explain without going into code.

update:

Thing is when I did this with NWN2, they had an API with a Brush object, and I just said brush radius is x and then brush go to x,y and apply texture A that is mapped to LandType A and apply x pressure. Then that brush would go over the entire terrain and apply textures accordingly. Now I'm working on the binary file itself and I'm not that versed in 3D data structures yet. I know everything are triangles and such, but how is that then saved in the file ??? My best guess is some kind of two dimensional array with Triplets each Triplet being the points of the triangle. Maybe multiple arrays for each Layer of textures ?

Open sourced it on github
Divine Divinity Original Sin Terrain Importer Tool Source

Last edited by Celludriel; 24/07/14 03:54 PM.
Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
Both formats seem extremely simplistic and I'm unsure if you'll be able to produce anything appealing if you try to import a map with those constraints. Unless I missed something you'll be unable to use 2 features of the DOS designer that look really important to me: texture blending and variable intensity.

I created the 3 images below to try to highlight those features:
http://imgur.com/a/ocvT7

The first one shows that every tile of a DOS terrain can contain up to 20 different textures that are blended together to create more variation to the tiles. It's really important if you want to avoid repeating patterns but if I understood your wiki correctly, each tile of an L3DT map only has one texture. I fear that it'll make the map look monotonous to a human eye.

The 2nd and 3rd images show that, when a texture is applied to a tile, you can choose the strength of the brush applying it. Your L3DT spec seem to imply that texture presence is only binary in this format: the texture is either there or is not. In DOS editor you have 255 possible levels of intensity.
If I take the second image, that clearly has a low intensity texture in the top left area and apply a formula to force each tile to full texture or no texture, I get the third image.
As you can see, you still have the graphical shader that cuts the image smoothly around the stones but it remains very rough compared to the result that you could get with the DOS editor.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I tend to agree that it is not perfect and quite limiting taking into account those two features. Question is, is it possible that with the data at hand, you could still produce something decent. Maybe some kind of random or calculated variable intensity ? The blending could maybe be fixed by assigning two textures to the same landtype and then draw them both at the same location. I'm just throwing some stuff out here to see if it would be manageable.

I created a new binary with the l3dt code in it as well now.

http://users.telenet.be/sunspot/dos/DosTerrainImporter.7z

Hope you like it.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I tried to figure out how the texturing file format exactly works but at the moment it's a bit beyond me since I don't think I'm using the right knowledge and tools. I took a trial and error approach to figure it out.

- I created 1000 * 1000 map and saved it
- Copied that terrain to a temp folder
- Then went back in the editor and choose a texture, then applied it with 255 strength to eight triangles in the bottom left corner
- Opened the original terrain in the temp folder in a HEX editor and noted down the last address location
- Opened the textured terrain and copy pasted everything after the last address location that I noted down to a new file
- Then I started investigating the result

My findings are at one side straight forward on the other hand something strange is happening as well.

- A lot of the adressess are 0 probably triangles without textures or anything.
- The total size of the data block is 28428 bytes
- Somewhere in the data I find the following block

Code
0 0 0 0 0 0 0 0 0 16 0 0 255 255 255 255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255


I presume the 16 stands for the texture layer and the 255 are my textured triangles. So the question raises why are there two zero values after the 16 and since I textured a square of triangles why are there so many zero values between values, probably because the texturing array goes line by line and not in blocks ???

- Now here is something I totally don't understand. At the bottom of the data you'll find this section

Code
0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
0 0 0 0 2 0 0 0 0 0 0 0 3 0 0 0
0 0 0 0 4 0 0 0 0 0 0 0 5 0 0 0
0 0 0 0 6 0 0 0 0 0 0 0 7 0 0 0
0 0 0 0 8 0 0 0 0 0 0 0 9 0 0 0
0 0 0 0 10 0 0 0 0 0 0 0 11 0 0 0
0 0 0 0 12 0 0 0 0 0 0 0 13 0 0 0
0 0 0 0 14 0 0 0 0 0 0 0 15 0 0 0
0 0 0 0 16 0 0 0 0 0 0 0 17 0 0 0
0 0 0 0 18 0 0 0 0 0 0 0 19 0 0 0
0 0 0 0 20 0 0 0 0 0 0 0 21 0 0 0
0 0 0 0 22 0 0 0 0 0 0 0 23 0 0 0
0 0 0 0 24 0 0 0 0 0 0 0 25 0 0 0
0 0 0 0 26 0 0 0 0 0 0 0 27 0 0 0
0 0 0 0 28 0 0 0 0 0 0 0 29 0 0 0
0 0 0 0 30 0 0 0 0 0 0 0 31 0 0 0
0 0 0 0 32 0 0 0 0 0 0 0 33 0 0 0
0 0 0 0 34 0 0 0 0 0 0 0 35 0 0 0
0 0 0 0 36 0 0 0 0 0 0 0 37 0 0 0
0 0 0 0 38 0 0 0 0 0 0 0 39 0 0 0
0 0 0 0 40 0 0 0 0 0 0 0 41 0 0 0
0 0 0 0 42 0 0 0 0 0 0 0 43 0 0 0
0 0 0 0 44 0 0 0 0 0 0 0 45 0 0 0
0 0 0 0 46 0 0 0 0 0 0 0 47 0 0 0
0 0 0 0 48 0 0 0 0 0 0 0 49 0 0 0
0 0 0 0 50 0 0 0 0 0 0 0 51 0 0 0
0 0 0 0 52 0 0 0 0 0 0 0 53 0 0 0
0 0 0 0 54 0 0 0 0 0 0 0 55 0 0 0
0 0 0 0 56 0 0 0 0 0 0 0 57 0 0 0
0 0 0 0 58 0 0 0 0 0 0 0 59 0 0 0
0 0 0 0 60 0 0 0 0 0 0 0 61 0 0 0
0 0 0 0 62 0 0 0 0 0 0 0 63 0 0 0
0 0 0 0 64 0 0 0 0 0 0 0 65 0 0 0
0 0 0 0 66 0 0 0 0 0 0 0 67 0 0 0
0 0 0 0 68 0 0 0 0 0 0 0 69 0 0 0
0 0 0 0 70 0 0 0 0 0 0 0 71 0 0 0
0 0 0 0 72 0 0 0 0 0 0 0 73 0 0 0
0 0 0 0 74 0 0 0 0 0 0 0 75 0 0 0
0 0 0 0 76 0 0 0 0 0 0 0 77 0 0 0
0 0 0 0 78 0 0 0 0 0 0 0 79 0 0 0
0 0 0 0 80 0 0 0 0 0 0 0 81 0 0 0
0 0 0 0 82 0 0 0 0 0 0 0 83 0 0 0
0 0 0 0 84 0 0 0 0 0 0 0 85 0 0 0
0 0 0 0 86 0 0 0 0 0 0 0 87 0 0 0
0 0 0 0 88 0 0 0 0 0 0 0 89 0 0 0
0 0 0 0 90 0 0 0 0 0 0 0 91 0 0 0
0 0 0 0 92 0 0 0 0 0 0 0 93 0 0 0
0 0 0 0 94 0 0 0 0 0 0 0 95 0 0 0
0 0 0 0 96 0 0 0 0 0 0 0 97 0 0 0
0 0 0 0 98 0 0 0 0 0 0 0 99 0 0 0
0 0 0 0 100 0 0 0 0 0 0 0 101 0 0 0
0 0 0 0 102 0 0 0 0 0 0 0 103 0 0 0
0 0 0 0 104 0 0 0 0 0 0 0 105 0 0 0
0 0 0 0 106 0 0 0 0 0 0 0 107 0 0 0
0 0 0 0 108 0 0 0 0 0 0 0 109 0 0 0
0 0 0 0 110 0 0 0 0 0 0 0 111 0 0 0
0 0 0 0 112 0 0 0 0 0 0 0 113 0 0 0
0 0 0 0 114 0 0 0 0 0 0 0 115 0 0 0
0 0 0 0 116 0 0 0 0 0 0 0 117 0 0 0
0 0 0 0 118 0 0 0 0 0 0 0 119 0 0 0
0 0 0 0 120 0 0 0 0 0 0 0 121 0 0 0
0 0 0 0 122 0 0 0 0 0 0 0 123 0 0 0
0 0 0 0 124 0 0 0 0 0 0 0 125 0 0 0
0 0 0 0 126 0 0 0 0 0 0 0 127 0 0 0
0 0 0 0 128 0 0 0 0 0 0 0 129 0 0 0
0 0 0 0 130 0 0 0 0 0 0 0 131 0 0 0
0 0 0 0 132 0 0 0 0 0 0 0 133 0 0 0
0 0 0 0 134 0 0 0 0 0 0 0 135 0 0 0
0 0 0 0 136 0 0 0 0 0 0 0 137 0 0 0
0 0 0 0 138 0 0 0 0 0 0 0 139 0 0 0
0 0 0 0 140 0 0 0 0 0 0 0 141 0 0 0
0 0 0 0 142 0 0 0 0 0 0 0 143 0 0 0
0 0 0 0 144 0 0 0 0 0 0 0 145 0 0 0
0 0 0 0 146 0 0 0 0 0 0 0 147 0 0 0
0 0 0 0 148 0 0 0 0 0 0 0 149 0 0 0
0 0 0 0 150 0 0 0 0 0 0 0 151 0 0 0
0 0 0 0 152 0 0 0 0 0 0 0 153 0 0 0
0 0 0 0 154 0 0 0 0 0 0 0 155 0 0 0
0 0 0 0 156 0 0 0 0 0 0 0 157 0 0 0
0 0 0 0 158 0 0 0 0 0 0 0 159 0 0 0
0 0 0 0 160 0 0 0 0 0 0 0 161 0 0 0
0 0 0 0 162 0 0 0 0 0 0 0 163 0 0 0
0 0 0 0 164 0 0 0 0 0 0 0 165 0 0 0
0 0 0 0 166 0 0 0 0 0 0 0 167 0 0 0
0 0 0 0 168 0 0 0 0 0 0 0 169 0 0 0
0 0 0 0 170 0 0 0 0 0 0 0 171 0 0 0
0 0 0 0 172 0 0 0 0 0 0 0 173 0 0 0
0 0 0 0 174 0 0 0 0 0 0 0 175 0 0 0
0 0 0 0 176 0 0 0 0 0 0 0 177 0 0 0
0 0 0 0 178 0 0 0 0 0 0 0 179 0 0 0
0 0 0 0 180 0 0 0 0 0 0 0 181 0 0 0
0 0 0 0 182 0 0 0 0 0 0 0 183 0 0 0
0 0 0 0 184 0 0 0 0 0 0 0 185 0 0 0
0 0 0 0 186 0 0 0 0 0 0 0 187 0 0 0
0 0 0 0 188 0 0 0 0 0 0 0 189 0 0 0
0 0 0 0 190 0 0 0 0 0 0 0 191 0 0 0
0 0 0 0 192 0 0 0 0 0 0 0 193 0 0 0
0 0 0 0 194 0 0 0 0 0 0 0 195 0 0 0
0 0 0 0 196 0 0 0 0 0 0 0 197 0 0 0
0 0 0 0 198 0 0 0 0 0 0 0 199 0 0 0
0 0 0 0 200 0 0 0 0 0 0 0 201 0 0 0
0 0 0 0 202 0 0 0 0 0 0 0 203 0 0 0
0 0 0 0 204 0 0 0 0 0 0 0 205 0 0 0
0 0 0 0 206 0 0 0 0 0 0 0 207 0 0 0
0 0 0 0 208 0 0 0 0 0 0 0 209 0 0 0
0 0 0 0 210 0 0 0 0 0 0 0 211 0 0 0
0 0 0 0 212 0 0 0 0 0 0 0 213 0 0 0
0 0 0 0 214 0 0 0 0 0 0 0 215 0 0 0
0 0 0 0 216 0 0 0 0 0 0 0 217 0 0 0
0 0 0 0 218 0 0 0 0 0 0 0 219 0 0 0
0 0 0 0 220 0 0 0 0 0 0 0 221 0 0 0
0 0 0 0 222 0 0 0 0 0 0 0 223 0 0 0
0 0 0 0 224 0 0 0 0 0 0 0


Each value is just one character, it's like they wrote an entire ASCII table into the file at the bottom .... WHY ????????

This is just one texture layer btw I presume adding two would add another one of this block I'll have to test that later today since I have to go to work.

Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
Just wrote this:
http://divinity.gamepedia.com/Terrain_format


Please tell me if you don't find the answers you seek or if something is unclear.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Thanks for this great investigation, I wouldn't have known how to start decently with it. Now this is what I'm going to attempt.

Create a C# 4.5 library DosTerrainLibrary with following convenience methods

Code
- void ReadTerrain(int width, int height, string filename)
  Will read the terrain file into a memory data structure
- void WriteTerrain(string outputFileName)
  Writes the memory data structure to a file
- void SetAltitudeAt(int x, int y, int min, int max, float height)
  Sets a particular intersection of tiles to given float height (scaled with min and max to DOS scale)
- int CreateTextureLayer()
  Creates a new texture layer at the bottom and returns it's index
- void RemoveTextureLayerAt(int index)
  Removes a texture layer at given index
- Layer GetLayerAt(int index)
  Returns a layer at given index
- void SetTriangleIntensityAt(int x, int y, Layer layer, single intensity)
  Will set the layers intensity at x, y with given intensity


I might come up with more needed methods but for now this should do. Now mind you I'm a java developer so .NET is something I try to learn in my spare time. I'm not proficient in it in any way. So this might take me a decent amount of time to develop. I'll open source it ofcourse so anyone can pitch in or give advice evil

edit:

What I don't get though, is where is the type of texture stored ? You got the layers and intensity , but where is stored if it is rock, sand or whatever ?

Last edited by Celludriel; 25/07/14 01:35 PM.
Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
I'm going to write my own parser in the near future as I plan to create a tool to generate random terrains (similar to the Civ5 fractal generator) and to allow resizing in the editor. If you don't want to write the lib, you can use mine.

On the other hand, if you want to do it, no one forces you to use .Net. The heightmap algorithm is like 10 lines long, it should be quite easy to rewrite it in Java if you're more comfortable with this language.

Originally Posted by Celludriel
What I don't get though, is where is the type of texture stored ? You got the layers and intensity , but where is stored if it is rock, sand or whatever ?

It's in the LSB file that is stored with a copy of the terrain at the following path:
Divinity - Original Sin\Data\Mods\ModName\Levels\LevelName\Terrains

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Well the editor is written in .NET and I feel as a developer I need to be multiversed in many languages. So this is a perfect challenge for me to do in .NET. I feel we are both on the same path though. I wanted to do something likewise after I finished the L3DT stuff. I found a paper on the net a few months ago about terrain generating algorithms and wanted to try it out. I first wanted to do this for NWN2 but it seems I could perfectly try it with DOS as well. But that is for later on, first I like to write the parser. If I can get it decent enough maybe you could improve on it and save yourself some time writing your own.

Kinda sucks that the data is stored in two places. That means if I'm going to implement the parser in the terrain importer tool I have to generate two files instead of one frown

edit:

http://www.float4x4.net/index.php/2010/06/generating-realistic-and-playable-terrain-height-maps/

this is the article I was talking about

edit2:

Started work on the library and put it on github

https://github.com/Celludriel/DOS_Terrain_Lib

Only the basis is here now, I'll be expanding on this in the coming days

Last edited by Celludriel; 25/07/14 05:44 PM.
Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I've made an attempt to write the parser according to the spec on the wiki but either I wrote it wrong or we haven't figured it out right yet. It all goes well until after reading the "TerrainPatchData" characters.

example file
- terrain 100 * 100
- 2 added texture layers

so that would mean the background layer has 50 * 50 * 24 triangles each triangle 12 bytes so that's 720000 bytes. Yet after the string there are only 24 587 bytes left in the file. So I end up with an EndOfStreamException. So either I misinterpretated the spec or we are missing something. Notice I didn't draw any textures on the terrain. Something other particular the first UINT32 read after the string is not the expected 60000 but 24576

- Created terrain 100 * 100 , cysal_base texture
- Added texture layer = grass something
- Added texture layer = stone something
- Save and then copy to experiment on

I've commited my work as is to the repository as reference the example data file is in there as well

edit:

Did a small test, I removed one texture layer, then fully painted the terrain with the remaining texture layer and the file size increased. So if there hasn't been drawn on the terrain there seems to be data missing.

edit2:

I was curious and went into the editor and counted the tiles on the border of my 100*100 terrain , the end result was 32 on either side so (32 * 2) * (32 * 2) triangles would be the end result. But maybe the triangles in the grid view aren't the same as the triangles in the data structure ... I'm not sure

Last edited by Celludriel; 25/07/14 08:27 PM.
Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
Originally Posted by Celludriel
Kinda sucks that the data is stored in two places. That means if I'm going to implement the parser in the terrain importer tool I have to generate two files instead of one

If you don't have an LSB parser yet, this is probably going to be the hardest part. The LSB format is far more complex than the terrain format:
http://divinity.gamepedia.com/LSB_format

Originally Posted by Celludriel
so that would mean the background layer has 50 * 50 * 24 triangles each triangle 12 bytes so that's 720000 bytes.

This part is wrong. X*Y*24 is the number of BYTES in a layer chunk. The number of triangles is X*Y*2 (see "Triangle array" section on the wiki). You can count those triangles directly on screen with the wireframe view.

Originally Posted by Celludriel
Did a small test, I removed one texture layer, then fully painted the terrain with the remaining texture layer and the file size increased. So if there hasn't been drawn on the terrain there seems to be data missing.

This is correct, if a layer is completely empty, the triangle array length and intensity array length are set to 0.

Originally Posted by Celludriel
I was curious and went into the editor and counted the tiles on the border of my 100*100 terrain , the end result was 32 on either side so (32 * 2) * (32 * 2) triangles would be the end result. But maybe the triangles in the grid view aren't the same as the triangles in the data structure ... I'm not sure

Something went wrong when you created the terrain. A terrain of size 100x100 has 50*50 tiles (i.e. 50x50 squares made of 2 triangles each).
32x32 tiles is typical of a terrain with the default dimensions (64x64).
Please, try it again.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Ok so the layer size is X*Y*24 I misunderstood that one. Now I tried over five times to create a terrain of size 100*100 and each time in the editor I only count 32 tiles on either side of the square. However when I parse the heightfield in the file the size is actually 100 * 100 so not 64 * 64.

I succeeded, made some dumb mistakes but I'm going to blame them on being to tired from my dayjob, a good nights sleep and some debugging got me thru. I was able to parse a 64 * 64 terrain.

Ok next up is to write a writer and then a bunch on NUnit tests with several terrains to see everything keeps working.

edit:

Got my writer working , so perfectly able to read a terrain and write it back one on one without breaking anything

edit2:

Added NUnit tests, all tests pass except the 100 by 100 since I expect 50 tiles on each side instead of the 32 that are in the terrain. Bug at Larian side ???

Last edited by Celludriel; 26/07/14 07:23 AM.
Joined: Jul 2014
stranger
OP Offline
stranger
Joined: Jul 2014
You are right and this is weird. I'm pretty sure I created a 60x100 terrain one week ago and it had 30x50 tiles. As of today, it seems that terrain bigger than 64 can only have a multiple of 32 tiles.
Not sure if it's bug or not.

Congrats on your parser.

Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
Thanks, but if this isn't a bug and working as intended it will complicate things I believe. I wanted to write some helper classes , where you would be able to set the intensity at a certain X,Y coordinate. Something in the line of

public void setIntensityAt(TypeLayer layer, uint32 x, uint32 y, byte value1, byte value2, byte value3, byte value4)

it would look for the Intensity object in the array for x and y and then set the values. Except for finding the right index for the x, y coord , this is fairly easy. But if I can't count on a 100*100 terrain being x:50 and y:50 ... well I'm a bit screwed ...

I'll have to sleep on this, see if I can figure out a math formula or algorithm to find the right tile and set the layer intensity

edit:

I was curious and created a 256*256 area and counted the tiles and the result was 128*128 so the size / 2 equation was kept ? Tomorrow I'll try a 300 * 300 and see what that gives

Last edited by Celludriel; 26/07/14 10:14 PM.
Joined: Jul 2014
C
member
Offline
member
C
Joined: Jul 2014
I'm a bit stuck at the moment. I'm trying to make my parser work for terrains with bigger sizes. I tried with a 1000*1000 one and those results where a disaster. I went through it debugging at the moment the layers get parsed. More in specific when I read the first layer. So now at max the first UInt32 read is 24576. Then after all those triangles get read instead of the count for number of texture layers that follow you get another 24576. I presume another set of background layer triangles. Now fine, but there is nowhere a read for how many iterations of blocks of 24576 size so how do I know when the next UInt32 will be the read of how many texture layers ?

edit:

ALmost thought I had it

uint n = (UInt32) Math.Ceiling((width * height) / 24576.0);

This works for 180*180 but not for 1000*1000 ... so back to square one grrrrrrrr frustrating

Last edited by Celludriel; 27/07/14 10:25 AM.
Page 2 of 3 1 2 3

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5