Thread: [Algorithms] Glowing objects
Brought to you by:
vexxed72
From: toni <to...@4d...> - 2004-12-27 07:45:00
|
Hello, I'm trying to add glow to my engine and well, after reading some articles [gpu gems] and talking with some demosceners (they add lots of post processing effects to their productions] i've ended with 2 solutions: 1st) Doing glow on a per object basis. With this i mean: render a pass to a texture with each object that glows, something like this SetRenderTarget(texture) for each object if(object->glows) RenderObject(object, object->glowMaterial); else RenderObject(object, blackMaterial); end for Blur(texture); SetRenderTarget(frameBuffer) RenderScene(); RenderQuad(texture, BlendingMode::ADD); 2) The approach used by demosceners is a bit different. They render the scene in a texture and then they do all the post process, something like this: SetRenderTarget(texture) RenderScene() GetTheBrightParts(texture); Blur(texture); SetRenderTarget(fremeBuffer); RenderScene(); RenderQuad(texture, BlendingMode::ADD); Ok, once presented both "algorithms", here comes the question. I prefer method one, as it allows me having glowing objects with an arbitrary material (this is a blue object with a green aura, for example), but i've found several caveats that makes me wonder if i am right or not. The biggest one is about having "remote cameras". Imagine a scene where u have several surveillance displays. Each one of those TV's have a camera attached that point to a different part of a building. Ok, those "remote cameras" render what they see to a texture and then u draw the monitor screen with that texture (as usual). The problem comes when u see a glowing object in one of those cameras and at the same time u see a glowing object in the surveillance room. U would be applying algorithm (1) twice (one for the remote camera and another for the main room). This means 2 glow passes and well, imho it starts to become expensive. Of course u can say something like "well, remote cameras don't apply glow", and that would solve the problem but i was wondering what other glowing algorithms are out there, if i'm following the right path, or if my approach is totally wrong. Sumarizing, what are the usual ways of doing real time glow (without using impostors, of course :) Thanx in advance, Toni |
From: Jon W. <hp...@mi...> - 2004-12-27 17:04:17
|
> camera attached that point to a different part of a building. Ok, those > "remote cameras" render what they see to a texture and then u draw the > monitor screen with that texture (as usual). The problem comes when u > see a glowing object in one of those cameras and at the same time u see You are correct: Per-object methods have a higher cost per object vertex; per-screen methods have a higher cost per pixel rendered (unless you get an entire screen's worth of glowing objects in the first case). Note that there's another draw-back to per-object glow: it doesn't look as natural. The reasons thing glow in real life have to do with two things: either light diffraction through non-transparent mediums such as haze, or physical (for cameras) or biological (for eyes) overbrightening in one area "spilling over" to nearby areas (in effect, a low-pass phenomenon). These two reasons for real-world glow are better emulated with screen- space brightness-distrubtion solutions, in my opinion. Cheers, / h+ |
From: David W. <da...@pl...> - 2004-12-27 19:06:32
|
I suggest you allow the artist to specify a glow channel (use the alpha of some existing texture... diffuse...normal map... whatever is free.). So in the example of the TV Monitor you render the scene from that camera's POV and the glow goes into the glow channel of the resulting texutre (diffuse). That gets put into the scene by rendering it on a quad and it's alpha goes into your framebuffer's glow channel (which might be alpha too). Then do the full screen glow. This would cause glows to bleed over the bezel of the TV Monitor, but that may or may not look bad. The bigger problem is that glow is a screen space operation and small things will appear to have much larger glow halos than big things... or rather... things farther from the camera. Something on a TV monitor that glows will look like it's blazing probably because one assumes the TV monitor is typically small on the screen so whatever it is viewing is even smaller. -- David toni wrote: > Hello, > > I'm trying to add glow to my engine and well, after reading some > articles [gpu gems] and talking with some demosceners (they add lots > of post processing effects to their productions] i've ended with 2 > solutions: > > 1st) Doing glow on a per object basis. With this i mean: render a pass > to a texture with each object that glows, something like this > SetRenderTarget(texture) > for each object > if(object->glows) RenderObject(object, object->glowMaterial); > else RenderObject(object, blackMaterial); > end for > Blur(texture); > > SetRenderTarget(frameBuffer) > RenderScene(); > RenderQuad(texture, BlendingMode::ADD); > > 2) The approach used by demosceners is a bit different. They render > the scene in a texture and then they do all the post process, > something like this: > SetRenderTarget(texture) > RenderScene() > GetTheBrightParts(texture); > Blur(texture); > > SetRenderTarget(fremeBuffer); > RenderScene(); > RenderQuad(texture, BlendingMode::ADD); > > Ok, once presented both "algorithms", here comes the question. > I prefer method one, as it allows me having glowing objects with an > arbitrary material (this is a blue object with a green aura, for > example), but i've found several caveats that makes me wonder if i am > right or not. > The biggest one is about having "remote cameras". Imagine a scene > where u have several surveillance displays. Each one of those TV's > have a camera attached that point to a different part of a building. > Ok, those "remote cameras" render what they see to a texture and then > u draw the monitor screen with that texture (as usual). The problem > comes when u see a glowing object in one of those cameras and at the > same time u see a glowing object in the surveillance room. U would be > applying algorithm (1) twice (one for the remote camera and another > for the main room). This means 2 glow passes and well, imho it starts > to become expensive. > > Of course u can say something like "well, remote cameras don't apply > glow", and that would solve the problem but i was wondering what other > glowing algorithms are out there, if i'm following the right path, or > if my approach is totally wrong. > Sumarizing, what are the usual ways of doing real time glow (without > using impostors, of course :) > > Thanx in advance, > > Toni > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > 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: Juhani H. <ju...@al...> - 2004-12-29 09:58:21
|
Hi, I have found it pretty hard to maintain alpha channel for the glow purposes only so I tried to find an alternative approach. Currently I am using the color channel only to create a glow. I am halving the color accuracy from 8-bit to 7-bit and using values above 127 for the glow only.I found this method to be much easier controlled than the alpha channel method. I would be interested in knowing if someone else is using similar approach. I'm doing along these lines: scene = rendered scene; glow = blur( everything_above(127, scene) ) final = scene * 2 + glow + ui passes -juhani -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of David Whatley Sent: Tuesday, December 28, 2004 4:06 AM To: gda...@li... Subject: Re: [Algorithms] Glowing objects I suggest you allow the artist to specify a glow channel (use the alpha of some existing texture... diffuse...normal map... whatever is free.). So in the example of the TV Monitor you render the scene from that camera's POV and the glow goes into the glow channel of the resulting texutre (diffuse). That gets put into the scene by rendering it on a quad and it's alpha goes into your framebuffer's glow channel (which might be alpha too). Then do the full screen glow. This would cause glows to bleed over the bezel of the TV Monitor, but that may or may not look bad. The bigger problem is that glow is a screen space operation and small things will appear to have much larger glow halos than big things... or rather... things farther from the camera. Something on a TV monitor that glows will look like it's blazing probably because one assumes the TV monitor is typically small on the screen so whatever it is viewing is even smaller. -- David toni wrote: > Hello, > > I'm trying to add glow to my engine and well, after reading some > articles [gpu gems] and talking with some demosceners (they add lots > of post processing effects to their productions] i've ended with 2 > solutions: > > 1st) Doing glow on a per object basis. With this i mean: render a pass > to a texture with each object that glows, something like this > SetRenderTarget(texture) > for each object > if(object->glows) RenderObject(object, object->glowMaterial); > else RenderObject(object, blackMaterial); end for > Blur(texture); > > SetRenderTarget(frameBuffer) > RenderScene(); > RenderQuad(texture, BlendingMode::ADD); > > 2) The approach used by demosceners is a bit different. They render > the scene in a texture and then they do all the post process, > something like this: > SetRenderTarget(texture) > RenderScene() > GetTheBrightParts(texture); > Blur(texture); > > SetRenderTarget(fremeBuffer); > RenderScene(); > RenderQuad(texture, BlendingMode::ADD); > > Ok, once presented both "algorithms", here comes the question. > I prefer method one, as it allows me having glowing objects with an > arbitrary material (this is a blue object with a green aura, for > example), but i've found several caveats that makes me wonder if i am > right or not. > The biggest one is about having "remote cameras". Imagine a scene > where u have several surveillance displays. Each one of those TV's > have a camera attached that point to a different part of a building. > Ok, those "remote cameras" render what they see to a texture and then > u draw the monitor screen with that texture (as usual). The problem > comes when u see a glowing object in one of those cameras and at the > same time u see a glowing object in the surveillance room. U would be > applying algorithm (1) twice (one for the remote camera and another > for the main room). This means 2 glow passes and well, imho it starts > to become expensive. > > Of course u can say something like "well, remote cameras don't apply > glow", and that would solve the problem but i was wondering what other > glowing algorithms are out there, if i'm following the right path, or > if my approach is totally wrong. > Sumarizing, what are the usual ways of doing real time glow (without > using impostors, of course :) > > Thanx in advance, > > Toni > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide Read honest & candid > reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ 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: Tom F. <tom...@ee...> - 2004-12-29 11:06:50
|
The problem with this method is that you cannot get a glowing light that = is not one of the seven pure colours (red, green, blue, yellow, cyan, = magenta, white). For example, orange. Orange is 100% red with 50% green. So if = you render a "glowing orange", what you get is two incorrect effects: -In the middle of the light, you get 200% red and 100% green. The red saturates to 100%, and you simply get bright yellow, not orange. -Around the edges, only the red channel blooms outwards, but the green = does not. So it's a yellow light with a red glow around it, as opposed to an = orange light with an orange glow around it. This is an extreme example, but you = can see the effect in real game situations as well, and it can look rather = odd at times. A hybrid scheme is to render the way you describe, ignoring what happens = to the alpha channel, then do a post-process and fill in the alpha channel = as the greyscale version of the colours. Then do the blur with the alpha channel, as described. That way it is the alpha channel that blurs, and drags the colour "orange" with it, rather than the red and green = channels blurring separately. This seemed to work slightly better for me. The downside is that with only a small dynamic range - 0 to 2 - it can = be really hard to get subtle degrees of glowing. Stuff tends to either glow massively, or not at all. You can't use a larger dynamic range because typically you only have 8 bits per channel. Losing one bit is not too = bad, but losing two is pretty visible. Whereas with the alpha channel method, non-glowing colours all have the full 8 bits to play with (alpha=3D0), = and glow amount also has 8 bits to play with, independent of the colour channels. (the reason I was trying to get the non-alpha-channel method working was that this had to work on various consoles which have extremely limited control over what happens in the destination alpha channel) It's all very tricky. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Juhani Honkala > Sent: 29 December 2004 01:56 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects >=20 >=20 > Hi,=20 >=20 > I have found it pretty hard to maintain alpha channel for the=20 > glow purposes > only=20 > so I tried to find an alternative approach. Currently I am=20 > using the color > channel=20 > only to create a glow. I am halving the color accuracy from=20 > 8-bit to 7-bit > and using=20 > values above 127 for the glow only.I found this method to be=20 > much easier > controlled=20 > than the alpha channel method. I would be interested in=20 > knowing if someone > else=20 > is using similar approach. >=20 > I'm doing along these lines: >=20 > scene =3D rendered scene; > glow =3D blur( everything_above(127, scene) ) > final =3D scene * 2 + glow + ui passes >=20 >=20 >=20 >=20 >=20 > -juhani >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On=20 > Behalf Of David > Whatley > Sent: Tuesday, December 28, 2004 4:06 AM > To: gda...@li... > Subject: Re: [Algorithms] Glowing objects >=20 > I suggest you allow the artist to specify a glow channel (use=20 > the alpha of > some existing texture... diffuse...normal map... whatever is free.). =20 > So in the example of the TV Monitor you render the scene from=20 > that camera's > POV and the glow goes into the glow channel of the resulting texutre > (diffuse). That gets put into the scene by rendering it on a=20 > quad and it's > alpha goes into your framebuffer's glow channel (which might=20 > be alpha too). > Then do the full screen glow. This would cause glows to=20 > bleed over the > bezel of the TV Monitor, but that may or may not look bad. >=20 > The bigger problem is that glow is a screen space operation=20 > and small things > will appear to have much larger glow halos than big things...=20 > or rather... > things farther from the camera. Something on a TV monitor=20 > that glows will > look like it's blazing probably because one assumes the TV monitor is > typically small on the screen so whatever it is viewing is=20 > even smaller. >=20 > -- David >=20 >=20 > toni wrote: >=20 > > Hello, > > > > I'm trying to add glow to my engine and well, after reading some=20 > > articles [gpu gems] and talking with some demosceners (they=20 > add lots=20 > > of post processing effects to their productions] i've ended with 2 > > solutions: > > > > 1st) Doing glow on a per object basis. With this i mean:=20 > render a pass=20 > > to a texture with each object that glows, something like this > > SetRenderTarget(texture) > > for each object > > if(object->glows) RenderObject(object, object->glowMaterial); > > else RenderObject(object, blackMaterial); end for =20 > > Blur(texture); > > > > SetRenderTarget(frameBuffer) > > RenderScene(); > > RenderQuad(texture, BlendingMode::ADD); > > > > 2) The approach used by demosceners is a bit different. They render=20 > > the scene in a texture and then they do all the post process,=20 > > something like this: > > SetRenderTarget(texture) > > RenderScene() > > GetTheBrightParts(texture); > > Blur(texture); > > > > SetRenderTarget(fremeBuffer); > > RenderScene(); > > RenderQuad(texture, BlendingMode::ADD); > > =20 > > Ok, once presented both "algorithms", here comes the question. > > I prefer method one, as it allows me having glowing objects with an=20 > > arbitrary material (this is a blue object with a green aura, for=20 > > example), but i've found several caveats that makes me=20 > wonder if i am=20 > > right or not. > > The biggest one is about having "remote cameras". Imagine a scene=20 > > where u have several surveillance displays. Each one of those TV's=20 > > have a camera attached that point to a different part of a building. > > Ok, those "remote cameras" render what they see to a=20 > texture and then=20 > > u draw the monitor screen with that texture (as usual). The problem=20 > > comes when u see a glowing object in one of those cameras=20 > and at the=20 > > same time u see a glowing object in the surveillance room.=20 > U would be=20 > > applying algorithm (1) twice (one for the remote camera and another=20 > > for the main room). This means 2 glow passes and well, imho=20 > it starts=20 > > to become expensive. > > > > Of course u can say something like "well, remote cameras=20 > don't apply=20 > > glow", and that would solve the problem but i was wondering=20 > what other=20 > > glowing algorithms are out there, if i'm following the=20 > right path, or=20 > > if my approach is totally wrong. > > Sumarizing, what are the usual ways of doing real time glow=20 > (without=20 > > using impostors, of course :) > > > > Thanx in advance, > > > > Toni > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide Read honest=20 > & candid=20 > > reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start=20 > reading now.=20 > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > 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 email is sponsored by - The IT Product Guide Read honest &=20 > candid reviews > on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > 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 email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > 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: David W. <da...@pl...> - 2004-12-29 17:38:35
|
I don't know about consoles.... but in Hero's Journey we use the alpha channel for glow and it is both easy to implement, manage and look sweeeet. :) -- David [Tom Forsyth on 12/29/2004 5:06 AM] >The problem with this method is that you cannot get a glowing light that is >not one of the seven pure colours (red, green, blue, yellow, cyan, magenta, >white). For example, orange. Orange is 100% red with 50% green. So if you >render a "glowing orange", what you get is two incorrect effects: > >-In the middle of the light, you get 200% red and 100% green. The red >saturates to 100%, and you simply get bright yellow, not orange. > >-Around the edges, only the red channel blooms outwards, but the green does >not. > >So it's a yellow light with a red glow around it, as opposed to an orange >light with an orange glow around it. This is an extreme example, but you can >see the effect in real game situations as well, and it can look rather odd >at times. > >A hybrid scheme is to render the way you describe, ignoring what happens to >the alpha channel, then do a post-process and fill in the alpha channel as >the greyscale version of the colours. Then do the blur with the alpha >channel, as described. That way it is the alpha channel that blurs, and >drags the colour "orange" with it, rather than the red and green channels >blurring separately. This seemed to work slightly better for me. > >The downside is that with only a small dynamic range - 0 to 2 - it can be >really hard to get subtle degrees of glowing. Stuff tends to either glow >massively, or not at all. You can't use a larger dynamic range because >typically you only have 8 bits per channel. Losing one bit is not too bad, >but losing two is pretty visible. Whereas with the alpha channel method, >non-glowing colours all have the full 8 bits to play with (alpha=0), and >glow amount also has 8 bits to play with, independent of the colour >channels. > >(the reason I was trying to get the non-alpha-channel method working was >that this had to work on various consoles which have extremely limited >control over what happens in the destination alpha channel) > >It's all very tricky. > > >TomF. > > > > >>-----Original Message----- >>From: gda...@li... >>[mailto:gda...@li...] On >>Behalf Of Juhani Honkala >>Sent: 29 December 2004 01:56 >>To: gda...@li... >>Subject: RE: [Algorithms] Glowing objects >> >> >>Hi, >> >>I have found it pretty hard to maintain alpha channel for the >>glow purposes >>only >>so I tried to find an alternative approach. Currently I am >>using the color >>channel >>only to create a glow. I am halving the color accuracy from >>8-bit to 7-bit >>and using >>values above 127 for the glow only.I found this method to be >>much easier >>controlled >>than the alpha channel method. I would be interested in >>knowing if someone >>else >>is using similar approach. >> >>I'm doing along these lines: >> >> scene = rendered scene; >> glow = blur( everything_above(127, scene) ) >> final = scene * 2 + glow + ui passes >> >> >> >> >> >>-juhani >> >> >> >> >> >> >> >>-----Original Message----- >>From: gda...@li... >>[mailto:gda...@li...] On >>Behalf Of David >>Whatley >>Sent: Tuesday, December 28, 2004 4:06 AM >>To: gda...@li... >>Subject: Re: [Algorithms] Glowing objects >> >>I suggest you allow the artist to specify a glow channel (use >>the alpha of >>some existing texture... diffuse...normal map... whatever is free.). >>So in the example of the TV Monitor you render the scene from >>that camera's >>POV and the glow goes into the glow channel of the resulting texutre >>(diffuse). That gets put into the scene by rendering it on a >>quad and it's >>alpha goes into your framebuffer's glow channel (which might >>be alpha too). >>Then do the full screen glow. This would cause glows to >>bleed over the >>bezel of the TV Monitor, but that may or may not look bad. >> >>The bigger problem is that glow is a screen space operation >>and small things >>will appear to have much larger glow halos than big things... >>or rather... >>things farther from the camera. Something on a TV monitor >>that glows will >>look like it's blazing probably because one assumes the TV monitor is >>typically small on the screen so whatever it is viewing is >>even smaller. >> >>-- David >> >> >>toni wrote: >> >> >> >>>Hello, >>> >>>I'm trying to add glow to my engine and well, after reading some >>>articles [gpu gems] and talking with some demosceners (they >>> >>> >>add lots >> >> >>>of post processing effects to their productions] i've ended with 2 >>>solutions: >>> >>>1st) Doing glow on a per object basis. With this i mean: >>> >>> >>render a pass >> >> >>>to a texture with each object that glows, something like this >>> SetRenderTarget(texture) >>> for each object >>> if(object->glows) RenderObject(object, object->glowMaterial); >>> else RenderObject(object, blackMaterial); end for >>>Blur(texture); >>> >>>SetRenderTarget(frameBuffer) >>>RenderScene(); >>>RenderQuad(texture, BlendingMode::ADD); >>> >>>2) The approach used by demosceners is a bit different. They render >>>the scene in a texture and then they do all the post process, >>>something like this: >>> SetRenderTarget(texture) >>> RenderScene() >>> GetTheBrightParts(texture); >>> Blur(texture); >>> >>> SetRenderTarget(fremeBuffer); >>> RenderScene(); >>> RenderQuad(texture, BlendingMode::ADD); >>> >>>Ok, once presented both "algorithms", here comes the question. >>>I prefer method one, as it allows me having glowing objects with an >>>arbitrary material (this is a blue object with a green aura, for >>>example), but i've found several caveats that makes me >>> >>> >>wonder if i am >> >> >>>right or not. >>>The biggest one is about having "remote cameras". Imagine a scene >>>where u have several surveillance displays. Each one of those TV's >>>have a camera attached that point to a different part of a building. >>>Ok, those "remote cameras" render what they see to a >>> >>> >>texture and then >> >> >>>u draw the monitor screen with that texture (as usual). The problem >>>comes when u see a glowing object in one of those cameras >>> >>> >>and at the >> >> >>>same time u see a glowing object in the surveillance room. >>> >>> >>U would be >> >> >>>applying algorithm (1) twice (one for the remote camera and another >>>for the main room). This means 2 glow passes and well, imho >>> >>> >>it starts >> >> >>>to become expensive. >>> >>>Of course u can say something like "well, remote cameras >>> >>> >>don't apply >> >> >>>glow", and that would solve the problem but i was wondering >>> >>> >>what other >> >> >>>glowing algorithms are out there, if i'm following the >>> >>> >>right path, or >> >> >>>if my approach is totally wrong. >>>Sumarizing, what are the usual ways of doing real time glow >>> >>> >>(without >> >> >>>using impostors, of course :) >>> >>>Thanx in advance, >>> >>>Toni >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide Read honest >>> >>> >>& candid >> >> >>>reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start >>> >>> >>reading now. >> >> >>>http://productguide.itmanagersjournal.com/ >>>_______________________________________________ >>>GDAlgorithms-list mailing list >>>GDA...@li... >>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>Archives: >>>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >>> >>> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide Read honest & >>candid reviews >>on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://productguide.itmanagersjournal.com/ >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from >>real users. >>Discover which products truly live up to the hype. Start reading now. >>http://productguide.itmanagersjournal.com/ >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://productguide.itmanagersjournal.com/ >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > |
From: Juhani H. <ju...@al...> - 2004-12-30 07:09:04
|
Thanks for your reply Tom. I have pretty much the problem you described and not really happy about it. In some problem cases it actually looks quite nice and provides interesting looking effects though ~ somehow reminds me of the classic Lomo camera a bit.. you never sure what you get but it still looks cool ;) The idea of calculating the brightness of color channels and using that to create a blurred glow is nice. I haven't yet tried it myself but it sounds pretty doable. Thanks for the idea. The reason I am looking beyond alpha-based glow is that I have problems maintaining a good glow-friendly alpha with the particle blending. Especially a one specific particle shader is a problem :) I have a 2-pass shader which darkens the background in the first pass and then the second pass renders the particles using additive blending. The point is that alpha is used to tell transparency of the particle - not its brightness. the higher the alpha is more the background is darkened in the first pass, in the second pass the alpha is somewhat ignored as simple additive blending is done. It can be that very dark particle has an alpha channel with the high alpha values and vice-versa. I could use two separate alpha channels though but that would mean extra work for artists and increased memory requirements. still looking for the optimal solution but I guess in the world of tricks there's none -juhani -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: Wednesday, December 29, 2004 8:07 PM To: gda...@li... Subject: RE: [Algorithms] Glowing objects The problem with this method is that you cannot get a glowing light that is not one of the seven pure colours (red, green, blue, yellow, cyan, magenta, white). For example, orange. Orange is 100% red with 50% green. So if you render a "glowing orange", what you get is two incorrect effects: -In the middle of the light, you get 200% red and 100% green. The red saturates to 100%, and you simply get bright yellow, not orange. -Around the edges, only the red channel blooms outwards, but the green does not. So it's a yellow light with a red glow around it, as opposed to an orange light with an orange glow around it. This is an extreme example, but you can see the effect in real game situations as well, and it can look rather odd at times. A hybrid scheme is to render the way you describe, ignoring what happens to the alpha channel, then do a post-process and fill in the alpha channel as the greyscale version of the colours. Then do the blur with the alpha channel, as described. That way it is the alpha channel that blurs, and drags the colour "orange" with it, rather than the red and green channels blurring separately. This seemed to work slightly better for me. The downside is that with only a small dynamic range - 0 to 2 - it can be really hard to get subtle degrees of glowing. Stuff tends to either glow massively, or not at all. You can't use a larger dynamic range because typically you only have 8 bits per channel. Losing one bit is not too bad, but losing two is pretty visible. Whereas with the alpha channel method, non-glowing colours all have the full 8 bits to play with (alpha=0), and glow amount also has 8 bits to play with, independent of the colour channels. (the reason I was trying to get the non-alpha-channel method working was that this had to work on various consoles which have extremely limited control over what happens in the destination alpha channel) It's all very tricky. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of > Juhani Honkala > Sent: 29 December 2004 01:56 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects > > > Hi, > > I have found it pretty hard to maintain alpha channel for the glow > purposes only so I tried to find an alternative approach. Currently I > am using the color channel only to create a glow. I am halving the > color accuracy from 8-bit to 7-bit and using values above 127 for the > glow only.I found this method to be much easier controlled than the > alpha channel method. I would be interested in knowing if someone else > is using similar approach. > > I'm doing along these lines: > > scene = rendered scene; > glow = blur( everything_above(127, scene) ) final = scene * 2 + > glow + ui passes > > > > > > -juhani > > > > > > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of > David Whatley > Sent: Tuesday, December 28, 2004 4:06 AM > To: gda...@li... > Subject: Re: [Algorithms] Glowing objects > > I suggest you allow the artist to specify a glow channel (use the > alpha of some existing texture... diffuse...normal map... whatever is > free.). > So in the example of the TV Monitor you render the scene from that > camera's POV and the glow goes into the glow channel of the resulting > texutre (diffuse). That gets put into the scene by rendering it on a > quad and it's alpha goes into your framebuffer's glow channel (which > might be alpha too). > Then do the full screen glow. This would cause glows to bleed over > the bezel of the TV Monitor, but that may or may not look bad. > > The bigger problem is that glow is a screen space operation and small > things will appear to have much larger glow halos than big things... > or rather... > things farther from the camera. Something on a TV monitor that glows > will look like it's blazing probably because one assumes the TV > monitor is typically small on the screen so whatever it is viewing is > even smaller. > > -- David > > > toni wrote: > > > Hello, > > > > I'm trying to add glow to my engine and well, after reading some > > articles [gpu gems] and talking with some demosceners (they > add lots > > of post processing effects to their productions] i've ended with 2 > > solutions: > > > > 1st) Doing glow on a per object basis. With this i mean: > render a pass > > to a texture with each object that glows, something like this > > SetRenderTarget(texture) > > for each object > > if(object->glows) RenderObject(object, object->glowMaterial); > > else RenderObject(object, blackMaterial); end for > > Blur(texture); > > > > SetRenderTarget(frameBuffer) > > RenderScene(); > > RenderQuad(texture, BlendingMode::ADD); > > > > 2) The approach used by demosceners is a bit different. They render > > the scene in a texture and then they do all the post process, > > something like this: > > SetRenderTarget(texture) > > RenderScene() > > GetTheBrightParts(texture); > > Blur(texture); > > > > SetRenderTarget(fremeBuffer); > > RenderScene(); > > RenderQuad(texture, BlendingMode::ADD); > > > > Ok, once presented both "algorithms", here comes the question. > > I prefer method one, as it allows me having glowing objects with an > > arbitrary material (this is a blue object with a green aura, for > > example), but i've found several caveats that makes me > wonder if i am > > right or not. > > The biggest one is about having "remote cameras". Imagine a scene > > where u have several surveillance displays. Each one of those TV's > > have a camera attached that point to a different part of a building. > > Ok, those "remote cameras" render what they see to a > texture and then > > u draw the monitor screen with that texture (as usual). The problem > > comes when u see a glowing object in one of those cameras > and at the > > same time u see a glowing object in the surveillance room. > U would be > > applying algorithm (1) twice (one for the remote camera and another > > for the main room). This means 2 glow passes and well, imho > it starts > > to become expensive. > > > > Of course u can say something like "well, remote cameras > don't apply > > glow", and that would solve the problem but i was wondering > what other > > glowing algorithms are out there, if i'm following the > right path, or > > if my approach is totally wrong. > > Sumarizing, what are the usual ways of doing real time glow > (without > > using impostors, of course :) > > > > Thanx in advance, > > > > Toni > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide Read honest > & candid > > reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start > reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide Read honest & candid > reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide Read honest & candid > reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Jon W. <hp...@mi...> - 2004-12-30 07:25:33
|
> I have a 2-pass shader which darkens the background in the first pass and > then the second pass renders the particles using additive blending. The > point is that alpha is used to tell transparency of the particle - not its > brightness. the higher the alpha is more the background is darkened in the > first pass, in the second pass the alpha is somewhat ignored as simple > additive blending is done. It can be that very dark particle has an alpha > channel with the high alpha values and vice-versa. I could use two separate > alpha channels though but that would mean extra work for artists and > increased memory requirements. First: Why is it two-pass? We use that effect in many particle effects; it's the pre-multiplied alpha blend mode: out_color = src_color + prev_color * (1 - src_alpha) Note that most cards can set blend mode for alpha separately from color, both in GL and D3D, so the blend equations would be: dst_color = src_color + dst_color * (1 - src_alpha) dst_alpha = dst_alpha This doesn't solve the question of alpha glow, though, but I just wondered why you didn't formulate the effect in this way in the first place. Second: if you're going two passes, couldn't you just add the colors together into alpha in the second pass, to get contribution to alpha at that point? Or is this running on hardware that can't route color to alpha? (dot-product texture blending should work great for this, btw) Something like: out_color = in_color out_alpha = dot3(in_color, const(0.3,0.3,0.3)) I believe even the lowly GeForce 256 could do this, although you might need to calculate color twice because of the way dot-product smears to all output channels. Just some suggestions, perhaps they'll work for your case. Cheers, / h+ |
From: Tom F. <tom...@ee...> - 2004-12-30 07:47:26
|
Premultiplied alpha is the shizzle. <rant> It means you can have a = particle that does "alpha blending" and "additive blending" with different = pixels. So for example you can have a particle that has an additive fire core and = an alpha sorround of darkening smoke. Premultiplied alpha was discovered to = be the Right Thing about three decades ago or something. It's still not the standard mode. </rant> Another thing you can do is dsable writes to the alpha channel when = doing blends like this. That means the particles won't glow, but maybe that's = far more acceptable than the particles glowing like crazy. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Jon Watte > Sent: 29 December 2004 23:26 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects >=20 >=20 >=20 > > I have a 2-pass shader which darkens the background in the=20 > first pass and > > then the second pass renders the particles using additive=20 > blending. The > > point is that alpha is used to tell transparency of the=20 > particle - not its > > brightness. the higher the alpha is more the background is=20 > darkened in the > > first pass, in the second pass the alpha is somewhat=20 > ignored as simple > > additive blending is done. It can be that very dark=20 > particle has an alpha > > channel with the high alpha values and vice-versa. I could use two > separate > > alpha channels though but that would mean extra work for artists and > > increased memory requirements. >=20 >=20 > First: Why is it two-pass? We use that effect in many=20 > particle effects; it's > the pre-multiplied alpha blend mode: >=20 > out_color =3D src_color + prev_color * (1 - src_alpha) >=20 > Note that most cards can set blend mode for alpha separately=20 > from color, > both > in GL and D3D, so the blend equations would be: >=20 > dst_color =3D src_color + dst_color * (1 - src_alpha) > dst_alpha =3D dst_alpha >=20 > This doesn't solve the question of alpha glow, though, but I=20 > just wondered > why > you didn't formulate the effect in this way in the first place. >=20 >=20 > Second: if you're going two passes, couldn't you just add the colors > together > into alpha in the second pass, to get contribution to alpha=20 > at that point? > Or is this running on hardware that can't route color to=20 > alpha? (dot-product > texture blending should work great for this, btw) >=20 > Something like: >=20 > out_color =3D in_color > out_alpha =3D dot3(in_color, const(0.3,0.3,0.3)) >=20 > I believe even the lowly GeForce 256 could do this, although=20 > you might need > to calculate color twice because of the way dot-product=20 > smears to all output > channels. >=20 >=20 > Just some suggestions, perhaps they'll work for your case. >=20 >=20 > Cheers, >=20 > / h+ |
From: Richard E C. <ri...@co...> - 2004-12-30 09:20:37
|
Maybe i'm being a bit dumb but how does premultiplied alpha do this? I thought all it was, was the colour channel mul'd by the alpha channel and so saving some time on low end GFX cards. instead of ( source RGB * A) + ( dest RGB * (1-A)) you do RGB + (dest RGB * (1-A)). is this simular to the alpha range the ps2 has, < 128 normal blend, 128 being solid and > 128 making it additive? Richard e Collins ----- Original Message ----- From: "Tom Forsyth" <tom...@ee...> To: <gda...@li...> Sent: Thursday, December 30, 2004 7:46 AM Subject: RE: [Algorithms] Glowing objects Premultiplied alpha is the shizzle. <rant> It means you can have a particle that does "alpha blending" and "additive blending" with different pixels. So for example you can have a particle that has an additive fire core and an alpha sorround of darkening smoke. Premultiplied alpha was discovered to be the Right Thing about three decades ago or something. It's still not the standard mode. </rant> Another thing you can do is dsable writes to the alpha channel when doing blends like this. That means the particles won't glow, but maybe that's far more acceptable than the particles glowing like crazy. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Jon Watte > Sent: 29 December 2004 23:26 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects > > > > > I have a 2-pass shader which darkens the background in the > first pass and > > then the second pass renders the particles using additive > blending. The > > point is that alpha is used to tell transparency of the > particle - not its > > brightness. the higher the alpha is more the background is > darkened in the > > first pass, in the second pass the alpha is somewhat > ignored as simple > > additive blending is done. It can be that very dark > particle has an alpha > > channel with the high alpha values and vice-versa. I could use two > separate > > alpha channels though but that would mean extra work for artists and > > increased memory requirements. > > > First: Why is it two-pass? We use that effect in many > particle effects; it's > the pre-multiplied alpha blend mode: > > out_color = src_color + prev_color * (1 - src_alpha) > > Note that most cards can set blend mode for alpha separately > from color, > both > in GL and D3D, so the blend equations would be: > > dst_color = src_color + dst_color * (1 - src_alpha) > dst_alpha = dst_alpha > > This doesn't solve the question of alpha glow, though, but I > just wondered > why > you didn't formulate the effect in this way in the first place. > > > Second: if you're going two passes, couldn't you just add the colors > together > into alpha in the second pass, to get contribution to alpha > at that point? > Or is this running on hardware that can't route color to > alpha? (dot-product > texture blending should work great for this, btw) > > Something like: > > out_color = in_color > out_alpha = dot3(in_color, const(0.3,0.3,0.3)) > > I believe even the lowly GeForce 256 could do this, although > you might need > to calculate color twice because of the way dot-product > smears to all output > channels. > > > Just some suggestions, perhaps they'll work for your case. > > > Cheers, > > / h+ ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Alen L. <ale...@cr...> - 2004-12-30 10:06:26
|
Yeah, premultiplied alpha is cool, but I always find it hard to convince artists to use it. Probably has something to do with the fact that it is not very straight-forward to author it in Photoshop. :) Do you know of any tools that help? ----- Original Message ----- From: "Tom Forsyth" <tom...@ee...> To: <gda...@li...> Sent: Thursday, December 30, 2004 07:46 Subject: RE: [Algorithms] Glowing objects Premultiplied alpha is the shizzle. <rant> It means you can have a particle that does "alpha blending" and "additive blending" with different pixels. So for example you can have a particle that has an additive fire core and an alpha sorround of darkening smoke. Premultiplied alpha was discovered to be the Right Thing about three decades ago or something. It's still not the standard mode. </rant> Another thing you can do is dsable writes to the alpha channel when doing blends like this. That means the particles won't glow, but maybe that's far more acceptable than the particles glowing like crazy. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Jon Watte > Sent: 29 December 2004 23:26 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects > > > > > I have a 2-pass shader which darkens the background in the > first pass and > > then the second pass renders the particles using additive > blending. The > > point is that alpha is used to tell transparency of the > particle - not its > > brightness. the higher the alpha is more the background is > darkened in the > > first pass, in the second pass the alpha is somewhat > ignored as simple > > additive blending is done. It can be that very dark > particle has an alpha > > channel with the high alpha values and vice-versa. I could use two > separate > > alpha channels though but that would mean extra work for artists and > > increased memory requirements. > > > First: Why is it two-pass? We use that effect in many > particle effects; it's > the pre-multiplied alpha blend mode: > > out_color = src_color + prev_color * (1 - src_alpha) > > Note that most cards can set blend mode for alpha separately > from color, > both > in GL and D3D, so the blend equations would be: > > dst_color = src_color + dst_color * (1 - src_alpha) > dst_alpha = dst_alpha > > This doesn't solve the question of alpha glow, though, but I > just wondered > why > you didn't formulate the effect in this way in the first place. > > > Second: if you're going two passes, couldn't you just add the colors > together > into alpha in the second pass, to get contribution to alpha > at that point? > Or is this running on hardware that can't route color to > alpha? (dot-product > texture blending should work great for this, btw) > > Something like: > > out_color = in_color > out_alpha = dot3(in_color, const(0.3,0.3,0.3)) > > I believe even the lowly GeForce 256 could do this, although > you might need > to calculate color twice because of the way dot-product > smears to all output > channels. > > > Just some suggestions, perhaps they'll work for your case. > > > Cheers, > > / h+ ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Tom F. <tom...@ee...> - 2004-12-30 11:42:28
|
You might be able to author it in two bits - one lerp-blending texture = and then one additive texture. Then just composite them into one texture at preprocess time. Artist sees texture T1 and T2. T1 is an alpha-blending texture, T2 is an additive one. First blend: FB.rgb =3D T1.a * T1.rgb + (1-T1.a) * FB.rgb Second blend: FB.rgb =3D FB.rgb + T2.rgb Result: FB.rgb =3D T1.a * T1.rgb + T2.rgb + (1-T1.a) * FB.rgb So at preprocess you premultiply T1's colour channel and add T2's colour channel to form a new premultiplied-alpha texture T3: T3.a =3D T1.a T3.rgb =3D T2.rgb + T1.a * T1.rgb Then at runtime do the premultiplied alpha blend: FB.rgb =3D T3.rgb + (1-T3.a) * FB.rgb (expanding out T3 into original T1 and T2): =3D T2.rgb + T1.a * T1.rgb + (1-T1.a) * FB.rgb ...which is what the artist saw with the two textures. (I've not actually tried this, it's just a way I thought of representing = the wierd concept) TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Alen Ladavac > Sent: 30 December 2004 03:07 > To: gda...@li... > Subject: Re: [Algorithms] Glowing objects >=20 >=20 > Yeah, premultiplied alpha is cool, but I always find it hard=20 > to convince > artists to use it. Probably has something to do with the fact=20 > that it is not > very straight-forward to author it in Photoshop. :) Do you=20 > know of any tools > that help? >=20 > ----- Original Message ----- > From: "Tom Forsyth" <tom...@ee...> > To: <gda...@li...> > Sent: Thursday, December 30, 2004 07:46 > Subject: RE: [Algorithms] Glowing objects >=20 >=20 > Premultiplied alpha is the shizzle. <rant> It means you can=20 > have a particle > that does "alpha blending" and "additive blending" with=20 > different pixels. So > for example you can have a particle that has an additive fire=20 > core and an > alpha sorround of darkening smoke. Premultiplied alpha was=20 > discovered to be > the Right Thing about three decades ago or something. It's=20 > still not the > standard mode. </rant> >=20 > Another thing you can do is dsable writes to the alpha=20 > channel when doing > blends like this. That means the particles won't glow, but=20 > maybe that's far > more acceptable than the particles glowing like crazy. >=20 > TomF. >=20 > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On > > Behalf Of Jon Watte > > Sent: 29 December 2004 23:26 > > To: gda...@li... > > Subject: RE: [Algorithms] Glowing objects > > > > > > > > > I have a 2-pass shader which darkens the background in the > > first pass and > > > then the second pass renders the particles using additive > > blending. The > > > point is that alpha is used to tell transparency of the > > particle - not its > > > brightness. the higher the alpha is more the background is > > darkened in the > > > first pass, in the second pass the alpha is somewhat > > ignored as simple > > > additive blending is done. It can be that very dark > > particle has an alpha > > > channel with the high alpha values and vice-versa. I could use two > > separate > > > alpha channels though but that would mean extra work for=20 > artists and > > > increased memory requirements. > > > > > > First: Why is it two-pass? We use that effect in many > > particle effects; it's > > the pre-multiplied alpha blend mode: > > > > out_color =3D src_color + prev_color * (1 - src_alpha) > > > > Note that most cards can set blend mode for alpha separately > > from color, > > both > > in GL and D3D, so the blend equations would be: > > > > dst_color =3D src_color + dst_color * (1 - src_alpha) > > dst_alpha =3D dst_alpha > > > > This doesn't solve the question of alpha glow, though, but I > > just wondered > > why > > you didn't formulate the effect in this way in the first place. > > > > > > Second: if you're going two passes, couldn't you just add the colors > > together > > into alpha in the second pass, to get contribution to alpha > > at that point? > > Or is this running on hardware that can't route color to > > alpha? (dot-product > > texture blending should work great for this, btw) > > > > Something like: > > > > out_color =3D in_color > > out_alpha =3D dot3(in_color, const(0.3,0.3,0.3)) > > > > I believe even the lowly GeForce 256 could do this, although > > you might need > > to calculate color twice because of the way dot-product > > smears to all output > > channels. > > > > > > Just some suggestions, perhaps they'll work for your case. > > > > > > Cheers, > > > > / h+ >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > 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: Alen L. <ale...@cr...> - 2004-12-30 12:19:02
|
Cool. I discarded such idea initially, because I thought that it wouldn't be able to represent the darkening effect that way. But darkening effect is in fact just blending with black. Seeing the math makes it clearer. Thanks. ----- Original Message ----- From: "Tom Forsyth" <tom...@ee...> To: <gda...@li...> Sent: Thursday, December 30, 2004 11:41 Subject: RE: [Algorithms] Glowing objects You might be able to author it in two bits - one lerp-blending texture and then one additive texture. Then just composite them into one texture at preprocess time. Artist sees texture T1 and T2. T1 is an alpha-blending texture, T2 is an additive one. First blend: FB.rgb = T1.a * T1.rgb + (1-T1.a) * FB.rgb Second blend: FB.rgb = FB.rgb + T2.rgb Result: FB.rgb = T1.a * T1.rgb + T2.rgb + (1-T1.a) * FB.rgb So at preprocess you premultiply T1's colour channel and add T2's colour channel to form a new premultiplied-alpha texture T3: T3.a = T1.a T3.rgb = T2.rgb + T1.a * T1.rgb Then at runtime do the premultiplied alpha blend: FB.rgb = T3.rgb + (1-T3.a) * FB.rgb (expanding out T3 into original T1 and T2): = T2.rgb + T1.a * T1.rgb + (1-T1.a) * FB.rgb ...which is what the artist saw with the two textures. (I've not actually tried this, it's just a way I thought of representing the wierd concept) TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Alen Ladavac > Sent: 30 December 2004 03:07 > To: gda...@li... > Subject: Re: [Algorithms] Glowing objects > > > Yeah, premultiplied alpha is cool, but I always find it hard > to convince > artists to use it. Probably has something to do with the fact > that it is not > very straight-forward to author it in Photoshop. :) Do you > know of any tools > that help? > > ----- Original Message ----- > From: "Tom Forsyth" <tom...@ee...> > To: <gda...@li...> > Sent: Thursday, December 30, 2004 07:46 > Subject: RE: [Algorithms] Glowing objects > > > Premultiplied alpha is the shizzle. <rant> It means you can > have a particle > that does "alpha blending" and "additive blending" with > different pixels. So > for example you can have a particle that has an additive fire > core and an > alpha sorround of darkening smoke. Premultiplied alpha was > discovered to be > the Right Thing about three decades ago or something. It's > still not the > standard mode. </rant> > > Another thing you can do is dsable writes to the alpha > channel when doing > blends like this. That means the particles won't glow, but > maybe that's far > more acceptable than the particles glowing like crazy. > > TomF. > > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On > > Behalf Of Jon Watte > > Sent: 29 December 2004 23:26 > > To: gda...@li... > > Subject: RE: [Algorithms] Glowing objects > > > > > > > > > I have a 2-pass shader which darkens the background in the > > first pass and > > > then the second pass renders the particles using additive > > blending. The > > > point is that alpha is used to tell transparency of the > > particle - not its > > > brightness. the higher the alpha is more the background is > > darkened in the > > > first pass, in the second pass the alpha is somewhat > > ignored as simple > > > additive blending is done. It can be that very dark > > particle has an alpha > > > channel with the high alpha values and vice-versa. I could use two > > separate > > > alpha channels though but that would mean extra work for > artists and > > > increased memory requirements. > > > > > > First: Why is it two-pass? We use that effect in many > > particle effects; it's > > the pre-multiplied alpha blend mode: > > > > out_color = src_color + prev_color * (1 - src_alpha) > > > > Note that most cards can set blend mode for alpha separately > > from color, > > both > > in GL and D3D, so the blend equations would be: > > > > dst_color = src_color + dst_color * (1 - src_alpha) > > dst_alpha = dst_alpha > > > > This doesn't solve the question of alpha glow, though, but I > > just wondered > > why > > you didn't formulate the effect in this way in the first place. > > > > > > Second: if you're going two passes, couldn't you just add the colors > > together > > into alpha in the second pass, to get contribution to alpha > > at that point? > > Or is this running on hardware that can't route color to > > alpha? (dot-product > > texture blending should work great for this, btw) > > > > Something like: > > > > out_color = in_color > > out_alpha = dot3(in_color, const(0.3,0.3,0.3)) > > > > I believe even the lowly GeForce 256 could do this, although > > you might need > > to calculate color twice because of the way dot-product > > smears to all output > > channels. > > > > > > Just some suggestions, perhaps they'll work for your case. > > > > > > Cheers, > > > > / h+ > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Jon W. <hp...@mi...> - 2004-12-31 00:59:47
|
> Yeah, premultiplied alpha is cool, but I always find it hard to convince > artists to use it. Probably has something to do with the fact that it is not > very straight-forward to author it in Photoshop. :) Do you know of any tools > that help? Try something like this: 1) set up an alpha channel 2) make the alpha channel all white 3) paint blackness into the alpha channel where you want the background to be blotted out 4) select all and invert the alpha channel 5) make RGB all black 6) paint colors into RGB where you want to brighten/color the particles Typically, you'll need to darken the background more than you think, and you need to add less RGB than you think, so painting the thing first, and then adjusting brightness of alpha up, and of RGB down, often helps. Cheers, / h+ |
From: Juhani H. <ju...@al...> - 2004-12-31 03:40:11
|
I am using both, a 1-pass standard premultiplied alpha shader and the 2-pass shader I earlier described. The problem with the glow is more urgent with the 2-pass as it usually results in brighter (and usually better looking) particle clouds compared to the single pass approach. I rather not disable alpha writes as it works against having the glow in the first place and bright particles with the glow give some really nice effects I don't want to miss. (trees in the front of some fire comes to mind.) -juhani -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: Thursday, December 30, 2004 4:46 PM To: gda...@li... Subject: RE: [Algorithms] Glowing objects Premultiplied alpha is the shizzle. <rant> It means you can have a particle that does "alpha blending" and "additive blending" with different pixels. So for example you can have a particle that has an additive fire core and an alpha sorround of darkening smoke. Premultiplied alpha was discovered to be the Right Thing about three decades ago or something. It's still not the standard mode. </rant> Another thing you can do is dsable writes to the alpha channel when doing blends like this. That means the particles won't glow, but maybe that's far more acceptable than the particles glowing like crazy. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of > Jon Watte > Sent: 29 December 2004 23:26 > To: gda...@li... > Subject: RE: [Algorithms] Glowing objects > > > > > I have a 2-pass shader which darkens the background in the > first pass and > > then the second pass renders the particles using additive > blending. The > > point is that alpha is used to tell transparency of the > particle - not its > > brightness. the higher the alpha is more the background is > darkened in the > > first pass, in the second pass the alpha is somewhat > ignored as simple > > additive blending is done. It can be that very dark > particle has an alpha > > channel with the high alpha values and vice-versa. I could use two > separate > > alpha channels though but that would mean extra work for artists and > > increased memory requirements. > > > First: Why is it two-pass? We use that effect in many particle > effects; it's the pre-multiplied alpha blend mode: > > out_color = src_color + prev_color * (1 - src_alpha) > > Note that most cards can set blend mode for alpha separately from > color, both in GL and D3D, so the blend equations would be: > > dst_color = src_color + dst_color * (1 - src_alpha) dst_alpha = > dst_alpha > > This doesn't solve the question of alpha glow, though, but I just > wondered why you didn't formulate the effect in this way in the first > place. > > > Second: if you're going two passes, couldn't you just add the colors > together into alpha in the second pass, to get contribution to alpha > at that point? > Or is this running on hardware that can't route color to alpha? > (dot-product texture blending should work great for this, btw) > > Something like: > > out_color = in_color > out_alpha = dot3(in_color, const(0.3,0.3,0.3)) > > I believe even the lowly GeForce 256 could do this, although you might > need to calculate color twice because of the way dot-product smears to > all output channels. > > > Just some suggestions, perhaps they'll work for your case. > > > Cheers, > > / h+ ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: igrok <ig...@bl...> - 2005-01-01 13:38:13
|
Using shadow volumes, to cull a volume coming from a directional light, I'm using a cylinder, which works pretty well as its easy to construct from the data and easy to frustum test against. However, I'm not sure what the best type of bounding volume is when the shadow volume is coming from a point light. I have a quick AABB test currently, but want something more accurate. I've read it mentioned that capped cones or maybe capped pyramids are good for this but I can see two problems. Firstly, if the point light source is inside the occluding object, then I can't see how a cone can be generated any more. In that particular case, I suppose a sphere or box is a better bounding volume. Not sure how to detect this accurately though. I guess maybe a basic 'is light within objects bound sphere' would generate poor results quite often. Secondly, I'm not sure of doing a capped-cone vs frustum test (googling hasn't really helped so far) and I'm equally unsure of the maths required to create the cone in the first place. Does anyone have any pointers on this? Thanks (And happy new year!) :) |
From: Tom F. <tom...@ee...> - 2005-01-01 19:45:28
|
I use cones a lot for shadowbuffers. They're pretty easy to use, but likewise I had to invent all the maths routines myself - don't seem to = be any existing docs on it (maybe I'm just not googling for the right = things). The way I represent a cone is by a unit-length vector and a scalar that = is the cosine of half the angle at the base of the cone. I thought of multiplying the two together, but the maths isn't quite as clean for = some things. There's not much in it. And your cone may store the position of = the cone vertex in it as well - I had multiple cones coming from one point = (the light), so this was implied a lot of the time. Finding if a point is inside the cone is easy of course. Find the vector from the cone vertex to the point, normalise, find the dot-product with = the cone vecto, and compare against the cos(halfangle) (obviously the = normalise factors out in most cases) And the other really useful thing is to be able to create a cone that = bounds a sphere, defined by a position relative to the base of the cone (the = light) and a radius: ViewCone ConeMake ( const M31 &vCentre, float fRadius ) { ViewCone res; float fOneOverLengthSq =3D 1.0f / vCentre.LengthSquared(); float fOneOverLength =3D sqrtf ( fOneOverLengthSq ); res.vAxis =3D vCentre * fOneOverLength; if ( 1.0f <=3D ( fRadius * fOneOverLength ) ) { // Point is inside the sphere. res.fCosAngle =3D -1.0f; return res; } // AdjacentLength =3D sqrt ( fLength * fLength - fRadius * fRadius ) // CosAngle =3D AdjacentLength / fLength // =3D sqrt ( fLength * fLength - fRadius * fRadius ) / fLength // =3D sqrt ( 1.0f - ( fRadius * fRadius ) / ( fLength * fLength ) ) res.fCosAngle =3D sqrtf ( 1.0f - ( fRadius * fRadius ) * fOneOverLengthSq ); ASSERT ( fabsf ( res.fCosAngle - cosf ( asinf ( fRadius * fOneOverLength ) ) ) < 0.00001f ); return res; } My cones weren't capped, but that should be pretty easy to add. Whether cones realy are the most elegant bounding volume, I'm not sure. = They are only circular, so maybe a sort of rectangle-based pyramid might work better in some cases (for the same reason that AABBs can be better than spheres). I just started with cones, and they seem to work pretty well = for my purposes. > Firstly, if the point light source is inside the occluding object, > then I can't see how a cone can be generated any more. In that > particular > case, I suppose a sphere or box is a better bounding volume. Not sure > how to detect this accurately though. I guess maybe a basic 'is light > within objects bound sphere' would generate poor results quite often. I think you just have to check how close the light is to the object's bounding sphere and switch. Note that you will want to do this before = the light actually hits the bounding sphere - as the light approaches the bounding sphere, the cone's base angle becomes enormous, which probably makes it pretty useless as a bounding object. Probably want to switch at bounding radius * 2 or something. I didn't do a cone vs frustum test (it's not something you need to do = for shadowbuffering), but you could either make a cone from the frustum and = then do a cone vs cone check (I don't have one of those - sorry), or you = could intersect the cone with the four (five?) frustum planes - each = intersection gives you a conic section (circle, ellipse, parabola, etc), and you can probably work out the bounds of that and see if it lies within the = frustum. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of igrok > Sent: 01 January 2005 05:38 > To: gda...@li... > Subject: [Algorithms] Bounding volumes for shadows >=20 >=20 > Using shadow volumes, to cull a volume coming from a directional > light, I'm using a cylinder, which works pretty well as its easy > to construct from the data and easy to frustum test against. >=20 > However, I'm not sure what the best type of bounding volume is > when the shadow volume is coming from a point light. I have a quick > AABB test currently, but want something more accurate. > I've read it mentioned that capped cones or maybe capped pyramids > are good for this but I can see two problems. >=20 > Firstly, if the point light source is inside the occluding object, > then I can't see how a cone can be generated any more. In that > particular > case, I suppose a sphere or box is a better bounding volume. Not sure > how to detect this accurately though. I guess maybe a basic 'is light > within objects bound sphere' would generate poor results quite often. >=20 > Secondly, I'm not sure of doing a capped-cone vs frustum test=20 > (googling > hasn't really helped so far) and I'm equally unsure of the maths > required to create the cone in the first place. Does anyone have any > pointers on this? >=20 > Thanks > (And happy new year!) :) >=20 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > 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: Pete W. <gda...@pe...> - 2005-01-07 23:36:31
|
On 29 Dec 2004, at 23:46, Tom Forsyth wrote: > Premultiplied alpha is the shizzle. <rant> It means you can have a > particle > that does "alpha blending" and "additive blending" with different > pixels. So > for example you can have a particle that has an additive fire core and > an > alpha sorround of darkening smoke. Premultiplied alpha was discovered > to be > the Right Thing about three decades ago or something. It's still not > the > standard mode. </rant> A bit late to jump in on this one, but I'm now a firm believer in The One True Alpha Format for other reasons. I (re)discovered bilinear filtering doesn't do the right thing with straight alpha when dealing with pixels that border on zero-alpha pixels. The rgb values from zero alpha pixels get blended in with their non-transparent neighbors. This is not a big deal when you're dealing with artist-created textures; they just need to fix up the rgb values in those zero alpha pixels to something sensible. It gets very nasty when you're dealing with a pipeline of render-textures though. When you draw a poly into a render buffer, how do you make sure that those zero-alpha pixels adjacent to the poly have something sensible in them? For most game rendering purposes you can get away with the slight fringing, but in our case it wasn't acceptable, so we had to switch our pipeline to premult from straight at a late stage. Not fun. I recently saw a GDMag article on this, (which of course referenced Jim Blinn discussing this many years ago :) ) and I have put up a note with some diagrams on my site. http://petewarden.com/notes (Look for 'Straight Alpha and Bilinear Filtering', near the bottom) Pete |
From: Juhani H. <ju...@al...> - 2004-12-30 08:23:20
|
Hi Jon, The reason I am using two passes is that I want background to be darkened but I don't want a single particle to darken other particles. that way I can get nice blending between particles and at the same time so that background doesn't affect the effect much. Using the dot product to solve the brightness problem is a great idea though ~ I don't know why I didn't think of this myself earlier :) .....feel kind of stupid now hehe.. thanks, -juhani -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Jon Watte Sent: Thursday, December 30, 2004 4:26 PM To: gda...@li... Subject: RE: [Algorithms] Glowing objects > I have a 2-pass shader which darkens the background in the first pass > and then the second pass renders the particles using additive > blending. The point is that alpha is used to tell transparency of the > particle - not its brightness. the higher the alpha is more the > background is darkened in the first pass, in the second pass the alpha > is somewhat ignored as simple additive blending is done. It can be > that very dark particle has an alpha channel with the high alpha > values and vice-versa. I could use two separate > alpha channels though but that would mean extra work for artists and > increased memory requirements. First: Why is it two-pass? We use that effect in many particle effects; it's the pre-multiplied alpha blend mode: out_color = src_color + prev_color * (1 - src_alpha) Note that most cards can set blend mode for alpha separately from color, both in GL and D3D, so the blend equations would be: dst_color = src_color + dst_color * (1 - src_alpha) dst_alpha = dst_alpha This doesn't solve the question of alpha glow, though, but I just wondered why you didn't formulate the effect in this way in the first place. Second: if you're going two passes, couldn't you just add the colors together into alpha in the second pass, to get contribution to alpha at that point? Or is this running on hardware that can't route color to alpha? (dot-product texture blending should work great for this, btw) Something like: out_color = in_color out_alpha = dot3(in_color, const(0.3,0.3,0.3)) I believe even the lowly GeForce 256 could do this, although you might need to calculate color twice because of the way dot-product smears to all output channels. Just some suggestions, perhaps they'll work for your case. Cheers, / h+ ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |