Skip to content

LOD slicing, UV mapping and orthographic scale#4

Open
memo33 wants to merge 30 commits intoGoldenQubicle:masterfrom
memo33:slicing
Open

LOD slicing, UV mapping and orthographic scale#4
memo33 wants to merge 30 commits intoGoldenQubicle:masterfrom
memo33:slicing

Conversation

@memo33
Copy link

@memo33 memo33 commented Jul 27, 2024

This PR implements several things:

  • slicing of rendered images that are larger than 256 px.
  • slicing of LODs for export for each zoom/rotation.
  • UV mapping for exported LODs.
  • correction of orthographic scale for all zoom levels (especially zooms 1 to 3 were quite a bit off of the correct scale); the computation is now based off of the scripts included in BAT4Max 5.
  • smaller (non-square) dimensions for rendered images smaller than 256 px.
  • support for more than 16 images per zoom/rotation for large buildings.
  • roadmap.
  • coding style maintenance.
  • sets sun angle to that of BAT4Max.
  • HD rendering option.
  • Randomize Group ID button.

Conversion of exported .obj model files to S3D is implemented in fshgen 0.2.0+.

memo33 added 23 commits July 7, 2024 16:18
This now allows non-square output and fits better around the LOD.
This should help with finding UV-mapping coordinates for the sliced
LODs, as they can be obtained from `sliced_lod.matrix_local`.
Detached parts of LOD not intersecting canvas tile frame would otherwise
not be selected, which would immediately fail for zoom 1.
This could otherwise lead to conflicts if some zooms/rotations use nodes
and subsequent zooms/rotations or later renders/previews do not use
nodes.

Depending on whether nodes are used for anything else in the future,
this may need to be changed so that all zooms/rotations do use nodes,
but for now there is no need for nodes.
Especially for zooms 1 to 3, the orthographic scale was quite a bit off.
For zooms 4 and 5, it is more precise now as well.

The general approach follows code contained in BAT4Max 5, using a 16×16
reference cell, which renders with specific widths in pixels.

The results were verified using a pixel grid as UV-map, which resulted
in a pixel-perfect display in game.
@memo33
Copy link
Author

memo33 commented Jul 27, 2024

This PR is based on #3.

I've verified that the orthographic scale is now correct by applying a "pixel-grid" texture to an exported object. For each zoom, this displays each individual pixel without any irregularities.
2024-07-26_19 55 26b pixelgrid256

memo33 added 2 commits July 27, 2024 22:14
The fix is to render the full image (instead of 256×256 tiles) to avoid
artifacts introduced by denoising filter at the border of 256×256 tiles
when these are rendered one-by-one.

This now renders the full image, applies a denoising filter to the full
image if any, and cuts the image into 256×256 pieces as a final
post-processing step.
@memo33
Copy link
Author

memo33 commented Jul 27, 2024

When using Cycles as renderer with a denoising filter, I've noticed that the denoising lead to artifacts at the borders of the 256×256 tiles, as in the bottom right corner here:
2024-07-27_14 09 06
That would be a problem for seamlessly aligning LODs larger than 256 pixels.

I've fixed this by rendering the full image as a whole first (instead of rendering the individual 256×256 subregions). The denoising filter is then applied to the entire image. Afterwards, the image is sliced into 256×256 tiles using numpy, as a post-processing step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant