Thread: RE: [Algorithms] Multipass alpha-blended objects
Brought to you by:
vexxed72
From: Rowan W. <ro...@ir...> - 2005-11-14 22:37:33
|
I'll just stick my head into this thread and say "depth peeling".... solves all these issues, and is *almost* feasible on current hardware. rowan=20 > -----Original Message----- > From: Miles Macklin [mailto:gd...@co...]=20 > Sent: Tuesday, 15 November 2005 7:59 AM > To: gda...@li... > Subject: Re: [Algorithms] Multipass alpha-blended objects >=20 > Sorry you are right though, fogging transparent objects is=20 > more difficult because your destblend would have to look=20 > something like 1-fogintensity*alpha and your srcblend like=20 > fogintensity*alpha - which isn't quite right, you can try=20 > rearranging it but they all have varying degrees of wrongness. >=20 >=20 > ----- Original Message ----- > From: "Miles Macklin" <gd...@co...> > To: <gda...@li...> > Sent: Tuesday, November 15, 2005 9:31 AM > Subject: Re: [Algorithms] Multipass alpha-blended objects >=20 >=20 > > > 1. Dest alpha might not be available for various reasons.=20 > Did you use > dest > > > alpha, or were your materials simple enough to be able to generate > > > on-demand? > > > > We don't use dest alpha because generally our alpha values=20 > are simple > enough > > to output. > > > > > 2. Material color was very expensive to generate, so=20 > doing it once for > > alpha > > > and again for color was not acceptable. Some materials=20 > were themselves > > > multiple passes, so that was basically impracticle. > > > > Sorry I'm not sure I follow, why would you generate the=20 > material colour > for > > alpha and then generate it again for colour ? But I=20 > understand if you > have > > a material colour that is very expensive and you need=20 > access to it in > > multiple passes you probably want a temporary copy. > > > > > 3. there was no general set of math that could be done in=20 > each pass to > > blend > > > the accumulated result properly. When doing additive=20 > diffuse passes > > followed > > > by modulative material passes followed by specular/env=20 > passes and fog, > it > > > just couldn't be done without storing temporary results=20 > in alternate > > > buffers. > > > > I can't see why doing a bunch of additive passes followed by a green > overlay > > pass (for example) followed by a fog pass doesn't work. In=20 > fact thats > > exactly what we do, it just breaks down to: > > > > result =3D (((light0 + light1 + > > light2)*green)*(1-fogIntensity))+(fogIntensity*fogColour) > > > > > > > Your example is almost like this except it seems to have=20 > only additive > > > passes mentioned. And perhaps I misunderstood, but I'm=20 > not sure how the > > sort > > > groups actually help the situation. I think if each=20 > object was its own > > group > > > the inter-group problems would be eliminated. Basically,=20 > do all the > passes > > > for each object before moving on... Maybe batching the=20 > shader passes was > > > more important than proper sorting in your case...? > > > > Yes, this is what I was getting at with my note at the=20 > bottom. The sort > > groups are only used to reduce batch counts, the general=20 > solution is to > use > > each object as a group. > > > > > > > > > > I'm pretty sure there really is no magic bullet here to=20 > get everything > > > "right"--just a matter of choosing the appropriate=20 > tradeoffs. Maybe more > > > games than I realize just accept bad sorting and get away=20 > with it... > > > > > > Thanks, > > > Wes > > > > > > ----- Original Message -----=20 > > > From: "Miles Macklin" <gd...@co...> > > > To: <gda...@li...> > > > Sent: Sunday, November 13, 2005 8:18 PM > > > Subject: Re: [Algorithms] Multipass alpha-blended objects > > > > > > > > > > Not sure if this is exactly what you want but this is=20 > what we use to > do > > > > multi-pass lighting with transparency. We separate our material > batches > > > > into sort groups. So our render pipeline looks something like: > > > > > > > > For each sort group > > > > Render base pass (ambient + emissive) using=20 > 1-SrcAlpha as Dest > Blend > > > > (for transparent materials) > > > > For each light > > > > Render shadows > > > > Render light affected batches in this sort group=20 > (modulate > result > > > > by > > > > alpha if transparent) > > > > > > > > A material specifies which sort group it belongs to and=20 > it's blend > > modes. > > > > Some examples > > > > of sort groups we have defined are: > > > > > > > > Opaque > > > > Decal > > > > Transparent > > > > Post Fog > > > > Post Process > > > > > > > > It doesnt solve the issue of multiple layers of=20 > transparency within a > > sort > > > > group (two transparent objects one in front of the=20 > other) but it does > > work > > > > between sort groups. Also you probably don't want to=20 > do shadow setup > > > > twice, > > > > we only render shadows for the opaque group (no shadows=20 > on transparent > > > > objects). > > > > > > > > Lots of caveats, but should work with MSAA. > > > > > > > > NB: this is really just a performance optimized version=20 > of the general > > > > solution, being: > > > > > > > > Sort batches back to front > > > > > > > > For each batch > > > > Render base pass > > > > For each light affecting batch > > > > Render shadows > > > > Render lights contribution (modulated by materials alpha > output) > > > > > > > > > > > > > > > > Cheers, Miles > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo=20 > App Server. > > Download > > > it for free - -and be entered to win a 42" plasma tv or=20 > your very own > > > Sony(tm)PSP. Click here to play:=20 > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDA...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > Download > > it for free - -and be entered to win a 42" plasma tv or=20 > your very own > > Sony(tm)PSP. Click here to play:=20 > http://sourceforge.net/geronimo.php > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App=20 > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: Rowan W. <ro...@ir...> - 2005-11-17 02:05:49
|
We don't use depth peeling (Not brave enuff to spend the time putting it in). We just disable the alpha dest blend on passes except for pass 0, and this only causes glitches in the mesh itself where it overlaps itself. For convex meshes (windows n such) that's not a problem, for other meshes the glitches tend to just be slightly lighter patches on the object (fine if this is just a quick fadeout effect). rowan > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...]=20 > Sent: Tuesday, 15 November 2005 10:31 AM > To: gda...@li... > Subject: Re: [Algorithms] Multipass alpha-blended objects >=20 > Yes, very true on both counts. Yes it works. Yes it's=20 > *almost* feasible. :) Does that mean you've made it perform=20 > well in an engine...? What's your secret sauce for making=20 > multipass alpha work, or do you just make sure your tools=20 > don't let it happen? >=20 > -Wes >=20 > ----- Original Message ----- > From: "Rowan Wyborn" <ro...@ir...> > To: <gda...@li...> > Sent: Monday, November 14, 2005 5:37 PM > Subject: RE: [Algorithms] Multipass alpha-blended objects >=20 >=20 > I'll just stick my head into this thread and say "depth peeling".... > solves all these issues, and is *almost* feasible on current hardware. >=20 > rowan >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: Wesley H. <we...@fu...> - 2005-11-17 05:28:46
|
Ah, so all your passes are additive, or do you just accept that the results won't look like a single-pass version? For instance, I'll have a bunch of additive diffuse passes, followed by a modulated material pass (followed by more additive passes). My material pass is too expensive to be done for each diffuse pass. This non-additive pass totally screws this up, because it modulates the accum'ed lighting AND what was behind the object. Yeah, a non-convex mesh may have problems in particular view directions even with single-pass. Thanks, Wes ----- Original Message ----- From: "Rowan Wyborn" <ro...@ir...> To: <gda...@li...> Sent: Wednesday, November 16, 2005 9:04 PM Subject: RE: [Algorithms] Multipass alpha-blended objects We don't use depth peeling (Not brave enuff to spend the time putting it in). We just disable the alpha dest blend on passes except for pass 0, and this only causes glitches in the mesh itself where it overlaps itself. For convex meshes (windows n such) that's not a problem, for other meshes the glitches tend to just be slightly lighter patches on the object (fine if this is just a quick fadeout effect). rowan |
From: Nicholas F. <nic...@ot...> - 2005-11-17 08:37:07
|
In Unity, we have a lot of multipassing going on. We use shader scripts that lets you set the blendmode, and it usually works fine for us to just hack something together that looks ok rather than trying to come up with a set of rules. The general pattern I see is that the 1st pass dims the background down using a normal alphaBlend (SrcAlpha OneMinusSrcAlpha). After that, passes that are essentially additive are just added with color modulated by alpha (srcAlpha One). If they are essentially multiplicative, we fade the colors up towards white as they get more transparent, and multiply them in. Works fine in practice.... Also goes fine with fixed-function fogging. Of course, if you have a configurable artist-set blend mode then it gets harder.... Can you possibly have a map of 'what this non- transparent blending mode should be when made transparent'?. Also, if the idea of fading the multiplicative pass to white as transparency increases can be hard if you give artists much control... \Nicholas On Nov 17, 2005, at 6:28 AM, Wesley Hunt wrote: > Ah, so all your passes are additive, or do you just accept that the > results won't look like a single-pass version? For instance, I'll > have a bunch of additive diffuse passes, followed by a modulated > material pass (followed by more additive passes). My material pass > is too expensive to be done for each diffuse pass. This non- > additive pass totally screws this up, because it modulates the > accum'ed lighting AND what was behind the object. > > Yeah, a non-convex mesh may have problems in particular view > directions even with single-pass. > > Thanks, > Wes > > ----- Original Message ----- From: "Rowan Wyborn" > <ro...@ir...> > To: <gda...@li...> > Sent: Wednesday, November 16, 2005 9:04 PM > Subject: RE: [Algorithms] Multipass alpha-blended objects > > > We don't use depth peeling (Not brave enuff to spend the time > putting it > in). > > We just disable the alpha dest blend on passes except for pass 0, and > this only causes glitches in the mesh itself where it overlaps itself. > For convex meshes (windows n such) that's not a problem, for other > meshes the glitches tend to just be slightly lighter patches on the > object (fine if this is just a quick fadeout effect). > > rowan > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Wesley H. <we...@fu...> - 2005-11-14 23:31:49
|
Yes, very true on both counts. Yes it works. Yes it's *almost* feasible. :) Does that mean you've made it perform well in an engine...? What's your secret sauce for making multipass alpha work, or do you just make sure your tools don't let it happen? -Wes ----- Original Message ----- From: "Rowan Wyborn" <ro...@ir...> To: <gda...@li...> Sent: Monday, November 14, 2005 5:37 PM Subject: RE: [Algorithms] Multipass alpha-blended objects I'll just stick my head into this thread and say "depth peeling".... solves all these issues, and is *almost* feasible on current hardware. rowan |