The ALB map porting project WIZARDS PLS HELP

User avatar
Hob_Gadling
Captain
Posts: 1621
Joined: Tue 14 Feb 2012 00:15
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Hob_Gadling » Sat 1 Oct 2016 21:33

integ3r wrote:Also, I tried copy pasting "district" data from ALB to RD. But that seems only to have removed all the districts. It's possible however that they were placed underground, i.e. on the wrong level since all the zones were also underground.


Have you tried copypasting district data from another RD map onto ALB maps?

RUSE map editing is pretty much the same thing conceptually as this is. Since that one has a manual available and I'm lazy...

https://steamcommunity.com/sharedfiles/ ... =393903635

I know this isn't as helpful as it could be, but it's much easier to start editing existing stuff than try to recreate it completely from scratch.

User avatar
integ3r
Lieutenant
Posts: 1143
Joined: Mon 3 Jun 2013 03:10
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby integ3r » Mon 3 Oct 2016 08:00

Hob_Gadling wrote:
integ3r wrote:Also, I tried copy pasting "district" data from ALB to RD. But that seems only to have removed all the districts. It's possible however that they were placed underground, i.e. on the wrong level since all the zones were also underground.


Have you tried copypasting district data from another RD map onto ALB maps?

Essentially yes. Because the fastest way to get stuff working is replacing the map file. The map file is just the terrain. So it still uses the district and zone data for the map it replaced. So all the districts are functional... it's just that they're from the old map.

I think the district data might be the most compatible though. I was able to just copy it from ALB to RD and AT LEAST it didn't crash. But it might not have worked regardless, as I said, I couldn't find any districts at all ingame.

Hob_Gadling wrote:
RUSE map editing is pretty much the same thing conceptually as this is. Since that one has a manual available and I'm lazy...

https://steamcommunity.com/sharedfiles/ ... =393903635

I know this isn't as helpful as it could be, but it's much easier to start editing existing stuff than try to recreate it completely from scratch.

I think it points me in the right direction at least. Adding maps to the dropdown list is low priority, but something I would like to do eventually to keep this compatible with the main game. That way it's easy to encourge people to just "get the map pack" with no hassle.

Priority 1 is functional zones and districts. 2 is buildings and assets and textures. Camera bounds are easy and I already know how to do it.
"How do into gaem of war? How 2 git gud?":
Spoiler : :

User avatar
Hob_Gadling
Captain
Posts: 1621
Joined: Tue 14 Feb 2012 00:15
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Hob_Gadling » Fri 7 Oct 2016 21:05

Should probably post this here too...

If someone among the readers knows what this is all about:

https://kwasi-ich.de/blog/bytenormals/

let me or integ3r know about it. We got some good stuff brewing, but we don't understand the underlying structure well enough.

User avatar
Eukie
Chief Warrant Officer
Posts: 515
Joined: Wed 23 Apr 2014 16:22
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Eukie » Sat 8 Oct 2016 01:01

Hob_Gadling wrote:Should probably post this here too...

If someone among the readers knows what this is all about:

https://kwasi-ich.de/blog/bytenormals/

let me or integ3r know about it. We got some good stuff brewing, but we don't understand the underlying structure well enough.


OK, so, a Normal is some kind of lighting-thing I don't know much about, but I think I can explain the computer-math on the website you linked.

When pre-calculated, the normal is given as a three-dimensional vector of length 1. The Normal consists of 3 floating-point numbers that span the range from -1 to 1. That's one float for the x-dimension, 1 float for the y-dimension, and 1 float for the z-dimension, or 12 bytes in total.

That's a lot of bytes, so naively we may think to convert each float to an 8-bit integer to represent the normal and make that 3 bytes instead of 12. However, this introduces some rounding errors, as the floats are rounded towards zero when converted to ints. The normals will always be vectors pointing to the surface of a sphere of radius 1. To reduce these rounding errors, the webpage suggests making the normal-vector point to spaces inside and outside the sphere.

Image

This is the diagram they use. We have a 2D normal (red) described with 8 bytes of floating-point data, which gives the red dot. We want to convert it to 2 bytes of int data. If we multiply each float by 127 and convert to an int, we get the green dot. The integer values are described by the grid-lines, and the green dot can only lie where the grid lines intersect. Here, (6,4) However, looking at the green line, we can see that when we draw the normal onto the sphere of radius 1, it's quite far from the red line. This is because of rounding.

And that's no good!

So what this website proposes is to describe the normal with points that can also be outside or inside the sphere. By making the 2 bytes point to (8,6), the yellow dot, we get a vector that's much closer to the red line but is not of length 127. This way of storing normals as vectors of any length anywhere on [-127 127]^3 allows far greater accuracy than only storing normals as vectors of length 127.

So basically, instead of converting float_x to int_x, float_y to int_y, float_z to int_z for storage and then back again for calculations, this method determines which vector (int_x, int_y, int_z) is most parallel to (float_x, float_y, float_z) and stores that instead. It takes the same 3 bytes, but is more accurate and basically no more computationally intensive.

If that wasn't clear, tell me and I might be able to whip up some pseudocode that shows how normals are stored this way.

User avatar
Hob_Gadling
Captain
Posts: 1621
Joined: Tue 14 Feb 2012 00:15
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Hob_Gadling » Sat 8 Oct 2016 12:51

Eukie wrote:OK, so, a Normal is some kind of lighting-thing I don't know much about, but I think I can explain the computer-math on the website you linked.


Okay, I think I got it. Cool.

The previous effort is documented here:

viewtopic.php?f=187&t=53287

This is why I'm asking:

Code: Select all

2B 00 00 00 FF 7F 00 00  // headers

// The next part is zone locations. 6 bytes of something (maybe the first corner point, maybe a name for the zone, maybe something else) followed by 3x2 bytes of corner points for zones.

19 65 75 73 FF 7F
   D3 09 15 6B 00 00
   DC 01 95 73 00 00
   34 02 89 1F 00 00
   E6 1A F0 7A 00 00
12 4F 63 74 56 55
   8B 7F 0D 68 00 00
   A1 7B 9A 74 00 00
   61 0A F7 7B 00 00
   E4 06 CB 71 00 00
...


And so on. The last time we were stumped on how to define zone vertices since there's so little data. 3x2 bytes seems too little. Maybe it is 2x3 bytes and zones are 2D?

User avatar
Eukie
Chief Warrant Officer
Posts: 515
Joined: Wed 23 Apr 2014 16:22
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Eukie » Sat 8 Oct 2016 14:45

Hob_Gadling wrote:And so on. The last time we were stumped on how to define zone vertices since there's so little data. 3x2 bytes seems too little. Maybe it is 2x3 bytes and zones are 2D?


It's possible that zones are defined in 2-byte blocks and then scaled up to fit the map. So a zone vertex can only begin in on each 256th point or something.

User avatar
Eukie
Chief Warrant Officer
Posts: 515
Joined: Wed 23 Apr 2014 16:22
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Eukie » Sun 9 Oct 2016 15:16

I've strong reason to believe that the coordinate data is stored as two blocks of 14-bit data followed by 4 bits of data about the axes and stuff. So if you have D3 09 15 6B 00 00, that's D3 09 15 6B and two bytes of padding. This becomes 1101 0011 0000 1001 0001 0101 0110 1011

Where the first block of 14 bits is 13506 as an unsigned 16-bit int, and the second is 4438, giving the Cartesian coordinate (13506, 4438).

I also think that in-game Wargame3 converts these back to floats, using x_float = x_int/8191.45 -1 and equivalently for y, for ingame use. So the coordinates become (0.648, -0.458) to three significant figures.

User avatar
integ3r
Lieutenant
Posts: 1143
Joined: Mon 3 Jun 2013 03:10
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby integ3r » Sun 9 Oct 2016 17:28

I'll spend some time on this later when I can make the time... (probably in a couple of weeks)

But for the obvious question.. Is it impossible for the initial 6 bytes to simply reference an initial point on the map (either first corner in the zone or just an arbitrary anchor point for the following coordinates), each 2 bytes representing an int value (X, Y, Z, for a total of 6 bytes) with the following ones being relative coordinates to the first one? So the 00 00 parts just represent a relative Z value. (I.e.: They're on the same plane as the first). Is that really too little data?
"How do into gaem of war? How 2 git gud?":
Spoiler : :

User avatar
Hob_Gadling
Captain
Posts: 1621
Joined: Tue 14 Feb 2012 00:15
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby Hob_Gadling » Sun 9 Oct 2016 18:10

I have a strong reason to believe Eukie is on the right track.

User avatar
The W:AB Noob
Lieutenant General
Posts: 4538
Joined: Fri 12 Jul 2013 22:29
Location: United States, Central Time Zone
Contact:

Re: The ALB map porting project WIZARDS PLS HELP

Postby The W:AB Noob » Sun 9 Oct 2016 20:33

I have a strong reason to be excited.
W:RD Sandbox Mod 5.4.2, the Final and Ultimate Patch Click -> Image

Who is online

Users browsing this forum: No registered users and 4 guests