[RELEASE] Povray Planets 1.0

[pagroove]

I believe there was a tool to fix this.

PlanetTool? Is that still available?

Yes that was it. Don't know if it is still available. Edited to add. Maybe I have this in the old archives.

[another_commander]

Planettool is still available in the Oolite repository and, in case anyone is interested, I have a Windows x86 SSE2 binary uploaded here

[Commander_X]

Probably an old non-cubmapped texture.

It is actually cubemapped. The version gsagostinho showed is from PP 1.1, while Cody's is from 1.0.
I'd say the cubemapping happened after some scaling, which broke the seamlessness of the texture.

[submersible]

I've had success in running the padre scripts for generating my own textures as follows:
- Get the povray/perl source from the link mentioned in the post.
- get megapov 1.21.1 (http://megapov.inetart.net)
- edit share/povray/cm/cm_camera.inc, remove the commenting-out from the *second* /* .. */ block, so that it is no longer commented out (that's the block containing CubeMapCamera).
- go to share/povray, run perl script.pl, install all missing dependencies one by one (I had to install perl-digest-jhash and perl-text-csv).
- run perl script.pl ../oolite/oolite_galaxy_1.csv 1 1 from inside share/povray
takes about 5 minutes per planet for me, seems to work fine (I only ran 5 though

Good luck, and thanks for the great textures! Would it be possible to just replace the existing ones with higher-resolution ones? or do they have to be 256x256 per face?

Pretty late follow up to this - but let it be known that I'm easing back into povray and texture generation and discovered something quite interesting. ecraven had access to an older generation of the povray-planets rendering code when the remaining galaxies were so graciously rendered.

It seems that in addition to not including some essential turbulence maps in the code repository, the tip of trunk was in a half-and-half state where I had been experimenting with a patched version of povray3.7 as an alternative to megapov1.2.1. This means that potentially some povray planets galaxies may be missing some render features (like antialiasing/supersampling and lower distortion cube mapping) which had been working on at that time. This also explains why certain parts of the povray scene description language needed to be uncommented in order to compile to valid megapov1.2.1 SDL.

There's a lot of tidying to be done here, I feel like the patches for povray3.7 I had developed are either lost forever or gathering dust on an HP laptop under the stairs (It could be landfill by now - I haven't found it yet). IIRC they were largely to do with adding pigment warp features from megapov to the newer povray version , and to embrace newer povray camera capabilities.

I'm going to dig around some more and report back. A somewhat tidied but still not-right-yet version is now on github for the curious -
https://github.com/submersibletoaster/p ... nets-build . Dockerfile included.

[vaxon]

Please, reload the archives to gdrive because galaxies 4,5 are missing.

[submersible]

Please, reload the archives to gdrive because galaxies 4,5 are missing.

Better - switched over to cloudflare and a domain for itself. Please see initial post for updated links.

[Cholmondely]

Please, reload the archives to gdrive because galaxies 4,5 are missing.

Better - switched over to cloudflare and a domain for itself. Please see initial post for updated links.

Thank you for this!

[cbr]

Here I viewed/used a cubemap povray texture from G7 ( in lave=earth.oxp )

The higher the resolution the smaller is the seam...


Here I convert a povray texture from cube to cubex,
the seam is not showing in the side by side placed images ( conversion by planettool )
only in the vertical placed images

Looks like the seam is about one pixel big.



I also converted this cubemap to a latlong map there also an irregular seam became visible on certain place,
seam size also looked like 1 pixel big.

[cbr]

Comparing a converted cubex to the original povray planet texture.

The converted cubex ( which i believe should only rearrange the original 6 images ) shows the pixel shift also.

I overlayed an original povray planet image to compare quality, size. The converted image was shifted 1 pixel horizontal
and 1 pixel vertical, image quality showed a little blur.

Perhaps oolite does something similar in use of the original povray planet images,
so the original high(er) resolution povray images show no anomalies when viewed in een imageviewer (2d)

[submersible]

I overlayed an original povray planet image to compare quality, size. The converted image was shifted 1 pixel horizontal
and 1 pixel vertical, image quality showed a little blur.

Thanks cbr that illustrates it really well.

Is this the entire image being shifted? The blur might be explained by a subpixel shift. I would expect it should be possible to create the vertical and horizontal cross formats pixel for pixel from those in 1:6 format, no subpixel sampling should be necessary.

Could you pick a texture from Galaxy5 and one from Galaxy7 (IIRC the rendering pipeline for these was slightly different) and compare if they have the same issue. If you could let me know which tools you're using for the conversion that would also be a big help.

[submersible]

Further to this - I have managed to get the rendering pipeline built again. Even when rendered with each side at 1024x1024 , I can still see a seam when converting with planettool to mercator or cubex. I had suspected that the povray antialiasing being enabled was part of the problem - sadly no - even without AA enabled the seams are still there.

I'm not sure what else to look for. Possibly a contrived example with a single colour for each side - just to see if any file exhibits the same issue.
Galaxy 7 Isisan @6K

[cbr]

The above example was from G7, I tried one from G5 also a seam.
The amount also seems to be more prominent to the diversity of the planet ( dust planet less visible, cloud/ liquid/land planets more visible seam )

I tried an other source cubemap ( non povray )


converted with planettool sse, also a little seam.
The higher the original resolution the smaller the seam-error

Next I copied this rectangle and moved it over the seam with a mask, to see if the seam is easily covered,
doable but not whole galaxies by hand



I tried another converter 360toolkit.co which als produced seam errors ( and shifting whole landmasses around )



So at the moment I think the seam-errors are due to small conversion errors not the original images.
Using different programs to convert cubemaps also gives a very different result...

Can povray output directly to the format Another_Commander uses in his 8k solar system?
( which compared to cubemaps show less details in the pole regions but no (?) seam...)

[submersible]

Possibly something to do with texture binding. I'm not sure how planettool treats the individual faces , but assembling the TEXTURE_CUBE in opengl may have some texture wrapping by default. See link regarding skybox (the traditional use of cube map textures)

https://gamedev.stackexchange.com/quest ... ct-on-edge

[Commander_X]

Definitely, any attempt to convert an image by changing its UV mapping, is very prone to create seams.
Even "only" rescaling images used as textures, will also very likely bring in seams.

[cbr]

To identity the error area I made a 'perfect' cubecrossmap ( 2048w ) a contrasting checkerboard



Convertered it with planettool with latlong option

A tiny seam became visibile ( 1000%+ zoom )



From this converted image i removed the contrasting red and green
to make the seam more visible for the human eye



Somehow this area should be blurred...

I used also blue in cubecrossmap and i believe planettool uses information/pixels outside of the regular 512 tiles.