[Talon 1024]

Hi there.  Since I've upgraded my drivers, i've just been able to make the "normal maps" feature work.  It all looks very cool and the geometry of the model looks more defined.

I'm having some problems creating normal maps myself.  Somehow, the light seems to behave oddly at different positions.  I'm using the latest version of Crazybump and trying to render a normal map that looks "somewhat" like yours.





And if you want the original normal map, here you go.

[taylor]

Did you convert the map to DXT5nm?  That's how it looks actually, like you didn't convert the map to the proper texture format.

[Talon 1024]

I knew there was DXT5, but i didn't know there was DXT5nm.  I'm using DDS Converter 2.1 to convert to DDS.

[Nuke]

the only real difference is what chanels the normal data gets stored it.

[taylor]

the only real difference is what chanels the normal data gets stored it.

Well, actually DXT5nm has much higher image quality for normal maps, and it only stores 2 of the 3 channels required for the normal map (given 2 channels the shader can generate the 3rd itself).  But, this only applies to normal maps, since they are special and allow this sort of thing.  In all respects though, DXT5nm is technically identical to regular DXT5, it's just that the "nm" version takes advantage of the particulars of how normal maps work combined with how the DXT5 compression format works.


The problem for us is that it's got to be one way or the other by default, since the shaders expect the image to be in one particular format (since with DXT5nm it must generate the 3rd channel).

On the main topic though, I have never used DDS Converter, so I have no idea whether it supports DXT5nm or not.  You could try using either NVIDIA's DDS utilities, or go with ATI's Compressonator.

[Nuke]

when i re-downloaded the photoshop plugin from nvidia it had support for the dxt5nm format. really you just need something that can save or convert to dxt5 from a 4 channel format. its just a matter of moving red into alpha and clearing clearing red and blue before converting/saving. as i understand it, green and alpha are the channels which suffer less loss from the compression, and x goes into one and y into the other and the z is extrapolated. it would be cool to have an option between dxt5nm and an uncompressed, 2 channel 16 bit format though.

[Scooby_Doo]

Do normal maps need to be DXT5? What about DXT1?

[taylor]

Do normal maps need to be DXT5? What about DXT1?

With the default shaders, it must be DXT5nm.  If you create your own shader set then you can make the normal maps any format that you want.

[DaBrain]

when i re-downloaded the photoshop plugin from nvidia it had support for the dxt5nm format. really you just need something that can save or convert to dxt5 from a 4 channel format. its just a matter of moving red into alpha and clearing clearing red and blue before converting/saving. as i understand it, green and alpha are the channels which suffer less loss from the compression, and x goes into one and y into the other and the z is extrapolated. it would be cool to have an option between dxt5nm and an uncompressed, 2 channel 16 bit format though.

That's what the material system is for... or better "will be for".

Everything else we can do now would be a hack. Unless ou completely switch to another format.
DXT5nm is the best normal map format anyway imho.

[Scooby_Doo]

Do normal maps need to be DXT5? What about DXT1?

With the default shaders, it must be DXT5nm.  If you create your own shader set then you can make the normal maps any format that you want.

Ahhh nuts, now I need to go back and redo them.

[taylor]

... it would be cool to have an option between dxt5nm and an uncompressed, 2 channel 16 bit format though.

Somehow I missed this last sentence when I was reading your post.  But, as DaBrain said, this is something that the material system would allow for.  I did actually add support for L8A8 DDS format (which is 2 8-bit channels, giving a 2-channel 16-bit format), but at the moment I have no plans to add this code to CVS (not for 3.6.10 anyway).  It was determined that DXT5nm would provide all of the quality that we need (it loses 2-bits of precision on the luminance channel compared to L8A8), and requires half of the memory.  Memory efficiency was far more important than that little bit of extra quality.  But as I've said, if you want to use a different format then just modify the shaders and include them with your mod.  All normal maps that you use would be required to be in the same format, but that is a choice that you can make and deal with on your own.

The problem with the current code (in general, not the shader/OpenGL code specifically) is that it's all or nothing.  In order to use L8A8, every single normal map would have to be in that format.  That same with DXT5nm, you either use it or you don't, you can't simply pick and choose for each map.  The material code would allow this restriction to be removed, but there is no way to do it with the current code.

[DaBrain]

Btw, you should try to fix a problem in your nomal map before you convert it.

There seems to be a smoothing group problem on the high or low-poly model. Maybe it's simply unclean geometry (two vertex points where only one is supposed to be).

[Herra Tohtori]

 

Old topic, but related questions, so I figured it better to bump the topic instead of making a new one...

In relation to a little experiment (landscape model, basically) I'm working on, I'm trying to make animated water surface with (naturally) animated normal map to take care of fancy reflections, but I'm a bit stumped. I now have something like this:






Tileable, 60 frames, original size 512x512 (I might reduce it to 256^2 in the end). So that's supposed to be the elevation of the water's surface so that dark equals bottom of a wave and bright equals top of a wave.

Obviously the zeroth question is if it's even possible to use animation as a normal map. If yes, I'm assuming a standard *.eff would work, using frames of individual normal maps, right?

Now, what I'm wondering is how to make a normal map out of this kind of grayscale elevation image (well, it's not really greyscale, it's RGB but it just happens to be gray so I'm using that word a bit loosely here). I suppose I need to convert it to that cyan/magenta thingy where different slopes are identified by different colours? If so, how do I do it?

I'm using NVidia DDS utilities, and the command

nvdxt -file wave_00.tga n9x9

does produce something that has blue and violet stripes in it - am I right to assume that's one way to generate a normal map? Please correct me if I'm completely wrong. The file the command produces is named wave_00.dds. But is this file in which format then? Do I need to first convert the grayscale images into normal map format, and then convert them to DXT5nm format with

nvdxt -file wave_00.dds -dxt5nm

or what?

Secondly, if I use command

nvdxt -file wave_00.tga -dxt5nm

or, in other words, convert the black/white elevation tga map directly to DXT5nm format, it makes a file where (when viewed with GIMP) dark parts become transparent and bright parts remain visible... what is this, then? Can I use that directly without going through the colourful phase?


Final question - if I wanted to use a height map for the wave animation as well, what format would that use? Simple greyscale DXT5 or what? And would it even be worth it to do that in the first place?

Any and all help appreciated very much.

[DaBrain]

The last time I checked it animated normal maps didn't work. I think they would be useful for a few things though.

Anyway, I think for water, texture translastion would be a good method to save memory. At least if it is a rather simple animation like yours (left to right). That means animated UVs.

The DXT5nm one should work already. I bet Gimp is displaying the Alpha channel (the Y-Axis for the normals) as transparence.


Height should be either uncompressed TGA/DDS 8:8:8, or DXT1. (-height)

[Herra Tohtori]

Yeah, I pretty much figured out animated normals doesn't work yet.

But at any case, if you pay attention to individualy waves you'll notice they don't simply move from left to right, they slightly change their form as well. So simple texture translation wouldn't work as I intended.


Apparently animated shinemaps don't work either. Main texture and the glowmaps seem to be the only ones that work. Oh well, seems like I need to simply include the waves into the main texture as animation... and perhaps some day the normal maps will work animated as well.

[taylor]

When I originally did the normal map code it was without shaders.  It worked ok, but not great.  It didn't support DXT5nm either, which meant that you had a choice between really bad quality images, or complete memory hogs.  And that's why I didn't allow for animated normal/height maps.

There isn't much reason to keep it that way now though, so I'll add that to my list of things to do next week.

Apparently animated shinemaps don't work either. Main texture and the glowmaps seem to be the only ones that work. Oh well, seems like I need to simply include the waves into the main texture as animation... and perhaps some day the normal maps will work animated as well.

Support for animated specmaps was added over a year ago.  It's been a while since I actually tried it out though so I suppose it's possible that something got b0rked at some point.  I'll take a look at it tomorrow and make sure that everything is still good.

[Herra Tohtori]

Thanks for information.

I did manage to make a normal map out of the files, but since the animations don't work yet I'm dropping that lane of thought for now.

As to animated spec maps, well, I was trying with -spec after the texture name instead of -shine, so it's not surprising that didn't work at that point... which doesn't rule out the possibility of it not working after all, haven't tried with correct filenames yet.

[Talon 1024]

Btw, you should try to fix a problem in your nomal map before you convert it.

There seems to be a smoothing group problem on the high or low-poly model. Maybe it's simply unclean geometry (two vertex points where only one is supposed to be).

Thank you.  That really helped me out.

I generated the normal maps with xNormal.  Apparently, xN can't read smoothing group data from a 3DS model, so I had to stick with ms3d format instead.  That seems to fix the problem.

[Nuke]

Old topic, but related questions, so I figured it better to bump the topic instead of making a new one...

In relation to a little experiment (landscape model, basically) I'm working on, I'm trying to make animated water surface with (naturally) animated normal map to take care of fancy reflections, but I'm a bit stumped. I now have something like this:






Tileable, 60 frames, original size 512x512 (I might reduce it to 256^2 in the end). So that's supposed to be the elevation of the water's surface so that dark equals bottom of a wave and bright equals top of a wave.

Obviously the zeroth question is if it's even possible to use animation as a normal map. If yes, I'm assuming a standard *.eff would work, using frames of individual normal maps, right?

Now, what I'm wondering is how to make a normal map out of this kind of grayscale elevation image (well, it's not really greyscale, it's RGB but it just happens to be gray so I'm using that word a bit loosely here). I suppose I need to convert it to that cyan/magenta thingy where different slopes are identified by different colours? If so, how do I do it?

I'm using NVidia DDS utilities, and the command

nvdxt -file wave_00.tga n9x9

does produce something that has blue and violet stripes in it - am I right to assume that's one way to generate a normal map? Please correct me if I'm completely wrong. The file the command produces is named wave_00.dds. But is this file in which format then? Do I need to first convert the grayscale images into normal map format, and then convert them to DXT5nm format with

nvdxt -file wave_00.dds -dxt5nm

or what?

Secondly, if I use command

nvdxt -file wave_00.tga -dxt5nm

or, in other words, convert the black/white elevation tga map directly to DXT5nm format, it makes a file where (when viewed with GIMP) dark parts become transparent and bright parts remain visible... what is this, then? Can I use that directly without going through the colourful phase?


Final question - if I wanted to use a height map for the wave animation as well, what format would that use? Simple greyscale DXT5 or what? And would it even be worth it to do that in the first place?

Any and all help appreciated very much.

what i would do is make a plane in max and map the texture to it so it fits entirely on the plane. then id apply of iterations of mesh smooth and a displace filter to it (use a frame of the map as your height). then id eport it for ati's normal map renderer. then remove the modifiers and save it as your low-poly model (you may need to lower it first).

hard part is you need to do this on a per frame basis. once for each frame. also it will take awhile to crunch so you might want to set up a batch file to do it overnight.  then when theyre all rendered to tga, open in photoshop and re-save as dxt5_nm.

[Herra Tohtori]

...what? I understood only the first sentence completely, and even if I knew how to do iterations and other more advanced modelling stuff, I don't have Max. Thanks for suggestions, though... I guess.

As far as normal map making goes, I've pretty much figured out how to make them (- thanks for help about the formats!)... at least to some degree. Judge for yourself:






These are made based on the main textures' seam lines, nothing fancier than that. I simply drew them on a layer over the texture, then made a normal map out of that and coverted that to dxt5nm format. Works better than none anyway...