CrossPlatform GUI (Qt) for my F-TexTools/Nmtools

[Hungry4info]

I think a GUI would be a great idea. I can speak from experience that command line style input isn't very easy for those who aren't familiar with it. I've been fiddling around with the F-TexTools and command lines for about a week, until I finally got it to work.

[t00fri]

I think a GUI would be a great idea. I can speak from experience that command line style input isn't very easy for those who aren't familiar with it. I've been fiddling around with the F-TexTools and command lines for about a week, until I finally got it to work.

See my happy reaction to your success elsewhere!

I am certain that you also read Andy74's enthusiastic report above. As one conclusion he wrote

Now about the GUI: As I am able to use the commandline tools, I won't need a GUI version.

Same sentence by praesepe who started this huge Moon thread off with his 64k Moon VT set via the F-TexTools.

Same with cartrite, quite a few others and me of course. Command lines have many advantages, once you know how to handle them.

But irrespectively, I have seen enough struggle by people that I think it's worth the effort to come forward with an easy going cross platform GUI.

Fridger

[Hungry4info]

But irrespectively, I have seen enough struggle by people that I think it's worth the effort to come forward with an easy going cross platform GUI.

Agreed.

However, those who don't actually learn how to do the command line method miss out on the experience, lol.

[t00fri]

But irrespectively, I have seen enough struggle by people that I think it's worth the effort to come forward with an easy going cross platform GUI.

Agreed.

However, those who don't actually learn how to do the command line method miss out on the experience, lol.

Let me put it this way: a GUI is mainly needed to get people over the initial "threshold".

Most people later prefer the more elegant and flexible command lines once they understood their functioning. Pipelines = "plumbing applications together", for example, are a most elegant concept that doesn't work with GUIs .

Fridger

[duds26]

This is a great enhancement to the tools.
Congratulations


(May I suggest, from the screen shot, that a user can choose the maximum output level.)
(It would be nice for people who don't know, to mention in the generate vt tiles area (right bottom of screen shot) that the Tile size is the width.)
(Be able to choose if all pictures or just the top picture should have a mipmap.)

[t00fri]

This is a great enhancement to the tools.
Congratulations


(May I suggest, from the screen shot, that a user can choose the maximum output level.)

duds26,

thanks for your comments and suggestions.

Allowing to choose the maximum output level, could only mean that users might not want to exploit the full resolution power of their original texture? Is this really a sensible option?

Since there is the familiar relation between TileSize, Level and initial Width(Level), I allow the user to choose the most sensible quantities compatible with a constant TileSize across all levels and the initial Width(Level) being a power of two. I can therefore NOT allow to choose both Level AND TileSize. TileSize bears a direct relation to the user's harddisk performance and graphics card memory. Therefore I use TileSize[pixels] as a selectable parameter.

It would be nice for people who don't know, to mention in the generate vt tiles area (right bottom of screen shot) that the Tile size is the width.

TileSize [pixels] is also to indicate that tilewidth = tileheight! That's why I preferred TileSize rather than TileWidth.

Note that I always specify the units! Since it is pixels not pixels^2, TileSize must be a LINEAR scale (rather than an area)...

Be able to choose if all pictures or just the top picture should have a mipmap.

For VT tiles in DXT format it is not very sensible to allow for mipmaps in addition to the various levels (>0). To a large extent, the levels already play the role of mipmaps (apart from level0). In case of PNG tiles, mipmaps cannot be embedded anyhow. But for DXT tile output, this is at least a possible option. Thanks for reminding me...

Fridger

[jogad]

Hello,

For VT tiles in DXT format it is not very sensible to allow for mipmaps in addition to the various levels (>0). To a large extent, the levels already play the role of mipmaps (apart from level0). In case of PNG tiles, mipmaps cannot be embedded anyhow. But for DXT tile output, this is at least a possible option.

maybe mipmaps are not suitable even at level 0.
This is the difference for se same level0 with and without mipmaps.
(south pole of the moon with a vt made with the 64k clementine texture)

with mipmaps.jpg

no mipmap.jpg

This is only seen at level0.
Other levels are ok.

[chris]

Hello,

For VT tiles in DXT format it is not very sensible to allow for mipmaps in addition to the various levels (>0). To a large extent, the levels already play the role of mipmaps (apart from level0). In case of PNG tiles, mipmaps cannot be embedded anyhow. But for DXT tile output, this is at least a possible option.

maybe mipmaps are not suitable even at level 0.
This is the difference for se same level0 with and without mipmaps.
(south pole of the moon with a vt made with the 64k clementine texture)

This is only seen at level0.
Other levels are ok.

Interesting... It looks like mipmapping is indeed responsible for the infamous 'polar pinch' problem. It appears that the compression in longitude near the poles is causing a low resolution mipmap level to be chosen even though the texture is not being oversampled in latitude. Disabling mipmapping isn't a good idea though. You'll end up oversampling the texture when the viewpoint is far enough from the planet that one pixel covers more than one texel. This has two negative side effects:
- 'Sparkling' caused by texture aliasing
- Reduced performance caused by thrashing the texel cache

All new graphics hardware now supports anisotropic texture filtering, which should mitigate the problem. I'll try some experiments.

--Chris

[t00fri]

Interesting... It looks like mipmapping is indeed responsible for the infamous 'polar pinch' problem. It appears that the compression in longitude near the poles is causing a low resolution mipmap level to be chosen even though the texture is not being oversampled in latitude. Disabling mipmapping isn't a good idea though. You'll end up oversampling the texture when the viewpoint is far enough from the planet that one pixel covers more than one texel.

But this argument would only concern level0, as we all agree. For higher VT levels, the next lower VT level plays the role of the leading mipmap etc. Moreover, polar oversampling is avoided by reducing the resolution dynamically, as is implemented in my tools.

For non-VTs of course mipmapping is essential for the reasons you mentioned.

As a curious reminder: We had vivid discussions previously about the 'polar pinch' effect, as well as it's apparent absence in case of VTs (as I used to argue). I never use mipmaps with VTs, hence no pinch

Anybody can see a 'pinch' structure at the pole of my 32k Mars VT?


Fridger

[chris]

A quick experiment with the effect of anisotropic filtering on 'polar pinch' artifacts. The two examples below use the 4k Mercury texture in the 1.6.0 RC2 Celestia package. In the first image, normal trilinear filtering is enabled:

mercury-trilinear.jpg

In this image, anisotropic filtering was set to 8x via the NVIDIA control panel:

mercury-aniso8.jpg

There's a big difference! Based on these results, I highly recommend enabling anisotropic filtering in the control panel for your graphics card. Be aware that it may slow down rendering in some cases. The quality improvement is dramatic enough that I think the next version of Celestia should allow user control over anisotropic filtering (with some level enabled by default.)

--Chris

[t00fri]

A quick experiment with the effect of anisotropic filtering on 'polar pinch' artifacts. The two examples below use the 4k Mercury texture in the 1.6.0 RC2 Celestia package. In the first image, normal trilinear filtering is enabled:

mercury-trilinear.jpg

In this image, anisotropic filtering was set to 8x via the NVIDIA control panel:

mercury-aniso8.jpg

There's a big difference! Based on these results, I highly recommend enabling anisotropic filtering in the control panel for your graphics card. Be aware that it may slow down rendering in some cases. The quality improvement is dramatic enough that I think the next version of Celestia should allow user control over anisotropic filtering (with some level enabled by default.)

--Chris

I completely agree!

Since a long time I always used 8x anisotropic filtering via the NV control. Despite my old FX9500Ultra, there is very little slowdown, quite unlike AA.

Fridger

[chris]

Interesting... It looks like mipmapping is indeed responsible for the infamous 'polar pinch' problem. It appears that the compression in longitude near the poles is causing a low resolution mipmap level to be chosen even though the texture is not being oversampled in latitude. Disabling mipmapping isn't a good idea though. You'll end up oversampling the texture when the viewpoint is far enough from the planet that one pixel covers more than one texel.

But this argument would only concern level0, as we all agree. For higher VT levels, the next lower VT level plays the role of the leading mipmap etc.

Yes, it only concerns level zero.

Moreover, polar oversampling is avoided by reducing the resolution dynamically, as is implemented in my tools.

For non-VTs of course mipmapping is essential for the reasons you mentioned.

As a curious reminder: We had vivid discussions previously about the 'polar pinch' effect, as well as it's apparent absence in case of VTs (as I used to argue). I never use mipmaps with VTs, hence no pinch

Right. But if you don't use mipmaps with level zero, you'll get the oversampling artifacts when level zero is used. For the best quality--even for VTs--you want to enable mipmaps for level zero and turn on anisotropic texture filtering in your GPU control panel.

VTs suffer from other oversampling artifacts due to Celestia's using just a single level of detail for the whole planet. This is addressed by the new adaptive LOD renderer that I was discussing in the Moon thread started by Spiff.

--Chris

[t00fri]

Interesting... It looks like mipmapping is indeed responsible for the infamous 'polar pinch' problem. It appears that the compression in longitude near the poles is causing a low resolution mipmap level to be chosen even though the texture is not being oversampled in latitude. Disabling mipmapping isn't a good idea though. You'll end up oversampling the texture when the viewpoint is far enough from the planet that one pixel covers more than one texel.

But this argument would only concern level0, as we all agree. For higher VT levels, the next lower VT level plays the role of the leading mipmap etc.

Yes, it only concerns level zero.

Moreover, polar oversampling is avoided by reducing the resolution dynamically, as is implemented in my tools.

For non-VTs of course mipmapping is essential for the reasons you mentioned.

As a curious reminder: We had vivid discussions previously about the 'polar pinch' effect, as well as it's apparent absence in case of VTs (as I used to argue). I never use mipmaps with VTs, hence no pinch

Right. But if you don't use mipmaps with level zero, you'll get the oversampling artifacts when level zero is used.

But , of course, my VT sets ALWAYS have mipmaps switched on for level0! But ONLY for level0. As I wrote this is long clear.

For the best quality--even for VTs--you want to enable mipmaps for level zero and turn on anisotropic texture filtering in your GPU control panel.

Right, that's what I have been doing for the last 5 years or so.

VTs suffer from other oversampling artifacts due to Celestia's using just a single level of detail for the whole planet. This is addressed by the new adaptive LOD renderer that I was discussing in the Moon thread started by Spiff.

--Chris

It is really time to adress this issue, I agree...

Fridger

[cartrite]

I got similar results with no normalmap. But anisotropic filtering did not help pole pinching with a normalmap.
cartrite

[t00fri]

I got similar results with no normalmap. But anisotropic filtering did not help pole pinching with a normalmap.
cartrite

My above Mars pole image has 8x anisotropic filtering and a normalmap but NO pinch

Fridger

[cartrite]

I'm using a Mars normalmap from the ISIS version2 shape file of Mars, png format. How did you get rid of the pinching? It was produced by your tools cause the polar regions have the smaller widths. I'm using a old card though.
cartrite

[t00fri]

I'm using a Mars normalmap from the ISIS version2 shape file of Mars, png format. How did you get rid of the pinching? It was produced by your tools cause the polar regions have the smaller widths. I'm using a old card though.
cartrite

I used DXT1 for the base texture and DXTnm for the normalmap. That's all. But it's Mario's 32k base texture and normalmap!

Fridger

[cartrite]

I think can remember now. I may have created the normalmap from original megt files. They only covered 88n to 88s and I had to oversample the 88n-90n 88s to 90s. This may be the reason for the pinching. I don't have any pinching on Earth's south pole even with a normalmap.

The problem I had with using the ISIS file was the conversion to height values from radii values. They only had a very low resolution areoid file available to subtract from the radii values to get true height values.

I'll have to give this another try someday.
cartrite