Re our demos: Don’t blame me! Virtually all the GL apps I write are very minimal – plain old GLUT apps. I use C++, but not for most of its fancy features. Of course, I think only one of my apps has ever ended up on our website.
- Matt
I don´t blame you Matt, but you work for NVIDIA and perhaps you could mention, that it would be really nice to see some demos, that are simple, minimalistic and really show the point 
(and not how complicated one can code C / C++).
Diapolo
Originally posted by MichaelK:
[b]And what about templates? You can pass as an argument a set of options (number of dims, internal format, target). In that way class will be very efficent. For example:
template<DWORD num_dims, DWORD target>
class texture {
public:
void set_wrap_mode (GLenum mode) {
glTexParameteri (target, GL_TEXTURE_WRAP_S, mode);
if (num_dims >= 2)
glTex… (…GL_T…);
// and so on for GL_R and GL_Q}
};
Compiler should optimize this class such as unneeded instructions will be omitted because branches can be evaluated at runtime.
What do you think about this concept?[/b]
I don´t understand how this template is used here. We had them in school for classes and functions, where you don´t specifiy a variable-type like int or float (but I´ve never used them).
Diapolo
Originally posted by MichaelK:
[b]And what about templates? You can pass as an argument a set of options (number of dims, internal format, target). In that way class will be very efficent. For example:
template<DWORD num_dims, DWORD target>
class texture {
public:
void set_wrap_mode (GLenum mode) {
glTexParameteri (target, GL_TEXTURE_WRAP_S, mode);
if (num_dims >= 2)
glTex… (…GL_T…);
// and so on for GL_R and GL_Q}
};
Compiler should optimize this class such as unneeded instructions will be omitted because branches can be evaluated at runtime.
What do you think about this concept?[/b]
That’s a pretty cool idea. In fact, OpenGL functions are kinda like template functions. You can get glSomeFuncf, glSomeFunci, etc.
I had a prof in university who used to reminisce about the good old days when he wrote a renderer in microcode. I remember one of his lectures where he showed how to write template functions in C code using the preprocessor, a bunch of macros, and selectively inserting C-style comments into your function names and parameters. This dude was a wealth of info.
Back to your comment. That is a pretty cool idea. The problem that I see is that there may be too many template parameters.
I would have to sit down with a pen and paper and design it all out before I could see it as being feasible.
I dont understand, how to supply num_dims and target, could someone explain that little class 
?
Diapolo
Originally posted by Diapolo:
[b]I dont understand, how to supply num_dims and target, could someone explain that little class ?
Diapolo[/b]
typedef texture< 2, GL_TEXTURE_2D > CTexture2D;
CTexture2D myTexture;
Ahhhh, thank you .
Diapolo
OK, I´m looking for the basics, that I need, to create the Mipmap levels from a Normalmap.
I could read in the texture, pixel for pixel in a RGB triple (one byte for every component).
Every component (R, G and B) can consist of values in the range 0 to 255.
Every RGB triple represents a Vector in the normalmap in the range 0.0 to 1.0 (unsigned).
Correct the above, if something is wrong .
But now how do I have to use that knowledge, to down-sample and renormalize the Normalmap?
Diapolo
Any ideas / hints?
Regards,
Diapolo
Originally posted by Diapolo:
[b]OK, I´m looking for the basics, that I need, to create the Mipmap levels from a Normalmap.
I could read in the texture, pixel for pixel in a RGB triple (one byte for every component).
Every component (R, G and B) can consist of values in the range 0 to 255.
Every RGB triple represents a Vector in the normalmap in the range 0.0 to 1.0 (unsigned).
Correct the above, if something is wrong
But now how do I have to use that knowledge, to down-sample and renormalize the Normalmap?
Diapolo[/b]
its in the range -1 to 1, signed…
convert to a float, divide through 128, subtract one, and you get the 3 components…
sum up 4 normals wich result in the lowerres pixel, normalize, compress again by adding 1, dividing trough 128, store the lowrespixel. do this for every lowrespixel, upload. repeat with the lowrespixels as highres, for the next lower lowres image…
I read in a NV PDF, that the Normalmaps Normals are in the range 0 to 1.
And the ones in Heightmaps were -1 to 1.
But since it´s one byte, there are only 256 possible values, that was right, or?
And if it´s signed the range is from -128 to +128, did I get that basic stuff right 
?
About the Algo to create the Mipmapsm thanks and I will look into that, when I´m at home!
Regards,
Diapolo
Diapolo,
I believe you are right about that.
What you are doing right now is all the same stuff I’m trying to get implemented. Do you mind if I send you an email with some questions I have about normal maps and dot3?
Thanks,
Old GLman
Sure, you can send me an E-Mail .
I´ll try my best to help you …
But I´m still unsure about the range of the Normals in the Normalmaps .
0 to 1 or -1 to 1
I´ll quote the text from the NV PDF, that I´m talking about.
Or perhaps another guru could give me a short info on that .
Diapolo
Here is the info from the NV PDF BumpMappingWithRegisterCombiners.pdf, I was talking about.
Here, normals in
the [-1…1] range
are compressed to
the [0…1] range
The mostly chalk blue appearance
is because the “straight up” normal
is [0.5 0.5 1.0]
You see a height map on the left side and a Normalmap on the right side, so I´m pretty sure, that the Normals in a Normalmap are in the 0 to 1 range.
Diapolo