Blueprints Format (Unity)
- paulevs
- Thread is marked as Resolved.
-
-
-
-
-
I have a small note - terrain data stores array capacity between 3 array dimensions and actual terrain data, so most my attempts to write data looked like this before I found the reason:
Oh, sorry, I forgot to mention that Yeah terrain is stored as a flattened 3d array. To get the actual index from x, y and z values, you can use x + y * sizeX + z * sizeX * sizeY
I'll update my original post accordingly
Also looks like terrain data is stored with [id-strength] order instead of [strength-id] order (which I noticed during test output), probably this is related to stream order
Yes, it indeed depends on the endianness, we're using little endian everywhere (unlike the Java version, which used big endian), so the strength is stored in the first 8 bits while the id is stored in last 8 bits
Hm, looks like grass used some bite tags? I found that I can create grassy blocks with missing data and very long grass
Grass ids are currently between 100 and 145 The grass type is stored in steps of 5 (100 is regular grass, 105 is arid grass, 110 dry grass, 115 is dead grass, 120 is frozen grass, 125 is forest grass, 130 is jungle grass, 135 is sea grass and 140 is seaweed). The subsequent 4 values describe the grass length (the game uses fixed values depending on the grass type), so for example, 100 is plain grass (no blades), 101 is short grass, 102 is the default grass length, 103 is tall grass and 104 is very tall grass. 105 then is plain arid grass, 106 is short arid grass etc.
-
It may be the wine on a Sunday night, but my mind is scrambled.
x + y * sizeX + z * sizeX * sizeY
-
Are we talking x, y, z locations on a flattened x y map?
So for example x 0, y, 0 would contain something like (5,7,2)?
-
x + y * sizeX + z * sizeX * sizeY
What's so funny about that?
Are we talking x, y, z locations on a flattened x y map?
So for example x 0, y, 0 would contain something like (5,7,2)?x, y and z are the coordinates for the 3D terrain array (which is stored in terrain blueprints) If you wanted to store terrain in a 3D array (where x and z are indeed the horizontal positions and y is the vertical position), it would basically look like this in Java, for example:
For reasons of performance or serialization, it's usually better to represent the 3D array as a flattened (1D) array - but now you can no longer access the index easily, so you have to convert your x, y and z coordinates to a new index:
-
Grass ids are currently between 100 and 145 The grass type is stored in steps of 5 (100 is regular grass, 105 is arid grass, 110 dry grass, 115 is dead grass, 120 is frozen grass, 125 is forest grass, 130 is jungle grass, 135 is sea grass and 140 is seaweed). The subsequent 4 values describe the grass length (the game uses fixed values depending on the grass type), so for example, 100 is plain grass (no blades), 101 is short grass, 102 is the default grass length, 103 is tall grass and 104 is very tall grass. 105 then is plain arid grass, 106 is short arid grass etc.
Thank you, I already found that when I placed all possible IDs on map
So basically ores are on 50-55 range (56-99 is reserved)
Grasses are on 100-144 range (145-200 is reserved, can be used to generate cool red grass on black terrain)
Water is 201 and 202 (and repeating up to 255, probably other liquids will be stored after it)
And normal terrain is on 0-31 range. There are also some addional grass entries. All these things will be added as constants in next BlueLib version
-
What's so funny about that?
x, y and z are the coordinates for the 3D terrain array (which is stored in terrain blueprints) If you wanted to store terrain in a 3D array (where x and z are indeed the horizontal positions and y is the vertical position), it would basically look like this in Java, for example:
For reasons of performance or serialization, it's usually better to represent the 3D array as a flattened (1D) array - but now you can no longer access the index easily, so you have to convert your x, y and z coordinates to a new index:
Thanks for the code examples. I *think* i get this now. I would need to run some practice code myself to be confident in it. But it feels like it makes sense.
-
Thank you, I already found that when I placed all possible IDs on map
So basically ores are on 50-55 range (56-99 is reserved)
Grasses are on 100-144 range (145-200 is reserved, can be used to generate cool red grass on black terrain)
Water is 201 and 202 (and repeating up to 255, probably other liquids will be stored after it)
And normal terrain is on 0-31 range. There are also some addional grass entries. All these things will be added as constants in next BlueLib version
Looks awesome. Maybe I'll try your lib, if not too complicated for me.
Gives me the idea of little water ponds nearby / at the seaside where some
some crabs, mussels or other animals can live. Maybe the idea of sharing nice terraformed blueprints with others.
-
red51, good day, I think that I found a bug in blueprints. On preview plants are placed on terrain (left), but when this blueprints is placed in the world all plants are offseted by all 3 axis (right)
Blueprint for testing: Floating Island.blueprint
-
-
-
The format is still the same The alignment setting is stored in the "flags" bitmask of the construction element. 4 (0b100) is the value to force world alignment, 8 (0b1000) is the value to force local alignment. If these two bits are not set, the default texture alignment is used (which is usually the world alignment, but that depends on the texture).
Participate now!
Don’t have an account yet? Create a new account now and be part of our community!