PDA

View Full Version : are gradients possible in the stencil buffer? ref/mask perhaps?



opengl_enquirer
10-02-2003, 07:34 AM
here is the idea. i would like to cut down the fill when rendering shadow volumes. so i'm keeping my extrusion distance relatively short. but ideally i wonder if it would be possible to create a gradient in the stencil buffer so that when the volumes are drawn into the stencil buffer with alpha components at the far side of the volume it will create a gradient darkest at the source of the volume and lightest at the destination. in this way making the short extrusions less obvious in the ends. due to constraints this can only be done in the stencil buffer. i have a feeling this is not possible but its worth a shot i guess.

michael

[This message has been edited by opengl_enquirer (edited 10-02-2003).]

dorbie
10-02-2003, 08:32 AM
You can make a color gradient on the extruded volume which might be appropriate for some cheesey approaches to blending the shadow or light contribution, that sounds like it's what you want to do.

zeckensack
10-02-2003, 08:36 AM
No. Stencil is not a vertex attribute and is not subject to interpolation.
You could achieve some of that with an interpolated (destination) alpha, I guess, but definitely not with stencil alone.

opengl_enquirer
10-02-2003, 12:38 PM
yeah i don't figure it would work. all i wanted is that the shadow would fade out with distance. there is a simple way to do this but it is too expensive. the only viable solution would be to store the gradient in the stencil buffer if possible. does the stencil buffer not have depth? or is it one bit deep? if so what would be the use of the depth?

Korval
10-02-2003, 01:11 PM
I don't think that you fully understand how shadow volumes create shadows.

A fragment is culled if it is in shadow and not culled if it is not; that's what stencil operations do. There is no concept of "kinda shadowed" or some percentage of shadow. The stencil operation either culls the fragment or not.

opengl_enquirer
10-02-2003, 03:21 PM
i don't pretend to fully understand the stencil operations or architecture entirely, in fact i can assure you i don't. what you have to add is quite clear, but to assume no more functionality exists i think would be foolish. clearly ore at least likely there is much more functionality then that in the stencil buffer operations and architecture.

i've seen many statements regarding the stencil buffer which suggests it is more than a bit buffer. and if that is the case then there is not unreasonable to imagine that the buffer might be able to do "partial" shadows as you phrase it.

notions such as increment decrement and overflow are regularly used with regard to the stencil system. if such is merely as you state it then clearly incriments and decrements would be meaningless and only invert would make since. but that does not appear to be the case. perhaps this is used for future functionality and presently the buffer is but merely 1 bit deep. i don't claim to these matters as a matter of fact. in any case that is the basis of my reasoning.

michael

dorbie
10-02-2003, 04:09 PM
opengl_enquirer, it's clear you haven't tried to implement even basic stencil shadows, perhaps you should before exploring more advanced questions. Korval is 100% correct, the increments and decrements are counting stencil contributions from front vs back faces, there is no concept of partly shadowed in the basic stencil algorithm. These capabilities do not contradict anything korval said. There are two phases to stencil operations, one is the counting of the extruded wall contributions to each pixel the other is the test of some form of lighting or shadow contribution against the result. These are very distinct and specific uses of stencil buffer at different stages in implementing the algorithm.

[This message has been edited by dorbie (edited 10-02-2003).]

opengl_enquirer
10-02-2003, 05:11 PM
forgive me if i'm mistaken, but your attitudes appear rather antipathetic. i'm running the most sophisticated shadow volume demonstration i've ever seen anywhere. thats not to say they come in too many varieties. in any case i don't apreciate your attitudes nor do i care to entertain your response, which appears to be more to shelter your ego than to be of any real service to anyone, at least on this occasion.

michael

Tom Nuydens
10-03-2003, 12:00 AM
Originally posted by opengl_enquirer:
i'm running the most sophisticated shadow volume demonstration i've ever seen anywhere. thats not to say they come in too many varieties.

First you say you don't pretend to understand stencil operations entirely. You state that perhaps increment/decrement operations are meaningless and that only inverting should suffice, and that you think the stencil buffer might only be 1 bit deep. All of which is wrong. That's okay though -- we're here to help, after all.

But then you attack Dorbie for suggesting the obvious, namely that you should first try to get a full understanding of how the stencil shadow algorithm works before attempting to tackle more advanced issues. So I hope you'll forgive us our scepticism when you suddenly claim to have written the most advanced stencil shadow implementation around...

-- Tom

opengl_enquirer
10-03-2003, 05:29 AM
"First you say you don't pretend to understand stencil operations entirely."

entirely is a very extensive word.

" You state that perhaps increment/decrement operations are meaningless and that only inverting should suffice, and that you think the stencil buffer might only be 1 bit deep."

i did not feel that way, and perhaps if you would pay more attention you would realize that these comments i made were satirical.

"All of which is wrong."

which i hardly doubted. pay attention.

"That's okay though -- we're here to help,after all."

thats an admirable trait, so is honesty.


"But then you attack Dorbie for suggesting the obvious, namely that you should first try to get a full understanding of how the stencil shadow algorithm works before attempting to tackle more advanced issues."

i do understand how it works essentially. and the dorbie chap was either being fececious or did not pay any attention to the discussion at hand. one might come to the same conclusion on your behalf...

"So I hope you'll forgive us our scepticism when you suddenly claim to have written the most advanced stencil shadow implementation around..."

clearly you are being fececious as well at this point. i don't have time to quible over the relevance of my doings. i'm running about 20 to 30 more shadows than i've ever seen and the code is highly optimized more so than anything i've witnessed, but then i don't get out much. if you would pay attention the point of this thread was to find ways to cut down fill rate when rendering shadows. but i think i'm but wasting my breath at this point, as this crowd seems to have an overly negative and irrationally confrontational air about it.

in the future i hope you can find time to reexamine your posture towards such interactions between social beings.

best wishes,

michael

DopeFish
10-03-2003, 05:54 AM
Please dont even pretend that you are in the right here opengl_enquirer. The replies above from others are explaining how things work, which you clearly did not know in your posts, and you attack them for it.

Especially attacking Dorbie... he is one of those I respect the most on this forum, as he is highly knowledgable and often lends an answer to ones questions.

Again, you clearly didnt know how the stencil buffer works nor how it is used in relation to shadow volumes, yet when told this you attacked those who mentioned it. Not a very sociable thing to do. If you attack those who are trying to help you, where will you end up?

opengl_enquirer
10-03-2003, 07:25 AM
listen, i don't have time for this. you are now accusing me of lieing. how can you make claims you can by no means begin to prove on any grounds. clearly this has become an irrational discussion. as for my sincerity i can asure you it is impecible. actually i suffer from something akin to lieaphobia. i would sooner kill over than shed anything remotely associable to a lie.

so you are wrong. that i can assure you. in fact if false words have crossed my lips then unto you i bequeath my soul provided the facilities exist.

clearly no technical progress is being made here so i must bid this thread adieu.

sincerely,

michael

Korval
10-03-2003, 08:36 AM
what you have to add is quite clear, but to assume no more functionality exists i think would be foolish.

I'm sorry, you seem to have misinterpreted my statements as an opinion or supposition.

I assure you that what I said is no less than the the absolute fact; no assumptions or suppositions. The only thing a stencil operation does is cull fragments based on the outcome of a test, in a similar fashion to how the alpha test works. Since a fragment can only be culled or not culled, you can't have the stencil operation return a "half-culled" fragment.

Now, you can choose not to believe this fact. You can go off investigating other possibilities in stencil hardware. Your disbelief will not change the facts. Your search for other stencil possibilities will not change the facts. You can either accept these facts, or not.

vincoof
10-03-2003, 09:59 AM
opengl_enquirer : I don't want to continue the flame war, but if you read carefully at the posts, you are the one who is dropping the first blood. Indeed, you felt like you were attacked when dorbie told you to learn basic stencil shadows first, but it was not his intention.

As for setting this post on-topic, I'm afraid that Korval is right : the stencil buffer can only cull or not cull. Actually, there is no other way of using the stencil buffer. Maybe that future hardware will be capable of using the stencil buffer as an input of a blending stage, but for what I know there is no plan on doing so, not even in the long run. And as for creating a stencil gradient, actually it's only possible if you render your model multiple times with e.g. the stencil operation set to increment and combined with clipping planes... that's possible, but I think it's really too gpu-intensive and definately not acceptable for real-time applications.

dorbie
10-03-2003, 11:13 AM
You have a very thin skin, it wasn't my intention to attack and I agree with others that I was simply stating the obvious w.r.t. stencil ops vs stencil test, I was trying to be helpful although I could have tried a gentler approach.

Shelter my ego from what? All I did was point out korval was correct, how is *my* ego affected? I don't think you have an appreciation for just how off base your disagreement with korval makes you look to the informed reader. I explained in my post the difference between stencil ops and stencil testing, perhaps you should take the time to read that part of my post. Implementing stencil shadows with any degree of comprehension would make what korval has written absolutely clear to you.

I'm sure it's possible to do a great stencil shadow demo with an incomplete understanding of the details, there are plenty of tutorials to get the code from but understandig exactly how this works can be rewarding and help you make real progress with your own ideas.

opengl_enquirer
10-03-2003, 06:04 PM
i've looked around for a complete explanation of shadow volumes that is clear but i've been unable to find one that is unambiguous.

i understand basic shadow volumes, but i admit i don't fully understand the complete implications of the ref and mask states.

of the stencil op i think it is may be function i don't have a reference on had at this terminal.

the mask is a bit mask, but it is always set to ones compliment zero in any use of it i've seen. i'm not sure what this does, i've never seen an explanation and i've never dared to experiment with it. i'm not sure what effects it might cause. i understand that the reference is anded with the mask. i saw a demo where 128 is used by the reference in order to disable self shadowing. with greater than or equal depth testin i think it was. which reminds me is there only one mask and one reference or a set for each depth function? these sorts of things are up in the air in my head. and i've never found any sufficient documentation regarding these matters. i guess 128 could mean pass on the first pass if greater than or equal. and the mask is unecesarry unless the values are dynamically changing. i think i understand it, but i would still like to see a list of effects than can be achieved. it just seems to me if you are storing a whole byte in the stencil buffer you ought to be able to use it for something more intersting than culling.

//edit: on second thought this really wouldn't work to well unless you could use a procedural texture look up in a fragment program that renders to the stencil. which would look flat.

i'm sure it would be a little lossy. but it seems to me you aught to be able to do a gradient easily with it if the functionality was provided in the API. for instance you could count the passes from 0~255 with gradient values. have some clamping and scaling, and don't permit overflow, and i bet you could come up with something similar to what i would like to do with it.

[This message has been edited by opengl_enquirer (edited 10-03-2003).]

opengl_enquirer
10-03-2003, 06:32 PM
"You have a very thin skin, it wasn't my intention to attack and I agree with others that I was simply stating the obvious w.r.t. stencil ops vs stencil test, I was trying to be helpful although I could have tried a gentler approach."

stating the obvious under the circumstances can only be reasonably interperetted as condescending behavior. which serves no one, wasting your time as well as my own. the only remaining motivation is one of ego. this is the advanced forum is it not? perhaps this is how people treat one another, but i don't find it terribly comforting. especially under the impersonal circumstances.


"Shelter my ego from what?"

your conscious i would suppose. i wouldn't know really.


"All I did was point out korval was correct, how is *my* ego affected?"

i'm sorry i don't recall the discussion.

"I don't think you have an appreciation for just how off base your disagreement with korval makes you look to the informed reader."

i don't recall disagreeing on any technical grounds. perhaps i might disagree with any lack of consideration or general aloofness.


" I explained in my post the difference between stencil ops and stencil testing"

yeah one is rendering to mask one is rendering through mask. what good does that do me. recall the whole point was to find methods to subtract from fill rate. do you have nothing more to do with your time than to treat others with kids gloves? really. this is the advanced forum is it not?

"perhaps you should take the time to read that part of my post. Implementing stencil shadows with any degree of comprehension would make what korval has written absolutely clear to you."

i did not deny his/her words nor did i disagree as i recall. i probably disagreed in the manner they were delivered.

"I'm sure it's possible to do a great stencil shadow demo with an incomplete understanding of the details, there are plenty of tutorials to get the code from but understandig exactly how this works can be rewarding and help you make real progress with your own ideas."

i've seen two or three tops different versions of using the stencil buffer in shadow rendering. its bells and whistles surely would warrant more uses i thought. more often people are narrow minded. they see one way to use to use any given object for instance. its easier to say what can be done than what can't be done.

in any case while we're on the subject.

i've noticed for some time when rendering shadows it seems that if you position the view in a particular spot the frame rate will fall way down move a few degrees over and its totally gone. what is it with these spots? any solutions? what could cause this behavior?

anyhow i'm moving on to bump mapping now. i hope i don't cause quite the same uproar over that.


must be going,

michael

opengl_enquirer
10-03-2003, 06:59 PM
so if more than 8 shadows overlap then the buffer overflows? or is it four? does overflow result in intersection effects? for instance if you overlap 2 black filled circles and the overlaping parts become white.

also i'm thinking about just rendering the shadow volumes again with alpha components on the ends during the stencil testing phase. this will have the same desired effect and will allow for shorter extrusions which mean less fill. the gradient shadows might be less fill than would be required to render the fully extruded volumes. i can afford to do this as all of my rendering is within a well confined space floating in blackness.

edit: actually this won't really work for what its worth at least not without any tricks that probably wouldn't be supported by the api.

my system seems to be much more fill limited than geometry limited. i guess this means i could afford denser geometry. are there any good general solutions to overcome fill rate?


by the way someone suggested i was building a demo. i don't do demos... i think i used the term demonstration myself, but i only meant it in the most abstract form.

i'm just trying to get my monies worth out my graphics hardware. plus the graphics impress people who like shiny things. usually the sorts who have a lot of shiny things...

well back to the laundry.

michael


edit: PS i guess the only thing left is frustum culling the shdows and not extruding them further than necesarry. opengl does clip the polygons to the viewport doesn't it?


[This message has been edited by opengl_enquirer (edited 10-04-2003).]