Question about SMOD file format

I mean, the 'mesh' that defines a terrain.
According to the wireframe view in the game, the terrain looks like made of 'squares, split in 4 triangles each' (due to that vertex in the center).

"According to the wireframe view in the game" ?!?
How do you obtain such a view?

normal chat commands /wire and /basic (wireframe and normal views) at least on EP5 game.exe
As you can see in wireframe, around the ground theres a kind of 'dome' mesh. I asume if to create sky?

I as thinking on make a 3d grid 512*512, then edit the azimut to make mountains,etc, and with a script iterate over the vertices and write the azimut value to a file, and use it as a terrain.

Also, one could paint a few textures over the 3d terrain (in the 3d package), and with a script check each vertice to see what material (texture) is using, and write that index to a file to be used in the WLD section.

I've seen in the scripting manual, that one could even read bone info (from 3DC files), so you could edit armors (or mobs?), and then save the bone info back, But I doubt anyone would be willing to take the time required to model new mobs, armors, etc.

Quote:

Originally Posted by sominus chat commands /wire and /basic ... As you can see in wireframe, around the ground theres a kind of 'dome' mesh. I asume if to create sky?

well actually, I cannot see it, since as of today I haven't GM rights on any server; so I cannot comment on what could be the ground definition based on the wireframe drawing that maybe the actually defined lines or a construction on defined points.
what I know for sure is that when a .wld claims to have a 1024 size, we can read 263.169 azimuths and 263.169 texture IDs which means information for 512*512 tiles. It cannot be information for 4 corners of a tile plus its center since 363 * 363 tiles will generate 262.813 figures and 364*364 tiles 264.265

so, to repeat my point of view, the point n°5 in your last figure (the center of the tile) does not exist in the map-field data and so each tile is drawn as a square (not as 4 triangles).

That's good news, because I was having a hard time trying to make those 4 triangles with a script :p, now drawing a grid with just squares, is just a mouse click.

Edit:
Tried with a flat 3D plane, 1024x1024 (generic units, which equals to 26 meters), 512 x 512 segments, and the result is:
"Vertex Count: 263169"
"Face Count: 524288" (each square tile in the grid, is divided in 2 faces)
Will try to save the height value of each vertex to a binary file, to see if the data lenght is the same as in WLD files.

ok, I've succeeded to make a few checks in /wire mode [1] and indeed, each tile is drawn with 4 triangles.

Possibly the diagonals are generated by the code (meaning they are not in .wld file) but the selection and use of textures become (far) less obvious.

The scaling of X & Z coordinates is also puzzling, on map 16, the tile seems to have a size of 8.0x8.0 units at corner (0, 0) and 16.0x16.0 units at corner (2048, 0) while the mapSize of 2048 is assumed to mean 1024x1024 tiles (so 2.0 units by side).

Being able to load custom map (.wld) would be helpful to better understand the logic.

[1] Many thank to [Only registered and activated users can see links. Click Here To Register...] admin who gave me temporary GM rights to do so.

EDIT:
Im testing to export a flat 3d mesh to see if the game loads it.

Im 'rounding' the floats from 3d studio to use just the integer part (Eg 10.25 becomes just 10), to be able to save the vertex coordinates as short values. (Don't know if there is another method to convert floats to shorts)

The output binary data is 80802h lenght. Now, 1 unit distance in 3dstudio, translates to 0.0001 units distance in shaiya (more or less), so I've put a multiplier in the convert script, but it is not exact yet.
Also, y=0 in 3dstudio, translates to a ground below the sea level in the game, so I had to Add +13000 to the base height before converting.

So far this shape in 3dstudio

Translates to this terrain in the game (the texture was not added by me)

About the texture, I think a previous post of yours was right, it checks what texture index is applied to each vertex coordinate. The problem is how 2 textures blend.

We have yet to find the right size of each tile in the game, to make an editable 3d mesh of the correct size, so shapes won't be distorted when ported to the game.

And of course you were right, looks like the central dot and diagonals are added by the game engine.

Quote:

Originally Posted by sominus EDIT: Im testing to export a flat 3d mesh to see if the game loads it. Im 'rounding' the floats from 3d studio to use just the integer part (Eg 10.25 becomes just 10), to be able to save the vertex coordinates as short values. (Don't know if there is another method to convert floats to shorts) The output binary data is 80802h lenght. Now, 1 unit distance in 3dstudio, translates to 0.0001 units distance in shaiya (more or less), so I've put a multiplier in the convert script, but it is not exact yet. Also, y=0 in 3dstudio, translates to a ground below the sea level in the game, so I had to Add +13000 to the base height before converting. So far this shape in 3dstudio  Spoiler [Only registered and activated users can see links. Click Here To Register...] Translates to this terrain in the game (the texture was not added by me)  Spoiler [Only registered and activated users can see links. Click Here To Register...]  Spoiler [Only registered and activated users can see links. Click Here To Register...] About the texture, I think a previous post of yours was right, it checks what texture index is applied to each vertex coordinate. The problem is how 2 textures blend. We have yet to find the right size of each tile in the game, to make an editable 3d mesh of the correct size, so shapes won't be distorted when ported to the game. And of course you were right, looks like the central dot and diagonals are added by the game engine.

Shaiya client converts heights from short to float using the following formula: (short) height_from_wld * 0.2 + (-200.0)

upd:
IDA badly defined float on screenshot, in CE everything is ok

Quote:

Originally Posted by Призрак урана Shaiya client converts heights from short to float using the following formula: (short) height_from_wld * 0.2 + (-200.0)

Could you please give asm code (the bytecodes) for these instructions (or any info that let's locate the operation)?

The map-height viewer of shStudio normalizes heights as about:
height = (height_from_wld - minHeightFromWld) * 0.03;

(the coeff 0.03 is exactly: ∆x / (5 * ∆y), so specific to each map (specific to its range of azimuths, and that was likely not a good idea).

your coeff of 0.2 seems too high from my point of view.

I'm trying to do the inverse now, read the terrain block from a WLD and create a terrain in 3dstudio, and use the data to shape a 3d plane, and see if it looks the same as in the game.
But I can't find documentation on how to convert a ReadShort value to a Float in MaxScript.

EDIT:
Sorry it was my mistake, I was using path="d:\3dsmax" an it was "D:\\3dsmax" so variables were actually empty, thus giving me error.

Quote:

//f is a file stream (is reading the first 2 bytes of a terrain block from 18.wld) a = ReadShort f b = Float(a * 0.2 + (-200)) gives me b = 1860.0f (which seems to high? ) With 0.03 it gives me 109.0f

UPDATE:
This is how 18.wld looks in 3dstudio with imported terrain data:
Here I added the 18.tga minimap as a texture:


This is the steps, for anyone who has 3dstudio:

1) Copy the script code in Notepad and save it as myscript.ms

2) Create a Plane with the mouse (Primitives TAB, "plane")
Edit the parameters:
-Lenght 1024 Width 1024
-Segments: 512 x 512
-Scale 1, Density 1

3) Change the object name (Plane01) to "ground" and Right CLick the object and choose "Convert To: Editable Mesh")

4) Run the script (Utilities TAB, MaxScript, Run Script), and run myscript.ms

5) Wait a few seconds, and then plane now should look like 18 map.

This is the code I used:

Dont know if the Round FLoat function (function roF) is mandatory, I just use it for printing values.

*You can also use 3dstudio own Code Editor, for better sintaxis highlighting if you want (I use VS Code, with a maxscript extension, since it has a little intellisense)

Quote:

Originally Posted by castor4878 Could you please give asm code (the bytecodes) for these instructions (or any info that let's locate the operation)? The map-height viewer of shStudio normalizes heights as about: height = (height_from_wld - minHeightFromWld) * 0.03; (the coeff 0.03 is exactly: ∆x / (5 * ∆y), so specific to each map (specific to its range of azimuths, and that was likely not a good idea). your coeff of 0.2 seems too high from my point of view.

I use Shaya PT (it seems 7 ep) if you are comfortable then I can find this function in another game.exe that you useAnd yes, I made a mistake with the coeff, correct one will be 0.02, sorry =\

The game engine do something else with the heights, if I create a flat terrain and move up just the first 4 vertices, that does not translate to a in-game terrain with just the first 4 vertex raised. It's like the game do some "average azimuth" kind of function with the surrounding vertex. And the central dot added by the game, should have a reason to be there.

Quote:

Originally Posted by sominus The game engine does something else with the heights, if I create a flat terrain and move up just the first 4 vertices...

What does mean the "first 4 vertices" ?
Keeping my assumption (and best understanding of the .wld data), the client defines the map by the azimuths of a square mesh of the surface.
Since I understand that you create the surface with 3DStudio (w/o knowing how; it is a set of triangles or squares?) and export it using your conversion method, does it mean you change Y (azimuths) of the 4 vertices that form the 1st square? How much do you change them? What are the values of the converted map-height?

I've followed your remark (your tip) to draw a textured view with the minimap tga file (instead of handling actual texture IDs); I obtain the following for the map 18:


We don't know how these minimaps were produced, but for sure the heights read from .wld and scaled as described above (I used: y = 0.015 fileAzimuth - 200); do not generate the same ground as the client (the light blacksmith is definitely not on a hill).
So I'm still not 100% sure that we read and use the map-height data exactly as we should.

Sorry I didn't explain correctly:
I rise the height of the first tile (a square with 4 vertex) in the x0, y0 corner in the map, so in the game the terrain should look flat, with the fist tile rised.
But it dosn't :( Eg: Just the fisrt vertex rises, or the first and second, etc. So as you say, the game is doing something we're missing, with the height info, before using it on the mesh.

Here's what happens: 4 vertex rised in 3dstudio, but just 1 vertex rised ingame.

About the source mesh in 3dstudio: is a big flat plane, divided in little square tiles, each tile is formed by 4 vertex and 2 triangle faces.

In your picture, your coef seems to low, in my picture the mountains are higher (I used coef 0.03, the more you use, the higher difference in altitudes.

Edit:
See the blacksmith here is not in a mountain.
I've included a pic of my source mesh, the first tile, 4 yellow vertex, 2 red faces (only one is selected).
And the blue lines are 'edges', the whole plane has 512x512 edges.

If I translate that to the game, it shows just the first vertex (index 0), rised just a little.

Anyway, in 3dsmax Im using 'max units' which might be different to shaiya-units. Actually I don't know "what are shaiya units", pixels? metters? something else?
And TBH is a little hard to model a full terrain in 3dstudio (at least in the old version 2010). I remember Unity3D had better tools to do that.

I still can't find a correct way to export UV coordinates in my smod script, the textures look all messed up in game.