Bald Eagle wrote on 30/07/2020 12:59:
> A bit more progress:
> 
> Got the cartesian to spherical to uv conversions worked out, used the mapping to
> look up altitude at any given point, and have bezier arrays for each of the
> tiles.  Using the mapping to sample the center rgb value of a tile from a color
> world map gave me a rough value which hopefully may be used to automate terrain
> designations and texture definitions.
> 
> I overrode the random format assigned to the tiles, and made them all bezier
> patches - about 1500.  Elevation is greatly exaggerated (x300).  Can render as a
> wireframe of bezier splines, and still have to work out how to generate the
> appropriate heightfields from the world map for the individual tiles.
> 

More and more interesting...

Paolo

Post a reply to this message

I managed to code most of the "user-side" of the project, where the customized
options and scene description for that tile region gets stored.  All of the
infrastructure gets generated and stored, and tiles get enabled by renaming from
..tmp to .inc

Presently I just have a simple user-defined checker texture that can be
uv-mapped on the terrain for that tile.

I need to adjust my world image_maps so that the Greenwich Prime Meridian is at
x=0, and then do some verification that all of the lat/long calculations are
correct.

I'm thinking about how to partially uv-map a tile with a map or satellite data -
probably an image_map once and some scaling.
The map square shown is just a double triangle textured with an image_map, and
it floats in space.

The whole thing gets pre-generated in a very short amount of time (1500 tiles)
and renders extremely quickly.

I need to smooth out the bezier seams then begin to work on how to tie in
subdivided tiles of different levels of detail.

Also some mechanism for determining which files need to be edited given a
certain view would be a huge step forward in terms of ease-of-use.

Post a reply to this message

Attachments:
Download 'myplanet.png' (146 KB)

Preview of image 'myplanet.png'

OK, got my image map oriented, and have a Prime Meridian indicator.
I have a macro for determining what tile includes a given point, so the proper
file(s) can be edited.
Got rid of relative filenames.
Need to tweak the implementation a bit, using the ini and shell command stuff.
I have uv_mapped tile numbers, and I fixed the Bezier array so that it uv maps
the correct way.
(was thinking maybe checkerboarding the tilename colors and/or orientation +/-
45 deg)
Added prefixes Planet_ and User_ to tile filenames on either side so that they
are easily differentiable without knowing the path (like looking at the filename
in an editor) ;)
Moved the tile generator and the tile index file into the PlanetCode directory
so that they're not mixed in with the tiles.

Reworked my bilinear interpolation macro into a function, and used that to
create a function pigment in order to take the pigment at each of the 4 corners
of a tile and interpolate the rest of the tile.
Added normals, and finishes with some control variables.

Parse - 7 seconds
Render - 11 seconds.
24 x 24 tiles per face = 576 * 6 faces = 3456 tiles.

Post a reply to this message

Attachments:
Download 'myplanet.png' (535 KB)

Preview of image 'myplanet.png'

So, even with the not-working normals, it's starting to look pretty good.
This is the "full" 48,000 basis-tile planet which will have (6?) levels of
subdivision created on an as-needed basis.

Takes about 3+ minutes to automagically create 48,000 infrastructure tiles plus
an additional 48,000 user tiles that will implement all of the user content.

Takes about 6+ minutes to parse it all and render.

I need to do some smoothing of the bicubic patch edges, and start working on the
camera-distance driven subdivision, using a (already written and working) custom
type of specially-modified quad-tree.
And then absolutely filter out everything not in view to keep the memory usage
and parse time way down.

Helpful comments and ideas very very welcome.

Post a reply to this message

Attachments:
Download 'myplanet.png' (553 KB)

Preview of image 'myplanet.png'

On 5/25/2020 7:42 PM, Bald Eagle wrote:
> So, I played around with this a bit more.
> 
> Got some tile face normals, used the array indices to generate tile labels.
> Reworked the cube-to-sphere transform.
> 
> Need to write an animation to step through a cubic map and generate image maps
> for all the tiles.
> 
> 
> I'm not exactly sure how to generate a tile, map it, then translate/squish it to
> fit in its proper space.
> 
> 
> This is at a "face resolution" of 12, which give an 11x11 tiled side of the base
> cube (so the labels are legible)
> 
> The idea here is that at full resolution, each tile will have an associated
> image map or include file for rendering whatever goes there.
> 
> This only took 2 seconds to render.
> 


Would be interesting to use this for a LEGO project. Not sure the LEGO 
system's "magic numbers" can be made to properly fit a sphere though 
without stressing the fragile plastic.


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> Would be interesting to use this for a LEGO project. Not sure the LEGO
> system's "magic numbers" can be made to properly fit a sphere though
> without stressing the fragile plastic.

You'd have to create a LEGO system designed for spherical shells.
As the altitude increased, the arc-length of the pieces would have to increase
to compensate.

So, every piece would have to be a curved wedge shape.

I guess we could bend the existing shapes...
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d4b7ce3a683fa3a4eec112d0%40news.povray.org%3E/?ttop=430245
&toff=50

Post a reply to this message

On 2/28/2021 6:40 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
> 
>> Would be interesting to use this for a LEGO project. Not sure the LEGO
>> system's "magic numbers" can be made to properly fit a sphere though
>> without stressing the fragile plastic.
> 
> You'd have to create a LEGO system designed for spherical shells.
> As the altitude increased, the arc-length of the pieces would have to increase
> to compensate.
> 
> So, every piece would have to be a curved wedge shape.
> 
> I guess we could bend the existing shapes...
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d4b7ce3a683fa3a4eec112d0%40news.povray.org%3E/?ttop=430245
> &toff=50
> 

Or just flatten each section to create faceted dome.


Mike

Post a reply to this message