it says its an invalid file format. so what i have to do is open the .ter file in Terragen and resave as .ter file and then import w/o problems into Dreamscape in Max. its kinda odd since Terragen can open the .ter file from WM. has anyone else seen this problem?
i’ll also post this same issue in the afterworks dreamscape forum.
cheers,
Rom
snowblindstudios.com
primarymotion.com
You should probably wait for Stephen’s reply, but WM’s use of the Ter file format is rather limited. It is meant to serve as aquick way to interact with terragen. There is bound to be some features supported by the .ter format that WM doesn’t use (like textures and so on)… So naturally, if the Dreamscape plugin uses any of them, it won’t find them on WM generated .ter files.
To work arround this, you may consider saving to a different file type that 3dsMax accepts (take care in not doing it for 16-bit formats)… Alternatively, terragen opens WM’s .ter files… So you should be able to open it in terragen, and save it as a new file, that Dreamscape plugin may chew easily 
Cheers,
Fil, actually, the .ter format doesn’t store anything else than the terrain shape and size (along with the metre point spacing)… the texture and every other settings are stored in the .tgw file.
So I don’t understand why WM ter files could be different than Terragen ones…
oops ? :shock:
Strange :?
But they definetly are… You also can’t load a wm-ter into blender (there is a script or something which allows you to do so).
OK, so let’s take a look at the files. I built a 32²-file (output), loaded it in TG and saved it with TG (output2).
Here’s the result:
You see WM doesn’t use some of the “chunks”. But according to the specification these are optional anyway.
Maybe some programmers didn’t know that these are optional.
Another thing I noticed is, that wm adds 2Bytes somewhere in between the altitude data! While the wm-file has correct (32+1)²*2byte = 2178byte of data, the TG file has two more. I believe these are two bytes before the “EOF” wich are both zero and not mentioned in the specification.
I didn’t know of that binary/hexadecimal viewer! It’s freeware even! Thanks Nikita!! 
About those 2 missing bytes, could they be a spacer for keeping the file size a multiple of something?
You also have to keep in mind, that the leveller-format is also .ter.
But that doesn’t explain why some tools support a tg but not a wm heigtfield.
For those who don’t know - I’m programming my own terrain-editor wheneber i have the time.
Today I noticed that when I write terrain files, I also add these two zero-bytes before the "EOF ".
But I don’t know why.
Ah, now I know! You were right Fil, it has to do with multiples.
All chunks are aligned to the nearest 4 bytes. Each chunk contains a 4-byte marker (eg. "ALTW"), then some data.
Let’s just say the position of the first byte in the file is 1, the next position is 2 etc.
Now there is the file header which wm writes correctly. (its length is a multiple of 4 and each chunk starts at a multiple of 4). Then there is height data.
Usually, terrains have a resolution of ( (2^x)+1 )² wm creates files in this way too. (eg 513 = (2^9)+1 )
Now these are:
( (2^x)+1 )²
= (2^x)² + 2*(2^x)1 + 1²
= (2^x)² + 2(2^x) + 1 height values that describe the heightfield. 2^x ist always a multiple of 4 when x>1 so there is no problem with the (2^x)² + 2*(2^x) part - if the heightfield had this length the length would be a multiple of 4 and thus if you’d put the EOF chunk right afterwards it would also start at a multiple-of-4 position.
But the 1! There is one height value left. A height-value is represented by a two-byte number. So that is two additional bytes somewhere and the total length of the heigt data is a multiple of 4 plus 2.
That is why you have to add two more bytes - so "EOF " starts at a position which is a multiple of 4.
Now it would be interesting to see if this solves the incompatibility problem with wm made terrains.
:mrgreen:
That’s easy… grab a WM generated terrain, edit the file with the hex editor puting in the extra zeros, and pass it on to someone who can teste it!..
Anyone with problems reading a WM-generated .ter file want to jump in and give it a try? Nikita, can you upload somewhere a “corrected” .ter file for testing?
There it is: http://nikita.tac-design.net/sonstiges/xfiles.rar
The file called simplewm.ter is directly taken from wm.
The file called addedbytes.ter has the two zero bytes added before EOF .
One big issue is that the folks writing Terragen don’t even follow their own file format specs. :x
I ran into this with my custom Heightmap Conversion software. Various versions of Terragen itself will output the identical file with varying use of the “optional” chunks.
Because of this, I had to code my import/export feature for .ter to support the entire chunk system with handling of varying file styles.
WM unfortunately will have to do the same if the other software applications mentioned (Dreamscape etc.) are not written to properly handle the so-called optional chunks.
You may wish to see my post in another thread regarding 3DS Max and WM. You are better off converting directly from WM output to mesh if you are currently using displacement maps.
This is really easy to do.