It is currently Wed, 13-12-17, 10:52 GMT

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun, 16-07-17, 7:47 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
https://celestiaproject.net/forum/viewt ... =3&t=17733


Top
 Profile  
 
PostPosted: Sun, 16-07-17, 14:12 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4514
Location: Hamburg, Germany
sjohn / john71 wrote:
https://celestiaproject.net/forum/viewtopic.php?f=3&t=17733

As I anticipated, your crashes are not rooted in a 32bit -> 64bit issue.

What I strongly recommend to you in this situation is to consider textures including so-called mipmaps, i.e. instead of single textures, a set of textures, each being smaller by a factor of two than the previous one.

Wiki has a well readable introduction here:
https://en.wikipedia.org/wiki/Mipmap

OpenGL can handle these in the sense that dynamically, far away bodies are properly filtered to use an appropriate mipmap instead of the full texture! There is a large amount of literature about this technique in the net. Mipmaps may be generated with various tools, including --I recall-- the so-called NVIDIA texture tools.

Let me know if you need help there. But it's quite easy with the Nvidia texture tools. The DXT format naturally involves mipmaps. Hence all you need to do is to download the NV tools and compress (via nvcompress) all your 8k PNG textures into DXT format. There is a flag that may suppress generation of mipmaps during the conversion of PNG->DXT. Note that VT tiles automatically show mipmap behaviour...

While still developing Celestia (i.e.> 7 years ago) I did plenty of respective experiments with mipmaps. Here is such a thread of mine from 2004 ;-)
https://celestiaproject.net/forum/viewt ... 68&p=37872

Yet, my personal preference is still to switch to 16k VT tiles throughout and to optimize things with my tools, notably using DXT5nm instead of PNG for the normal maps! The resulting quality and resolution is excellent and the display speed is hard to beat. No problems with crashes at least in celestia.Sci.

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Tue, 18-07-17, 4:42 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 21:55 GMT
Posts: 775
Location: N 42.38846 W 83.45456
if you are using a MS windows OS then use the directX dds format

my opinion is well known , so use what is BEST for YOU

and use the driver from your 3d card's website and NOT the one that win10 auto update will keep reinstalling
( unless MS has made peace with AMD and Nvidia in their war with them )

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7


Top
 Profile  
 
PostPosted: Tue, 18-07-17, 18:54 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
Thanks for the advice! By the way, can I use dds for bump maps?

I started to use dds dxt5 files with mipmaps and there is some improvement.


Top
 Profile  
 
PostPosted: Tue, 18-07-17, 19:02 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 21:55 GMT
Posts: 775
Location: N 42.38846 W 83.45456
i would not use "bump maps"

Use a Normal map instead , for a planet texture use the "texturetools"

the normal tool converts the projection for a SPHERE!!!!! and not a flat plain ( like the gimp and PS tools do
also do not use "crazy bump " or like tools , they really do not work

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7


Top
 Profile  
 
PostPosted: Tue, 18-07-17, 20:57 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
OK, but is it possible to have a dds normalmap?


Top
 Profile  
 
PostPosted: Tue, 18-07-17, 21:52 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 21:55 GMT
Posts: 775
Location: N 42.38846 W 83.45456
just do not compress it or if you do a very small amount

Cosmographia uses dds for a lot of things and celestia uses the same cmod code
Attachment:
Screenshot_20170718_175027.png
Screenshot_20170718_175027.png [ 571.69 KiB | Viewed 797 times ]

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7


Top
 Profile  
 
PostPosted: Wed, 19-07-17, 7:21 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4514
Location: Hamburg, Germany
sjohn wrote:
OK, but is it possible to have a dds normalmap?


@sjohn / john71:

While most of my previous writitng in this thread was about that issue ;-), how about reading this old tutorial of mine explaining in detail the importance and advantages of using DXT normalmaps.

http://www.celestialmatters.org/?q=node/10

For really excellent results, normalmaps need very smooth 16bit elevation map input AND need to be in the dedicated normalmap (nm) format dxt5nm.

Note this is crucial. dxt5nm is NOT equal to dxt5!!
Note also what I emphasized previously in this thread and JohnVV repeated:
t00fri wrote:
My tools moreover optimize the dxt5nm rendering and project the normal map correctly on spheres rather than incorrectly on plane surfaces!

John Van Vliet wrote:
..use the "texturetools" . The normal tool converts the projection for a SPHERE!!!!! and not a flat plain


How about having a look (again?) onto my previous two 16k examples utilizing exclusively DXT format for every texture including the normalmaps.
viewtopic.php?f=11&t=908#p14911

_________________
Image


Top
 Profile  
 
PostPosted: Wed, 19-07-17, 21:08 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
Fridger: thanks for your help, but not everybody is a scientist! :)

I personally find your otherwise excellent programs hard to use without a GUI. So I use GIMP instead. Sorry. :o

DXT5nm (mipmaps generated) graphic files really work using the NormalMap parameter (but not BumpMap). Unfortunately under OpenGL 2.0 it produced very strange digital artifacts, so I decided to use png for the time being.

I have to admit that NormalMap is better than BumpMap.

I discovered CloudNormalMap, which is fantastic, very realistic!

Hey guys I have only used Celestia since 2014...I cannot know everything!

But thanks for your excellent help and advice!


Top
 Profile  
 
PostPosted: Mon, 31-07-17, 10:58 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
I changed all my png normalmaps to dxt5nm format and it truly works! RAM usage is significantly lower and there are far fewer crashes. Thanks again!


Top
 Profile  
 
PostPosted: Tue, 01-08-17, 14:48 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4514
Location: Hamburg, Germany
@sjohn/ john71:

sjohn wrote:
I changed all my png normalmaps to dxt5nm format and it truly works! RAM usage is significantly lower and there are far fewer crashes. Thanks again!


Good to hear!

Still I am worried about what I read from you in the dxt5nm context here and over in your CelestiaProject site:

Using dxt5nm via some format converter is one thing. But for astronomical applications, most such tools assume the WRONG projection surface! Namely a plane surface rather than a spherical one (e.g. Planets, Moons, ...). Actually there is even a generalization for vastly non-spherical surfaces as occuring e.g. for Asteroids, Comets...This aspherical dxt5nm technique was successfully explored long ago by Chris Laurel.

I suppose you intend to make really valuable contributions in the texture domain. Then it is not enough to state that "not everyone is a scientist" and that "you absolutely need a GUI for such tools". Real texture experts like JohnVV or myself would never want to use or build upon a normalmap with incorrect underlying geometry. Last not least, some commandline tools offer a far superior memory management for really LARGE texture applications and hence are substantially faster or even more versatile than GUI-based tools. The ISIS3 tools, the NVIDIA texture tools or my texture tools belong to this category.

Good luck,
Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Fri, 04-08-17, 9:35 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
Fridger,

I used this GUI: https://vvvv.org/contribution/dds-converter.

It converts png files to any kind of dds file.

As I understand the png files already should have the right projection to get a right dxt5nm file...?

By the way I use DXT1 files without mipmaps for larger interplanetary textures like megastructures (Dyson sphere etc.), because DXT5 files with mipmaps produced some strange artifacts.

I use DXT3 with alpha channel + mipmaps for clouds.

And for the rest I use DXT5 with mipmaps.

Projections are bothering me but I simulate artificial exoplanets so I really mix empirical data with fictional aesthetics...I like of course scientific accuracy but these are mostly fictional (not observable and not existing) planets... (not talking about TRAPPIST-1 planets but the bulk of my textures...).

But I see that I have to learn much more...


Last edited by sjohn on Fri, 04-08-17, 17:51 GMT, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri, 04-08-17, 10:08 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
Fictional exoplanet created with dds files only:

Attachment:
exoplanet.png
exoplanet.png [ 1.43 MiB | Viewed 647 times ]


Top
 Profile  
 
PostPosted: Wed, 09-08-17, 14:09 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4514
Location: Hamburg, Germany
sjohn wrote:
Fridger,

I used this GUI: https://vvvv.org/contribution/dds-converter.

It converts png files to any kind of dds file.

This is certainly correct. However, you have to sharply distinguish between a pure graphics format conversion (like png to dds) and the generation of a RGB normalmap e.g. from measured height map data as inputs.

While a height map only associates simple numbers (the heights) with each point of a given surface, each pixel of a RGB normalmap (color-)encodes which direction in space that particular surface point is facing. This requires specification of the components of a 3-dimensional (unit) vector - the "normal vector" at each point (x,y) of the surface. It is orthogonal to the surface as it's name says.

The purpose of the normalmaps is to create a sense of dynamical shading of the surface, i.e. a variable shading, depending on the position of the light source (Sun, other star). For this mechanism to work properly, one should NOT use (statically) shaded surface textures together with normalmaps, but instead so-called "flat" ones.

The input elevation data should by all means be 16bit, else the crucial requirements of noise freedom and maximal smoothness of the resulting normalmap will fail. It is in this calculational step that the body's geometry enters crucially.

The popular apps for generating normalmaps from texture data all assume a plane projection geometry rather than a spherical one.
Such normalmaps will lead to an increasingly bad incorrectness near the poles of spherical bodies. Also ficticious normalmaps will in general be affected by this problematics. The difference being just that some ficticious input data source was chosen.

Fridger

_________________
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group