[Request] Edit .wld and Portal

When you say 'the header 803h' (map terrain), what you mean with header?
Is it the first 'row' of triangles?
As in X0 to +Xn ?

I've seen the terrain is built (in-game) from X0,Y0 to Xn,Y0 (left to right), then it goes up to the next row, and again, left to right.

Now, I asume you need 3 floats to build the most basic triangle, right? Problem is terrain data doesn't seem to be floats, or at lest they doesn't make sense.

Even using values as e.g. +0.000000xxx to create a terrain, the games translates that to a +800 height value.

In this image:

How you think triangles are built?
A-B-C and then to the right (the yellow ones, 1 2 3).

or ABC and then the magenta ones, to build a square with 4 triangles, then another 4 triangles for the next square, en so on.

Note: in that pic the terrain is flat (constant height). In this case I've used:

The size of the "height-thing" is 0x0C0C03 (789507) when the map is a square of 1024x1024 pts and 0x301803 (3151875) when the map is 2048x2048.

May be the resolution (the distant between 2 pts that define the geometry/topography) of the map is not constant, in such case, somewhere in these data is coded that resolution, it must be found and used to try to undertsand the next data ...
Or the resolution is constant, I prefer that option for several reasons, in this case the data that defines the topography of a map 4 times bigger than another must use 4 times more data.
In such case, the topo of the 1024x1024 pts square must be defined by 0x0C0400 bytes and thus an header of 0x0803 bytes is present (such header is may be present at the begening of the block, of course it is also possible that maps have a unknown / garbage / useless block of 0x803 bytes somewhere "near" the beginning (start, middle, or end of "map-height" block). So far we don't explain any byte of this block, the assumption of a descriptive header is valid but not validated at all.

Now how the map-height is built ? No idea, I asked for advices from 3D modelers expert, nobody gave feedback. Actually, i have some ideas but I don't success to validate them. Very likely, the surface is not built with triangles.

"Small" shapes, and also full dongeon, are built with vertices - meaning the classical triangles (could be also square) on which a texture is applied;each point is defined by (x,y,z) (the spatial point) + (u,v) the coords on the (flat) texture bitmap; the triangles can be as small (and many) than desired to provide a very smooth resolution, but usually it is possible to zoom enough the object to see the triangles (and not a truly curved surface). Objects in field are like that.

The ground surface generated by a map-height is *not* like that. First, the texture is usually not a single file (reuiqred if the ground is one big set of triangles), instead several bitmaps are used (and found). Also the ground can not be decomposed in triangles, as for your try, the floor is corrugated w/o flat small structures.
Schematically, the floor is drawn by a set of points defining altitudes smoothed themselves (by splines or other bezier). Still what is the resolution of map and azimut - meaning how many bits to define each individual altitude? and how many points on the 1024 pts side? ... no idea.

YOu mean the terrain is not a 'standar' 3d mesh but actually a topography model? So the distance between X,Z points is constant, but the Y (height) info is what changes?
Like having a constant size grid, then apply different height values to each point.

And the header would be a block that defines how the basic grid is built?

Now about 3d packages, I've used 3d studio time ago, but it uses heightmap info to actually 'deform' a standar square 3d mesh.
May be packages like VUE generates real topographic models, tho they result in millions of polygons.

Now, I've seen that changing the first 4 bytes (0x08 to 0x0B) does actually change the very first point in the terrain ingame (it changes it's altitude). If you edit the next bytes, then the next 'triangle' shape to the right (the yellow ones in my picture, changes its altitude also, and so on.

Quote:

Like having a constant size grid, then apply different height values to each point.

Yes, it's my best guess; issue: if 0x0C0400 bytes define the altitude of points in a physical square ... it must be a square figure (whatever the resolution), it's not th case sqrt(787456) = 887.39 :(

Quote:

And the header would be a block that defines how the basic grid is built?

Possibly, but it is also possible that it defines any constant-size-info.

EDIT:

you already note it: the values of these blocks are ugly, they don't read like int or float (getting some values in 1e-38 or illogical set of int indicates most of time an error regarding assumed format.

but this point is actually only true for the beginning of the block, the second part (+/- the 20-25% last part) looks homogeneous, and *voila* I found my square!

using the 1024 pts maps to use smaller fingures, it appears that the ""second block"" (should say "last") is 0x40401 long, each 513 bytes a 'FF' value seems to indicate the end of lines (or just particular bounds of the 18.wld), so some lines of 512 bytes to (may be) describe azimuts of 1024 pts; one byte (with 256 possible heights) at every 2 pts (since values are not similar by word or nibble), it seems that heights are coded on 1 byte.

But, actually it's 512 intervals, so 513 pts, and 513 x 513 = 263*169 = 0x040401, got it.

Now these points can be heights or simply indexes of the texture / color / whatever used to draw that point - the range of values found in 3 maps checked is a bit small, so may be indexes rather than actual heights.
only its size seems known, for a 1024² map it'is the last 40401h bytes of the "topo block", for a 2048² map, it's the last 100801h = 1*050*625 = 1025x1025 bytes of the block.

The begining of the block can be some texture (since there is no "flood textures folder" where to look for them) or altitudes coded as floats ... the work is not over (:

Could it be that the grid is a 1024 or 2048 square where each line (of the grid) is paralell to the respective 'col/row' header?

Example:


And, is just the point height what changes, but the horizontal distance between each grid point, is constant? (and we see it deformed just because of the perspective, plus the height changes)

So lets say the terrain code could be something like (Im rambling here):
(pointIDX, height), (pointIDX, height), (pointIDX, height)... etc

Or may be:
(row,col, height), (row,col, height), (row,col, height), etc...

Yes, it is very likely like that. A bit simplier actually, only heights, no identifier of the point.

The map size (the size of one side)(1024 or 2048) is known by the header info (or hard coded but it would be a bad (poor) choice).
The whole surface is so swept with a constant step* in X & Z coordinates and the "map-height" data defines the Y (azimut) coordinate.

(*) I indicate in previous post that I would prefer the same constant step for all maps, we can also imagine this it is coded somewhere in the map-header block.

Edit:

apparently, no header.

the map-height of 18.wld is:

513 lines of 1026 bytes (may be 513 int16 defining azimut on 16 bits)
513 lines of 513 bytes (may be defining texture (or filling) attribute)

Don't know if this helps:
I've walked a 1024 map in /wire view (select_a.wld), and counted a grid of 129 lines (0 to 128).
Of course each 'square' in the grid has 4 triangles in it, and the central vertex is also a point (|X|).
So, between 2 grid lines, there are 3 points affected by height.

So, 0 - 128 = 129 grid lines, plus 128 central points = 257 points (0 - 256)

I dont know, 256x256 = 'a 512 grid' ? Or may be is just coincidence.

You said Int16, does that mean 2 bytes ? Cause it seems to be coded in 2 bytes. Even in 1 byte.

Update:

Well, indeed it seems to be In16 (no header, no index, just an array of height values).
Made a test using a same value (10898):

And the result was a flat terrain in that area.

Adding +250 (10898 + 250), results in a +10 'meters' altitude diference in-game.

Great, you've got the last point. And the point was in your previous pictures, I missed it.

The map is split in small squares which are indeed drawn by 4 triangles (the square divided by its diagonals). So along 1 axe, 3 pts are required (sides of square and its center), sides are common with the previous / next squares except for first and last squares.

Since we found, for a 1024 map, 513*513 heights, it should use 256 * 256 squares, but you counted only 128, may be only half of them are used ...

Using all known info, and drawing using a point of 5 for 1024 map or 10 for 2048 map, I obtain:
Proelium (#18, 1024 pts):
[Only registered and activated users can see links. Click Here To Register...]

D-Water Borderland (#0, 2048 pts)
[Only registered and activated users can see links. Click Here To Register...]

Well, it looks like maps (not garbage) but w/o objects, textures and w/o knowing where are North and South, it is not obvious to recognize the map.

Next step, generating our maps, who is fluent with a terra-former?

Nice :handsdown:

Is that opengl? (I've tried with WPF but it was heavy on resources)

PS: I've counted 128 squares but adding each central point it could be 128 sqrt + 128 central points. Thought each point only have to be defined 1 time, since each point in the X axis will share position with a same point on the Y axis.

What you think about the Terragen file spects?
[Only registered and activated users can see links. Click Here To Register...]

Yes, all my 3D stuff is done with openGL.

128 say-left sides + 128 centers + 1 right side = 257 ... but we have 513 points (for 1024 map).

I gave a try to terragen and failed to generate the map :(
Here are the (normalized) heights of map 18 as a bmp (png actually) if you wanna try.

Edit: I've done another tries ... and I crashed terragen, I'm always excellent at beta-tests :-/

[Only registered and activated users can see links. Click Here To Register...]

It crashed on me also (testing some functions).
Anyway, the terrain generated inside Terragen using your bmp.
But the data in the saved .ter file, created just a bunch of ultra high peaks in shaiya. Also I've failed at making a terrain with just the 'required' amount of points.
Thought, terragen's Ter file seems to use an array of Int16 (heights), just as shaiya needs.

Updated:
Tested in a generator called World Machine (v2.2). It produces terragen (.ter) files also.

Using your png as source, it generated a .ter file. The height data in that .ter file, had a 80802H lenght (same as a 1024 terrain from shaiya).
So, I've just copied the height block into a shaiya map, and this is how it looks:
Can't tell if it has the map 18 'shape' of course. But it looks like a terrain at least.
Problem is, altitude range is too big. May be there's a way to parse the data, and divide any altitude above zero, by some X factor, to smooth the heights.

Update2:

This was a test with a custom bitmap as a source.
This image:

Make this terrain:
It looks weird in the pic but ingame you can see the shapes are there, in the same orientation as the source bitmap (north south east west).
Also found in WOrld Machine some tools to set the desired height limit, terrain smoothness, terraces, etc.

Now the problem would be 'how to set up the ground textures assignment.
Is there a fixed number of textures a terrain may have? Can we assign where 'X' texture will be applied?

PS: Attached to this post, is the data block for the terrain in the pic (the 80802H block that have to be inserted in a 1024 WLD file)

As pointed by Nubness, Unity3D also has a terrain modeling tool (in this case it doesnt have a generator, nor perlin noise and that stuff, but you can actually 'paint' the altitude in real time).

This is how an imported 18.wld looks like:
That's the legacy 18 map (before the robots).
Of course the entities are not there, I've just used the 18 minimap TGA from the interface folder, as a whole texture, for a better view.

Sorry to drift off the new topic slightly, but has anyone managed to insert new portals into the WLD files?
Thanks to the previous posts by Castor / Sominus I've worked out where all the portal data is held, but if i try to insert a new portal to the end of the list, even if it's a copy of the other portal data's. It doesn't seem to come into game at all. I don't get any disconnections or errors. I am adding the portals in to the SvMap as well.

Yeah happened to me on a map, also I couldn't make it display a 'name' when you point on it.

Edit:
Did you add not just the 3d Model, but also the 'logical' portal definition ?

Ah, well thanks for the reply anyway. I noticed the "name" didn't show up either, even while adding a new line into the txt file for it.
Odd that it doesn't let you add a new portal in, i tried adding in new bytes, overwriting existing ones.. neither way seems to make any difference and the new portal doesnt come into being at all.