Archived

This topic is now archived and is closed to further replies.

Locke

Decals

Recommended Posts

Locke    122
Would anyone have any ideas as to apply decals. ie, have one texture on a face, but then, have another texture, with a trnslucent border, be drawn on the same face, so you can see the textures ''on top'' of each other. Any ideas would be greatly appreciated, Brendan ''Locke'' Hennessy

Share this post


Link to post
Share on other sites
vincoof    514
Multitexturing is the way to go.
But multitexturing is a bit complex to implement, and some graphics card do not support it (very rare not to support it nowadays though).


Otherwise, you can emulate with by drawing the second face with depth testing enabled to GL_EQUAL :
  
GLenum depth_func;
GLuint texture_back = ...; // set here your texture id for the overlapped texture

GLuint texture_front = ...; // set here you texture id for the overlapping texture. may have an alpha channel


glGetIntegerv(GL_DEPTH_FUNC, &depth_func); // get depth function. probably GL_LESS or GL_LEQUAL


// draw the polygons a first time

glBindTexture(GL_TEXTURE_2D, texture_back); // draw those polygons with the "back" texture.

drawMyPolygons();

glDepthFunc(GL_EQUAL); // ask the depth buffer to accept only the polygons which depth equals the depth of already drawn polygons.


// draw the polygons a second time

glBindTexture(GL_TEXTURE_2D, texture_front); // draw those polygons with the "front" texture.

drawMyPolygons();

glDepthFunc(depth_func); // restore the depth function back to the one that was activated before

Needless to say, texture mapping must be enabled using glEnable(GL_TEXTURE_2D); (if your texture has 2 dimensions of course).

Note that your 2 textures may not use the same texture coordinates. In that case, you have to change the code a little bit. (Not very complex, "I''ll let it as an exercise for the reader" )

It is very important that the 2 sets of polygons (1 set for the back, 1 set for the front) have exactly the same coordinates, or else the depth test will fail and result in undesirable effects.


That''s just an example to see how decal works.
But for faster implementations (say, if a lot of polygons use decals), I recommend using multitexturing.

Share this post


Link to post
Share on other sites
Melgo    122
Hi,
I''m new to ogl (playing with NeHe''s firsts tuts) and can''t really figure it out but i guess send polys more than once in the pipeline is not a really efective way to work with decals.

I''ve never used textures but I think copy/paste and blend texs in video memory is fast so why not :

- calculate or aproximate decals coords on the back texture
- make a copy of the back texture in video memory
- copy the decal(s) on the copy of the back tex (with a transparency color if needed)
- draw the poly with the new tex (back tex + decals)
- destroy the new tex because video memory''s not infinite

now the things i don''t know :
- can we do that with ogl?
- is it an efective way of working with decals?

Share this post


Link to post
Share on other sites
vincoof    514
Salut Melgo,
Et un français de plus, un

Your technique is very clever, but may not be applied in "the general case".
If the two textures are always drawn together, you can do it and it will be faster, because obviously simpletexturing is the fastest way if possible.

But the textures might not be used together only. The back "texture" may be used somewhere else, and probably the "decal" texture too. In that case, you could still do your method, but you may not free the "back" and "decal" textures, and so it would overload the memory.

There''s also another problem if you want to make the decal "float" over the back texture (for instance, a shadow over a surface) : as your method is static, it would not be possible unless you compute your texture again at each frame (very expensive).


Also, to answer your questions:

> can we do that with ogl?
Yes we can. And it can be very fast if you do it well.

> is it an efective way of working with decals?
It is the most effective way, but it requires some conditions, as shown above.


Generally, if your method is used, it may not be done by OpenGL.
The texture could be computed by the software which saved the picture.
In most games, that kind of preprocessing is rarely done on-the-fly (eg while running the game) because it slows down the program (even if it''s done in the starting : it slows down the starting which is undesirable too).

Share this post


Link to post
Share on other sites
Shag    122
NO NO NO!

Assuming you really are talking about decalling, rather than multitexturing, there is an extention which helps you out here:-

glPolygonoffset()

Look at:-

http://www.opengl.org/developers/faqs/technical/polygonoffset.htm

http://www.google.com/search?hl=en&q=glpolygonoffset

I have seen a demo using this somewhere - I'm sure if you dig deeply enough you'll find it!

Edited by - Shag on January 16, 2002 2:04:45 PM

Share this post


Link to post
Share on other sites
vincoof    514
Well hem, sorry, but I would not recommend using polygon offset.
I know it works quite well, but it's specialized for other cases IMO.

In that case, polygon offset is probably slower and surely give some artefacts, even though those artefacts are rarely "visible".

However, if your polygons where to apply the textures are be a little bit different (I mean, they don't have exactly the same vertex coordinates), you'll need polygon offset ; because the depth test would fail (with GL_EQUAL) and without polygon offset you could not guarantee the polygons to overlap perfectly.

Edited by - vincoof on January 16, 2002 2:41:45 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Nope, polygon offset is *exactly* for that case. Furthermore, it won''t make *any* speed difference, because it''s implemented in hardware in the OpenGL pipeline.

It is used to *remove* artifacts you get from the zbuffer, if your 2 decals do not match 100% accurate, because they do not share the same vertices. Polygon offsets now simply applies an offset to the z value written in the buffer, to avoid z-fighting artifacts. It works very well.

And I wouldn''t use multitexturing for decals. It''s a waste of texture units. And not all decal effects are possible using multitexturing. Imagine a big wall (with a repeated texture on it) with several different decals applied at different positions on the wall. The whole thing is lit with a lightmap.

Now, not using multitexturing you do the following: Draw the wall with the wall texture in Unit0, the lightmap in Unit1. You have a perfectly lit wall in a single pass. Now render the small decals with polygon offset and the decal texture in Unit0 (lightmap is still in Unit1). Perfectly lit decals, without any artifacts.

You could do the wall/decal drawing with multitexturing, but that would require splitting the geometry. And even with a single decal on a single wall: Never forget, that if you use up all your texture units for things like decals, then you won''t have them, if you want to light your scene (or apply effects such as bumpmaps), and then you are in trouble. You''d have to do several lighting passes, and that kills framerate. Texture units are a precious resource, don''t waste them.

Share this post


Link to post
Share on other sites
vincoof    514
I definately agree for the multitexturing thingy. Moreover, I could not have explained better myself

But IMO, if texture units are not a problem (say, if there''s no lightmap, no bump) I think multitexturing remains the best choice.
The thing is, I don''t know what Locke looks for.

About polygon offset, I agree that it''s useful when the surfaces do not perfectly match, but I disagree about the non-existence of the artefacts.
Polygon offset is by definition an artefact.
But as I alreay wrote, I admit those artefacts are rarely "visible".

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:

About polygon offset, I agree that it''s useful when the surfaces do not perfectly match, but I disagree about the non-existence of the artefacts.
Polygon offset is by definition an artefact.



How yo you define artifact ? Z-fighting is obviously one (and a very bad one), and a polygon offset eliminates it. I''m not aware of any artifacts that polygon offset *creates*. In fact, you could draw your whole scene with a polygon offset, and you wouldn''t notice the slighest difference, it''s just a zbuffer offset. It doesn''t affect projection or rasterization in any other way. It''s nothing more than a kind of ''GL_APPROXIMATE'' depth buffer function with an adjustable epsilon. Don''t see any problems with that.

Share this post


Link to post
Share on other sites
vincoof    514
The problem comes from the solution of the particular cases. (very deep, but does not mean anything :b)

With polygon offset, you can tell OpenGL that an object is in front of another when in reality it is at the same place or behind. (You can also reverse the effect, but it doesn''t matter).

The thing is, it''s obviously good for any polygon you want to create effects like decal. It is a desirable effect.

But, also, there could be polygons where this effect could appear whithout you were thinking of it. The undesirable effect.

Imagine a floor. It is textured and lightmapped (just to consume the texture units and not let use multitexturing for decal), and you add a "decal" : you write the "decal" part in front of the floor thanks to polygon offset. That''s okay.
Now imagine that a leaf falls. The leaf ends very close to the floor. But if you don''t take care of the polygon offset, the "decal" of the floor will draw "over" the leaf. That''s bad.

Do you see the kind of *artefact* I am talking about ?

To my mind, depth testing is not an artefact since an entire scene draw with depth testing looks real whatever the scene is (except for translucency). But polygon offset is, IMO, an artefact since it may add weird effects like this one.

Share this post


Link to post
Share on other sites
Shag    122
I can''t really see what the problem would be?

I assume you''re also using decals to draw the leaves? in which case draw the original decal with a very small offset, then draw the leave with a slightly larger offset!

Look at Q3A for example - can you tell that the bullet marks on walls are use glPolygonOffset? I somehow doubt it! I haven''t tried but I suspect you could layer several decals over each other without noticing.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:

With polygon offset, you can tell OpenGL that an object is in front of another when in reality it is at the same place or behind. (You can also reverse the effect, but it doesn''t matter).



That''s correct.

quote:

Imagine a floor. It is textured and lightmapped (just to consume the texture units and not let use multitexturing for decal), and you add a "decal" : you write the "decal" part in front of the floor thanks to polygon offset. That''s okay.
Now imagine that a leaf falls. The leaf ends very close to the floor. But if you don''t take care of the polygon offset, the "decal" of the floor will draw "over" the leaf. That''s bad.


No it will not. Remember, that polygon offset actually shifts the value written to the zbuffer. Note, that I didn''t say the z coordinate, but the *value* in depth buffers internal fixed point format. It will move it perhaps 10 units away (if you specify it like that). Modern zbuffers have at least 24bit. That''s a dynamic range of 16777216 units. The leaf that falls onto the ground will stop at least 1000-2000 units away from the floor (it is visually allready on the floor, since 1000 zbuffer units are visually indistinguishable). Now, what does the 10 little polygon offset units will do ? Nothing. And this becomes even more precise, if the camera is near the leaf, since the zbuffer precision is concentrated in the near view field.

Well parametrized polygon offsetting is visually perfect. No artifacts. You could literally draw thousands of layers one over the other with offsetting - It would still look perfect.

quote:

To my mind, depth testing is not an artefact since an entire scene draw with depth testing looks real whatever the scene is (except for translucency)



Not always. If you have to faces that intersect at a small angle, then you''ll get an effect known as z-fighting. It''s due to accuracy problems of the zbuffer, and that''s a *very* ugly artifact. Look at eg. Half-life, it was full of those not so nice effects.
NB: moi aussi, j''suis français...

Share this post


Link to post
Share on other sites
vincoof    514
On est envahi par des français


Shag: In this example I wouldn't like to see the "decal" on the leaf. That's why there is a problem.


quote:
Well parametrized polygon offsetting is visually perfect.

Of course, but that depends on how you define "well parametrized".
In your example, you reckon there's a 24bit depth buffer and that you know how to tweak a polygon offset to 10 units while you know that you won't let your leaf fall closer than 1000 units to the floor. In that case, the user knows exactly what he does. That's why it is perfect.
What I pointed out is, if you don't use the polygon offset wisely, you could have 1000 units offset while there are 10 units between the leaf and the floor. And that case may happen if the programmer doesn't master OpenGL.


quote:
If you have to faces that intersect at a small angle, then you'll get an effect known as z-fighting.

True about that.
Also, you can correct it too with polygon offset, but that's a waste of time for real-time rendering (unless you have a very poor zbuffer, like 8bit).

Edited by - vincoof on January 17, 2002 3:30:48 AM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
> On est envahi par des français

Hehe.. mais je suis breton, pas vraiment français, quoi

quote:

Of course, but that depends on how you define "well parametrized".
In your example, you reckon there''s a 24bit depth buffer and that you know how to tweak a polygon offset to 10 units while you know that you won''t let your leaf fall closer than 1000 units to the floor. In that case, the user knows exactly what he does. That''s why it is perfect.
What I pointed out is, if you don''t use the polygon offset wisely, you could have 1000 units offset while there are 10 units between the leaf and the floor. And that case may happen if the programmer doesn''t master OpenGL.



I agree on your general point. If you get more and more used to OGL, then it''s pretty obvious that you''ll get visually better results, knowing how to use particular functions the way they were intended to be used.

But this is true for lots of different parts in OpenGL, not only polygon offset. Polygon offset isn''t that difficult to parametrize either.

How many newbies do things like: glDepthRange(0.00001, 10000.0), and then they wonder why they have z tearing all over the place, even with 24bit+ zbuffers. Correct parametrization is a very important issue in a complex graphics system, and I agree that especially the whole zbuffer handling is not easy to get right. But I wouldn''t go that far and call a function like polygon offset an artifact by definition, simply because it isn''t. Yes, it can create artifacts, when handled in a wrong way, but allmost every function in OGL could. So, it''s entirely upon the programmer.

quote:

> If you have to faces that intersect at a small angle, then you''ll get an effect known as z-fighting.
True about that.
Also, you can correct it too with polygon offset, but that''s a waste of time for real-time rendering (unless you have a very poor zbuffer, like 8bit).



Well, I wouldn''t use a poly offset to correct those kind of problems either. It''s not intended for that, and would probably make the problem worse than it was before, if the 2 faces actually intersect instead of being coplanar. A good parametrization of the depth range can almost always avoid those problems, and if not, you can still split the faces at the intersection point.

Share this post


Link to post
Share on other sites
vincoof    514
> Hehe.. mais je suis breton, pas vraiment français, quoi
LOL


quote:
If you get more and more used to OGL, then it''s pretty obvious that you''ll get visually better results, knowing how to use particular functions the way they were intended to be used.

I agree, but I don''t know why I still think polygon offset is something fake in the graphics pipeline.
But in reality, 3D CG is fake in its whole ! So why should I set polygon offset as an exception ? Well, huh, dunno


quote:
How many newbies do things like: glDepthRange(0.00001, 10000.0)

And I would even say "glDepthRange(0., 0.1)"
Hey, that happened to me too in the beginning ! Don''t ROFL !


quote:
> > If you have to faces that intersect at a small angle, then you''ll get an effect known as z-fighting.
> True about that.
> Also, you can correct it too with polygon offset, but that''s a waste of time for real-time rendering.
Well, I wouldn''t use a poly offset to correct those kind of problems either. It''s not intended for that.

So who said you what it was intended for ? Eh eh, you can use every effect wherever you want if you can master it, right ?
I know it''s not a good way, but for realistic rendering it may be a solution. And remember you can not always tweak the depth range.


quote:
you can still split the faces at the intersection point

Hem, no.
I don''t see how it can correct the problem. Your polygons will still have close depth fragments, and the artefact will still be visible.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:

And I would even say "glDepthRange(0., 0.1)"
Hey, that happened to me too in the beginning ! Don''t ROFL !



The weird thing is, glDepthRange(0, 0) can actually have interesting applications when trying to get very advanced effects, dealing with z masking and depth textures.
quote:

So who said you what it was intended for ? Eh eh, you can use every effect wherever you want if you can master it, right ?
I know it''s not a good way, but for realistic rendering it may be a solution. And remember you can not always tweak the depth range.



Well, yes, you *could* of course use it. But you''d need a very special engine structure to sort those ''offending'' faces apart, then switch on poly offset, at the right level, render them, etc.. You''ll find yourself constantly switching states, it''s going to be slow as hell, if you do that for an entire scene. Though I agree that it can be usefull for very few, but critical problems, that can''t be removed otherwise.

On the other hand: a 24bit zbuffer is really enough, if you know how to use it. You can do really large ranges without getting artifacts, if you are carefull about your geometry. I try to avoid those degenerated faces in the first place Isn''t there an OGL extension, that uses the value 1/z in the buffer (kind of w-buffering) and enhances the dynamic range ? Something like float_depth_buffer or similar, I''ll have to check the ext-registry.

quote:

> you can still split the faces at the intersection point
Hem, no.
I don''t see how it can correct the problem. Your polygons will still have close depth fragments, and the artefact will still be visible.



Depends. There are 2 distinct artifacts created by the zbuffer, they are essentially the same phenomena, but one can be eliminated that way, the other not. If you have 2 faces that intersect, but are not really coplanar, they you might get tearing at the intersection line, since this intersection isn''t geometric, but created by the zbuffer at fragment level. You can 100% eliminate that effect by splitting your geometry.
The other artifact is z-fighting with almost coplanar faces, intersecting or not, you''ll get problems. This effect can only be solved by polygon offset, or a 64bit zbuffer, as some SGI systems have...

Share this post


Link to post
Share on other sites
vincoof    514
quote:
The weird thing is, glDepthRange(0, 0) can actually have interesting applications when trying to get very advanced effects, dealing with z masking and depth textures.

Huh, I''ve never heard about anything about this technique !?
Could you tell a little bit more please ? Give an example if possible ?
Thanks in advance.


quote:
But you''d need a very special engine structure to sort those ''offending'' faces apart, then switch on poly offset, at the right level, render them, etc.. You''ll find yourself constantly switching states, it''s going to be slow as hell, if you do that for an entire scene.

I know. That''s why I''ve written it may not used for real-time rendering. I''ve also written it''s good for realistic rendering. What could I say on top of that ?


quote:
Isn''t there an OGL extension, that uses the value 1/z in the buffer (kind of w-buffering)

I think the hardware decides it automatically for us.
But I may be wrong...


quote:
If you have 2 faces that intersect, but are not really coplanar, they you might get tearing at the intersection line, since this intersection isn''t geometric, but created by the zbuffer at fragment level. You can 100% eliminate that effect by splitting your geometry.

I''m sorry but I still don''t get that.
Je crois que si on ne parle pas français on ne se comprendra pas suffisamment ^^
Si 2 face s''intersectent, forcément elles ne sont pas coplanaires (sinon il y a comme qui dirait un pépin). Mais une question que je me pose : parles-tu d''une intersection en L, en T ou en X ?
En L je suis d''accord au détail près qu''il faut être tordu pour ne pas avoir les mêmes cordonnées dans l''angle. Donc ce ne peut logiquement pas être de cela dont tu parles, car la solution n''est pas de découper les polygones.
En T je suis d''accord uniquement si on voit le T de dos (c''est-à-dire si la caméra est au dessus de la lettre T).
En X je ne suis pas d''accord, car tu ne pourras pas te débarraser du "z-fighting" même en découpant les polygones.


quote:
or a 64bit zbuffer, as some SGI systems have

Well, of course it may be a little bit better. But it''s just about pushing the limits of the buffer a bit further. It does not really eliminate the problem.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:

>The weird thing is, glDepthRange(0, 0) can actually have interesting applications when trying to get very advanced effects, dealing with z masking and depth textures.
Huh, I''ve never heard about anything about this technique !?
Could you tell a little bit more please ? Give an example if possible ?
Thanks in advance.


No probs. One application, for example, are reflection. Everybody always told you, that you need a stencil buffer to make good multiple reflection in your scene, right ? Wrong. You don''t need a stencil buffer at all, all you need is glDepthRange. Effectively, calling glDepthRange(0,0) degenerates the z value written to the zbuffer to always be zero, but does not effect other raterization properties of the face. This makes it a perfect mask. Instead of a stencil mask, you can just write a z-mask with this method (if you use GL_LESS as depth buffer test on your scene, then the masked z buffer (being zero at masked pixels) will make sure that *no* geometry can draw into the masked region). You can unmask the region with glDepthRange(1,1). Here you go, perfect refllections, no stencil needed, works on every card that supports a zbuffer.

quote:

> Isn''t there an OGL extension, that uses the value 1/z in the buffer (kind of w-buffering)
I think the hardware decides it automatically for us.
But I may be wrong...



No it uses a linear zbuffer by default. The extension is called wgl_depth_float, I just looked it up. My 3D card does not support it, though.
quote:

Si 2 face s''intersectent, forcément elles ne sont pas coplanaires (sinon il y a comme qui dirait un pépin). Mais une question que je me pose : parles-tu d''une intersection en L, en T ou en X ?
En L je suis d''accord au détail près qu''il faut être tordu pour ne pas avoir les mêmes cordonnées dans l''angle. Donc ce ne peut logiquement pas être de cela dont tu parles, car la solution n''est pas de découper les polygones.
En T je suis d''accord uniquement si on voit le T de dos (c''est-à-dire si la caméra est au dessus de la lettre T).
En X je ne suis pas d''accord, car tu ne pourras pas te débarraser du "z-fighting" même en découpant les polygones.



Je parles du dernier cas, 2 faces qui s''intersectent en X. Hmm, comment expliquer ça, c''est pas évident... Ça à avoir avec la façon qu''OpenGL rasterise les triangles. Par l''interpolation de la valeur Z sur le triangle, OGL perds tout d''abord de la précision, et puis il n''est pas garanti, qu''un certain pixel reçoit la même valeur z, si les vertex bougent un tout petit peu. Disons, que tu as 2 faces en X, l''une d''entre elles bouge lentement en X ou Y. Regardes l''intersection de plus proche, tu verras qu''il y a une sorte de scintillement dans les pixel qui font l''intersection. C''est un effet comparable à celui créer par les vertex T. Ça doit pas nécessairement être énorme, mais selon les couleurs et le contrast, ça peut être assez génant. Par contre, si tu découpes les faces à l''intersection, cette ligne est mathématiquement précise, elle aura toujours les même valeurs z, même si elle bouge en X ou Y. L''intersection sera toujours claire et sans défauts. Les faces coplanaires sont un cas différent, là il faut le poly offset.

quote:

>or a 64bit zbuffer, as some SGI systems have
Well, of course it may be a little bit better. But it''s just about pushing the limits of the buffer a bit further. It does not really eliminate the problem.



I would say, it practically does eleminate the problem. Keep in mind, that the range of a 64bit buffer is around 1,100,000,000,000 times higher than the range of a 24bit buffer... means that instead of have two values mapping over the range of one single z unit in your 24 bit buffer, they map to a range of over 1 trillion units in the 64 bit buffer... That should *really* be enough

Share this post


Link to post
Share on other sites
vincoof    514
quote:
Here you go, perfect refllections, no stencil needed, works on every card that supports a zbuffer.

Well, you mean :
glClearDepth(0);
glClear(GL_DEPTH_BUFFER_BIT); // writes 0s in all depth buffer
glDepthRange(1,1);
glDepthFunc(GL_ALWAYS);
drawMyPolygon(); // create the mask with 1s in depth buffer
glDepthRange(0,1);
glDepthFunc(GL_LESS);
drawMyObjects(); // draw objects in the masked region

That's purely awesome !!!
Thanx for the tip

Also, it has one limitation : you can't render that at any moment. You have to find the time to do it at the beginning or the end of the rendering. right ?



quote:
Disons, que tu as 2 faces en X, l'une d'entre elles bouge lentement en X ou Y. Regardes l'intersection de plus proche, tu verras qu'il y a une sorte de scintillement dans les pixel qui font l'intersection.

Oui oui, Je vois très bien l'effet que c'est. Mais je ne vois pas en quoi le découpage des polygones peut arranger cet effet. Effectivement, l'approximation des Z est meilleure, mais toujours pas parfaite (et ne le sera jamais car les flottants auront toujours une précision limitée).

Mais ceci dit, je ce que vois encore moins, c'est pourquoi on se prend la tête avec ce cas particulier. Il faut qu'il y ait beaucoup de conditions réunies pour que ce soit visibile, et tout juste visible quand on sait qu'il existe et qu'on s'y attarde.



quote:
I would say, it practically does eleminate the problem. Keep in mind, that the range of a 64bit buffer is around 1,100,000,000,000 times higher than the range of a 24bit buffer...

LOL !!!
For the X junction, I agree it would be sufficient (unless your viewport is around 1e+15 pixels wide and high ).
But it would still not get rid of flickering for decal. Polygon Offset remains necessary.

Edited by - vincoof on January 18, 2002 5:49:30 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
> Also, it has one limitation : you can''t render that at any moment. You have to find the time to do it at the beginning or the end of the rendering. right ?

Yes, right. I do that at the beginning, before rendering the actual scene. Before rendering your non-reflected scene, you have to remove the screen mask with a glClear(), but this one is rather fast, esp. since it''s only on the zbuffer.
Then, directly after removing the mask, I rerender my original mask polygons (those who make the reflective faces) into the freshly cleared zbuffer, but this time without mask (with their normal depth values) and with their original texture. You can simply blend them with a constant alpha (will make a constant reflectivity), or with an alpha mask to modulate reflectivity by a map, very nice effect. It''s important to render them *directly* after clearing the mask, so that their original zbuffer coordinates are restored, or they will be overwritten by some other geometry.

If you want multiple reflective surfaces per frame, just remask your poly after having drawn your reflected scene, and repeat the procedure. This opens the door for another *really* cool effect you can do while rendering your initial masks: normally you would render your masks black or without affecting the colour channel. But if you actually set the blend function to modulate and render a coloured polygon while remasking your faces, then you will get a mirror with a filter colour effect. It will reflect the scene tinted in a specific colour, if you set it to eg. red, all your reflected scene will be tinted blood-red in the mirror.

AND: (while I''m allready at giving out the cool functions of my engine ), you can go a step further: don''t use a constant colour for the filter, but a filter colour map. Now, it''s starts to get really awesome. Take photoshop and write a red text onto a white background, make it look like blood... Use it as a filter colour map. Now your reflected scene will look normal in the mirror, but will be reflected tinted in red on the part of the mirror covered with your letters. This effect is so cool, and I haven''t seen it done anywhere before.
quote:

Mais ceci dit, je ce que vois encore moins, c''est pourquoi on se prend la tête avec ce cas particulier. Il faut qu''il y ait beaucoup de conditions réunies pour que ce soit visibile, et tout juste visible quand on sait qu''il existe et qu''on s''y attarde.



Bof, ça depends, moi ça m''énerve ce genre de problèmes, mais c''est peut-être, parce-que je suis perfectionniste

quote:

But it would still not get rid of flickering for decal. Polygon Offset remains necessary.



Your decal would have to be really very *very* close to your surface. Lift it up about a µm, and it will be OK. It all depends on your scale, and your depth range settings. But if you manage to get z fighting with a 64bit zbuffer, then you just deserve it

Share this post


Link to post
Share on other sites
vincoof    514
quote:
If you want multiple reflective surfaces per frame, just remask your poly after having drawn your reflected scene, and repeat the procedure.

Okay, that''s not so difficult. But don''t you think there could be a problem with depth buffer ?
With stencil buffer, you don''t modify the depth fragments, so there''s not a problem.
But with your technique you keep on clearing the z-buffer... that may yield some unexpected results when the polygons overlap between two reflections...


quote:
It will reflect the scene tinted in a specific colour, if you set it to eg. red, all your reflected scene will be tinted blood-red in the mirror.

Eh eh, but you can also do that with the stencil buffer


quote:
Take photoshop and write a red text onto a white background, make it look like blood... Use it as a filter colour map. Now your reflected scene will look normal in the mirror, but will be reflected tinted in red on the part of the mirror covered with your letters.

That seems to be very cool
Moreover, I don''t know if you can achieve such effects with the stencil buffer because I don''t know if removing the color masks also removes alpha testing.



Thanks again for all those tips. Make sure read ones of mine somewhere in this forum

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:

Okay, that''s not so difficult. But don''t you think there could be a problem with depth buffer ?
With stencil buffer, you don''t modify the depth fragments, so there''s not a problem.
But with your technique you keep on clearing the z-buffer... that may yield some unexpected results when the polygons overlap between two reflections...



Well, you can''t have reflective faces that intersect. But who uses them anyway ? Intersecting mirros automatically mean infinite interreflections, not a good idea... Other than that, everything else is possible with this method.
quote:

Eh eh, but you can also do that with the stencil buffer



Yes, but it requires an additional pass.

Share this post


Link to post
Share on other sites
tSG    122
That z-buffer technique sounds really good!!
And what do your experiments show? Is it faster or slower than using stencil buffer? Well, stencil buffer is implemented in hardware, but depth-buffer also!

Thanks in advance


-- tSG --

Share this post


Link to post
Share on other sites