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
(12) 
2
(6) 
3
(5) 
4
(5) 
5
(11) 
6
(3) 
7
(2) 
8
(11) 
9
(35) 
10
(38) 
11
(41) 
12
(18) 
13
(11) 
14
(16) 
15
(7) 
16
(31) 
17
(18) 
18
(5) 
19
(1) 
20

21
(20) 
22
(15) 
23
(33) 
24
(18) 
25
(46) 
26
(19) 
27
(2) 
28
(33) 
29
(31) 
30
(29) 
31
(24) 


From: Per Vognsen <per@ep...>  20030721 21:30:44

Sorry, I thought you were asking for an explicitly conservative, rather = than exact, algorithm. If you seek an exact algorithm, I can think of a = couple of approaches: Take the Minkowski sum of the AABB and a sphere with radius equal to the = radius of the lineswept sphere. Then intersect this sum with the = central line segment of the lineswept sphere. This is equivalent to = intersecting the central line segment with an AABBswept sphere with = radius equal to the radius of the lineswept sphere. This is done by = calculating the squared distance from the line segment to the AABB and = comparing it to the squared radius. The distance calculation can become = complicated; even calculating the distance between two line segments = turns out to be difficult. Thus this approach is probably one of the = least desirable. If you have already implemented GJK you can use that; the support = mapping for a lineswept sphere is easily derived. You can use the separating axis theorem. The conservative algorithm I = presented is actually a degenerate version of this as I only check the = three axes most likely to be separating. To find the complete set of = candidate axes, it helps to think of the lineswept sphere as being = decomposed into three features: a cylindrical shell and two = hemispherical caps. A separating axis for the cylindrical shell will = always be orthogonal to the central axis of the cylinder. Due to = symmetry, the hemispherical caps have no "preferred" separating axes. = These considerations indicate that the candidate separating axis are: (i) The normals of the faces of the AABB (ii) Cross products of AABB edge vectors and the central axis of the = lineswept sphere. There are thus six separating axis to consider. Hopefully I did not = leave any out; I have not discovered a general approach to finding = separating axis so I mostly go by intuition and symmetry considerations. Per  Original Message =20 From: Marius Elvert=20 To: gdalgorithmslist@...=20 Sent: Monday, July 21, 2003 4:21 PM Subject: Re: [Algorithms] linesweptsphere / AABB test Thanx for the reply, however, I think that solution is pretty much = conservative, as it's basicly an AABB vs moving AABB test, where the second box has it's center at the = sphere's center and extends of 'radius'. It'd give you false positives... or am I missing = something there? The problem can be reduced to intersecting the lineswept sphere with = three slabs, corresponding to the x, y and z axes. // The lineswept sphere has radius r and a center axis with ends u1 and = u2. // The AABB has extremal vertices v1 and v2. // Find the ends of the projection of the lineswept sphere onto the x = axis. float p1 =3D min(u1.x, u2.x)  r, p2 =3D max(u1.x, u2.x) + r; // Do the projections of the lineswept sphere and the AABB onto the x = axis not intersect? if (p2 < v1.x  p1 > v2.x) return false; // No intersection // Similarly for the y and z axes. return true; // The lineswept sphere intersects all three slabs and = hence it intersects the AABB. Per  Original Message  From: "Marius Elvert" <LtJax@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 10:55 AM Subject: [Algorithms] linesweptsphere / AABB test I'm wondering if's there some smart test for a linesweptsphere vs an AABB that is _NOT_ conservative. Out of my head, I'd try to clip the sphere's line of movement into the 26 surrounding sectors and measure the distance to box feature in that sector ( plane, line or point ) but that sounds kinda expensive. Any better ideas? I dont need a the time of intersection, simple boolean test will do. Marius  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 =20  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Jason Zisk <zisk@n...>  20030721 20:49:47

Oh I've already got alpha fading working, because it is so easy with premultiplied alpha blending. The problem is that it won't work for our situation (I didn't realize it wouldn't work until I tried it). Imagine this situation, you have a tree that is really huge so it doesn't become an imposter until its pretty far away. By then, it is already in the "fog band", and thus being fogged. If it becomes an imposter, suddenly it is no longer fogged normally and is being alpha faded, and thus pops in the change over quite drastically. Now you might say why not just alpha fade the 3d objects as well so everything matches? Well it still won't match because an alpha faded 3d object and an alpha faded imposter look very different due to alpha "buildup" in the 3d object (branches behind other branches being rendered on top of each other, etc.). Anyway besides that, we want "real fog" because it creates a nice atmosphere, for instance in rainly or low visibility levels, that you couldn't achieve with just alpha fading. I guess this is the artist's way of looking at it but I think its just as valid. :)  Jason Zisk  nFusion Interactive LLC  Original Message  From: "Gribb, Gil" <ggribb@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 4:20 PM Subject: RE: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > In all games we have ever done, it worked perfectly to fade instead of fog things like imposters. Look at it this way, if the fog color is red, then there will be some red background behind the imposter that will "take over" as you fade your imposter out. Try it, you will like it. If your imposters are huge and therefore a single fog factor for the whole sprite is not acceptable, we can probably come up with some other way to do it using the more normal fog thing. > > Gil > > > > I'm looking to actually fog the imposter, so if the fog color is redish I > want it to become redish in the distance (how standard fog works). I > believe what you describe is alphafading the imposter out as it gets > further away, which is a cool effect isn't desired in my situation. Unless > I'm misunderstanding you, which may very well be the case. :) > > Thanks, > >  Jason Zisk >  nFusion Interactive LLC > > >  Original Message  > From: "Gribb, Gil" <ggribb@...> > To: <gdalgorithmslist@...> > Sent: Monday, July 21, 2003 3:27 PM > Subject: RE: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > > > > Under openGL, I think a fog color of black and 0 alpha I think works > directly. > > > > Under D3D, I think you can probably manage it, especially if you can > compute the fog factor manually for the entire imposter (which we have done > with good sucess in the past). In this case, turn off fogging and just use > RGBA vertex colors of (f,f,f,f), where f is the fog factor (tex modulate). > > > > Gil > > > > Original Message > > From: Jason Zisk [mailto:zisk@...] > > Sent: Monday, July 21, 2003 1:58 PM > > To: gdalgo > > Subject: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > > > > > > I'm rendering some imposter sprites with one:invsrcalpha blending but I > also > > need to fog them. This of course doesn't work because the fog is additive > > so it just makes the parts of the image with 0 alpha get brighter. > > > > I've been trying to figure this one out for a while now but haven't come > up > > with anything. Is there some magic blending mode I can use that would > work > > here? Or maybe a multipass solution? I'm thinking maybe there is some > way > > I could cleverly blend two passes so the fogging works out correctly with > > the blending mode but I haven't come up with it yet. > > > > Thanks for any ideas on this. > > > >  Jason Zisk > >  nFusion Interactive LLC > > > > > > > > > > > >  > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > > _______________________________________________ > > 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: VM Ware > > With VMware you can run multiple operating systems on a single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > 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: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > 
From: Phil Teschner <philt@mi...>  20030721 20:48:50

Have the fog color for the imposters go to black instead of the regular fog color. That will make the sprites go to black in the distance. This means that your sprites slowly disappear in the distance and at the point that everything else is the fog color the sprites no longer show up. Phil Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jason Zisk Sent: Monday, July 21, 2003 11:58 AM To: gdalgo Subject: [Algorithms] Premultiplied alpha and fog I'm rendering some imposter sprites with one:invsrcalpha blending but I also need to fog them. This of course doesn't work because the fog is additive so it just makes the parts of the image with 0 alpha get brighter. I've been trying to figure this one out for a while now but haven't come up with anything. Is there some magic blending mode I can use that would work here? Or maybe a multipass solution? I'm thinking maybe there is some way I could cleverly blend two passes so the fogging works out correctly with the blending mode but I haven't come up with it yet. Thanks for any ideas on this.  Jason Zisk  nFusion Interactive LLC  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: <LtJax@t...>  20030721 20:23:41

Thanx for the reply, however, I think that solution is pretty much conservative, as it's basicly an AABB vs moving AABB test, where the second box has it's center at the sphere's center and extends of 'radius'. It'd give you false positives... or am I missing something there? >The problem can be reduced to intersecting the lineswept sphere with three >slabs, corresponding to the x, y and z axes. > >// The lineswept sphere has radius r and a center axis with ends u1 and u2. >// The AABB has extremal vertices v1 and v2. > >// Find the ends of the projection of the lineswept sphere onto the x axis. >float p1 = min(u1.x, u2.x)  r, p2 = max(u1.x, u2.x) + r; >// Do the projections of the lineswept sphere and the AABB onto the x axis >not intersect? >if (p2 < v1.x  p1 > v2.x) > return false; // No intersection >// Similarly for the y and z axes. >return true; // The lineswept sphere intersects all three slabs and hence >it intersects the AABB. > >Per > > Original Message  >From: "Marius Elvert" <LtJax@...> >To: <gdalgorithmslist@...> >Sent: Monday, July 21, 2003 10:55 AM >Subject: [Algorithms] linesweptsphere / AABB test > > > > >>I'm wondering if's there some smart test for a linesweptsphere vs an >>AABB that is _NOT_ conservative. Out of my head, I'd try to clip the >>sphere's line of movement into the 26 surrounding sectors and measure >>the distance to box feature in that sector ( plane, line or point ) but >>that sounds kinda expensive. Any better ideas? I dont need a the time of >>intersection, simple boolean test will do. >> >>Marius >> >> >> >> >>This SF.net email is sponsored by: VM Ware >>With VMware you can run multiple operating systems on a single machine. >>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the >>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >>_______________________________________________ >>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: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the >same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > 
From: Gribb, Gil <ggribb@ra...>  20030721 20:20:38

In all games we have ever done, it worked perfectly to fade instead of = fog things like imposters. Look at it this way, if the fog color is red, = then there will be some red background behind the imposter that will = "take over" as you fade your imposter out. Try it, you will like it. If = your imposters are huge and therefore a single fog factor for the whole = sprite is not acceptable, we can probably come up with some other way to = do it using the more normal fog thing. Gil I'm looking to actually fog the imposter, so if the fog color is redish = I want it to become redish in the distance (how standard fog works). I believe what you describe is alphafading the imposter out as it gets further away, which is a cool effect isn't desired in my situation. = Unless I'm misunderstanding you, which may very well be the case. :) Thanks,  Jason Zisk  nFusion Interactive LLC  Original Message =20 From: "Gribb, Gil" <ggribb@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 3:27 PM Subject: RE: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > Under openGL, I think a fog color of black and 0 alpha I think works directly. > > Under D3D, I think you can probably manage it, especially if you can compute the fog factor manually for the entire imposter (which we have = done with good sucess in the past). In this case, turn off fogging and just = use RGBA vertex colors of (f,f,f,f), where f is the fog factor (tex = modulate). > > Gil > > Original Message > From: Jason Zisk [mailto:zisk@...] > Sent: Monday, July 21, 2003 1:58 PM > To: gdalgo > Subject: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > > > I'm rendering some imposter sprites with one:invsrcalpha blending but = I also > need to fog them. This of course doesn't work because the fog is = additive > so it just makes the parts of the image with 0 alpha get brighter. > > I've been trying to figure this one out for a while now but haven't = come up > with anything. Is there some magic blending mode I can use that would work > here? Or maybe a multipass solution? I'm thinking maybe there is = some way > I could cleverly blend two passes so the fogging works out correctly = with > the blending mode but I haven't come up with it yet. > > Thanks for any ideas on this. > >  Jason Zisk >  nFusion Interactive LLC > > > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single = machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at = the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single = machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at = the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Jason Zisk <zisk@n...>  20030721 20:05:07

I'm looking to actually fog the imposter, so if the fog color is redish I want it to become redish in the distance (how standard fog works). I believe what you describe is alphafading the imposter out as it gets further away, which is a cool effect isn't desired in my situation. Unless I'm misunderstanding you, which may very well be the case. :) Thanks,  Jason Zisk  nFusion Interactive LLC  Original Message  From: "Gribb, Gil" <ggribb@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 3:27 PM Subject: RE: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > Under openGL, I think a fog color of black and 0 alpha I think works directly. > > Under D3D, I think you can probably manage it, especially if you can compute the fog factor manually for the entire imposter (which we have done with good sucess in the past). In this case, turn off fogging and just use RGBA vertex colors of (f,f,f,f), where f is the fog factor (tex modulate). > > Gil > > Original Message > From: Jason Zisk [mailto:zisk@...] > Sent: Monday, July 21, 2003 1:58 PM > To: gdalgo > Subject: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] > > > I'm rendering some imposter sprites with one:invsrcalpha blending but I also > need to fog them. This of course doesn't work because the fog is additive > so it just makes the parts of the image with 0 alpha get brighter. > > I've been trying to figure this one out for a while now but haven't come up > with anything. Is there some magic blending mode I can use that would work > here? Or maybe a multipass solution? I'm thinking maybe there is some way > I could cleverly blend two passes so the fogging works out correctly with > the blending mode but I haven't come up with it yet. > > Thanks for any ideas on this. > >  Jason Zisk >  nFusion Interactive LLC > > > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > 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: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > 
From: Gribb, Gil <ggribb@ra...>  20030721 19:26:50

Under openGL, I think a fog color of black and 0 alpha I think works = directly. Under D3D, I think you can probably manage it, especially if you can = compute the fog factor manually for the entire imposter (which we have = done with good sucess in the past). In this case, turn off fogging and = just use RGBA vertex colors of (f,f,f,f), where f is the fog factor (tex = modulate).=20 Gil Original Message From: Jason Zisk [mailto:zisk@...] Sent: Monday, July 21, 2003 1:58 PM To: gdalgo Subject: [Algorithms] Premultiplied alpha and fog [bcc][fake adr] I'm rendering some imposter sprites with one:invsrcalpha blending but I = also need to fog them. This of course doesn't work because the fog is = additive so it just makes the parts of the image with 0 alpha get brighter. I've been trying to figure this one out for a while now but haven't come = up with anything. Is there some magic blending mode I can use that would = work here? Or maybe a multipass solution? I'm thinking maybe there is some = way I could cleverly blend two passes so the fogging works out correctly = with the blending mode but I haven't come up with it yet. Thanks for any ideas on this.  Jason Zisk  nFusion Interactive LLC  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Per Vognsen <per@ep...>  20030721 19:22:58

The problem can be reduced to intersecting the lineswept sphere with three slabs, corresponding to the x, y and z axes. // The lineswept sphere has radius r and a center axis with ends u1 and u2. // The AABB has extremal vertices v1 and v2. // Find the ends of the projection of the lineswept sphere onto the x axis. float p1 = min(u1.x, u2.x)  r, p2 = max(u1.x, u2.x) + r; // Do the projections of the lineswept sphere and the AABB onto the x axis not intersect? if (p2 < v1.x  p1 > v2.x) return false; // No intersection // Similarly for the y and z axes. return true; // The lineswept sphere intersects all three slabs and hence it intersects the AABB. Per  Original Message  From: "Marius Elvert" <LtJax@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 10:55 AM Subject: [Algorithms] linesweptsphere / AABB test > I'm wondering if's there some smart test for a linesweptsphere vs an > AABB that is _NOT_ conservative. Out of my head, I'd try to clip the > sphere's line of movement into the 26 surrounding sectors and measure > the distance to box feature in that sector ( plane, line or point ) but > that sounds kinda expensive. Any better ideas? I dont need a the time of > intersection, simple boolean test will do. > > Marius > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Jason Zisk <zisk@n...>  20030721 18:58:10

I'm rendering some imposter sprites with one:invsrcalpha blending but I also need to fog them. This of course doesn't work because the fog is additive so it just makes the parts of the image with 0 alpha get brighter. I've been trying to figure this one out for a while now but haven't come up with anything. Is there some magic blending mode I can use that would work here? Or maybe a multipass solution? I'm thinking maybe there is some way I could cleverly blend two passes so the fogging works out correctly with the blending mode but I haven't come up with it yet. Thanks for any ideas on this.  Jason Zisk  nFusion Interactive LLC 
From: Paul Du Bois <dubois@do...>  20030721 18:03:50

The conservative approach is pretty fast (I'm specifically thinking of the 3slabs, ref RTR2 section 13.6.3). It seems to me that if you save the results of the slab comparisons you could narrow down the features you need to check more accurately to 1 vertex and its 3 adjacent edges. Since you have pretty good earlyouts from the conservative test anyway, you might not even need to get much more clever than that. p Marius Elvert wrote: > I'm wondering if's there some smart test for a=20 > linesweptsphere vs an=20 > AABB that is _NOT_ conservative. Out of my head, I'd try to clip the=20 > sphere's line of movement into the 26 surrounding sectors and measure=20 > the distance to box feature in that sector ( plane, line or=20 > point ) but=20 > that sounds kinda expensive. Any better ideas? I dont need a=20 > the time of=20 > intersection, simple boolean test will do. >=20 
From: Troy Gilbert <TroyG@cs...>  20030721 17:35:56

I'm a little slow when it comes to SH (though very interested to learn more), so please bare with me... When you say "one normal and an ambient ..." do you mean one _directional_ light and an ambient light? [Sorry if the terms are interchangeable, just never seen them used that way.] If that is the case (1dir+amb==4comp SH), is there an equivalent to the preferable 9comp SH? Perhaps a 4dir+amb setup? Troy Developer Relations Criterion Software http://www.csl.com > Original Message > From: Tom Forsyth [mailto:tom.forsyth@...] > Sent: Monday, July 21, 2003 11:41 AM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] [Rendering] Merging, approximating several > dynamic lights > > > One normal and an ambient == a 4component spherical harmonic! (I can > never remember if that's 1st order or 2nd order). The increase in > quality in going to a 9component one is IMHO significant. > > TomF. 
From: Tom Forsyth <tom.forsyth@bl...>  20030721 16:40:43

One normal and an ambient == a 4component spherical harmonic! (I can never remember if that's 1st order or 2nd order). The increase in quality in going to a 9component one is IMHO significant. TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Troy Gilbert > Sent: 21 July 2003 17:01 > To: 'gdalgorithmslist@...' > Subject: RE: [Algorithms] [Rendering] Merging, approximating > several dynamic lights > > > Don't know about others, but I'd be interested in hearing > what technique > you're using to merge all dynamic lights into one ambient and one > directional. In general, are there any papers relating to generically > "factoring down" dynamic lights in the same way there are so many mesh > reductions algorithms? > > Troy > Developer Relations > Criterion Software > http://www.csl.com > > > > Original Message > > From: Alen Ladavac [mailto:alengdalgs@...] > > Sent: Tuesday, July 15, 2003 1:10 PM > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] [Rendering] Merging, approximating several > > dynamic lights > > > > > > Hm, we've used a method for aproximating any number of > > point(local), directional(inifinite) and > > ambient lights into one ambient and one directional. The > > object could be 0100% in shadow wrt any > > light, and transitions were always smooth. The idea was > > simple and straightforward, but I am not > > sure if that is what you want, as it was all for pervertex > lighting. > > Is your problem in creating a smooth aproximation to for > > vertex lighting, or a smooth change between > > perpixel and vertex lighting? > > > > Alen 
From: Troy Gilbert <TroyG@cs...>  20030721 16:02:47

Don't know about others, but I'd be interested in hearing what technique you're using to merge all dynamic lights into one ambient and one directional. In general, are there any papers relating to generically "factoring down" dynamic lights in the same way there are so many mesh reductions algorithms? Troy Developer Relations Criterion Software http://www.csl.com > Original Message > From: Alen Ladavac [mailto:alengdalgs@...] > Sent: Tuesday, July 15, 2003 1:10 PM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] [Rendering] Merging, approximating several > dynamic lights > > > Hm, we've used a method for aproximating any number of > point(local), directional(inifinite) and > ambient lights into one ambient and one directional. The > object could be 0100% in shadow wrt any > light, and transitions were always smooth. The idea was > simple and straightforward, but I am not > sure if that is what you want, as it was all for pervertex lighting. > Is your problem in creating a smooth aproximation to for > vertex lighting, or a smooth change between > perpixel and vertex lighting? > > Alen 
From: <LtJax@t...>  20030721 14:58:02

I'm wondering if's there some smart test for a linesweptsphere vs an AABB that is _NOT_ conservative. Out of my head, I'd try to clip the sphere's line of movement into the 26 surrounding sectors and measure the distance to box feature in that sector ( plane, line or point ) but that sounds kinda expensive. Any better ideas? I dont need a the time of intersection, simple boolean test will do. Marius 
From: Gribb, Gil <ggribb@ra...>  20030721 13:30:44

>The SH stuff is really cool  you can throw as many directional lights in there as you like and the pervertex processing part doesn't change in cost. I'm doing a talk on this at GDC Europe, but there's a fair bit about them around already. >Trying to merge lights sounds like a complete nightmare. I don't even attempt it. The SH stuff IS merging lights, not a nightmare, in fact as you say, it = is really cool. Gil 
From: Alen Ladavac <alengdalgs@cr...>  20030721 13:23:40

Hm, you've lost me somewhere around the "cylinder frame". :) What I do is to find the point x' where the line (box edge) intersects the circle plane. Then imagine I have a circle with radius r'=distance(x', c), where 'c' is circle center. I then create a tangent to the circle in the point x'. The tangent is a line orthogonal to x'c. (I don't need to know r' for that.) Our separation axis will be a vector orthogonal to both the tangent and to the box edge. I am explaning the motivation, real formulae can skip a lot of parts here. Anyway, you can see that original point x and radius r are not mentioned. In fact, no radii are mentioned at all. Required property of a separating axis would be that it is orthogonal to both features in contact at the exact time of contact  i.e. border point between separation and intersection. In that case, x==x', so this satisfies property, since it is orthogonal to both the circle (or its tangent in the contact point) and to the box edge. Is this understandable? Alen  Original Message  From: "Bob Dowland" <Bob.Dowland@...> To: <gdalgorithmslist@...> Sent: Monday, July 21, 2003 9:18 AM Subject: RE: [Algorithms] seperating axes with cylinders > The idea was to change the circle radius so that it exactly > touches the point where the line intersects the circle plane. a cunning plan! :)  indeed in "cylinder frame", once you have the required intersection the grad/normal computation reduces to not much more than a simple "coordinate selection"  nice. > (actually, you don't even need to know the radius at all). I'm not convinced of this last point though  ;) somehow you need to do something like taking the difference of the two cylinder/circle points, don't you? For eg, if x and x' are points on the actual and scaled cylinder/circle then separation can be got by something like (x  x').test_axis where x' was got by the intersect_line_circle_plane. However, x would still be unknown and to get it you either have some inversetrig or some sqrt ing to do, no? Bob. > Original Message > From: Alen Ladavac [mailto:alengdalgs@...] > Sent: 19 July 2003 12:43 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] seperating axes with cylinders > > > > 24 seems like such a large number! I have to admit I would > have probably stopped after the first > seven in your list :) > > It's amazing what CPUs can do nowadays. :) Still, it really > will need some heavy trivial rejection, > but I belive that it will be possible. > > > So are you picking the normal to each circle at the point > (on the circle) that is closest to that > edge? > > Something like that, just that doing circlePointClosest(edge, > circle) in 3d is not so simple. Trying > to solve that analitically proved just too complicated. So, > instead of that, we used a very simple > formula that should give the testaxis directly. I don't have > a proof that it actually _is_ that > axis, but if it is not, it's a very good approximation, and > we weren't able to make the test fail in > any of our tests. > > The idea was to change the circle radius so that it exactly > touches the point where the line > intersects the circle plane. For such case, it is easy to > calculate the axis that is orthogonal to > both the circle tangent in that point and the edge (actually, > you don't even need to know the radius > at all). In case of exact contact, it is obvious that this is > exactly the correct axis, since that > is exactly the same circle. In case of separation it > certainly does separate, and in case of > intersection it gives a short exit direction, what is expected. > > Whether this really is _the shortest_ exit direction in case > of intersection I'm not sure. But it > certainly does not report false positives in case where there > is separation of those two features. > And that should be the main requirement for a separating > axis, I think. ;) > > Corrections are welcome. > > Alen > > >  Original Message  > From: "Bob Dowland" <Bob.Dowland@...> > To: <gdalgorithmslist@...> > Sent: Friday, July 18, 2003 3:13 PM > Subject: RE: [Algorithms] seperating axes with cylinders > > > > 5) 12 axes that are orthogonal to each edge of box and > > cylinder's top circle edge > > 6) 12 axes that are orthogonal to each edge of box and > > cylinder's bottom circle edge > > Alen, > > As usual very interesting to hear your angle on this! > > 24 seems like such a large number! I have to admit I would > have probably stopped after the first > seven in your list :) > > So are you picking the normal to each circle at the point (on > the circle) that is closest to that > edge? > > ie. p = circlePointClosest(edge, circle) > n = grad(circle(p)) > testaxis = cross(n, edge) > > Bob. > > > Original Message > > From: Alen Ladavac [mailto:alengdalgs@...] > > Sent: 18 July 2003 09:05 > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] seperating axes with cylinders > > > > > > Generally, when we were designing our separatingaxis > > colliders, we were following this idea: You > > need one separating axis for each possible pair of closest > > features (all combinations of > > vertexvertex, vertexface, etc). Canonically, for boxbox, > > each box has 6 faces, 12 edges and 8 > > vertices, it would give you (6+12+8)^2=676 combinations. In > > most cases, a lot of combinations are > > usually represented by the same axis. E.g, one axis of box A > > handles separation of its two faces > > against all other features on box B. That's why the boxbox > > collider ends up with only 15 axis. > > > > For cylinderbox, there are 6 box faces, 12 box edges, 8 box > > vertices, 2 cylinder flat surfaces (top > > and bottom), 1 cylinder shell (is this the right word for the > > curved surface on the cylinder?) and 2 > > cylinder's circle edges (the sharp helix along the end of the > > cylinder shell). > > That would give (6+12+8)*(2+1+2)=130 axes. Unfortunately, > > these don't merge as easily as boxbox, so > > we actually have 39 (!) axes. The 24 axes I mentioned in the > > post you refer to, are just that last > > 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me. > > > > Here's the whole set: > > 1) 3 box axes  they handle box faces against all cylinder features, > > 2) 1 cylinder axis  handles the top and bottom ends of the > > cylinder against all box features, > > 3) 3 cross products of cylinder axis with box axes  they > > handle cylinder shell against box edges > > 4) 8 axis through the box vertices orthogonal to cylinder > > axis  handle vertices against the > > cylinder shell > > 5) 12 axes that are orthogonal to each edge of box and > > cylinder's top circle edge > > 6) 12 axes that are orthogonal to each edge of box and > > cylinder's bottom circle edge > > > > This uses only projection onto axes, and there is no > > numerical root finding involved  the solution > > is completely analytical. > > > > The axes in 5) and 6) are a bit more complicated to derive > > than the others, but not nearly as hard > > to understand as the rootfinding methods proposed in the > > paper from MagicSoftware website (all > > praises to Mr. Eberly, as I honor his work a lot, but some > > parts are just too complicated for > > something I'd have in my collider's inner loop :)). All other > > axes are simple and straight forward. > > > > I don't claim to have a mathematical proof of the correctness > > of the method, or to say that it is > > faster than numerical methods. But it certainly works for us > > so far, it is _very_ simple to > > implement, works in constant bounded time, and offers a lot > > of earlyouts. > > > > Also, there is a great potential in quickly discarding most > > of the axes in 4), 5) and 6). I believe > > that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are > > relevant. But it will need to wait > > until this starts choking on some more complex scenes, so we > > are forced to devote time to optimizing > > it. :) > > > > If anyone finds a problem with this, or sees some > > optimization, please do let me know. I plan to > > make a document explaining all the colliders we use (sphere, > > box, capsule, cylinder, mesh), together > > with the actual contact point and penetration depth > > computations. I'd like to have that public so > > that it can be verified, and also to help putting an end to > > this neverending secrecy around simple > > and robust collision detection methods. Unfortunately, I > > don't have that much spare time right now, > > so I'll just resort to short (?) discussions like this. > > > > Alen > > > > > > > >  Original Message  > > From: metanet metanet > > To: gdalgorithmslist@... > > Sent: Thursday, July 17, 2003 7:00 PM > > Subject: [Algorithms] seperating axes with cylinders > > > > > > hi, > > i'm currently trying to find all seperating axes that need to > > be checked for boxcylinder > > intersection. > > > > in a previous thread, it was stated that there are > > (allagedly) 24 axes to test. a magicsoftware .pdf > > was linked to, but not only is it a bit over my head, it > > requires projection on to planes as well as > > axes. > > > > is there a projectionontoaxesonly method? and if so, any > > hints as to what the 24 axes are? i've > > only found about 10. > > > > > > thanks, > > raigan > > > > > > > > > >  > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a > > single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > > machines at the > > same time. Free trial click here: > http://www.vmware.com/wl/offer/345/0 > > _______________________________________________ > > 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: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > 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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Stephen J Baker <sjbaker@li...>  20030721 12:09:14

Jon Watte wrote: >>Yeah, I guess transparency is the lone vexing issue. As usual... > > Ask yourself: if it's three kilometers away, does it REALLY need full > transparency? Well  perhaps: * Some of the stuff we do requires a half degree field of view. * Some multipass techniques won't work properly  because the second pass is blended into the first. * Some translucent objects might be very large.  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://www.sjbaker.org 
From: Tom Forsyth <tom.forsyth@bl...>  20030721 11:56:54

One problem I've seen may be applicable to both APIs. The offsets with EMBM are signed, so if they're bytes then 0x80 = 128.0, 0xff = 1.0, 0x00 = 0.0, 0x1 = 1.0, 0x7f = 127.0. This is completely different to normalmap offsets which are usually biased: 0x00 = 128.0, 0x7f = 1.0, 0x80 = 0.0, 0x81 = 1.0, 0xff = 127.0. So you need to be careful when authoring them  you can't share the textures, even though it seems like you should be able to. [minor API diversion  PS1.3 (GF4) allows you to do "texbem t1, t0_bx2" which _does_ take biased values, but PS1.1 (GF3) does NOT allow the "_bx2" operator so can only take signed values  I doubt the GF3 and previous expose the biased mode under OpenGL either]. Another problem is that about 90% of the time the driver seems to randomly guess whether you want it to do signed filtering or unsigned filtering. So if it gets it wrong, you get strangeness where your offsets are around 0  i.e. exactly where you'd notice them most. The only solution is to get lucky with the driver (yeah, right), or disable bilinear filtering  square edges are less objectionable than wierd "rainbow" edges. TomF. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of John Pollard Sent: 17 July 2003 23:29 To: gdalgorithmslist@... Subject: Re: [Algorithms] EMBM filtering problems Well I guess OpenGL calls them fragment shaders, but then I'd have to cross post to get both crowds. Either way I'm screwed :(  Original Message  From: John Pollard To: gdalgorithmslist@... Sent: Thursday, July 17, 2003 5:17 PM Subject: Re: [Algorithms] EMBM filtering problems DirectX is the only thing that can do pixelshaders? I'm confused.  Original Message  From: Rusch, Matthew To: gdalgorithmslist@... Sent: Thursday, July 17, 2003 5:05 PM Subject: RE: [Algorithms] EMBM filtering problems Ask this on the directx board and I or someone else will be happy to answer it for you. Original Message From: John Pollard [mailto:johnp@...] Sent: Thursday, July 17, 2003 2:15 PM To: gdalgorithmslist@... Subject: [Algorithms] EMBM filtering problems This is kind of a noob question, but how are you folks solving the problem where you get tearing from EMBM sampling? For example, in the pixel shader you have code that uses another texture (a normal map) to perturb the uv's for the next stage. Some pixels will get shifted up, while others will get shifted down. Even with filtering turned on, the filtering is also shifted, so you get obvious tearing, which looks really ugly close up. I was thinking to fix this, just simply render this object to a rendertarget, and resample from the target to get a double filtering effect. This would filter across the ugly seams where the tearing occured. Does this sound like the right thing to do, or does anyone else have better ideas? John 
From: Tom Forsyth <tom.forsyth@bl...>  20030721 11:10:00

Am I right in thinking the main problem you are seeing is popping as you change which lights are what sort? If so, that's certainly solvable. What I do is for each object I decide how many of what sort of light type they get. (this is determined statically, but I don't see any big problem with doing it dynamically). The three sorts of light are perpixel (bumpmapped) ones, pervertex "proper" lights (i.e. doing all the proper local diffuse and local specular stuff) and all the rest which get thrown into my 9component spherical harmonic. So let's say for argument that I have 2 pixel lights, 4 vertex lights and an SH  keeps the numbers real. So for each object, find all the lights that hit it and sort them by their relative brightness at the closest point on the object to the light. So we now have lights L0, L1, L2, L3, etc... in order of brightness, brightest first. So there are 2 pixel lights. These will obviously be L0 and L1. But the problem is that as the object moves, L1 and L2 can swap places, and give you a pop in lighting. So the trick is to split L1 into part that is done perpixel and part that is done pervertex. The blend is such that when L1 and L2 are going to swap, i.e. they are at the same brightness, L1 is completely vertex and no pixel. Which means L1 and L2 are both vertex lights and can happily swap without a pop. Similarly, when L0 and L1 swap, make sure L1 is a completely pixelgenerated light, so again they can swap with no pop. So pixel lights are: L0 and L1*blend1 And vertex lights are L1*(1blend1), L2, L3, etc... (the multiplication just multiplies the colour of the light, it doesn't change the direction, etc). blend1 = (L1.bright  L2.bright)/(L0.bright  L2.bright); (note that when L1.bright==L2.bright, blend1==0, and when L0.bright==L1.bright, blend1==1). ...and you also do the same for the transition between vertex and SH: Pixel lights are: L0 and L1*blend1 Vertex lights are L1*(1blend1), L2, L3, L4*blend4 SH lights are L4*(1blend4), L5, L6, etc... blend1 = (L1.bright  L2.bright)/(L0.bright  L2.bright); blend4 = (L4.bright  L5.bright)/(L3.bright  L5.bright); The SH stuff is really cool  you can throw as many directional lights in there as you like and the pervertex processing part doesn't change in cost. I'm doing a talk on this at GDC Europe, but there's a fair bit about them around already. Trying to merge lights sounds like a complete nightmare. I don't even attempt it. TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Guillaume Provost > Sent: 16 July 2003 17:05 > To: 'gdalgorithmslist@...' > Subject: RE: [Algorithms] [Rendering] Merging, approximating > several dynamic lights > > > Alen, > > It's really a load balancing issue. There's two ways I > can save on > performance: > >  I can approximate and merge lights together >  I can degrade the lighting precision (pixel > vertex > > object) >  This can be done on an individual light basis. > > A few givens: > >  You'll want to naturally degrade the lighting precision if: >  The light is contributing very little > intensity (pixel > > vertex > object) >  The screenspace vertex density of an object is > sufficiently high (degrade pixel > vertex) >  The size of the object on screen is very > small (vertex > > object) > > Unfortunately, simply following the (above) rules is'nt > sufficient > in terms of performance, atleast not with the number of > lights and dynamic > objects that I'm currently dealing with. I can degrade lights > earlier, but > that comes at a significant visual cost  its basically > similar to switching > LODs too close from the camera. This technique also causes a > high variance > in vertex shader/pixel shader combinations, forcing me to dynamically > reconstruct, and resend code to the GPU several times a > frame. Its much more > preferable to have inacurate, consistent lighting, then acurate, > inconsistent lighting. > > I can balance the problem by merging lights. So that I > have, say, 4 > (vertex shader)/(pixel shader) combinations for various > levels of lighting > accuracy. The problem is that whatever algorithm I use to > merge lights needs > to be temporally continuous, in a way that reduces 'popping' > in the light > combinations that it produces. If a highdetail, inyourface > object (ie: a > player's avatar) is surrounded by 6 strong lights, I need to > merge those > lights into, say, two or three clusters, then ensure that > when the player > moves in the game world, the lighting contribution does'nt 'pop'. > > ie: A simple workaround would be to simply ignore the > lesssignificant lights (ie  not try to merge them), and > 'crossfade' out > old lights with new ones over time. Look at it as > 'motionblurring' the > lighting conditions over time. > > Guillaume. > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On > Behalf Of Alen > Ladavac > Sent: Tuesday, July 15, 2003 2:10 PM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] [Rendering] Merging, approximating several > dynamic lights > > > Hm, we've used a method for aproximating any number of point(local), > directional(inifinite) and > ambient lights into one ambient and one directional. The > object could be > 0100% in shadow wrt any > light, and transitions were always smooth. The idea was simple and > straightforward, but I am not > sure if that is what you want, as it was all for pervertex lighting. > Is your problem in creating a smooth aproximation to for > vertex lighting, or > a smooth change between > perpixel and vertex lighting? > > Alen > > >  Original Message  > From: "Guillaume Provost" <Guillaume@...> > To: <gdalgorithmslist@...> > Sent: Tuesday, July 15, 2003 3:13 PM > Subject: [Algorithms] [Rendering] Merging, approximating > several dynamic > lights > > > > Greetings, > > > > I am, as I'm sure you all are, constrained in the number of dynamic > > lights I can light a mesh with. I've implemented a > 'degrading scheme' > where > > I degrade a light from perpixel to pervertex to a simple > ambient cue in > > order to manage performance (these are also scaled with respect to > distance > > of the lightsource and camera), but these transitions are not always > > seemless. I was wondering whether some of you have tried merging > > lightsources as an alternative to this, and how much > success you've had at > > getting rid of discontinuities in the lighting conditions. > I currently > deal > > mostly with 'skewed' spotlights (pointellipsoid lights) > which I use to > > roughly approximate rectangular arealights, and > omnidirectional lights. > > > > Guillaume. > > http://www.celdamage.com > > > > > > > >  > > This SF.Net email sponsored by: Parasoft > > Error proof Web apps, automate testing & more. > > Download & eval WebKing and get a free book. > > http://www.parasoft.com/bulletproofapps1 > > _______________________________________________ > > 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: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > 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: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Bob Dowland <Bob.Dowland@bl...>  20030721 09:18:49

> The idea was to change the circle radius so that it exactly=20 > touches the point where the line intersects the circle plane.=20 a cunning plan! :)=20  indeed in "cylinder frame", once you have the required intersection = the grad/normal computation reduces to not much more than a simple = "coordinate selection"  nice. > (actually, you don't even need to know the radius at all).=20 I'm not convinced of this last point though  ;) somehow you need to do = something like taking the difference of the two cylinder/circle points, = don't you?=20 For eg, if x and x' are points on the actual and scaled cylinder/circle = then separation can be got by something like (x  x').test_axis where x' was got by the intersect_line_circle_plane. However, x would = still be unknown and to get it you either have some inversetrig or some = sqrt ing to do, no?=20 Bob. > Original Message > From: Alen Ladavac [mailto:alengdalgs@...] > Sent: 19 July 2003 12:43 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] seperating axes with cylinders >=20 >=20 > > 24 seems like such a large number! I have to admit I would=20 > have probably stopped after the first > seven in your list :) >=20 > It's amazing what CPUs can do nowadays. :) Still, it really=20 > will need some heavy trivial rejection, > but I belive that it will be possible. >=20 > > So are you picking the normal to each circle at the point=20 > (on the circle) that is closest to that > edge? >=20 > Something like that, just that doing circlePointClosest(edge,=20 > circle) in 3d is not so simple. Trying > to solve that analitically proved just too complicated. So,=20 > instead of that, we used a very simple > formula that should give the testaxis directly. I don't have=20 > a proof that it actually _is_ that > axis, but if it is not, it's a very good approximation, and=20 > we weren't able to make the test fail in > any of our tests. >=20 > The idea was to change the circle radius so that it exactly=20 > touches the point where the line > intersects the circle plane. For such case, it is easy to=20 > calculate the axis that is orthogonal to > both the circle tangent in that point and the edge (actually,=20 > you don't even need to know the radius > at all). In case of exact contact, it is obvious that this is=20 > exactly the correct axis, since that > is exactly the same circle. In case of separation it=20 > certainly does separate, and in case of > intersection it gives a short exit direction, what is expected. >=20 > Whether this really is _the shortest_ exit direction in case=20 > of intersection I'm not sure. But it > certainly does not report false positives in case where there=20 > is separation of those two features. > And that should be the main requirement for a separating=20 > axis, I think. ;) >=20 > Corrections are welcome. >=20 > Alen >=20 >=20 >  Original Message  > From: "Bob Dowland" <Bob.Dowland@...> > To: <gdalgorithmslist@...> > Sent: Friday, July 18, 2003 3:13 PM > Subject: RE: [Algorithms] seperating axes with cylinders >=20 >=20 > > 5) 12 axes that are orthogonal to each edge of box and > > cylinder's top circle edge > > 6) 12 axes that are orthogonal to each edge of box and > > cylinder's bottom circle edge >=20 > Alen, >=20 > As usual very interesting to hear your angle on this! >=20 > 24 seems like such a large number! I have to admit I would=20 > have probably stopped after the first > seven in your list :) >=20 > So are you picking the normal to each circle at the point (on=20 > the circle) that is closest to that > edge? >=20 > ie. p =3D circlePointClosest(edge, circle) > n =3D grad(circle(p)) > testaxis =3D cross(n, edge) >=20 > Bob. >=20 > > Original Message > > From: Alen Ladavac [mailto:alengdalgs@...] > > Sent: 18 July 2003 09:05 > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] seperating axes with cylinders > > > > > > Generally, when we were designing our separatingaxis > > colliders, we were following this idea: You > > need one separating axis for each possible pair of closest > > features (all combinations of > > vertexvertex, vertexface, etc). Canonically, for boxbox, > > each box has 6 faces, 12 edges and 8 > > vertices, it would give you (6+12+8)^2=3D676 combinations. In > > most cases, a lot of combinations are > > usually represented by the same axis. E.g, one axis of box A > > handles separation of its two faces > > against all other features on box B. That's why the boxbox > > collider ends up with only 15 axis. > > > > For cylinderbox, there are 6 box faces, 12 box edges, 8 box > > vertices, 2 cylinder flat surfaces (top > > and bottom), 1 cylinder shell (is this the right word for the > > curved surface on the cylinder?) and 2 > > cylinder's circle edges (the sharp helix along the end of the > > cylinder shell). > > That would give (6+12+8)*(2+1+2)=3D130 axes. Unfortunately, > > these don't merge as easily as boxbox, so > > we actually have 39 (!) axes. The 24 axes I mentioned in the > > post you refer to, are just that last > > 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me. > > > > Here's the whole set: > > 1) 3 box axes  they handle box faces against all cylinder features, > > 2) 1 cylinder axis  handles the top and bottom ends of the > > cylinder against all box features, > > 3) 3 cross products of cylinder axis with box axes  they > > handle cylinder shell against box edges > > 4) 8 axis through the box vertices orthogonal to cylinder > > axis  handle vertices against the > > cylinder shell > > 5) 12 axes that are orthogonal to each edge of box and > > cylinder's top circle edge > > 6) 12 axes that are orthogonal to each edge of box and > > cylinder's bottom circle edge > > > > This uses only projection onto axes, and there is no > > numerical root finding involved  the solution > > is completely analytical. > > > > The axes in 5) and 6) are a bit more complicated to derive > > than the others, but not nearly as hard > > to understand as the rootfinding methods proposed in the > > paper from MagicSoftware website (all > > praises to Mr. Eberly, as I honor his work a lot, but some > > parts are just too complicated for > > something I'd have in my collider's inner loop :)). All other > > axes are simple and straight forward. > > > > I don't claim to have a mathematical proof of the correctness > > of the method, or to say that it is > > faster than numerical methods. But it certainly works for us > > so far, it is _very_ simple to > > implement, works in constant bounded time, and offers a lot > > of earlyouts. > > > > Also, there is a great potential in quickly discarding most > > of the axes in 4), 5) and 6). I believe > > that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are > > relevant. But it will need to wait > > until this starts choking on some more complex scenes, so we > > are forced to devote time to optimizing > > it. :) > > > > If anyone finds a problem with this, or sees some > > optimization, please do let me know. I plan to > > make a document explaining all the colliders we use (sphere, > > box, capsule, cylinder, mesh), together > > with the actual contact point and penetration depth > > computations. I'd like to have that public so > > that it can be verified, and also to help putting an end to > > this neverending secrecy around simple > > and robust collision detection methods. Unfortunately, I > > don't have that much spare time right now, > > so I'll just resort to short (?) discussions like this. > > > > Alen > > > > > > > >  Original Message  > > From: metanet metanet > > To: gdalgorithmslist@... > > Sent: Thursday, July 17, 2003 7:00 PM > > Subject: [Algorithms] seperating axes with cylinders > > > > > > hi, > > i'm currently trying to find all seperating axes that need to > > be checked for boxcylinder > > intersection. > > > > in a previous thread, it was stated that there are > > (allagedly) 24 axes to test. a magicsoftware .pdf > > was linked to, but not only is it a bit over my head, it > > requires projection on to planes as well as > > axes. > > > > is there a projectionontoaxesonly method? and if so, any > > hints as to what the 24 axes are? i've > > only found about 10. > > > > > > thanks, > > raigan > > > > > > > > > >  > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a > > single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > > machines at the > > same time. Free trial click here:=20 > http://www.vmware.com/wl/offer/345/0 > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20 > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20 > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 