[Pottuvoi]

I've been wondering about the ambient light model of FSO and would like to propose a more advanced method which would be fast, good quality and tweakable by artists.

Basic idea is to have small cubemaps which describe the surrounding lighting, diffuse ambient comes from single texture fetch to a direction of surface normal.
This brings all the small detail from normal maps to the shadowed regions of the ship and possibility to have proper lighting from backgrounds like planet earth causing bluish tint to the ships.
It is also very easy to use with ambient occlusion, even with directional ao. (needs more samples from texture, but that's it.)

Another advantage is that having glossy reflections can be done easily as well (with variable blur per pixel), with the same pre-processing step and very small processing cost.

Best of all, there is a free tool, libraries and code even code sample for glossy reflections.
http://wiki.polycount.net/Diffusely_Convolved_Cube_Map
http://developer.amd.com/gpu/cubemapgen/Pages/default.aspx
http://developer.amd.com/media/gpu_assets/GDC2005_CubeMapGen.pdf

[Herra Tohtori]

Was just about to post this... but seeing as you already re-posted I'll just link to it.

Hardness map.

Basically a greyscale layer that affects how soft or sharp the environmental and specular reflections are.

It could be incorporated in the red or blue channel of the normal maps without adding memory use, it would "just" require the shaders to use it.


I'll leave it to the shader wizards to figure out the "just", but a hardness map would be an ideal solution to this because it would allow us to use high environmental intensity without falling prey to the mirror effect of the constant full sharpness of the effect. For example, one could use high environmental intensity for brushed metal surface, but use low hardness value for blurring the environmental effect, which would be far more realistic than the current system.

For ideal solution, material system would be the Holy Grail...

[Pottuvoi]

Thanks, didn't see the previous replies.

Indeed the whole image based lighting with a material system and possibilities it brings is quite nice dream.

Aardwolf:
The diffuse ambient would only be an extra cubemap & normalmap fetch, so it shouldn't be that bad.

[Aardwolf]

Uh... what just happened there?

I notice that this thread is topic #65,535, or 2^16 - 1... somewhat interesting.

[The E]

Read the news, Aard. http://www.hard-light.net/forums/index.php?topic=65531.0

[DaBrain]

I think it's a great suggestion.

I really don't like how the current ambient light kills the normal map detail, which is why I keep the value very low, most of the time.
I'd really like to see this feature implemented!




It should work even with just the current 'material system', but it needs some more work than just the update in the shaders.

[Zacam]

Well, the lighting system can handle constant and quadratic attenuation. Quad only looks good in the F3 lab though and balances the shine-line that most normal maps seem to have, but god's it's terrible in game.

Forcing AO on at the driver level makes some nice improvements. Sadly, getting those improvements in the shaders for everyone to enjoy is murder on the FPS right now.

Looking at the suggestion, as it may allow an ability to implement ENV without restricting it to the Alpha channel of a -shine map. Maybe.

[DaBrain]

Wait... the forced AO works in FS2_open now?!?

That's something I have to try when I get back home.




One other thing is, if we go for this. Do we want to turn off ambient light completely in all missions, still allow the usage of ambient light, so all missions would have touched.

I don't mind either way actually. I think the second solution is a little bit more safe.

[Pottuvoi]

Sorry to bump so old thread, but I found some nice example images from infinity blogs.
http://www.infinity-universe.com/Infinity/index.php?option=com_content&task=view&id=109&Itemid=27

The images in the bottom are mostly lit by ambient light. (diffuse and specular with variable convoluted blur.)

[KeldorKatarn]

Using the normal map channels for this is not a good idea. Frist of all there are people using uncompressed normal maps with their own shaders
and second of all, if compressed normal maps are used, their quality is reduced by a very large ammount if red and blue channels are not left empty.
That is exactly why this type of compression was used.
The compression lowers the quality of the color channels too much, which is why one tries to have only one channel to actually contain data and the rest
contain nothing so the values aren't corrupted too much. Alpha is compressed separately so one can more one additional channel there and recalculate the third one later.

But if you fill up the free channels you'll ruin the whole point of DXT5nm... trust me... quality of normal maps will drop by a very visible amount.

[Zacam]

What?

Edit after re-reading a few more times: What?

Having other data in the -normal file does frak-all in regards to the compression. If, to quote, I put a smiley face on R and B, nothing will change in how the nV compresses.

Compression artifacts on _any_ DDS file all come down to the quality of the application or plugin doing the compression and the quality and clarity of the texture details that you are compressing. Each channel is handled (optimally) on it's own independent of the other channels. So data or it's lack on either R or B changes nothing in regards to it's compression of data on G and A.

G and A are used for the data because that's how the shaders reading system for doing -normal was written. It was easier and more convenient to "blank" those channels in an attempt to mitigate the file data size, it had nothing to do with the compression. So we can allocate those channels to other effects, and hopefully handle it better if they are "all white" or "all black" better than the current handling of ENV.

[Herra Tohtori]

Using the normal map channels for this is not a good idea. Frist of all there are people using uncompressed normal maps with their own shaders

FS2_Open mediaVP shaders can read any file you throw at them as long as it has four channels and normal map information on green and alpha channel. Uncompressed u8888 DDS files run fine, TGA's just as well though they don't have mipmaps. Haven't tried PNG's yet, but presumably if the game can input the bitmap data it would read them just fine (unless they're restricted to interface only, as I said I haven't tested).

You don't need custom shaders to use uncompressed normal maps.

and second of all, if compressed normal maps are used, their quality is reduced by a very large ammount if red and blue channels are not left empty.

Leaving red and blue channels empty is good practice but not exactly necessary. DXT5nm is just DXT5 file used for normal mapping purposes; it's guts don't differ from standard DXT5 in any way. Personally I think how red and blue channels' information affects the integrity of green channel depends on the quality of the compressing utility and selected quality options; I haven't noticed too much loss of quality between "gray" and "green" normal maps; in former the converter has moved red channel to alpha and then multiplied green channel to red and blue channels, so the map looks gray with alpha on glance, while on the latter red and blue channels are filled with black (which by the way despite being just a bunch of zeroes is information precisely the same as any other pixel data) so the map looks green.

That is exactly why this type of compression was used.
The compression lowers the quality of the color channels too much, which is why one tries to have only one channel to actually contain data and the rest
contain nothing so the values aren't corrupted too much. Alpha is compressed separately so one can more one additional channel there and recalculate the third one later.

But if you fill up the free channels you'll ruin the whole point of DXT5nm... trust me... quality of normal maps will drop by a very visible amount.

You don't need such a huge bit depth for normal maps in general, which is one of the reasons dxt5nm was conveyed in the first place and which is why FS2_Open shader system adopted it. However as far as memory usage goes, it still has a poor quality/memory consumption ratio as it is. DXT5 has a compression ratio of 1/4, which means that an uncompressed, 2x8bit DDS file would use the same amount of memory [EDIT: I also fail basic maths, it would obviously use double the memory compared to DXT5) with far superior quality. However, if the ballast channels on the DXT5nm files could be put into some sensible use, it would improve the memory efficiency by a whole lot.

Besides, without hard experimental data I am entirely unconvinced that information on red/blue channels would reduce the green channel's integrity. It would be trivial to do some diffcompare analysis on the subject - just compress different kind of files to dxt5 and see how information or lack thereof on red and blue channel affects green channel contents. But damn if I can be arsed to do such research on my free time and document the results into a comprehensible format...

[KeldorKatarn]

Sigh, maybe read up on why people started to use that strange channel flipping in DTX5nm  in the first place, before immediately contradicting me.

The algorithm compresses the color channels by using the difference in values and such stuff. If there is complex non-monotone data in the other channels, the quality WILL suffer. if that wasn't the case, why not simply store the normal map in DXT1 to begin with?

If there was no quality loss you could simply store a normal map like everything else. but because of the compression the color channels lose accuracy, which is bad for normal maps, much worse than for color maps.

So you use the fact that alpha is compressed independently from the three color channels in DXT5 and story one channel there and one in the color section and leave the rest as it is, to not interfere with the one color channel. for that you either copy the channel over to the other two, or you keep the other two in a monotone color, all done to keep the difference value between the channels only dependent of the one channel containing the data.

You even move the x-coordinate data to the alpha and keep the green. why not move the green and keep the red where it is? because red has a higher quality loss due to the algorithm.

So if you start filling uup all the channels you completely destroy the basic idea behind DXT5nm, which is simply a hack to keep data quality as high as possible. You won#t corrupt quality of your ambient stuff much in visible terms, but you WILL corrupt the quality of the normals data.
Those channels are left empty for a reason...

[Herra Tohtori]

All right. Personally I think dxt5nm compressed normal maps look like arse on some situations anyway (diagonal lines tend to have artefacts around them) and I would much prefer an uncompressed, two-channel normal map format to a compressed four-channel format, but I've always sort of been interested in whether or not the red and blue channels affect the green channel and how much, so for both the argument's sake and my own interest, I'm going to commit a short empirical test on the matter.


I will use the Hercules fighter's normalmap as a subject to the test mainly for the reason that I have the uncompressed normal map available from when I made it. The test itself will be performed as follows:

I will convert three files into dxt5nm style maps.

First one will be a typical purple RGB normalmap converted to dxt5nm with nvDXT >nvdxt -file fighter06-02-normal.png -dxt5nm -quality_highest -nomipmap

Second one will be a per-channel managed RGBA normalmap converted directly to dxt5 since red channel is already moved to alpha and red and blue channel are filled with black in this case. >nvdxt -file fighter06-02-normal_CLEAR_RED&BLUE.png -dxt5 -quality_highest -nomipmap

Third and final will be a file where I was trying to mimick some typical information that could possibly be stored in red or blue channels, so I basically grayscaled the shinemap and used that as "hardness" map, and copied the height map to blue channel, assuming we would want to store something there just for ****s and giggles. >nvdxt -file fighter06-02-normal_RED=HARD&BLUE=HEIGHT.png -dxt5 -quality_highest -nomipmap

I will then detract the green channels from each file, save them as grayscale PNG's and compare them visually, since that will be sufficient for the purposes of the test; if there is a detectable visual difference, then the argument is solved.

This is the test setup. Visual measurements will be done on green channels on each of the three normal maps resulting from different sources.

Here is the hard data: http://www.mediafire.com/?di4md4mgmrf

This archive contains the images used in the test. Their filenames should be self-descriptive.

Here are the test results:

The file that was converted with the -dxt5nm file has the green channel copied over to red and blue channels for whatever reason, and interestingly (or probably not considering the bit depth differences between different channels on dxt5 format) the channel information differ slightly from each other. The green channel in the middle is, however, visually identical with the second file, which was the pre-channelmanaged file with clean black red and blue channels. However, there is a very slight difference on the filesize between the two saved PNG's, which would mean that the way nvDXT's converter does things with the -dxt5nm flag is not in fact the ideal way and the way of managing the channels manually and saving as dxt5 is the way to go. However, since there is no visual difference that I could discern, this hardly matters.


On the last one, there is in fact some clear difference from the other two, which can only be caused by the red and blue channels, so you were right on this regard. Based on the results of my independent research, I can confirm that apparently uniform or equal channel information on red/blue channels results in the cleanest possible green channel when using dxt5 compression.

Whether that change is enough to ruin the normal map quality is probably heavily dependant on the specific map in question; on a preliminary inspection based on this single map it seems that the strong normal map detail persists, while small/weak detail suffers the most degradation, and the interference from the other two colour channels will bleed over to the green channel to create some additional, unwanted normal detail changes. Not having tested any of these in-game, though, I can't say if this is enough to completely destroy the credibility of the normal maps; however I would probably not be willing to sacrifice even more quality considering that, like I said in the beginning, even dxt5nm looks bad in some situations.

However, it might be more effective to use a slightly larger single file than add another file to be read for things such as hardness value. In that case, something like uncompressed RGB (u888) would be sufficient. Memory-wise the change would be as follows:

Four-channel uncompressed RGBA (u8888 DDS)    100% (of which 50% is used by normals and 50% wasted)
Three-channel uncompressed RGBA (u888 DDS)      75% (of which 67% could be used for normal map and 33% for hardness map)
Two-channel uncompressed map (cxv8u8 DDS        50% (100% utilization, no quality loss)
Three-channel uncompressed RGBA (u555 DDS)      46.875% (67% for normal maps, 33% for hardness map, reduced bit depth for normal maps)
Four-channel compressed RGBA (dxt5nm DDS)        25% (technically only half of the channels gets used, but memory-wise a bit more complex issue).

However, using yet another map for hardness in conjunction with normal maps would look like this:

dxt5nm (normals) + u888 (hardness)  100% (memory-wise completely equal to using a single u8888 for both normal, hardness and optional height informatio, but with more file overhead by using two files instead of one)

dxt5nm (normals) + a8 (hardness as single alpha channel)   50% (66% of the memory used by uncompressed u888 file containing both normals and hardness information, with more file overhead)

dxt5nm (normals) + dxt1 (hardness)   41.67% (comes very close to using a single u555 texture for retaining both normal and hardness information, with more file overhead)


So in a pure numbers game, dxt compressed versions do beat the other options. But considering FS2_Open's tendency for performance being highly dependant on the amount of maps used, what would mean better performance - single file using N amount of memory, or two files using, say, 66% of that amount? It would probably depend on how much video ram is available in the first place, but then there are also quality gains to think of. If hardness maps were added as a feature, then I for one think it would be more beneficial to use a single u888 texture than two compressed files.

This conjecture is purely hypothetical, however, considering this is about a feature that might not appear before the advent of a true material system, if even then.

Nevertheless, concerning the technique of utilizing the empty channelsof dxt5nm files, it appears you were right - it would affect the quality of the normal maps, and most likely the normal map information of green channel would also interfere with the hardness map on red/blue channels, so using dxt5nm to contain both normals and hardness information seems to be out of count.

Additionally, it seems that on retrospect I might have been overeager to criticize you on a hunch, and for that you have my apologies.

It's good to be proven wrong occasionally (even if I'm doing the proving myself). Does wonders for the ego.

[Zacam]

"Those channels are left empty for a reason..."

Hmm. Funny. In photoshop normal map generator or DDS plugin when saving as a DXT5-NM (not just DXT5) those channels are in fact _not_ blank.

Hence the blanking of them and saving the results as a DXT5 or u8888.

[KeldorKatarn]

I said either blank or copies of the green channel. Which of both makes no difference since the difference value of channel difference remains the same.
If you copy it, the difference will be 0, if you leave it blank, the difference will be the channel value itsef.
I don't know why you keep arguing about this instead of simply looking of how DXT works. There's more than enough whitepapers out there discussion exactly this issue.

[Woolie Wool]

Wait... the forced AO works in FS2_open now?!?

That's something I have to try when I get back home.




One other thing is, if we go for this. Do we want to turn off ambient light completely in all missions, still allow the usage of ambient light, so all missions would have touched.

I don't mind either way actually. I think the second solution is a little bit more safe.

I don't like the idea of turning down ambient light in the launcher flags. To me, ambient light should be a choice of the mission designer, not of the player. For instance, if I make an atmosphere skybox mission I will use a very high ambient light setting. I think the correct response to this issue is for all FREDers making deep space missions to set ambient light in FRED to 0/0/0 or thereabouts. With that accomplished, only -no_emissive_light will be required.

[Bobboau]

I said either blank or copies of the green channel. Which of both makes no difference since the difference value of channel difference remains the same.
If you copy it, the difference will be 0, if you leave it blank, the difference will be the channel value itsef.
I don't know why you keep arguing about this instead of simply looking of how DXT works. There's more than enough whitepapers out there discussion exactly this issue.

because you clearly didn't read Herra Tohtori's post, let me give you the TL;DR
"yeah, you were right, my bad"

[KeldorKatarn]

I said either blank or copies of the green channel. Which of both makes no difference since the difference value of channel difference remains the same.
If you copy it, the difference will be 0, if you leave it blank, the difference will be the channel value itsef.
I don't know why you keep arguing about this instead of simply looking of how DXT works. There's more than enough whitepapers out there discussion exactly this issue.

because you clearly didn't read Herra Tohtori's post, let me give you the TL;DR
"yeah, you were right, my bad"

I read the post, my last post was a direct response to someone else, not to Herra Tohtori.
Anyway, to stop this offtopic crap, the original meaning was:

Great idea, but normal maps are probably not the best way to store it in. So.. back to discussion of ambient... what alternatives are there for implementing this and keeping the data?

[DaBrain]

What exactly do you want to store?

The blurred env map?

If you want a mask for this "ambient light", I think vertex colors should be enough to do the job. (Radiosity + blur)
I think the smooth look would work pretty well.

White = glossy reflection
Black = no light

I don't like the idea of turning down ambient light in the launcher flags. To me, ambient light should be a choice of the mission designer, not of the player. For instance, if I make an atmosphere skybox mission I will use a very high ambient light setting. I think the correct response to this issue is for all FREDers making deep space missions to set ambient light in FRED to 0/0/0 or thereabouts. With that accomplished, only -no_emissive_light will be required.

Yes, I also think the mission designer should be the one to set up the ambient light. However with this technique there is no ambient light anymore(!)
It all depends on your skybox.

The question is, do we want an additional ambient light, or do we just need the ability to change the color/brightness of the blurred env map?