Author Topic: Problem with size preset node  (Read 625 times)

Cryunreal

  • Sr. Member
  • ****
  • Posts: 55
Resolution preset has two parameters. Size in meters and Size in points.

If user set "Size in meters" 16384 and "Quad size" 1.0, absolutely logical the final result of texture should be 16384, but no! The final result of export texture will be 16385!
And all nodes using this preset have 16385 resolution.

I think you understand how many troubles it it generates.

This is critical problem, i think lot of people meating this.


Alexis Vaisse

  • Administrator
  • *****
  • Posts: 165
There is no bug: if the size of your terrain is 16,384 meters and the quad size is 1 meter, you will get 16,384 quads. As the number of vertices is equal to the number of quads plus one (for instance if you have 2 quads, you have 3 vertices), you get 16,385 vertices.
If you export the terrain as a heightmap, you have 1 pixel per vertex so the size of the texture is 16,385.

Cryunreal

  • Sr. Member
  • ****
  • Posts: 55
Mesh density should not be tied to highmap resolution. There is no need to control this, but the user needs to set the resolution of hightmap, and not the number of vertices.

Hightmap - raster image, the same as color. And it should has the same settings.

it is very confusing and incomprehensible.

You need to place first the textures resolution, because this is very important for export to applications where this hightmap will be used. Number of vertices in instant terra does not matter for users ever.

Danilo Nishimura

  • Sr. Member
  • ****
  • Posts: 66
  • Senior Technical Artist at Massive Entertainment
tldr; Wysilab is absolutely correct on their approach.

First, regarding your last comment, in my honest opinion, I think it's the other way around. You define the look of what you're creating, and when you're happy with it, export it to whatever resolution you want to use.

Now regarding the mesh density and size, I think this is just a bit of misunderstanding on why things are like this.

First, about the size. As Alexis said in his own words, vertices are mapped to pixels, one by one, so you can correctly reconstruct the mesh when reading the texture. If you have 1025x1025 vertex positions, you need 1025x1025 pixels.

Now why is it 1025 and not 1024?
A single quad mesh has 2x2 vertices. One for each corner of the quad. If you slice it up in the middle, you have a 2x2 quad with 3x3 vertices, because they share the edges, so they share the vertices. If you slice each quad in the middle again, you'll have 4x4 quads with 5x5 vertices. You need that +1 pixel. You shouldn't just "guess" the last vertex height just to keep the texture as a power of two. That doesn't make sense.

(ignore the quad colors)

The 3D software/engine reads the texture and reconstructs the terrain mesh. That's usually not a realtime thing, so it's not a problem that its size is not a power of two. The engine will convert that information to their own data structure.

Supposing you used a 1024x1024 texture to recreate a 1024x1024 terrain, you would end up with two of the terarin edges (probably the right and top ones) copying the previous pixel information. If you're using just one terrain, it might work just fine, but if you're tiling and stitching terrains together, that means that at each terrain intersection, there will be a mismatch between one terrain and the other.

There would be a different case if you were loading the texture at runtime to raymarch the terrain texture and recreate that terrain per pixel. In that case, I'd just crop out the extra pixel (you can automate that with instant terra api).

Now about size, @Alexis feel free to jump in and correct me if I'm wrong here, but the correct size in meters affects more than just "resolution", It's also used evaluate the erosion and other algorithms, which means the size and scale is important to correctly replicate the physical phenomena. If you're simulating a terrain with correct size and scale, the result will make much more sense than just keep bumping values up and down, not understanding why the value range doesn't make sense.
« Last Edit: July 07, 2021, 10:52:05 PM by Danilo Nishimura »

Cryunreal

  • Sr. Member
  • ****
  • Posts: 55
I understand what you mean, but i disagree with you, because this is bad UX. Make focus test and you will see that lot of users will make 1025 x 1025 resolutions on export.
I think Wysilab just need to swap Size in meters and Size in points in UI.
« Last Edit: July 09, 2021, 02:20:27 AM by Cryunreal »

Danilo Nishimura

  • Sr. Member
  • ****
  • Posts: 66
  • Senior Technical Artist at Massive Entertainment
Well, in my opinion, the information there is pretty straightforward, I don't see any reason to change that.
I do agree that testing with users is useful though. That will show if a lot of users are creating 1025x1025 sized terrains (not that it is a problem).
« Last Edit: July 08, 2021, 05:31:43 PM by Danilo Nishimura »