Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(31) 
2
(24) 
3
(32) 
4
(20) 
5
(5) 
6
(3) 
7
(8) 
8
(13) 
9
(23) 
10
(9) 
11
(68) 
12
(23) 
13
(3) 
14
(1) 
15
(13) 
16
(19) 
17
(8) 
18

19
(12) 
20
(12) 
21

22
(11) 
23
(12) 
24
(8) 
25
(22) 
26
(10) 
27
(8) 
28
(4) 
29
(16) 
30
(12) 
31
(11) 



From: Jon Watte <hplus@mi...>  20020704 17:19:36

> Thinking about removing convex/concave(?) edges that seemingly will never > cast shadows doesn't this breakdown with nonclosed geometry? (Although > you can always close it). Nonclosed geometry doesn't work for shadow volumes in general. "concave" edges may still be part of a silhouette outline in the case of overlap as seen from the light, assuming you build possibly multiple groups of connected edges (as would be appropriate for stencil shadows) Imagine this intersection of geometry seen from the "top" \ B \/\ <==== light A \ The edge at "A" is "concave" but will need to be part of a silhouette outline; "B" will be part of a different silhouette outline. Cheers, / h+ 
From: Adam Moravanszky <amoravanszky@dp...>  20020704 16:37:21

Emmanuel wrote: > Is it mandatory to double every edge ? You only really have to double 'hard' edges  those which are between two faces with a larger than epsilon relative angle (same deal as with vertex normals for smooth shading). You can set epsilon as you want, but if you don't split any edges, the results do look really screwed up.   Adam Moravanszky  http://www.novodex.com 
From: Charles Bloom <cbloom@cb...>  20020704 15:34:42

This "BSP" is a formulation of all the "visibility events" in 3d space. There are a bunch of old siggraph papers on this. People created "visibility trees" for fast global illumination and other such things. I think it's quite memoryuse intensive; it grows faster than O(N) in the number of polygons, because you have these extra "edgevert" and "edgeedgeedge" events. At 02:08 PM 7/4/2002 +0100, Tom Forsyth wrote: >Agreed  it's not a simple BSP, as done for sorting purposes. If anything, >it's not a traditional BSP at all (which only splits existing leaves). In >this, each face/plane potentially splits every leaf it intersects. Then you >remerge leaves when you find that in fact both sides have the same >silhouette value.  Charles Bloom cb@... http://www.cbloom.com 
From: Gareth Lewin <GLewin@cl...>  20020704 15:25:47

You are hitting a fairly well researched issue, and the normal solution for a real robust solution are GUIDs. Another thing to try is to take the CDKey as a base for your ids. Original Message From: Leigh McRae [mailto:leigh.mcrae@...] Sent: 04 July 2002 15:07 To: gdalgorithmslist@... Subject: [Algorithms] User content Hi all, How are people handling the integration of content after a product ships? Currently I use a database that manages unique ID's for me. So if someone adds some new models or textures I need an ID fr them. I was thinking of running a crc32 on the data of the resource and use it for the ID. Has anyone tried this? Leigh McRae 
From: Davies Sean <SDavies@uk...>  20020704 15:16:30

Fair enough  I can sort of see this now  the silhuoette clipping paper by Hoppe et al has an interesting preprocess step for the silhouette determination too  they build a tree of polygon groups, and cull whole groups based on a conservative back/front facing test. Their performance stats seem pretty good. http://people.deas.harvard.edu/~pvs/research/silclip/silclip.pdf <http://people.deas.harvard.edu/~pvs/research/silclip/silclip.pdf>; Unfortunately I would have thought that most of your complicated shadowing objects will be skinned characters anyway, so these algorithms are not appropriate ;( Original Message From: Warrick Buchanan [mailto:Warrick@...] Sent: 04 July 2002 15:41 To: Davies Sean; gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v The advantage is you're _precomputing_ the silhouette edges for possible positions of the light. And thanks guys I think my feeble hungover brain has started to grasp the idea! Thinking about removing convex/concave(?) edges that seemingly will never cast shadows doesn't this breakdown with nonclosed geometry? (Although you can always close it). I suppose to cut down on the memory consumption it will help to disregard areas where lights will never go as it were... Warrick. Original Message From: Davies Sean [ mailto:SDavies@... <mailto:SDavies@...> ] Sent: Thursday, July 04, 2002 3:45 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v Is this not just a reformulation of the backfacing/frontfacing triangles meeting at an edge test but using more memory? I can't immediately see any advantage of this method over the classic one... I may be being dim mind ;) cheers Sean Original Message From: John White [ mailto:johnw@... <mailto:johnw@...> ] Sent: 04 July 2002 14:44 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v I've been thinking about this recently. If you have 2 polys which share an edge you can catergorize 4 areas of space that the 2 planes (coplanar with the polys) split the world into. . . . 2 . . . 1 .. 3 /\ / \ / 4 \ / \ So area 2 is in the +ve space of both polys. 4 is in the ve space and both and 1 and 3 is in +ve space of one and ve space of the other. Determing which space the camera is in is 2 quick plane equateions. If the camera is in regions 1 or 3 then the edge is a shadow edge, otherwise it isn't. It _should_ be fairly striaghtforward to carve up all edges this way such that the leaves of the tree give an exact set of all sillouette edges. If the two polys sharing an edge have their normals pointing towards one another then there is no way (I think) that they can cast a shadow so can be completely ignored. It should also be possible to remove shadow edges if you know that they are redundant due to an enclosing set of shadow edges. I fear that the memory overhead will be two high as I have not tried this yet. Comments? Original Message From: gdalgorithmslistadmin@... [ mailto:gdalgorithmslistadmin@... <mailto:gdalgorithmslistadmin@...> ]On Behalf Of Ulf Ochsenfahrt Sent: 04 July 2002 14:00 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > Still twisting my head slightly on this  anyone care to click my brain into > the correct gear? Does this only work for convex objects? or does the fact > you're inflicting a BSP on space make it work in this case as well? I should join Tom in this as I havn't tried it either. The general idea is that you only have a finite number of possible silhouettes and that you can precalculate these. The only problem is then choosing the correct silouette. To do this you build a data structure where you can quickly get the correct silhouette data. Tom mentiones a BSP. Yet the naive approach of just doing a BSP on your object does not work in all cases. C +   B  + A Plane A is the root. Plane B is completely on one side of Plane A. The light source is in front of (below) A and looks towards A. Then the edge between A and B belongs to the silhoutte. If the light source moves to the left (or the object to the right) then the edge between A and B is no more correct but the edge between B and C must be taken. In a simple BSP you would still be in the same space partition.  Ulf  This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf <http://thinkgeek.com/sf>; _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist <https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist>; Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 <http://sourceforge.net/mailarchive/forum.php?forum_id=6188>;  This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf <http://thinkgeek.com/sf>; _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist <https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist>; Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 <http://sourceforge.net/mailarchive/forum.php?forum_id=6188>; 
From: <e_astier@ya...>  20020704 15:01:33

> > ASCII art time: > > > Mesh: > > + > /\ > /  \ > +  + > \  / > \/ > + > > Turns into: > > > ++ > / \ > /   \ > +   + > \   / > \ / > ++ > > > infinity be here > ++ > / \ > /   \ > +  shadow volume  + > \   / > \ / > ++ > Is it mandatory to double every edge ? Can't we just live with the diminution of the size of the shadow, with an infinity being far enougth ? infinity be here + /  /   +  shadow volume + \   \  + Emmanuel ___________________________________________________________ Do You Yahoo!?  Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com 
From: Warrick Buchanan <Warrick@de...>  20020704 14:37:13

The advantage is you're _precomputing_ the silhouette edges for possible positions of the light. And thanks guys I think my feeble hungover brain has started to grasp the idea! Thinking about removing convex/concave(?) edges that seemingly will never cast shadows doesn't this breakdown with nonclosed geometry? (Although you can always close it). I suppose to cut down on the memory consumption it will help to disregard areas where lights will never go as it were... Warrick. Original Message From: Davies Sean [mailto:SDavies@...] Sent: Thursday, July 04, 2002 3:45 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v Is this not just a reformulation of the backfacing/frontfacing triangles meeting at an edge test but using more memory? I can't immediately see any advantage of this method over the classic one... I may be being dim mind ;) cheers Sean Original Message From: John White [mailto:johnw@...] Sent: 04 July 2002 14:44 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v I've been thinking about this recently. If you have 2 polys which share an edge you can catergorize 4 areas of space that the 2 planes (coplanar with the polys) split the world into. . . . 2 . . . 1 .. 3 /\ / \ / 4 \ / \ So area 2 is in the +ve space of both polys. 4 is in the ve space and both and 1 and 3 is in +ve space of one and ve space of the other. Determing which space the camera is in is 2 quick plane equateions. If the camera is in regions 1 or 3 then the edge is a shadow edge, otherwise it isn't. It _should_ be fairly striaghtforward to carve up all edges this way such that the leaves of the tree give an exact set of all sillouette edges. If the two polys sharing an edge have their normals pointing towards one another then there is no way (I think) that they can cast a shadow so can be completely ignored. It should also be possible to remove shadow edges if you know that they are redundant due to an enclosing set of shadow edges. I fear that the memory overhead will be two high as I have not tried this yet. Comments? Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Ulf Ochsenfahrt Sent: 04 July 2002 14:00 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > Still twisting my head slightly on this  anyone care to click my brain into > the correct gear? Does this only work for convex objects? or does the fact > you're inflicting a BSP on space make it work in this case as well? I should join Tom in this as I havn't tried it either. The general idea is that you only have a finite number of possible silhouettes and that you can precalculate these. The only problem is then choosing the correct silouette. To do this you build a data structure where you can quickly get the correct silhouette data. Tom mentiones a BSP. Yet the naive approach of just doing a BSP on your object does not work in all cases. C +   B  + A Plane A is the root. Plane B is completely on one side of Plane A. The light source is in front of (below) A and looks towards A. Then the edge between A and B belongs to the silhoutte. If the light source moves to the left (or the object to the right) then the edge between A and B is no more correct but the edge between B and C must be taken. In a simple BSP you would still be in the same space partition.  Ulf  This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Leigh McRae <leigh.mcrae@co...>  20020704 14:06:59

Hi all, How are people handling the integration of content after a product = ships? Currently I use a database that manages unique ID's for me. So = if someone adds some new models or textures I need an ID fr them. I was = thinking of running a crc32 on the data of the resource and use it for = the ID. Has anyone tried this?=20 Leigh McRae 
From: Davies Sean <SDavies@uk...>  20020704 13:59:56

Is this not just a reformulation of the backfacing/frontfacing triangles meeting at an edge test but using more memory? I can't immediately see any advantage of this method over the classic one... I may be being dim mind ;) cheers Sean Original Message From: John White [mailto:johnw@...] Sent: 04 July 2002 14:44 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v I've been thinking about this recently. If you have 2 polys which share an edge you can catergorize 4 areas of space that the 2 planes (coplanar with the polys) split the world into. . . . 2 . . . 1 .. 3 /\ / \ / 4 \ / \ So area 2 is in the +ve space of both polys. 4 is in the ve space and both and 1 and 3 is in +ve space of one and ve space of the other. Determing which space the camera is in is 2 quick plane equateions. If the camera is in regions 1 or 3 then the edge is a shadow edge, otherwise it isn't. It _should_ be fairly striaghtforward to carve up all edges this way such that the leaves of the tree give an exact set of all sillouette edges. If the two polys sharing an edge have their normals pointing towards one another then there is no way (I think) that they can cast a shadow so can be completely ignored. It should also be possible to remove shadow edges if you know that they are redundant due to an enclosing set of shadow edges. I fear that the memory overhead will be two high as I have not tried this yet. Comments? Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Ulf Ochsenfahrt Sent: 04 July 2002 14:00 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > Still twisting my head slightly on this  anyone care to click my brain into > the correct gear? Does this only work for convex objects? or does the fact > you're inflicting a BSP on space make it work in this case as well? I should join Tom in this as I havn't tried it either. The general idea is that you only have a finite number of possible silhouettes and that you can precalculate these. The only problem is then choosing the correct silouette. To do this you build a data structure where you can quickly get the correct silhouette data. Tom mentiones a BSP. Yet the naive approach of just doing a BSP on your object does not work in all cases. C +   B  + A Plane A is the root. Plane B is completely on one side of Plane A. The light source is in front of (below) A and looks towards A. Then the edge between A and B belongs to the silhoutte. If the light source moves to the left (or the object to the right) then the edge between A and B is no more correct but the edge between B and C must be taken. In a simple BSP you would still be in the same space partition.  Ulf  This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: John White <johnw@de...>  20020704 13:36:23

I've been thinking about this recently. If you have 2 polys which share an edge you can catergorize 4 areas of space that the 2 planes (coplanar with the polys) split the world into. . . . 2 . . . 1 .. 3 /\ / \ / 4 \ / \ So area 2 is in the +ve space of both polys. 4 is in the ve space and both and 1 and 3 is in +ve space of one and ve space of the other. Determing which space the camera is in is 2 quick plane equateions. If the camera is in regions 1 or 3 then the edge is a shadow edge, otherwise it isn't. It _should_ be fairly striaghtforward to carve up all edges this way such that the leaves of the tree give an exact set of all sillouette edges. If the two polys sharing an edge have their normals pointing towards one another then there is no way (I think) that they can cast a shadow so can be completely ignored. It should also be possible to remove shadow edges if you know that they are redundant due to an enclosing set of shadow edges. I fear that the memory overhead will be two high as I have not tried this yet. Comments? Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Ulf Ochsenfahrt Sent: 04 July 2002 14:00 To: gdalgorithmslist@... Subject: RE: [Algorithms] Optimizing the silhouette finding for a shadow v On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > Still twisting my head slightly on this  anyone care to click my brain into > the correct gear? Does this only work for convex objects? or does the fact > you're inflicting a BSP on space make it work in this case as well? I should join Tom in this as I havn't tried it either. The general idea is that you only have a finite number of possible silhouettes and that you can precalculate these. The only problem is then choosing the correct silouette. To do this you build a data structure where you can quickly get the correct silhouette data. Tom mentiones a BSP. Yet the naive approach of just doing a BSP on your object does not work in all cases. C +   B  + A Plane A is the root. Plane B is completely on one side of Plane A. The light source is in front of (below) A and looks towards A. Then the edge between A and B belongs to the silhoutte. If the light source moves to the left (or the object to the right) then the edge between A and B is no more correct but the edge between B and C must be taken. In a simple BSP you would still be in the same space partition.  Ulf 
From: Tom Forsyth <tomf@mu...>  20020704 13:16:56

Agreed  it's not a simple BSP, as done for sorting purposes. If anything, it's not a traditional BSP at all (which only splits existing leaves). In this, each face/plane potentially splits every leaf it intersects. Then you remerge leaves when you find that in fact both sides have the same silhouette value. Simple 2D example, a square: AB       CD Normal BSP:         =5 leaves (one of which is inside the object). But for silhouette extraction, you need to split them all and get 9 leaves (one of which is inside the object). BC AB  AD   AB   AC ABCD BD   CD   AD CD  BC These correspond to all the possible silhouette vertices, as shown (erm... doesn't really work in 2D, but I'm sure you get the extrapolation to 3D) Again, I've never tried this, or indeed any other stencilshadow stuff, so... you know... Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Ulf Ochsenfahrt [mailto:ulfjack@...] > Sent: 04 July 2002 14:00 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Optimizing the silhouette finding > for a shadow > v olume. > > > On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > > Still twisting my head slightly on this  anyone care to > click my brain into > > the correct gear? Does this only work for convex objects? > or does the fact > > you're inflicting a BSP on space make it work in this case as well? > > I should join Tom in this as I havn't tried it either. The > general idea > is that you only have a finite number of possible silhouettes and that > you can precalculate these. The only problem is then choosing the > correct silouette. > > To do this you build a data structure where you can quickly get the > correct silhouette data. Tom mentiones a BSP. > > Yet the naive approach of just doing a BSP on your object > does not work > in all cases. > > C > + >  >  B >  > + A > > Plane A is the root. Plane B is completely on one side of Plane A. The > light source is in front of (below) A and looks towards A. > Then the edge > between A and B belongs to the silhoutte. If the light source moves to > the left (or the object to the right) then the edge between A and B is > no more correct but the edge between B and C must be taken. > > In a simple BSP you would still be in the same space partition. > >  Ulf > 
From: Ulf Ochsenfahrt <ulfjack@gm...>  20020704 13:01:35

On Thu, 20020704 at 14:06, Warrick Buchanan wrote: > Still twisting my head slightly on this  anyone care to click my brain i= nto > the correct gear? Does this only work for convex objects? or does the fa= ct > you're inflicting a BSP on space make it work in this case as well? I should join Tom in this as I havn't tried it either. The general idea is that you only have a finite number of possible silhouettes and that you can precalculate these. The only problem is then choosing the correct silouette. To do this you build a data structure where you can quickly get the correct silhouette data. Tom mentiones a BSP. Yet the naive approach of just doing a BSP on your object does not work in all cases. C +   B  + A Plane A is the root. Plane B is completely on one side of Plane A. The light source is in front of (below) A and looks towards A. Then the edge between A and B belongs to the silhoutte. If the light source moves to the left (or the object to the right) then the edge between A and B is no more correct but the edge between B and C must be taken. In a simple BSP you would still be in the same space partition.  Ulf 
From: Shawn Hargreaves <shargreaves@cl...>  20020704 12:59:40

Tom Forsyth writes: > Erm... I'm not sure if you also need degenerate polygons at > each vertex or not. Maybe the extra edge quads are good enough. I think that depends on whether your "move away from light" is a boolean function that always moves either zero or a constant, fixed distance, or if you smooth it out and move by an amount proportional to the light/normal dot. With discrete on/off movement, I'm pretty sure that just the edge quads will always be stiched, but with continuous motion you'd also need vertex degenerates in case the three verts are all moved by different amounts. I think so, anyway: this isn't easy to visualise! There's no point moving by variable amounts if you are adding the degenerate tris in any case: that is only useful to avoid popping if you are working directly with the original mesh.  Shawn Hargreaves Climax Brighton 
From: Tom Forsyth <tomf@mu...>  20020704 12:48:01

There's two techniques. One does nothing to the mesh, and just relies on high tesselation to avoid any artifacts. People are reporting good results with this, but it does require fairly high tesselation, and then of course you pretty much _require_ hardware vertex shaders, or performance is going to be terrible. The other, the "proper" way, is to have every edge a degenerate quad. Every vertex is doubled up, and each face gets a unique vertex with the normal _of the face_. So the normals used for silhouette testing are not the smoothed gouraudnormals, they are the normals of the face they are associated with. Then, when you do the normal.light_vector thing and throw half the vertices to infinity, the degenerate quads stretch and form the shadow volume. ASCII art time: Mesh: + /\ /  \ +  + \  / \/ + Turns into: ++ / \ /   \ +   + \   / \ / ++ ...except the new verts are actually coincident in position. Each vert uses the normal to the face it is connected to, not the smoothed one. Then when the rightmost face gets thrown to infinity: infinity be here ++ / \ /   \ +  shadow volume  + \   / \ / ++ (that quad is actually two triangles of course  join omitted for clarity). Erm... I'm not sure if you also need degenerate polygons at each vertex or not. Maybe the extra edge quads are good enough. Obviously this skyrockets your vertex count, but it's only applied to lowpoly models anyway, so maybe that's not a big problem. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Paul Firth [mailto:pfirth@...] > Sent: 04 July 2002 11:19 > To: gdalgorithmslist@... > Subject: [Algorithms] vertex shader shadow volume extrusion > > > Hi Ppl, > > Does anyone have any links which explain exactly how shadowvolume > extrusion in a vertex shader works? Specifically, what needs to be > done to the mesh before hand so it can be extruded correctly. > > Cheers, Paul. > > > >  > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Oles V. Shishkovtsov <oles@gs...>  20020704 12:07:51

Hello jason, Wednesday, July 03, 2002, 21:37:23, you wrote: jz> Thank you for the hints about what speed could be reasonable. jz> Now I'll look into the codes to find the bottle neck. jz> By the way, what spatial partition algorithm do you use for raytrace? We use rather simple structure: 1. 3D grid 2. In each cell: noleafAABBtree Another suggestion(s). 1. Try to localize/cull your lights before raytracing using all visinfo u have. (we have sectorportal info + dedicated (simple) geometry for occlusion culling) 2. Try to cache occluder polygons per light  usually lumels from which rays r casted are spatially near. >> jz> It is better than brutalforce method. But It is still slow. Much slower than >> jz> that of bspscene and too slow that radiosity computation seems impossible. >> jz> There is a program called lightscape with 3dsmax(Do you heard of it?). It can >> jz> compute the game scene within a few hours incluing radiosity, and my program needs >> jz> a few days approximately . I wonder whether there is a magic method I had never >> jz> thought of. >> >> Well, I don't know why u r getting such poor performance... >> >> Our bruteforce solution uses ~6 hours for the following conditions >> (last level compiled): >> >> * 1.8 M tris on level >> * 412 light sources >> * 11 lightmaps created (packed) >> * 1024x1024 lmap size >> * 9 raycasts per lumel per light (jittering) >> * around 30% partiallytransparent triangles (which we raycasted using >> alpha calculated from shader definition and texture(s) combination) >> >> But this time also includes sublightmaps color/gradients analysis >> and around 40% recalculations under condition that lightmap can be >> shrinked down. >> Plus, all sublightmaps was specifically packed to allow DXT1 >> compression (this takes some time too). >> >> So, all I can suggest  use good spatial partition for raytesting.  Best regards, Oles V. Shishkovtsov GSCGame World oles@... 
From: Warrick Buchanan <Warrick@de...>  20020704 12:03:23

> The BSP splits space into leaves, and at each leaf the list of silhouette > edges is stored. I guess that means that each BSP plane is parallel to a > triangle of the object, since once the light goes from the ve side of a > face to the +ve, different edges of that face are possible silhouette > candidates. Obviously not all faces will contribute planes to the BSP  a > lot will be culled from the final list. Still twisting my head slightly on this  anyone care to click my brain into the correct gear? Does this only work for convex objects? or does the fact you're inflicting a BSP on space make it work in this case as well? > The large amount of memory this uses has been mentioned  I suspect you > could reduce this using lots of "master leaves" that other leaves refer > to, plus a delta. That would reduce storage quite a bit. No doubt it is possible to condense the info to a reasonable and manageable size. > This also fails to use and frametoframe coherency, which is quite > important. A lot of other promising algorithms were mentioned that used > this heavily, but the mind goes fuzzy... Damn carrot dangling that is ;) > However, this is just me remembering the old conversation. I don't use > stencil shadows, so I've never tried anything remotely like this. > I shouldn't have mentioned it really  someone else who actually does this > stuff should speak up. Please? :) No not at all  I don't think this sort of thing has been publicly talked about enough to my knowledge  ie a practical scene level implementation of shadow volumes. To give you an escape route: are you guys at Ion Storm doing similar things for Deus ExII? or using some other kind of spatial structure (In fact I should read a previous post as I recall a hint to that info mentioned) ? but as you're (Ion Storm guys and anyone else of course) using a modified Unreal Warfare engine I guess you started off doing it the brute force way using the level BSP and instanced geometry? Have you tried to use the portal information as well to clip the volumes and reduce their size? At the moment the only 'fancy' thing I do is remove (static) shadow volumes whose bounding volumes are enclosed in other shadow volumes for a light, I'll probably get around to properly clipping the static volumes against geometry and do a proper boolean merge of the volumes one day... ooh lots of questions... Warrick. 
From: Paul Firth <pfirth@at...>  20020704 11:20:27

Tom Forsyth wrote: > However, this is just me remembering the old conversation. I don't use > stencil shadows, so I've never tried anything remotely like this. I > shouldn't have mentioned it really  someone else who actually does this > stuff should speak up. Please? :) I found this just now, looks like what you were talking about: "http://citeseer.nj.nec.com/cache/papers2/cs/1310/ftp:zSzzSzftp.dcs.qmw.ac.ukzSzpeoplezSzmelzSzBSPzSzshadow.pdf/slater92comparison.pdf"; Cheers, Paul. 
From: Paul Firth <pfirth@at...>  20020704 10:16:32

Hi Ppl, Does anyone have any links which explain exactly how shadowvolume extrusion in a vertex shader works? Specifically, what needs to be done to the mesh before hand so it can be extruded correctly. Cheers, Paul. 
From: Ray <ray@gu...>  20020704 05:37:33

Hi Nick, I looked at Redon's stuff and even emailed him once. I don't really understand how he creates the screwing frame though. I use geometrydriven detection until I know there is (possibly) a collision within the next frame. I 'fixed' some of my collision response by making sure I apply my angular velocity in the correct frame of reference, oops, heh. Actually what I have seems to be working really well now. I just need to add friction. Actually I don't _need_ to add friction because our game is a spacesim and friction is overkill, but I like being able to do accurate simulation of a dynamic system. Maybe we'll use it for other games, who knows?  Ray Nick Pelling wrote: > Hi Ray, > > Doing continuous CD on combined linear + angular velocities is a tough call. > Stephane Redon appears to have done the most research on this area (which, > to me, still seems a pretty basic prerequisite for a continuous CD system). > His homepage is: > > http://wwwrocq.inria.fr/~redon/research.htm > > His approach is to transform the relative linear + angular velocities into a > "screwing" frame: and then to generate an approximate version of the > equations, assuming low angular velocities. While this produces manageable > maths, it's definitely approximate  he suggests increasing the collision > "tickrate" if you need more accuracy. > > Personally, I'd rather build an exact (geometrydriven) solution to this > kind of problem: in my experience, 90%+ of the time this kind of code is > able to "earlyout" (using signs of determinants etc). But maybe if I'd > tried the maths, I'd change my mind. :) > > Can anyone say how existing games handle CD with angular rotation? > Presumably more or less all of them use iterationbased stepping CD rather > than continuous CD? > > Cheers, .....Nick Pelling..... > > Ray asked: > >>How do different people take angular velocity into account when finding >>a future collision? >> > 
From: Igor Kravtchenko <igor@ob...>  20020704 01:45:26

He seems to also use the probability distribution with the covarience matrix stuff. So, any one to light me about the "why of how" ? (le pourquoi du comment :) Is the method I described for axis aligned ellipsoid usually used by you, crazy coders ? Igor.  Original Message  From: "Pierre Terdiman" <p.terdiman@...> To: <gdalgorithmslist@...> Sent: Thursday, July 04, 2002 1:07 AM Subject: Re: [Algorithms] minimum bounding ellipsoid > http://www.magicsoftware.com/Source/Containment3D/MgcCont3DEllipsoid.cpp > > Just in case you missed it. > > Pierre > >  Original Message  > From: Igor Kravtchenko <igor@...> > To: <gdalgorithmslist@...> > Sent: Wednesday, July 03, 2002 10:37 PM > Subject: [Algorithms] minimum bounding ellipsoid > > > > > > To perform the minimum bounding ellipsoid of a mesh, I currently calcul > its AABB in order to obtain the > > lenght of its 3 axis (X, Y and Z). Then, I rescale the two smallest axis > to be equal to the longest one. > > On that new deformed mesh, the "normal" bounding sphere is performed. > Finally, each axis of the sphere > > (which are ofcourse all equal at the start) are back rescaled to produce > the correct bounding ellipsoid. > > It seems to work pretty okey and is ~ as fast as computing the bounding > sphere but ofcourse just provides > > an axis aligned bounding ellipsoid. > > > > However, it seems to exist other method like the probability distribution > explained by Fabio Pilocarpo. > > However, that method seems best suited for oriented bounding ellipsoid and > not optimal for axis aligned > > bounding ellipsoid. > > > > Any word on that subject is welcomed, > > > > Igor. > > > > > > > > > >  > > This sf.net email is sponsored by:ThinkGeek > > No, I will not fix your computer. > > http://thinkgeek.com/sf > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > >  > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 