Thread: RE: [Algorithms] Doom lightmaps
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Mark W. <mwa...@to...> - 2001-02-26 04:44:32
|
Perhaps simple stuff like rendering to a texture then projecting that? Mark -----Original Message----- From: Jason Zisk [mailto:zi...@op...] Sent: Monday, 26 February 2001 10:47 AM To: gda...@li... Subject: Re: [Algorithms] Doom lightmaps I don't see how you can draw a texture for objects/lights that are moving like in those movies? As soon as the light moves the texture would become invalid (I'm assuming there is a texture per light thats mapped onto the geometry). - Jason Zisk - nFusion Interactive LLC ----- Original Message ----- From: "Corrinne Yu" <cor...@ho...> To: <gda...@li...> Sent: Sunday, February 25, 2001 4:47 PM Subject: Re: [Algorithms] Doom lightmaps > -- Those are projective textures. How would I know? I know the man who made > the textures. And it is an artist, not a programmer. :) > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Alex C. <al...@ar...> - 2001-02-26 09:28:28
|
We don't use shadow maps (== nasty horrible artefacts). Adding full on volumetric shadows to an engine is not a light weight thing to do. Depending on the method used, they tend to: * Burn fill rate * Stencil methods in particular have very variable fill rate cost * Require skinning to be done CPU side (so you can calculate the silhouette) * Require fancy silhouette extraction algorithms (brute force extraction = expensive) * Require extremely accurate raycasts (to determine if the camera is shadow) * Require a very near clipping plane (so you _have_ to use a z-buffer) * Mess up loads of lighting optimisations (coalescing multiple lights into an average light doesn't work well due to the shadows affecting the blending) * They only really work for dynamic lights and typically you can only have a few on screen before your frame rate suffers very badly. * Force the artists to cap objects * Make it essential for all meshes to be manifold * May make lit semi-transparent materials a total nightmare * Require the artists to be very careful when modelling to avoid unfortunate self shadowing. * Require that the artists and designers don't try to use too many polys. You can forget about having 100k triangle / frame scenes with full on volumetric shadows However, They are quite pretty. Alex Clarke, Programmer Argonaut Games PLC > > It is funny you mention the stencil+shadow map method > because that is > > exactly how I do dynamic shadows in my engine. For any > object that might > > I think that's also what they do in Malice (just my guesses > of course). > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |
|
From: Akbar A. <sye...@ea...> - 2001-03-12 09:04:55
|
>* They only really work for dynamic lights and typically you can only >have a few on screen before your frame rate suffers very badly. yeah, this does suck. just one of the trade offs we have to take. but these techniques are pretty suited for dark/scary games IMHO "right now".., primarily due to the fact that the cpu/gpu's aren't ready to say, "light up a scene like q3dm12 without the frame rate dying." >We don't use shadow maps (== nasty horrible artifacts). well there not really _that_ "nasty", esp after you take a look at that terminal reality engine movie demo thingy.. in fact it' looked pretty cool.. >start with a GeForce 3 and burn fill-rate to implement a stencil >buffer shadowing algorithm. it can be a geforce 1/2 as well... personally i don't plan on using _any_ of the geforce3's features that aren't in hardware on the geforce 1X series. and iirc, nv_vertex_program is implemented in hardware in release 10 drivers and beyond.? Personally, 550 US $ for a graphics chip is a quite a bit for an average consumer, and i think the "buying computer frenzy" is pretty much over. i think people are happy with there 'new' computers and video cards (geforce2's and 1's) that came on there machines, and there satisfied with the performance there getting on there apps (AIM, ICQ, word, ie, media player ) .... >he smooth shadows look like projected textures and you could easily do an effect like a rotating >fan using an animated projective texture or even better using the texture remember, pretty much everything is 'uniformed'.. calculating silhouettes could possibly be where a perf hit is at? i haven't done this on any thing high mesh related data sets where i'd see a hit... jason zisk wrote: >move or is extremely small(soda cans, etc) I use a stencil shadow and for >everything else I use pre-computed lightmaps. neat, from the pictures i saw this looks like it 'suits your game' pretty well ;) a lot of people do want totally dynamic worlds. like maybe running with a shadow so your always dark, sounds like a cool idea to me. "Sounds like a mission for James Bond", well maybe not. Bond would come in with all sorts glory/lights/girls/action/guns and fancy electronic gadgets, no need for him to be sneaking around :-) you can't use a lightmap used for global illumination to do this kinda of thing.. and shadow maps really do need a lot of extra work for say a point light. i think for level and game designers, it will take some adjusting till they get in the mind set that each light (visible to viewer) has a cost factor attached to it .. very bored, starving and tired of seeing *"George Geczy" #!!@#%@% -akbar A. *has to do with the dx mailing list getting spammed horribly. can't unsubsribe either :( KILL the list @#%@% ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "plastic or metallic. please pick your version of lighting ;) " .me -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Alex Clarke Sent: Monday, February 26, 2001 3:32 AM To: 'gda...@li...' Subject: RE: [Algorithms] Doom lightmaps We don't use shadow maps (== nasty horrible artefacts). Adding full on volumetric shadows to an engine is not a light weight thing to do. Depending on the method used, they tend to: * Burn fill rate * Stencil methods in particular have very variable fill rate cost * Require skinning to be done CPU side (so you can calculate the silhouette) * Require fancy silhouette extraction algorithms (brute force extraction = expensive) * Require extremely accurate raycasts (to determine if the camera is shadow) * Require a very near clipping plane (so you _have_ to use a z-buffer) * Mess up loads of lighting optimisations (coalescing multiple lights into an average light doesn't work well due to the shadows affecting the blending) * They only really work for dynamic lights and typically you can only have a few on screen before your frame rate suffers very badly. * Force the artists to cap objects * Make it essential for all meshes to be manifold * May make lit semi-transparent materials a total nightmare * Require the artists to be very careful when modelling to avoid unfortunate self shadowing. * Require that the artists and designers don't try to use too many polys. You can forget about having 100k triangle / frame scenes with full on volumetric shadows However, They are quite pretty. Alex Clarke, Programmer Argonaut Games PLC > > It is funny you mention the stencil+shadow map method > because that is > > exactly how I do dynamic shadows in my engine. For any > object that might > > I think that's also what they do in Malice (just my guesses > of course). > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Brian H. <bw...@wk...> - 2001-02-26 09:48:29
|
At 09:32 AM 2/26/01 +0000, you wrote: >* Burn fill rate Yes. >* Stencil methods in particular have very variable fill rate cost Definitely. >* Require skinning to be done CPU side (so you can calculate the silhouette) Yep. >* Require fancy silhouette extraction algorithms (brute force extraction = >expensive) I wouldn't say something _fancy_ is required, but this is definitely a costly operation. >* They only really work for dynamic lights and typically you can only >have a few on screen before your frame rate suffers very badly. Eh? You can do static lights quite well too, e.g. shadow volume BSPs. >* Force the artists to cap objects I have not found this to be the case. >* Make it essential for all meshes to be manifold Nor this. >* May make lit semi-transparent materials a total nightmare Can be approximated with projected lights. >* Require the artists to be very careful when modelling to avoid >unfortunate self shadowing. ? >* Require that the artists and designers don't try to use too many >polys. You can forget about having 100k triangle / frame scenes with >full on volumetric shadows At this point I strongly believe that high polygon counts can be safely eschewed for better and more accurate lighting. We're at the point of significantly diminished returns for cranking up polygon counts (especially with bump mapping available now), so exchanging triangle density for more complex lighting is definitely worth while. Brian |
|
From: Akbar A. <sye...@ea...> - 2001-02-26 11:14:25
|
>At this point I strongly believe that high polygon counts can be safely >eschewed for better and more accurate lighting. exactly. i'm all for richer pixels. increased polycount is good and all, but i see visual quality as being more important for my work. on a side note, i can't wait till some stable vertex_program drivers come out!!@% -akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "plastic or metallic. please pick your version of lighting ;) " .me -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Brian Hook Sent: Monday, February 26, 2001 3:48 AM To: gda...@li... Subject: RE: [Algorithms] Doom lightmaps At 09:32 AM 2/26/01 +0000, you wrote: >* Burn fill rate Yes. >* Stencil methods in particular have very variable fill rate cost Definitely. >* Require skinning to be done CPU side (so you can calculate the silhouette) Yep. >* Require fancy silhouette extraction algorithms (brute force extraction = >expensive) I wouldn't say something _fancy_ is required, but this is definitely a costly operation. >* They only really work for dynamic lights and typically you can only >have a few on screen before your frame rate suffers very badly. Eh? You can do static lights quite well too, e.g. shadow volume BSPs. >* Force the artists to cap objects I have not found this to be the case. >* Make it essential for all meshes to be manifold Nor this. >* May make lit semi-transparent materials a total nightmare Can be approximated with projected lights. >* Require the artists to be very careful when modelling to avoid >unfortunate self shadowing. ? >* Require that the artists and designers don't try to use too many >polys. You can forget about having 100k triangle / frame scenes with >full on volumetric shadows At this point I strongly believe that high polygon counts can be safely eschewed for better and more accurate lighting. We're at the point of significantly diminished returns for cranking up polygon counts (especially with bump mapping available now), so exchanging triangle density for more complex lighting is definitely worth while. Brian _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Alex C. <al...@ar...> - 2001-02-26 10:23:41
|
> >* They only really work for dynamic lights and typically you can only > >have a few on screen before your frame rate suffers very badly. > > Eh? You can do static lights quite well too, e.g. shadow volume BSPs. Not really what I meant. I was thinking of shadows and pre-calculated light maps. It would be quite challenging to get dynamic shadows from static lighting since apart from anything the static lighting could be for hundreds of lights, or even worse a radiosity solution. > >* Force the artists to cap objects > > I have not found this to be the case. > > >* Make it essential for all meshes to be manifold > > Nor this. Err, you must have the worlds most robust silhouette extractor! I've never come across one that deals gracefully with non-manifold meshes. We can flag polys with open edges not to cast shadows, which helps avoid a lot of capping for world geometry, however if we have an edge shared by 3 triangles then we are hosed. We provide the artists with tools to find bad geometry, and they are quite proficient at correcting them. I would point out that for animated objects, capping is essential, otherwise you run the risk of ugly shadow artefacts. > >* May make lit semi-transparent materials a total nightmare > > Can be approximated with projected lights. Ok a stained glass window could be approximated this way, however this does not even come close to solving the problems with semi-transparent objects. Stencil methods only calculate if the front most surface is on shadow or not. This means that they can't light semi-transparent objects in the general case (you have to use shadow maps). I suppose we could use render to texture and projective methods to deal with dynamic objects, but I prefer the look of things to be internally consistent (artefacts for projective methods are different to stencil methods). > >* Require the artists to be very careful when modelling to avoid > >unfortunate self shadowing. Some of the character meshes our artists modelled had the creases in clothes modelled. Without the shadows it looked great. With the shadows it was ugly. The reason being that stencil shadows are either on or off, you would get ugly dark areas from the ridges in the clothing, often with a dotted line of bright pixels (due to z-buffer inaccuracies). The artist had to remodel to get rid of the ridges in the clothing (they went into the bumpmap instead). > At this point I strongly believe that high polygon counts can > be safely > eschewed for better and more accurate lighting. We're at the > point of > significantly diminished returns for cranking up polygon > counts (especially > with bump mapping available now), so exchanging triangle > density for more > complex lighting is definitely worth while. I tend to agree, however due to marketing nonsense, artists and designers often initially believe that they have a much higher poly budget than they really do. Alex Clarke, Programmer Argonaut Games PLC |
|
From: Pierre T. <p.t...@wa...> - 2001-02-26 10:35:04
|
> Err, you must have the worlds most robust silhouette extractor! > I've never come across one that deals gracefully with non-manifold > meshes. I think I don't see the problem either..... (?) P. |
|
From: Alex C. <al...@ar...> - 2001-02-26 10:48:43
|
Show me an algorithm that correctly extracts shilouettes from non manifold meshes. All tbe ones I tried don't work for non manifold meshes. Alex Clarke, Programmer Argonaut Games PLC > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 26 February 2001 10:31 > To: gda...@li... > Subject: Re: [Algorithms] Doom lightmaps > > > > Err, you must have the worlds most robust silhouette extractor! > > I've never come across one that deals gracefully with non-manifold > > meshes. > > I think I don't see the problem either..... (?) > > P. > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |
|
From: Alex C. <al...@ar...> - 2001-02-26 11:02:51
|
Ok, lets say we have an edge which is attached to three triangles. How do you classify this as being a silhouette edge or not? Alex Clarke, Programmer Argonaut Games PLC > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 26 February 2001 10:31 > To: gda...@li... > Subject: Re: [Algorithms] Doom lightmaps > > > > Err, you must have the worlds most robust silhouette extractor! > > I've never come across one that deals gracefully with non-manifold > > meshes. > > I think I don't see the problem either..... (?) > > P. > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |
|
From: Pierre T. <p.t...@wa...> - 2001-02-26 11:36:46
|
Ah, I see what you mean. But the issue there is not robustness, the problem is just that you can't really classify non-manifold edges in this case. Depending on what you further do with your silhouettes, you can adopt different strategies and come up with correct results anyway. For example, I have some code to fix non-manifold meshes by replicating the bad edges. You could just do that on-the-fly, i.e. test your example edge two times, with two sets of triangles. Or extend the silhouette rules to N faces. Or just mark all non-manifold edges as silhouette edges.Or discard them all. One way or another, your artist will probably fix them by replicating two vertices anyway. No? Pierre ----- Original Message ----- From: Alex Clarke <al...@ar...> To: <gda...@li...> Sent: Monday, February 26, 2001 12:06 PM Subject: RE: [Algorithms] Doom lightmaps > Ok, lets say we have an edge which is attached to three triangles. > How do you classify this as being a silhouette edge or not? > > Alex Clarke, Programmer > Argonaut Games PLC > > > -----Original Message----- > > From: Pierre Terdiman [mailto:p.t...@wa...] > > Sent: 26 February 2001 10:31 > > To: gda...@li... > > Subject: Re: [Algorithms] Doom lightmaps > > > > > > > Err, you must have the worlds most robust silhouette extractor! > > > I've never come across one that deals gracefully with non-manifold > > > meshes. > > > > I think I don't see the problem either..... (?) > > > > P. > > > > > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Eric H. <er...@ac...> - 2001-03-14 15:01:13
|
Alex wrote a great summary of shadow volume headaches (some I hadn't heard before): >We don't use shadow maps (== nasty horrible artefacts). Which ones? Biasing headaches (objects self-shadow, or float, depending on the bias), or shadow edges looking jaggy, or is there some third headache I don't know about yet? >Adding full on volumetric shadows to an engine is not a >light weight thing to do. > >Depending on the method used, they tend to: > >* Burn fill rate >* Stencil methods in particular have very variable fill rate cost >* Require skinning to be done CPU side (so you can calculate the silhouette) >* Require fancy silhouette extraction algorithms (brute force extraction = >expensive) >* Require extremely accurate raycasts (to determine if the camera is shadow) This is not necessary if you draw the shadow volume polygons only where their Z depth is beyond the surface (vs. in front of the surface, as is normally done). A guy named Bilodeau from Creative Labs explained this technique at GDC 1999 (and I didn't learn of it until a few months ago, from the BioWare team, who are using it in Neverwinter Nights). Basic idea is to cap the shadow volumes against (or at least somewhere near) the eye's far plane, and render to the stencil buffer only when the shadow volumes are beyond the stored z-buffer depth values. We'll be talking about it in our GDC talk on real-time shadows, and it'll be in the GDC proceedings. Has its own problems, but all the headaches of "eye inside the shadow volumes" problems go away! So far it's the cleverest graphical thing I've learnt this year. The Bioware guys also have some clever tricks for culling out content and for using a vertex shader program to generate shadow volumes (at the loss of no character self-shadowing, though). >* Require a very near clipping plane (so you _have_ to use a z-buffer) >* Mess up loads of lighting optimisations (coalescing multiple lights into >an average light doesn't work well due to the shadows affecting the >blending) >* They only really work for dynamic lights and typically you can only >have a few on screen before your frame rate suffers very badly. >* Force the artists to cap objects Not sure what you mean here... >* Make it essential for all meshes to be manifold >* May make lit semi-transparent materials a total nightmare >* Require the artists to be very careful when modelling to avoid >unfortunate self shadowing. What's this? >* Require that the artists and designers don't try to use too many >polys. You can forget about having 100k triangle / frame scenes with >full on volumetric shadows > >However, > >They are quite pretty. > >Alex Clarke, Programmer >Argonaut Games PLC Eric |
|
From: Alex C. <al...@ar...> - 2001-03-14 16:08:15
|
> Alex wrote a great summary of shadow volume headaches (some I > hadn't heard > before): > >We don't use shadow maps (== nasty horrible artefacts). > > Which ones? Biasing, jaggy/blocky edges when the camera is at a bad angle wrt the surface shadows are being projected on. No mip-mapping so that when the shadows should be mapmapped you get the usual unpleasant sampling artefacts. The nasty little problem when the shadows get cropped by the dimensions of the shadow map. Ok all of these probably have work rounds or can be lived with. However I personally _hate_ shadowmaps. I hate the limitations of stencils even more, but when stencil work, but in general I've found that they give far more consistently correct visual results than any of the texture methods, naturally YMMV. > >* Require extremely accurate raycasts (to determine if the > camera is shadow) > > This is not necessary if you draw the shadow volume polygons > only where > their Z depth is beyond the surface (vs. in front of the > surface, as is > normally done). Oooh Very interesting! Getting rid of the all the stencil shadow / camera problems would be great since: 1) We can have a sensible near clip plane! 2) We can throw out the extra raycasts. My guess is that Carmack must be doing this, otherwise stencil based shadows are totally inappropriate for a fps... (who wants the ugly camera related artefacts when you step into a shadowy recess?) > A guy named Bilodeau from Creative Labs > explained this > technique at GDC 1999 (and I didn't learn of it until a few > months ago, > from the BioWare team, who are using it in Neverwinter > Nights). Basic idea > is to cap the shadow volumes against (or at least somewhere > near) the eye's How do you go about capping the volumes? Do you just project the back face triangles from the mesh that is casting shadows? Won't this cause problems where the mapping causes triangles to double up on each other? > far plane, and render to the stencil buffer only when the > shadow volumes > are beyond the stored z-buffer depth values. > > We'll be talking about it in our GDC talk on real-time > shadows, and it'll > be in the GDC proceedings. Has its own problems, but all the > headaches of > "eye inside the shadow volumes" problems go away! So far it's > the cleverest > graphical thing I've learnt this year. The Bioware guys also > have some > clever tricks for culling out content and for using a vertex > shader program > to generate shadow volumes (at the loss of no character > self-shadowing, > though). We attempted this with vanilla stencil shadows and it seemed to burn T&L time, if this could be made to work with acceptable performance than that would be absolutely fabulous, since apart from anything I can save a large chunk of memory for every instance of an object. Alex Clarke, Programmer Argonaut Games PLC |
|
From: Alex C. <al...@ar...> - 2001-03-15 19:37:34
|
> This is not necessary if you draw the shadow volume polygons > only where > their Z depth is beyond the surface (vs. in front of the > surface, as is > normally done). A guy named Bilodeau from Creative Labs > explained this > technique at GDC 1999 (and I didn't learn of it until a few > months ago, > from the BioWare team, who are using it in Neverwinter > Nights). Basic idea > is to cap the shadow volumes against (or at least somewhere > near) the eye's > far plane, and render to the stencil buffer only when the > shadow volumes > are beyond the stored z-buffer depth values.> I had a try at implementing this. It certainly did seem to solve the camera intersection issues very nicely. However, self shadowing didn't seem to be working which is a little odd. (This has got to be a bug in my implementation) Also the capping scares me a tad. My utterly naieve attempt involved a pretty far clip plane, and ensureing the shadow volumes aren't projected that far and just rendering the entire mesh with back face culling on, incrementing the stencil value. Amazingly this seems to work so far. The "correct" approach would seem to be cull light facing tris, then project the mesh and treat the triangles like te rest of the shadow volume. I'm not yet sure how to do this fast in a veretx shader... Anyone else tried this varient of stencil shadows? Alex Clarke, Programmer Argonaut Games PLC |
|
From: Doug C. <dc...@d-...> - 2001-02-26 05:36:11
|
> Perhaps simple stuff like rendering to a texture then projecting that? > > Mark That would conflict with what Corrinne was saying - that artists created the shadow maps. Whatever it is - it looks awsome for realtime. It would be nice to know what JC is doing, at least from a high level perspective. Dosent he give speaches on his game engines in those Quake competitions sometimes? Mabye we should all start busting our asses getting l33t quake skills so we can attend LOL! Doug Chism |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X