fatty_h and fatty_s ...

xyz · **Joined:** Fri Apr 18, 2003 12:27 pm **Posts:** 14

Hi,

What are fatty_h.tga and fatty_s.tga for?

Thanks

der_ton · **Posted:** Sat Jul 12, 2003 7:53 pm

The _h files are the heightmaps, they contain the "depth" information for a texture, and they get combined with the _local files, they contain depth information too, but in a slightly different format, but basically they are equivalent.

The reason that there are two texture maps that contain depth information is because the _local files are generated by a program, and they are based on the geometry differences between the high-res polygonal models and the low-res (in-game) polygonal models.
The _h files are made by texture artists I assume, and they are not generated by programs. So splitting up the stuff into a heightmap and a localmap and then "adding" the two onto another is a pretty clever way to simply manage the depth of a texture in the engine, while maintaining flexibility in the creation process.

The _s files contain the color for the specular highlight. If you take a close look at the world around you, you´ll notice that some materials are shiny and some are not. The spots on a texture that are shiny appear bright in the corresponding _s texture, and they can even have a color. For example, the cool, "sterile" look in the washroom scene is supported by a slightly blue/greenish look of the specular reflection of the stuff that´s there (take a look at the toilet and urinal textures).

BNA! · **Posted:** Sat Jul 12, 2003 9:18 pm

What der_ton said.

A minor addendum:

The local maps store geometrical informations used for per pixel lighting operations (dot3 bump mapping I think, don't quote me on that).
So the local add geometrical depth to your surface.

The _h files are used in combination with the locals to add more surface quality / properties.
If your local map represents a techy panel you can use the _h(eight) map to add some surface roughness.

Basically you can freely combine them.
I often achieve very very good rendering results in Doom3 when I use the diffuse map or the _s(pecular) map as an _h(eightmap).
You don't have to create individual files.

In some (rare or carefully planned) cases I get away with one and the same texture for diffuse, height and specular.

xyz · **Joined:** Fri Apr 18, 2003 12:27 pm **Posts:** 14

thanks... another thing: what the h*** is gloss?

BNA! · **Posted:** Sat Jul 12, 2003 11:55 pm

xyz wrote:

thanks... another thing: what the h*** is gloss?

Specular.

macbearchen · **Posted:** Fri Oct 03, 2003 6:39 am

I know the "xxx_local" used for DOT3 in DOOM3.

"xxx_b" or "xxx_bmp" or "xxx_h" are also use for bumpmap.
Each of them seem the same for "addnormal" behavior, right?

But here I have a question about how to combine "xxx_local" & "xxx_h".

Material ".mtr" file include info about
---------------------------------
bumpmap addnormals (xxx_local.tga, heightmap (xxx_h.tga, 6 ))
---------------------------------
The last integer is strength value for xxx_h.tga

I know they should be combined for more detail bumpmap effect.
But what's the combine function? How to deal with strength integer for
"xxx_h" heightmap file?

I think "xxx_local" and "xxx_h" should combine first, then load into
texture memory. Would you please tell me what is the exactly combine function used in DOOM3?

Thanks in advance.

der_ton · **Posted:** Fri Oct 03, 2003 8:30 pm

That´s a good question, I don´t know the answer but that same question came to my mind when I was programming a md5viewer.

Two methods of combining them came to my mind. First, take the vector of the _local map, and then add the vector from the _b/_h map (which has to be calculated first, using the scale value, and which has a z-component set to zero).
The second method is a bit more accurate I think, but involves more math: take the vector of the _local map and add the rotated vector calculated from the bumpmap. The second vector should be rotated by the same rotation that rotates the (0, 0, 1) (=undistorted normal) vector into the first vector. Get it? :wink:

This is ofcourse no answer to your question. I don´t know how exactly doom3 does this. In my md5viewer, I used the first method, and it looks ok. The visual difference is pretty small anyway. It´s only a difference for places on a texture where the surface is distorted very much by the _local map, and where the _b map has strong distortions, too.

macbearchen · **Posted:** Mon Oct 06, 2003 6:39 am

Thanks your 2 addnormal-methods.

I think we have a way to find out what's the exactly combine method. Just uncompressed the ".d3t" files in the "./base/d3t" folder.

So my new question is how to read ".d3t" format and convert it to a bitmap. ".d3t" is a image format used in DOOM3. it seems a 16bit(RGB565) color, and compressed method is a little like ".dds" format.

If we could convert ".d3t" file to a bitmap file, and minus with xxx_local bitmap; then we will get the heightmap before addnormal.

Compare the result heightmap with and original heightmap xxx_h, the answer would be appeared.

But the key-point is reading ".d3t" format. How to? I don't know. Anyone has ideal?

der_ton · **Posted:** Mon Oct 06, 2003 9:08 pm

That´s a great idea to look into the .d3t files.
The .dds format is only a "container" format, with the bitmap encoding being not really related to dds. So it might be that they´re using the ordinary texture compression methods...

If you turn off compression, and set the texture color depth to 32 bit, then the d3t files should be easy to read, right? (If they are used at all... but they should be updated when you turn on texture caching...)

rich_is_bored · **Posted:** Tue Oct 07, 2003 1:29 am

Actually when you turn off compression, the directory and the d3t files therein are not even used.

macbearchen · **Posted:** Tue Oct 07, 2003 7:04 am

Quote:

So it might be that they´re using the ordinary texture compression methods...

So read ".d3t" as binary file, and skip header part; then assign data pointer to pData, and call following function.
---------------------------------------
glCompressedTexImage2DARB(GL_TEXTURE_2D, 0/*level*/, GL_COMPRESSED_RGB_S3TC_DXT1_EXT, width, height, 0/*border*/, imagesize, pData)
---------------------------------------
maybe it's the answer...

Just an

rich_is_bored · **Posted:** Tue Oct 07, 2003 3:48 pm

Judging from the quote of my post I'm guessing that openGL jargon was aimed at me?

Code:

glCompressedTexImage2DARB(GL_TEXTURE_2D, 0/*level*/, GL_COMPRESSED_RGB_S3TC_DXT1_EXT, width, height, 0/*border*/, imagesize, pData)

Ummm.... yeah.... 0100101 right back at ya.

der_ton · **Posted:** Tue Oct 07, 2003 9:17 pm

I think it´s quoted from my post, and to me the line of code makes sense, rich...

Have you tried that, macbearchen? I´m not looking into that issue, but I´m interested in what you find out.

You could also check some .dds files and compare them to the .d3t files. Or you could get info on the s3tc/dxt<n> texture compression specification and see if that´s what´s in these .d3t files.

macbearchen · **Posted:** Thu Oct 09, 2003 11:34 am

I try to use your 2nd method to generate more detail normalmap.
the key point is: use nVidia SDK "bumpmap_to_normalmap.cpp" to convert gray scale heightmap to RGB normalmap.

Quote:

The second method is a bit more accurate I think, but involves more math: take the vector of the _local map and add the rotated vector calculated from the bumpmap. The second vector should be rotated by the same rotation that rotates the (0, 0, 1) (=undistorted normal) vector into the first vector. Get it?

It seems work fine. About uncompress .d3t, maybe I will try it later, but currently I wish to do is make my md5viewer more reality as DOOM3 gameplay screen. der_ton, your md5mesh viewer is really cool that I ever see at internet. The other viewers often has some problems in bummap or specular part. You make the best.

I try to only use GL_COMBINE_ARB extension (no use NV/ATi/fragment) and 4 texture-units card(ex:Geforce3/4 ti, Radeon 8500). But, is it possible to render ambient+diffuse+specular multipass in 2 texture-units card(ex:Geforce2MX)? I know I could use NV_register_combiner to accomplish it, but how about just using ARB/EXT extensions?
Advanced Per-Pixel Lighting and Shadowing by Ronald Frazier has a method to use Alpha-Buffer to do multipass in 2 texture-units. but it used NV_register_combiner extensions.
Simple Bump Mapping by Paul do multipass in 2 texture-units and only use ARB extension, but it doesn't deal with ambient+specular.

Just curious if only 2 texture-units card(ex:Geforce2MX) and only use ARB/EXT extension possible to render ambient+diffuse+specular?

Of course, render ambient+diffuse+specular single pass in 8 texture-units card is also wonderful, but I don't have a GeforceFX card

And use stencil-buffer for shadow-volume in md5viewer is the final goal. Keep working...

der_ton · **Posted:** Thu Oct 09, 2003 9:15 pm

macbearchen wrote:

der_ton, your md5mesh viewer is really cool that I ever see at internet. The other viewers often has some problems in bummap or specular part. You make the best.

Thanks dude!

macbearchen wrote:

I try to only use GL_COMBINE_ARB extension (no use NV/ATi/fragment) and 4 texture-units card(ex:Geforce3/4 ti, Radeon 8500). But, is it possible to render ambient+diffuse+specular multipass in 2 texture-units card(ex:Geforce2MX)? I know I could use NV_register_combiner to accomplish it, but how about just using ARB/EXT extensions?
Advanced Per-Pixel Lighting and Shadowing by Ronald Frazier has a method to use Alpha-Buffer to do multipass in 2 texture-units. but it used NV_register_combiner extensions.
Simple Bump Mapping by Paul do multipass in 2 texture-units and only use ARB extension, but it doesn't deal with ambient+specular.

Just curious if only 2 texture-units card(ex:Geforce2MX) and only use ARB/EXT extension possible to render ambient+diffuse+specular?

If my viewer detects only 2 texture units, it doesn´t do specular lighting or ambient. I think D3 behaves the same way.

But it is possible to do the full ambient+diffuse+specular on a 2 texture unit card with ARB extensions only, that would involve rendering to temporary screens, it would be pretty slow. The temporary buffer is necessary, because you have to multiply the lighting pass with the diffuse texture. But the lighting pass itself has to be done with 2 textures (localmap DOT3ed with normalization cubemap). So if you have more than one lightsource, you cannot render the lighting of the 2nd and following lightsources to the screen anymore, without destroying the content.
With 1 lightsource, it works, because you start with the lighting, and then use a 2nd pass to multiply the result of the 1st pass with the diffuse texture. But for the specular, you would have to use a temporary buffer again.

By the way, there´s an updated version of my viewer that has better (more pointy) specular highlighting, but it uses NV_register_combiners to do that. It has some other added features, too. BNA has the zip but didn´t upload it yet. If you want to have it, send me a message.

I ask myself how you can get a pointy specular highlight on ATI cards with 4 texture units. There are no extensions similar to the register combiners, right? Maybe it´s possible with a 1D lookup texture that has the desired ramp.

BNA! · **Posted:** Fri Oct 10, 2003 5:36 am

der_ton wrote:

BNA has the zip but didn´t upload it yet. If you want to have it, send me a message.

Sorry, send it again and I'll up it asap!

macbearchen · **Posted:** Mon Oct 13, 2003 6:51 am

der_ton wrote:

By the way, there´s an updated version of my viewer that has better (more pointy) specular highlighting, but it uses NV_register_combiners to do that. It has some other added features, too. BNA has the zip but didn´t upload it yet. If you want to have it, send me a message.

Sure, would you please give me your lastest md5viewer via E-mail or share in this Doom3world.org?

May I ask you how many pass to render each light source (ambient+diffuse+specular) in your md5viewer and each texture unit usage at each pass in detail?

Thanks.