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}

S  M  T  W  T  F  S 





1
(7) 
2

3

4
(10) 
5
(12) 
6
(15) 
7
(2) 
8
(8) 
9
(7) 
10
(1) 
11
(6) 
12
(7) 
13
(13) 
14
(35) 
15
(17) 
16
(15) 
17
(12) 
18
(4) 
19
(13) 
20

21

22

23
(15) 
24
(6) 
25
(4) 
26
(19) 
27
(33) 
28
(16) 
29
(31) 
30
(30) 

From: John W. Ratcliff <jratcliff@in...>  20040430 01:25:40

With the Nv40 coming out there are soon going to be cards that will let you render massive numbers of instanced objects without constantly stalling out. For quite some time we have been told to perform as few state changes as possible. However, when a transform is considered a 'state change' this has prevented developers from doing massive (on the order or tens of thousands) of dynamic objects at high framerate; even if the sum total of those objects did not actually come near the triangle throughput of the card. I'm currently exploring how to render the theoretical maximum number of instanced objects possible at high frame rate on the Nv40. Once you start dealing with massive numbers of low polygon instanced objects; very quickly you realize that just the transform data itself can add up to a lot of memory. I am curious if you guys can think of more efficient ways to send transform data in massive quantities. For example, representing all of your transforms as a quaternion and a translation would take less than half as much bandwidth as a full 4x4 matrix (assuming of course your objects have no scale.) There is also the challenge of trying to manage this many entities without iterating through them in various portions of your pipeline. Thoughts? 
From: Joris Mans <joris.mans@pa...>  20040430 01:25:17

Is there such a thing as uv spider for max? > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Emanuele Salvucci > Sent: Friday, April 30, 2004 02:43 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Generating uv coordinates which > follow a shape > > > Hi, > > see if this paper is of some use...it's about UV > parametrization...I've just had a look: > > http://graphics.cs.uiuc.edu/~jch/papers/seamster.pdf > > It looks overkill for the example you shown...but maybe it > can give some useful hints. Also, you may want to ask your > artist to look around for mapping plugs...for the "road" a UV > spider could be enough. > > Best, > > Emanuele. > > >  Original Message  > From: "Joris Mans" <joris.mans@...> > To: <gdalgorithmslist@...> > Sent: Friday, April 30, 2004 1:53 AM > Subject: [Algorithms] Generating uv coordinates which follow a shape > > > > Hi > > > > I ve been fiddling with this for some days, but don't seem > to come up > > with a "general" solution. The problem is the following: > > Assume a planar mesh. I want to define uvs over that mesh in the > > following way. I have 4 corner vertices on the mesh which > will contain > > mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of > the mesh are > > calculated by iterating over the border and using the > piecewise distance > > of each line segment to define the interpolated values: > > > > Mapping[ k ] > > = Mapping[ corner_index ] > > + ( Mapping[ next_corner_index ]  Mapping[ corner_index > > ] ) > > * ( distance(corner_index,k) / > > distance(corner_index,next_corner_index) > > > > Whereby distance just sums up all the edge lengths from one vertex > > upto another, following the border of the mesh. > > > > Now this was the easy part, the hard part is assigning the > uvs to the > > nonborder vertices. And this is where I am getting stuck. > The problem > > is that the internal uvs should follow as good as possible, to > > minimize distortion issues. I ve been trying by using a massspring > > system on the mapping coordinates, and fixing the border > verts so they > > cant move, but getting a good configuration to start the > simulation is > > already a problem, coz you need to choose start positions for the > > internal vertices, spring rest lengths and so on. I tried several > > "project internal vertices on borders and interpolate" > approaches, but > > for all of those its quite easy to find a case where it breaks down. > > > > Here you see an example of what I want to achieve: > > > > http://users.pandora.be/ir_fuel/face_mapping_problem.jpg > > > > > > Oh, and I tried asking the artist to use Nurbs, which would > give me a > > nice parametrization to define the mapping, but that > doesn't seem to > > be the solution he is looking for ;) ;) > > > > > > Joris > > > > > > > >  > > This SF.Net email is sponsored by: Oracle 10g > > Get certified on the hottest thing ever to hit the market... Oracle > > 10g. Take an Oracle 10g class now, and we'll give you the > exam FREE. > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > _______________________________________________ > > 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: Oracle 10g > Get certified on the hottest thing ever to hit the market... > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam > FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Joris Mans <joris.mans@pa...>  20040430 01:23:37

Well, it is in 3dsmax, and it is for road mapping. And it is not as simple as applying bend modifiers on uvs and so on;) Our artists want to apply my plugin to a subselection of faces of a mesh. And yes, the uv edge detection is straightforward, its just the outer edge of the selected faces (all those faces are connected, no holes) > same thing as assuming the mesh has a defined hairline crack, > as above. Thus, follow each edge and assign the U, V in an > interpolative fashion. This I don't get, how can I interpolate from an edge vertex to a nonedge vertex, when I only have 1 known uv pair, namely that of the edge vertex? 
From: Emanuele Salvucci <info@fo...>  20040430 00:52:22

Hi, see if this paper is of some use...it's about UV parametrization...I've just had a look: http://graphics.cs.uiuc.edu/~jch/papers/seamster.pdf It looks overkill for the example you shown...but maybe it can give some useful hints. Also, you may want to ask your artist to look around for mapping plugs...for the "road" a UV spider could be enough. Best, Emanuele.  Original Message  From: "Joris Mans" <joris.mans@...> To: <gdalgorithmslist@...> Sent: Friday, April 30, 2004 1:53 AM Subject: [Algorithms] Generating uv coordinates which follow a shape > Hi > > I ve been fiddling with this for some days, but don't seem to come up > with a "general" solution. > The problem is the following: > Assume a planar mesh. I want to define uvs over that mesh in the > following way. I have 4 corner vertices on the mesh which will contain > mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are > calculated by iterating over the border and using the piecewise distance > of each line segment to define the interpolated values: > > Mapping[ k ] > = Mapping[ corner_index ] > + ( Mapping[ next_corner_index ]  Mapping[ corner_index > ] ) > * ( distance(corner_index,k) / > distance(corner_index,next_corner_index) > > Whereby distance just sums up all the edge lengths from one vertex upto > another, following the border of the mesh. > > Now this was the easy part, the hard part is assigning the uvs to the > nonborder vertices. And this is where I am getting stuck. The problem > is that the internal uvs should follow as good as possible, to minimize > distortion issues. I ve been trying by using a massspring system on the > mapping coordinates, and fixing the border verts so they cant move, but > getting a good configuration to start the simulation is already a > problem, coz you need to choose start positions for the internal > vertices, spring rest lengths and so on. > I tried several "project internal vertices on borders and interpolate" > approaches, but for all of those its quite easy to find a case where it > breaks down. > > Here you see an example of what I want to achieve: > > http://users.pandora.be/ir_fuel/face_mapping_problem.jpg > > > Oh, and I tried asking the artist to use Nurbs, which would give me a > nice parametrization to define the mapping, but that doesn't seem to be > the solution he is looking for ;) ;) > > > Joris > > > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Jon Watte <hplus@mi...>  20040430 00:44:05

What's the context? In 3dsmax, you can do this by applying a cylindrical map, and applying the Bend modifier on the mapping gizmo. Or insert the mapping before the geometry bend modifier in the modifier stack. Can you do the same thing? Are you hooked into the tool? If so, just provide a bunch of shapes, with parameters (amount of bend, stretch, etc), and let the artist adjust as appropriate. Also, assuming the mesh is planar, nonclosed manifold with no Tjunctions or threeedges, you can create an ordering of vertices by counting the number of hops between the vert and each of the "anchor verts" along the shortest route, follwing edges. I'm assuming the bent tube you're showing is not actually connected on the backside, i e there's a hairline crack, or at least I assume that you can identify where the discontinuity is, and thus where the "virtual" U,V edges are. I'm assuming that you can find edge vertices (not internal to the mesh) which link each of the anchor vertices. That's the same thing as assuming the mesh has a defined hairline crack, as above. Thus, follow each edge and assign the U, V in an interpolative fashion. Now, for the remaining verts, count the number of hops to the nearest vertex of each of the four sides, using edge connectivity, and assign a U, V that's a blend of the U,V of those side vertices, based on the hop count. You might want to weight the hops by the length of the edge of the hop, to weed out hops that follow diagonals of quads; this will also better account for differences in tesselation, if you want uniform texture stretching. Cheers, / h+ Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Joris Mans Sent: Thursday, April 29, 2004 4:54 PM To: gdalgorithmslist@... Subject: [Algorithms] Generating uv coordinates which follow a shape Hi I ve been fiddling with this for some days, but don't seem to come up with a "general" solution. The problem is the following: Assume a planar mesh. I want to define uvs over that mesh in the following way. I have 4 corner vertices on the mesh which will contain mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are calculated by iterating over the border and using the piecewise distance of each line segment to define the interpolated values: Mapping[ k ] = Mapping[ corner_index ] + ( Mapping[ next_corner_index ]  Mapping[ corner_index ] ) * ( distance(corner_index,k) / distance(corner_index,next_corner_index) Whereby distance just sums up all the edge lengths from one vertex upto another, following the border of the mesh. Now this was the easy part, the hard part is assigning the uvs to the nonborder vertices. And this is where I am getting stuck. The problem is that the internal uvs should follow as good as possible, to minimize distortion issues. I ve been trying by using a massspring system on the mapping coordinates, and fixing the border verts so they cant move, but getting a good configuration to start the simulation is already a problem, coz you need to choose start positions for the internal vertices, spring rest lengths and so on. I tried several "project internal vertices on borders and interpolate" approaches, but for all of those its quite easy to find a case where it breaks down. Here you see an example of what I want to achieve: http://users.pandora.be/ir_fuel/face_mapping_problem.jpg Oh, and I tried asking the artist to use Nurbs, which would give me a nice parametrization to define the mapping, but that doesn't seem to be the solution he is looking for ;) ;) Joris  This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Joris Mans <joris.mans@pa...>  20040429 23:54:02

Hi I ve been fiddling with this for some days, but don't seem to come up with a "general" solution. The problem is the following: Assume a planar mesh. I want to define uvs over that mesh in the following way. I have 4 corner vertices on the mesh which will contain mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are calculated by iterating over the border and using the piecewise distance of each line segment to define the interpolated values: Mapping[ k ] = Mapping[ corner_index ] + ( Mapping[ next_corner_index ]  Mapping[ corner_index ] ) * ( distance(corner_index,k) / distance(corner_index,next_corner_index) Whereby distance just sums up all the edge lengths from one vertex upto another, following the border of the mesh. Now this was the easy part, the hard part is assigning the uvs to the nonborder vertices. And this is where I am getting stuck. The problem is that the internal uvs should follow as good as possible, to minimize distortion issues. I ve been trying by using a massspring system on the mapping coordinates, and fixing the border verts so they cant move, but getting a good configuration to start the simulation is already a problem, coz you need to choose start positions for the internal vertices, spring rest lengths and so on. I tried several "project internal vertices on borders and interpolate" approaches, but for all of those its quite easy to find a case where it breaks down. Here you see an example of what I want to achieve: http://users.pandora.be/ir_fuel/face_mapping_problem.jpg Oh, and I tried asking the artist to use Nurbs, which would give me a nice parametrization to define the mapping, but that doesn't seem to be the solution he is looking for ;) ;) Joris 
From: <robin_green@pl...>  20040429 22:31:38

Oops, did I say Horner's form? I ment Estrin's method. I just saw the stack of multiplies to get the higher powers and assumed they were in order, but Guillaume was sneakier than that. My argument was still partially valid in that the stack of multiples followed by the polynomial reconstruction should be replaced by a series of (non IEEE754) multiplyadds on modern hardware rather than just the multiples. Estrin's trick of doing N parallel MADDS and glueing them together using a running x^(2^i) makes the parallelism more explicit. e.g. // evaluate a + bx + cx^2 + dx^3 + ex^4 + fx^5 + gx^6 + hx^7 // in three parallel steps // step 1  x2 = x*x; A = h*x+g; B = f*x+e; C = d*x+c; D = b*x+a; // step 2  x4 = x2*x2; AA = A*x2+B; BB = C*x2+D; // step 3  result = AA*x4 + BB;  Robin Green. PeterPike Sloan wrote: > I was under the impression that horners method was actually less > efficient on modern architectures because of the dependencies it > creates... > > PeterPike Sloan 
From: PeterPike Sloan <ppsloan@wi...>  20040429 21:33:58

I was under the impression that horners method was actually less efficient on modern architectures because of the dependencies it creates... PeterPike Sloan=20 Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of robin_green@... Sent: Thursday, April 29, 2004 2:09 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Approximating the pow() function I used this Maple script: > restart: > with(numapprox): > with(plots): > setoptions(axes=3DNORMAL,axesfont=3D[COURIER,12],labels=3D["",""]): > Digits :=3D 30; > b:=3D (ln(1+x)  (x+x^2*P(x))); > c:=3Dexpand(b/x^2): > d:=3Dc+P(x); > f:=3Dconvert(series(d,x,15),polynom): > weight:=3D1; > beg :=3D 0: > fin :=3D 1: > plot([f,weight],x=3Dbeg..fin, color=3D[red,green]); > fg:=3Dminimax(f,x=3Dbeg..fin,[3,0],weight,'err'); > ff:=3Devalf(expand(x+x^2*fg)); > evalf(infnorm(ln(1+x)ff, x=3Dbeg..fin, 'h'),2); > h; > g:=3Devalf(ff,9); > convert(g,horner); > plot([ln(1+x)ff, 1(ff/ln(1+x))], x=3Dbeg..fin, numpoints=3D200, color=3D[red,green]); > plot([g,ln(1+x)], x=3D0..1); Also, there's a quicker way of evaluating the polynomial called Horner's Form: fn(x) =3D (1.0 + (0.495858579 + ( 0.236771441 + ( 0.0946189007 + 0.172685158 * x) * x) * x) * x) * x ; You really should read that presentation I did at GDC, old chap! Pleased to be of service.  Robin. 
From: <robin_green@pl...>  20040429 21:09:28

I used this Maple script: > restart: > with(numapprox): > with(plots): > setoptions(axes=NORMAL,axesfont=[COURIER,12],labels=["",""]): > Digits := 30; > b:= (ln(1+x)  (x+x^2*P(x))); > c:=expand(b/x^2): > d:=c+P(x); > f:=convert(series(d,x,15),polynom): > weight:=1; > beg := 0: > fin := 1: > plot([f,weight],x=beg..fin, color=[red,green]); > fg:=minimax(f,x=beg..fin,[3,0],weight,'err'); > ff:=evalf(expand(x+x^2*fg)); > evalf(infnorm(ln(1+x)ff, x=beg..fin, 'h'),2); > h; > g:=evalf(ff,9); > convert(g,horner); > plot([ln(1+x)ff, 1(ff/ln(1+x))], x=beg..fin, numpoints=200, color=[red,green]); > plot([g,ln(1+x)], x=0..1); Also, there's a quicker way of evaluating the polynomial called Horner's Form: fn(x) = (1.0 + (0.495858579 + ( 0.236771441 + ( 0.0946189007 + 0.172685158 * x) * x) * x) * x) * x ; You really should read that presentation I did at GDC, old chap! Pleased to be of service.  Robin. Guillaume Provost wrote: > Robin, > > You rock. Thank you  it works like a charm. Did you get the minimax > coefficients through a general purpose optimizer or did you derive them > analytically? > > float approxlog(float log) > { > long& nat = ((*(long *)&log)); > float exp2 = ((nat & 0x7f800000) >> 23)  127; > > // interpolate the mantissa using a minimax polynomial > float mantissa = float(nat & 0x007fffff) * inverseMantissa; > float mantissa2 = mantissa * mantissa; > float mantissa3 = mantissa2 * mantissa; > float mantissa4 = mantissa2 * mantissa2; > float mantissa5 = mantissa3 * mantissa2; > > float loge_mantissa = mantissa  > 0.495858579 * (mantissa2) + > 0.236771441 * mantissa3 + > 0.0946189007 * mantissa4  > 0.172685158 * mantissa5; > > #ifdef _DEBUG > printf ("exp:%f\napx:%f\napm:%f\n\n", logf(log), exp2 * log2_e, exp2 * > log2_e + loge_mantissa); > #endif > > return exp2 * log2_e + loge_mantissa; > }; > > Guillaume. > P.S. David Wu says its nice to see you're still contributing to the > newsgroups. I agree ;) > > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > robin_green@... > Sent: Thursday, April 29, 2004 2:50 PM > To: gdalgorithmslist@... > Cc: Guillaume Provost > Subject: Re: [Algorithms] Approximating the pow() function > > > > Oops. Sent too soon. (If I may, I'll forward this to the list too) > > I am kindof assuming that you'll be coding the functions using range > reduction plus a polynomial approximation. If that is the case then > range reducing to base 2 or to base "e" makes no difference to the > number of instructions used. > > So, you're using the floatingpoint exponent as a first approximation to > the log of the number. Good, let's see what we can do about the mantissa > bits: > > ln(2^x * m) = x*ln(2) + ln(m) > > As the mantissa only varies between [1.0, 2.0), that's the polynomial you'll > > need to approximate. A quick'n'dirty method is to use Borchardt's Algorithm > over that range: > > ln(x) ~= 6*(x1) / ( x + 1 + 4 * sqrt(x) ) > > or use Maple to generate a minimax polynomial over that range, like this > one: > > ln(1+x) ~= 1.0 * x + > 0.495858579 * x^2 + > 0.236771441 * x^3 + > 0.0946189007 * x^4 + > 0.172685158 * x^5 > > Rational minimax polynomials work better, but cost an extra divide. The best > > tactic for even greater accuracy is to range reduce further using P.T.Tang's > > semitable based range reduction for log() and spend a little longer in > reconstruction. > >  Robin Green. > > > >>Guillaume Provost wrote: >> >> >>>Robin, >>> >>> Thanks alot  this helps. (The Faster Math Functions paper in >>>particular). FYI, pow is actually the last function I was >>>implementing, not >>>the first  its for a PS2 port of a fairly large codebase, so I have >>>several >>>different usage cases. Btw, going through a natural logarithm does'nt >>>make >>>sense in this context, since you're losing accuracy needlessly  the >>>original code kept the 754 log2 format for a +/ 50% relative (or one >>>bit) >>>accuracy cap on 32bits values. >>> >>> example  on: >>> x^y = exp(y*ln(x)) >>> >>> you get 'exponentlevel perfect' accuracy with the relation : >>> >>> x^y = 2^(y * log2(x)) >>> >>> My issue more has to do with dealing with the mantissa. The >>>polynomial interpolation I was talking about was simply to nonlinearly >>>interpolate the mantissa component across two exponents, it basically >>>amounts to saying: >>> >>> 1.25 x 2^x ~= 1 x 2^(x + polylerp(1  1.25)) for some polynomial >>>interpolator that approximates a power function better than just a >>>lerp. It >>>also gets rid of function discontinuities when the mantissa changes >>>but not >>>the exponent value. >>> >>> Guillaume. >>> >>>Original Message >>>From: gdalgorithmslistadmin@... >>>[mailto:gdalgorithmslistadmin@...]On Behalf Of >>>robin_green@... >>>Sent: Tuesday, April 27, 2004 12:59 PM >>>To: gdalgorithmslist@... >>>Subject: [Algorithms] Re: Approximating the pow() function >>> >>> >>>Message: 16 >>>From: Guillaume Provost <Guillaume@...> >>>Date: Mon, 26 Apr 2004 15:20:35 0400 >>>Subject: [Algorithms] Approximating the pow() function >>> >>> >>>>Sorry for asking a really dumb question, but have any of you worked >>>>around >>> >>> >>> >>>>this issue? I want a cheap and fast approximation to the pow( ) >>>>function without going through the standard math libs (this needs to >>>>be platform independant / IEEE single precision floating point format). >>> >>> >>> >>>Well, if you're going to get into coding fast versions of the >>>mathematical >>>functions, starting with the single most difficult one to code >>>accurately is >>>a >>>great place to start! >>> >>> >>> >>> >>>>Unfortunately, the (relatively small) error introduced by the log base 2 >>> >>> >>>gets >>> >>> >>>>compounded when I compute the exponential portion. This results in a >>>>+50% >>>>(or one exponential bit) in relative accuracy when dealing with higher >>>>exponent values. >>> >>> >>> >>>Yup. In the book "Elementary Functions: Algorithms and >>>Implementations" by >>>JeanMichel Muller, he describes how bad the problem can be (p.178, >>>"Notes >>>on x^y") >>> >>> The power function F(x,y) = x^y is very difficult to implement >>> if we want good accuracy. A straightforward use of the relationship >>> >>> x^y = exp(y*ln(x)) >>> >>> is to be avoided. First, it will always produce NaNs for negative >>> values of x, although x^y is defined when x<0 and y is an integer. >>> Second, unless the intermediate calculations are performed with a >>> significantly larger precision, that formula may lead to very large >>> relative errors. Assume that ln(x) is computed with relative error >>> "r", that is the computed value oL of ln(x) satisfies: >>> >>> L = (1 + r) ln(x) >>> >>> If we neglect the error due to the implementation of the exponential >>> function itself, we find that the computed value of x^y will be: >>> >>> exp(y*L) >>> = exp(y*ln(x) + y*r*ln(x)) >>> = x^y * e^(r*y*ln(x)) >>> >>> Therefore the error on the result, >>> >>>  r*y*ln(x)  >>>  e  1  > r*y*ln(x) >>> >>> can be very large (FOOTNOTE: Some programming languages avoid this >>> problem by not offering function x^y. Of course, this is the best >>>way >>> to make sure that most programmers will use the bad solution >>> exp(y*ln(x)) ) >>> >>>He then goes on to show some especially bad results along the number line >>>(e.g. >>>5^441 has an error of 791 units_in_the_last_place (ulps), 56^156 has 1052 >>>ulps). >>>Basically, your lower bits are mush. The only way around this, he goes >>>on to >>> >>>prove, is to use more bits of accuracy in the intermediate ln() >>>calculation: >>> >>> Thus, to get a correct result, we must get ln(x) with a number of >>> additional bits of precision that are slightly more than the number >>> of exponent bits. >>> >>>So for IEEE754 values, you'll need to calculate ln(x) to at least 24+8=32 >>>bits of mantissa. How is this done? By splitting the result across two >>>floating >>>point values, one carrying the upper bits and the remainder carrying >>>the lower >>>bits. >>> >>> ln(x) = a + b >>> >>> >>> >>>>Is there any other way to cheaply approximate pow( ) in a more precise >>> >>> >>>way? >>> >>> >>>>(Code appended). I thought about using a polynomial to interpolate the >>>>mantissa portion across exponent values, but that only decreases the >>> >>> >>>average >>> >>> >>>>error  not the worst case error. >>> >>> >>> >>>I hope you can see that the answer to your question is no, there >>>really is >>>no way to accurately *and* quickly approximate the power function. >>>This leads >>>me to ask the killer question  *why* do you need the power function >>>exactly? >>>Are you looking for a fast way to shape specular reflection lobes? If >>>you are, >>>then there are other functions you can use: integer powers, polynomial >>>approximations or rational functions. >>> >>>Christopher Schlick in Graphics Gems 4 has a paper on "A Fast >>>Alternative to >>> >>>Phong's Specular Model" (p.385) where her proposes the function: >>> >>> S(n,t) = t / (n  n*t + t) >>> >>>where t varies from [0,1] and n is the "shaping power". He also has >>>faster versions of bias() and gain() later in the book, again using a >>>small >>>rational approximation. Restricting yourself to integer powers can >>>give fastish >>>results: >>> >>> float powi(float x,int N) >>> { >>> float y,w; >>> bool ns = false; >>> bool xs = false; >>> if(N<0) { >>> ns = true; >>> N = N; >>> } >>> if(x<0.0f) { >>> xs = true; >>> x = x; >>> } >>> if(N&1) y = x; >>> else { >>> y = 1.0f; >>> xs = false; >>> } >>> w = x; N >>= 1; >>> while(N) { >>> w = w * w; >>> if(N&1) y *= w; >>> N >>= 1; >>> } >>> if(xs) y = y; >>> if(ns) y = 1.0f/y; >>> return y; >>> } >>> >>>as can a rather nice floatingpoint hack, courtesy Matthew Jones of >>>Infogrames, where you take a float, pretend that it's an integer and >>>covert the result >>>to a float. A magic constant is subtracted and the result is converted >>>back to an >>> >>>integer. The resulting bit pattern is used as a float. Confused yet? >>>Check >>>out the last section in my GDC talk about Faster Math Functions for a >>>better explanation: >>> >>> http://www.research.scea.com/gdc2003/fastmathfunctions.html >>> >>> >>> Robin Green >>> R&D Programmer >>> SCEA >>> >>> >>> >>> >>>This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek >>>For a limited time only, get FREE Ground shipping on all orders of $35 >>>or more. Hurry up and shop folks, this offer expires April 30th! >>>http://www.thinkgeek.com/freeshipping/?cpg=12297 >>>_______________________________________________ >>>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: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > 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: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > 
From: Guillaume Provost <Guillaume@ps...>  20040429 20:34:42

Robin, You rock. Thank you  it works like a charm. Did you get the minimax coefficients through a general purpose optimizer or did you derive them analytically? float approxlog(float log) { long& nat = ((*(long *)&log)); float exp2 = ((nat & 0x7f800000) >> 23)  127; // interpolate the mantissa using a minimax polynomial float mantissa = float(nat & 0x007fffff) * inverseMantissa; float mantissa2 = mantissa * mantissa; float mantissa3 = mantissa2 * mantissa; float mantissa4 = mantissa2 * mantissa2; float mantissa5 = mantissa3 * mantissa2; float loge_mantissa = mantissa  0.495858579 * (mantissa2) + 0.236771441 * mantissa3 + 0.0946189007 * mantissa4  0.172685158 * mantissa5; #ifdef _DEBUG printf ("exp:%f\napx:%f\napm:%f\n\n", logf(log), exp2 * log2_e, exp2 * log2_e + loge_mantissa); #endif return exp2 * log2_e + loge_mantissa; }; Guillaume. P.S. David Wu says its nice to see you're still contributing to the newsgroups. I agree ;) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of robin_green@... Sent: Thursday, April 29, 2004 2:50 PM To: gdalgorithmslist@... Cc: Guillaume Provost Subject: Re: [Algorithms] Approximating the pow() function Oops. Sent too soon. (If I may, I'll forward this to the list too) I am kindof assuming that you'll be coding the functions using range reduction plus a polynomial approximation. If that is the case then range reducing to base 2 or to base "e" makes no difference to the number of instructions used. So, you're using the floatingpoint exponent as a first approximation to the log of the number. Good, let's see what we can do about the mantissa bits: ln(2^x * m) = x*ln(2) + ln(m) As the mantissa only varies between [1.0, 2.0), that's the polynomial you'll need to approximate. A quick'n'dirty method is to use Borchardt's Algorithm over that range: ln(x) ~= 6*(x1) / ( x + 1 + 4 * sqrt(x) ) or use Maple to generate a minimax polynomial over that range, like this one: ln(1+x) ~= 1.0 * x + 0.495858579 * x^2 + 0.236771441 * x^3 + 0.0946189007 * x^4 + 0.172685158 * x^5 Rational minimax polynomials work better, but cost an extra divide. The best tactic for even greater accuracy is to range reduce further using P.T.Tang's semitable based range reduction for log() and spend a little longer in reconstruction.  Robin Green. > Guillaume Provost wrote: > >> Robin, >> >> Thanks alot  this helps. (The Faster Math Functions paper in >> particular). FYI, pow is actually the last function I was >> implementing, not >> the first  its for a PS2 port of a fairly large codebase, so I have >> several >> different usage cases. Btw, going through a natural logarithm does'nt >> make >> sense in this context, since you're losing accuracy needlessly  the >> original code kept the 754 log2 format for a +/ 50% relative (or one >> bit) >> accuracy cap on 32bits values. >> >> example  on: >> x^y = exp(y*ln(x)) >> >> you get 'exponentlevel perfect' accuracy with the relation : >> >> x^y = 2^(y * log2(x)) >> >> My issue more has to do with dealing with the mantissa. The >> polynomial interpolation I was talking about was simply to nonlinearly >> interpolate the mantissa component across two exponents, it basically >> amounts to saying: >> >> 1.25 x 2^x ~= 1 x 2^(x + polylerp(1  1.25)) for some polynomial >> interpolator that approximates a power function better than just a >> lerp. It >> also gets rid of function discontinuities when the mantissa changes >> but not >> the exponent value. >> >> Guillaume. >> >> Original Message >> From: gdalgorithmslistadmin@... >> [mailto:gdalgorithmslistadmin@...]On Behalf Of >> robin_green@... >> Sent: Tuesday, April 27, 2004 12:59 PM >> To: gdalgorithmslist@... >> Subject: [Algorithms] Re: Approximating the pow() function >> >> >> Message: 16 >> From: Guillaume Provost <Guillaume@...> >> Date: Mon, 26 Apr 2004 15:20:35 0400 >> Subject: [Algorithms] Approximating the pow() function >> >>> Sorry for asking a really dumb question, but have any of you worked >>> around >> >> >> >>> this issue? I want a cheap and fast approximation to the pow( ) >>> function without going through the standard math libs (this needs to >>> be platform independant / IEEE single precision floating point format). >> >> >> >> Well, if you're going to get into coding fast versions of the >> mathematical >> functions, starting with the single most difficult one to code >> accurately is >> a >> great place to start! >> >> >> >>> Unfortunately, the (relatively small) error introduced by the log base 2 >> >> >> gets >> >>> compounded when I compute the exponential portion. This results in a >>> +50% >>> (or one exponential bit) in relative accuracy when dealing with higher >>> exponent values. >> >> >> >> Yup. In the book "Elementary Functions: Algorithms and >> Implementations" by >> JeanMichel Muller, he describes how bad the problem can be (p.178, >> "Notes >> on x^y") >> >> The power function F(x,y) = x^y is very difficult to implement >> if we want good accuracy. A straightforward use of the relationship >> >> x^y = exp(y*ln(x)) >> >> is to be avoided. First, it will always produce NaNs for negative >> values of x, although x^y is defined when x<0 and y is an integer. >> Second, unless the intermediate calculations are performed with a >> significantly larger precision, that formula may lead to very large >> relative errors. Assume that ln(x) is computed with relative error >> "r", that is the computed value oL of ln(x) satisfies: >> >> L = (1 + r) ln(x) >> >> If we neglect the error due to the implementation of the exponential >> function itself, we find that the computed value of x^y will be: >> >> exp(y*L) >> = exp(y*ln(x) + y*r*ln(x)) >> = x^y * e^(r*y*ln(x)) >> >> Therefore the error on the result, >> >>  r*y*ln(x)  >>  e  1  > r*y*ln(x) >> >> can be very large (FOOTNOTE: Some programming languages avoid this >> problem by not offering function x^y. Of course, this is the best >> way >> to make sure that most programmers will use the bad solution >> exp(y*ln(x)) ) >> >> He then goes on to show some especially bad results along the number line >> (e.g. >> 5^441 has an error of 791 units_in_the_last_place (ulps), 56^156 has 1052 >> ulps). >> Basically, your lower bits are mush. The only way around this, he goes >> on to >> >> prove, is to use more bits of accuracy in the intermediate ln() >> calculation: >> >> Thus, to get a correct result, we must get ln(x) with a number of >> additional bits of precision that are slightly more than the number >> of exponent bits. >> >> So for IEEE754 values, you'll need to calculate ln(x) to at least 24+8=32 >> bits of mantissa. How is this done? By splitting the result across two >> floating >> point values, one carrying the upper bits and the remainder carrying >> the lower >> bits. >> >> ln(x) = a + b >> >> >>> Is there any other way to cheaply approximate pow( ) in a more precise >> >> >> way? >> >>> (Code appended). I thought about using a polynomial to interpolate the >>> mantissa portion across exponent values, but that only decreases the >> >> >> average >> >>> error  not the worst case error. >> >> >> >> I hope you can see that the answer to your question is no, there >> really is >> no way to accurately *and* quickly approximate the power function. >> This leads >> me to ask the killer question  *why* do you need the power function >> exactly? >> Are you looking for a fast way to shape specular reflection lobes? If >> you are, >> then there are other functions you can use: integer powers, polynomial >> approximations or rational functions. >> >> Christopher Schlick in Graphics Gems 4 has a paper on "A Fast >> Alternative to >> >> Phong's Specular Model" (p.385) where her proposes the function: >> >> S(n,t) = t / (n  n*t + t) >> >> where t varies from [0,1] and n is the "shaping power". He also has >> faster versions of bias() and gain() later in the book, again using a >> small >> rational approximation. Restricting yourself to integer powers can >> give fastish >> results: >> >> float powi(float x,int N) >> { >> float y,w; >> bool ns = false; >> bool xs = false; >> if(N<0) { >> ns = true; >> N = N; >> } >> if(x<0.0f) { >> xs = true; >> x = x; >> } >> if(N&1) y = x; >> else { >> y = 1.0f; >> xs = false; >> } >> w = x; N >>= 1; >> while(N) { >> w = w * w; >> if(N&1) y *= w; >> N >>= 1; >> } >> if(xs) y = y; >> if(ns) y = 1.0f/y; >> return y; >> } >> >> as can a rather nice floatingpoint hack, courtesy Matthew Jones of >> Infogrames, where you take a float, pretend that it's an integer and >> covert the result >> to a float. A magic constant is subtracted and the result is converted >> back to an >> >> integer. The resulting bit pattern is used as a float. Confused yet? >> Check >> out the last section in my GDC talk about Faster Math Functions for a >> better explanation: >> >> http://www.research.scea.com/gdc2003/fastmathfunctions.html >> >> >>  Robin Green >> R&D Programmer >> SCEA >> >> >> >>  >> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek >> For a limited time only, get FREE Ground shipping on all orders of $35 >> or more. Hurry up and shop folks, this offer expires April 30th! >> http://www.thinkgeek.com/freeshipping/?cpg=12297 >> _______________________________________________ >> 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Chapman, Greg <gchapman@ea...>  20040429 19:07:32

Just some vector unit fun  there's an error of one bit, so a value multiplied by one is not promised to be the same value. There are some easy workarounds, though. It causes all sorts of fun while track bugs if you're not aware of the problem while writing your microcode. Original Message Are you saying that the ps2 comes up with different results for the exact same computation? On which processor, the ee or the vu's? I'd be interested to know if this algorithm fails on that platform. 
From: <robin_green@pl...>  20040429 18:50:34

Oops. Sent too soon. (If I may, I'll forward this to the list too) I am kindof assuming that you'll be coding the functions using range reduction plus a polynomial approximation. If that is the case then range reducing to base 2 or to base "e" makes no difference to the number of instructions used. So, you're using the floatingpoint exponent as a first approximation to the log of the number. Good, let's see what we can do about the mantissa bits: ln(2^x * m) = x*ln(2) + ln(m) As the mantissa only varies between [1.0, 2.0), that's the polynomial you'll need to approximate. A quick'n'dirty method is to use Borchardt's Algorithm over that range: ln(x) ~= 6*(x1) / ( x + 1 + 4 * sqrt(x) ) or use Maple to generate a minimax polynomial over that range, like this one: ln(1+x) ~= 1.0 * x + 0.495858579 * x^2 + 0.236771441 * x^3 + 0.0946189007 * x^4 + 0.172685158 * x^5 Rational minimax polynomials work better, but cost an extra divide. The best tactic for even greater accuracy is to range reduce further using P.T.Tang's semitable based range reduction for log() and spend a little longer in reconstruction.  Robin Green. > Guillaume Provost wrote: > >> Robin, >> >> Thanks alot  this helps. (The Faster Math Functions paper in >> particular). FYI, pow is actually the last function I was >> implementing, not >> the first  its for a PS2 port of a fairly large codebase, so I have >> several >> different usage cases. Btw, going through a natural logarithm does'nt >> make >> sense in this context, since you're losing accuracy needlessly  the >> original code kept the 754 log2 format for a +/ 50% relative (or one >> bit) >> accuracy cap on 32bits values. >> >> example  on: >> x^y = exp(y*ln(x)) >> >> you get 'exponentlevel perfect' accuracy with the relation : >> >> x^y = 2^(y * log2(x)) >> >> My issue more has to do with dealing with the mantissa. The >> polynomial interpolation I was talking about was simply to nonlinearly >> interpolate the mantissa component across two exponents, it basically >> amounts to saying: >> >> 1.25 x 2^x ~= 1 x 2^(x + polylerp(1  1.25)) for some polynomial >> interpolator that approximates a power function better than just a >> lerp. It >> also gets rid of function discontinuities when the mantissa changes >> but not >> the exponent value. >> >> Guillaume. >> >> Original Message >> From: gdalgorithmslistadmin@... >> [mailto:gdalgorithmslistadmin@...]On Behalf Of >> robin_green@... >> Sent: Tuesday, April 27, 2004 12:59 PM >> To: gdalgorithmslist@... >> Subject: [Algorithms] Re: Approximating the pow() function >> >> >> Message: 16 >> From: Guillaume Provost <Guillaume@...> >> Date: Mon, 26 Apr 2004 15:20:35 0400 >> Subject: [Algorithms] Approximating the pow() function >> >>> Sorry for asking a really dumb question, but have any of you worked >>> around >> >> >> >>> this issue? I want a cheap and fast approximation to the pow( ) >>> function without going through the standard math libs (this needs to >>> be platform independant / IEEE single precision floating point format). >> >> >> >> Well, if you're going to get into coding fast versions of the >> mathematical >> functions, starting with the single most difficult one to code >> accurately is >> a >> great place to start! >> >> >> >>> Unfortunately, the (relatively small) error introduced by the log base 2 >> >> >> gets >> >>> compounded when I compute the exponential portion. This results in a >>> +50% >>> (or one exponential bit) in relative accuracy when dealing with higher >>> exponent values. >> >> >> >> Yup. In the book "Elementary Functions: Algorithms and >> Implementations" by >> JeanMichel Muller, he describes how bad the problem can be (p.178, >> "Notes >> on x^y") >> >> The power function F(x,y) = x^y is very difficult to implement >> if we want good accuracy. A straightforward use of the relationship >> >> x^y = exp(y*ln(x)) >> >> is to be avoided. First, it will always produce NaNs for negative >> values of x, although x^y is defined when x<0 and y is an integer. >> Second, unless the intermediate calculations are performed with a >> significantly larger precision, that formula may lead to very large >> relative errors. Assume that ln(x) is computed with relative error >> "r", that is the computed value oL of ln(x) satisfies: >> >> L = (1 + r) ln(x) >> >> If we neglect the error due to the implementation of the exponential >> function itself, we find that the computed value of x^y will be: >> >> exp(y*L) >> = exp(y*ln(x) + y*r*ln(x)) >> = x^y * e^(r*y*ln(x)) >> >> Therefore the error on the result, >> >>  r*y*ln(x)  >>  e  1  > r*y*ln(x) >> >> can be very large (FOOTNOTE: Some programming languages avoid this >> problem by not offering function x^y. Of course, this is the best >> way >> to make sure that most programmers will use the bad solution >> exp(y*ln(x)) ) >> >> He then goes on to show some especially bad results along the number line >> (e.g. >> 5^441 has an error of 791 units_in_the_last_place (ulps), 56^156 has 1052 >> ulps). >> Basically, your lower bits are mush. The only way around this, he goes >> on to >> >> prove, is to use more bits of accuracy in the intermediate ln() >> calculation: >> >> Thus, to get a correct result, we must get ln(x) with a number of >> additional bits of precision that are slightly more than the number >> of exponent bits. >> >> So for IEEE754 values, you'll need to calculate ln(x) to at least 24+8=32 >> bits of mantissa. How is this done? By splitting the result across two >> floating >> point values, one carrying the upper bits and the remainder carrying >> the lower >> bits. >> >> ln(x) = a + b >> >> >>> Is there any other way to cheaply approximate pow( ) in a more precise >> >> >> way? >> >>> (Code appended). I thought about using a polynomial to interpolate the >>> mantissa portion across exponent values, but that only decreases the >> >> >> average >> >>> error  not the worst case error. >> >> >> >> I hope you can see that the answer to your question is no, there >> really is >> no way to accurately *and* quickly approximate the power function. >> This leads >> me to ask the killer question  *why* do you need the power function >> exactly? >> Are you looking for a fast way to shape specular reflection lobes? If >> you are, >> then there are other functions you can use: integer powers, polynomial >> approximations or rational functions. >> >> Christopher Schlick in Graphics Gems 4 has a paper on "A Fast >> Alternative to >> >> Phong's Specular Model" (p.385) where her proposes the function: >> >> S(n,t) = t / (n  n*t + t) >> >> where t varies from [0,1] and n is the "shaping power". He also has >> faster versions of bias() and gain() later in the book, again using a >> small >> rational approximation. Restricting yourself to integer powers can >> give fastish >> results: >> >> float powi(float x,int N) >> { >> float y,w; >> bool ns = false; >> bool xs = false; >> if(N<0) { >> ns = true; >> N = N; >> } >> if(x<0.0f) { >> xs = true; >> x = x; >> } >> if(N&1) y = x; >> else { >> y = 1.0f; >> xs = false; >> } >> w = x; N >>= 1; >> while(N) { >> w = w * w; >> if(N&1) y *= w; >> N >>= 1; >> } >> if(xs) y = y; >> if(ns) y = 1.0f/y; >> return y; >> } >> >> as can a rather nice floatingpoint hack, courtesy Matthew Jones of >> Infogrames, where you take a float, pretend that it's an integer and >> covert the result >> to a float. A magic constant is subtracted and the result is converted >> back to an >> >> integer. The resulting bit pattern is used as a float. Confused yet? >> Check >> out the last section in my GDC talk about Faster Math Functions for a >> better explanation: >> >> http://www.research.scea.com/gdc2003/fastmathfunctions.html >> >> >>  Robin Green >> R&D Programmer >> SCEA >> >> >> >>  >> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek >> For a limited time only, get FREE Ground shipping on all orders of $35 >> or more. Hurry up and shop folks, this offer expires April 30th! >> http://www.thinkgeek.com/freeshipping/?cpg=12297 >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> > 
From: Hamilton Feltman <hfeltman@lu...>  20040429 18:45:22

Are you saying that the ps2 comes up with different results for the = exact same computation? On which processor, the ee or the vu's? I'd be = interested to know if this algorithm fails on that platform. >=20 > Hehe. So I still win the second half of the argument then? :) >=20 > TomF. >=20 > >=20 > > > Original Message > > > From: Tom Forsyth [mailto:tom.forsyth@...]=20 > > > Sent: 29. huhtikuuta 2004 9:38 > > > To: gdalgorithmslist@... > > > Subject: RE: [Algorithms] EPA : working ? > > >=20 > > > The pragmas are not terribly portable are they? The real=20 > > > solution is to carbetbomb the thing with the "volatile" keyword. > > >=20 > > > Oh, and you all knew the cool thing about the random=20 > > > bottombit of mantissa on the PS2 didn't you? Good, just=20 > > > checking. I'm just saying  testing for equality (or=20 > > > inequality) in any way shape or form with floatingpoint=20 > > > numbers is just asking for trouble. Maybe not today. Maybe=20 > > > not tomorrow, but soon and for the rest of your life. > > >=20 > > > TomF. > > >=20 
From: Joe Ante <joe@ut...>  20040429 18:41:07

Hi, I want to convert some euler based rotation hermite splines into quaternion based hermite splines. My unenlightened approach would be: 1) Split all euler based rotation so the x, y, z rotation curves have keyframes at the exact same positions. 2) Iterate through all keys. Take the tangents and key value from each rotation curve and convert it into a quaternion tangent and key value. I cant figure out how to solve the first problem. Basically how do I insert a keyframe which will not change the appearance of the curve? Is it enough to calculate the tangent at the position I want to insert the keyframe and use that as the tangent? How do I calculate the tangent at an arbitrary position in the curve? I am also not sure if the method would work correctly at all. I mean interpolation between euler angles and quaternions will most likely be different because well the interpolation method is just different. Is this a problem visible in a game? What are your experiences? Or are you forcing artists to use quaternion splines for animation? Joachim Ante http://www.otee.dk 
From: Emanuele Salvucci <info@fo...>  20040429 18:13:14

That's nice too...indeed... could be a good solution, but it's not that. Best, Emanuele.  Original Message  From: "Gribb, Gil" <ggribb@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 5:32 PM Subject: RE: [Algorithms] Stripes  how efficient and useful they really are? Chroma on the verts. Luminance in an A8 lightmap. Not a secret. Gil Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Emanuele Salvucci Sent: Thursday, April 29, 2004 9:59 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Stripes  how efficient and useful they really are? I wasn't aware of the other techniques. I did a fast one in 1 pass, but unfortunately I can't tell as I'd break confidential information agreements with my exemployer. I can say it's nothing particularly complicated, technically...no particular algorithm and such, but it does the job and it looks exactly like a PC "modulate". You may lose something in color precision (RGB values), but it's not something you'd spot playing the game...if you played Broken Sword 3 for PS2 you've already seen it (Monte Carlo radiosity 24 bit lightmaps). It was a very simple intuition. ;) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 2:47 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they really are? > On 29/04/2004 13:12:11 gdalgorithmslistadmin wrote: > > >It's doable in 1 pass... colors will be nothing more and nothing less > than > > the original 24 bit lightmap. ;) > > I did hear a way of doing it by storing another offscreen target which you > draw all your > light maps into (coloured, whatever) and then do one final composite > multiply with > the whole buffer over the screen. But its pretty slow due to the weird > things you need > to do to get each colour channel into the alpha where the multiply can > happen. And > who has the video mem available for that? > > The only other way I know is by using a approximation where you multiply > using > alpha and subtract in the colour channels to give a half way house between > the > two. > > If you know better than that, do tell ;) > > Cheers, Paul. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > > > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=ick _______________________________________________ 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...>  20040429 15:32:30

Chroma on the verts. Luminance in an A8 lightmap. Not a secret. Gil Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Emanuele Salvucci Sent: Thursday, April 29, 2004 9:59 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Stripes  how efficient and useful they really are? I wasn't aware of the other techniques. I did a fast one in 1 pass, but unfortunately I can't tell as I'd break confidential information agreements with my exemployer. I can say it's nothing particularly complicated, technically...no = particular algorithm and such, but it does the job and it looks exactly like a PC "modulate". You may lose something in color precision (RGB values), but it's not something you'd spot playing the game...if you played Broken Sword 3 for = PS2 you've already seen it (Monte Carlo radiosity 24 bit lightmaps). It was a very simple intuition. ;) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 2:47 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they really are? > On 29/04/2004 13:12:11 gdalgorithmslistadmin wrote: > > >It's doable in 1 pass... colors will be nothing more and nothing less > than > > the original 24 bit lightmap. ;) > > I did hear a way of doing it by storing another offscreen target which = you > draw all your > light maps into (coloured, whatever) and then do one final composite > multiply with > the whole buffer over the screen. But its pretty slow due to the weird > things you need > to do to get each colour channel into the alpha where the multiply can > happen. And > who has the video mem available for that? > > The only other way I know is by using a approximation where you = multiply > using > alpha and subtract in the colour channels to give a half way house = between > the > two. > > If you know better than that, do tell ;) > > Cheers, Paul. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > > > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle = 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. = Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Emanuele Salvucci <info@fo...>  20040429 15:03:24

I wasn't aware of the other techniques. I did a fast one in 1 pass, but unfortunately I can't tell as I'd break confidential information agreements with my exemployer. I can say it's nothing particularly complicated, technically...no particular algorithm and such, but it does the job and it looks exactly like a PC "modulate". You may lose something in color precision (RGB values), but it's not something you'd spot playing the game...if you played Broken Sword 3 for PS2 you've already seen it (Monte Carlo radiosity 24 bit lightmaps). It was a very simple intuition. ;) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 2:47 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they really are? > On 29/04/2004 13:12:11 gdalgorithmslistadmin wrote: > > >It's doable in 1 pass... colors will be nothing more and nothing less > than > > the original 24 bit lightmap. ;) > > I did hear a way of doing it by storing another offscreen target which you > draw all your > light maps into (coloured, whatever) and then do one final composite > multiply with > the whole buffer over the screen. But its pretty slow due to the weird > things you need > to do to get each colour channel into the alpha where the multiply can > happen. And > who has the video mem available for that? > > The only other way I know is by using a approximation where you multiply > using > alpha and subtract in the colour channels to give a half way house between > the > two. > > If you know better than that, do tell ;) > > Cheers, Paul. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > > > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Alen Ladavac <alenlml@cr...>  20040429 14:41:33

> 1 eliminate duplicates: [snip] > So this is a no brainer. Agreed. > 2 identify coplanar contact points: What exactly would classify as coplanar contact points? You can't remove any of four points if box lies on a plane, e.g., right? >this can be done quite cheaply as we keep both tri and sep normals in a >boxtri contact: the trinormal and the sep normal. If one is careful with >how the trinorm is calc'd then it should be possible to rely on >Dot(tri.norm, tripoint) as a measure of coplanarity  certain "coplanar >contacts" can be dumped with impunity. for eg below Is this also not a finished sentence? > 3 convex hull points: Clearly one can compute a 2D convex hull of the contacts (once grouped as in 2) and at least in some cases discard everything except those hull points. Yes, that would be an excellent great simplification. Speedup might be questionable, but stability could be improved a bit with it. Perhaps. >on a good day (not always) this will make a contact set with an unequivocal >separating plane. If the convex hull contains only box surface points then >the whole lot can be discarded and the contact can be recomputed as a >box<>plane contact. But, you cannot really do that with one contact. Can you? It would need at least 4 points to balance the box properly. >These are the sort of avenues I've been exploring, but there are lots of >gotchas  penetration is one area that needs to be addressed. In general I >think one can get away with a pretty redundant contact set (depending on >solution method) but once you start filtering a lot of special cases can >start being missed  so on a general note as is often the case the less one >can get away with, the better. What with penetration? Btw, this still doesn't tack the problem at edges, does it? :/ Alen 
From: Rok Erjavec <rok@si...>  20040429 13:38:31

Who wants shadows from lightmaps when I can just use static volumes for = the entire scene :D Now if I could only get rid of those pesky tree shadow maps too...  Original Message =20 From: Emanuele Salvucci=20 To: gdalgorithmslist@...=20 Sent: Thursday, April 29, 2004 8:17 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they = really are? Well, it always depends on what you want to achieve even on PS2. As a general rule...at least for what I observed, 24 bit lightmaps are = not very used on PS2... even though they could be. And yes, PS2 developers prefer vertex lighting... but I don't believe = *they* prefer it..it's just the hardware it's not very texturefriendly, = but rather vertexfriendly. Vertex lighting obviously won't do much "as lighting", IMHO... = everything looks often very flat on the environments... and if you want = to make shadows that way, you split by hand...or waste time on some = complicated algorithm that splits polygons according to incoming = illumination. (as Lightscape did...) FYI, multiple UV sets and 24bit lightmaps have been used in Broken = Sword 3 even on PS2... but you have to plan this since the very = beginning as the art dept. has to follow a very different workflow = compared to vertex lighting. Best, Emanuele Salvucci MayaLightwave Game Technical Artist Lscript developer http://www.forwardgames.com emanueles@... "#3. He causes things to look different so it would appear time has = passed." =   Original Message =20 From: Andrey Iones=20 To: gdalgorithmslist@...=20 Sent: Thursday, April 29, 2004 12:19 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they = really are? Speaking of multiple UV sets.=20 As far as I understand lightmaps are not really that useful on PS2, = and environment=20 lighting is usually done using vertex lighting. Is this true?=20 Thanks,=20 Andrey.=20 Emanuele Salvucci wrote:=20 Sure, but I wasn't talking characters.=20 It's usually environments that suffer from poor optimizations and = especially=20 when lightmapped (2 UV set for each material/object).=20 Moreover, once your environment objects are mappingoptimized = they're still=20 subject to any further "algorithmic" optimization...as this is not = any=20 compression technique which excludes others. Obviously if you = optimize the=20 "source" already by a factor of 3... well, you can see the = advantage. ;)=20 Best,=20 Emanuele.=20  Original Message =20 From: "Tom Forsyth" <tom.forsyth@...>=20 To: <gdalgorithmslist@...>=20 Sent: Thursday, April 29, 2004 8:45 AM=20 Subject: RE: [Algorithms] Stripes  how efficient and useful they = really=20 are?=20 > > On PC, we've noticed that manually optimized UV mapping with=20 > > 2 UV sets on=20 > > each object can save up to 2.7 times the number of total=20 > > vertices compared=20 > > to the worst case scenario (i.e. 3 vertices/triangle).=20 > > (also, with this optimization, indexed arrays and strips = perform quite=20 > > similarly, from a vertexcount point of view)=20 >=20 > That's not actually very good. With a good vertexcache = optimiser (e.g.=20 the=20 > D3DX one) you should be getting down to around 0.7 verts/tri for = something=20 > like a 10k poly character mesh. Which is a factor of over 4.=20 >=20 > TomF.=20 >=20 >=20 > > Original Message=20 > > From: gdalgorithmslistadmin@...=20 > > [mailto:gdalgorithmslistadmin@...] On=20 > > Behalf Of Emanuele Salvucci=20 > > Sent: 28 April 2004 03:12=20 > > To: gdalgorithmslist@...=20 > > Subject: Re: [Algorithms] Stripes  how efficient and useful=20 > > they really are?=20 > >=20 > >=20 > > For what I've experienced on PS2... (but it's a rather=20 > > general obvservation)=20 > > strips are useful only if you have wise artists.=20 > > If you also have more than one UV set on your objects,=20 > > artists will have to=20 > > be doublewise.=20 > > (I'm talking environment graphics only)=20 > >=20 > > Since strips break also according to material changes and UV=20 > > tiling/continuity this is going to be the main reason for=20 > > "short strips" and=20 > > high vertexcount in "practical life" situations.=20 > >=20 > > If artists make a good job on continuous UV mapping you can=20 > > save tons of=20 > > vertices.=20 > > But if meshes' topology and artistic design don't marry with=20 > > continuous UV=20 > > mapping, then I believe you'd be better off don't wasting=20 > > extra work on=20 > > strips...the actual gain wouldn't be worth the effort.=20 > >=20 > > On PC, we've noticed that manually optimized UV mapping with=20 > > 2 UV sets on=20 > > each object can save up to 2.7 times the number of total=20 > > vertices compared=20 > > to the worst case scenario (i.e. 3 vertices/triangle).=20 > > (also, with this optimization, indexed arrays and strips = perform quite=20 > > similarly, from a vertexcount point of view)=20 > >=20 > > The point is, frequent material changes and especially = unoptimized=20 > > automatic mapping for lightmaps can easily become the worst = case=20 > > scenario...leading to gigantic amounts of vertices for a few = tris.=20 > >=20 > > ...you might want to have a brainstorm with your lead artist=20 > > (or your more=20 > > experienced technical artist..since often they're not the=20 > > same person ;))=20 > > ...and see how he can help on this.=20 > >=20 > >=20 > > Best,=20 > >=20 > > Emanuele.=20 > >=20 > >=20 > >  Original Message =20 > > From: "Andrey Iones" <iones@...>=20 > > To: <gdalgorithmslist@...>=20 > > Sent: Tuesday, April 27, 2004 12:05 PM=20 > > Subject: [Algorithms] Stripes  how efficient and useful they=20 > > really are?=20 > >=20 > >=20 > > > Hello everybody,=20 > > >=20 > > > Could you share you experience on using stripified geometry=20 > > for rendering?=20 > > > I am particularly interested on stripe usefulness on PS2=20 > > platform. So far=20 > > I've heard=20 > > >=20 > > > mixed opinions on this  some people say we HAVE TO use=20 > > stripes 'cause=20 > > > they conserve VU memory and improve performance; others say=20 > > > we would be better of using indexed primitives because it = simplifies=20 > > building the=20 > > > geometry, and that level geometry is not really easily = stripifiable.=20 > > > Maybe the answer is to use stripes for character models=20 > > (which should be=20 > > better=20 > > > stripifiable), and use indexed primitives for level = geometry?=20 > > >=20 > > > What do you people think?=20 > > >=20 > > > Thanks,=20 > > >=20 > > > Andrey.=20 > > >=20 > > > =20 > > > Andrey Iones=20 > > > Project Leader PhD in Computer Science=20 > > > http://www.saber3d.com=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > This SF.net email is sponsored by: The Robotic Monkeys at = ThinkGeek=20 > > > For a limited time only, get FREE Ground shipping on all=20 > > orders of $35=20 > > > or more. Hurry up and shop folks, this offer expires April = 30th!=20 > > > http://www.thinkgeek.com/freeshipping/?cpg=3D12297=20 > > > _______________________________________________=20 > > > GDAlgorithmslist mailing list=20 > > > GDAlgorithmslist@...=20 > > > = https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 > > > Archives:=20 > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 = > > >=20 > >=20 > >=20 > >=20 > > =20 > > This SF.Net email is sponsored by: Oracle 10g=20 > > Get certified on the hottest thing ever to hit the market...=20 > > Oracle 10g.=20 > > Take an Oracle 10g class now, and we'll give you the exam = FREE.=20 > > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 > > _______________________________________________=20 > > GDAlgorithmslist mailing list=20 > > GDAlgorithmslist@...=20 > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist = > > Archives:=20 > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 > >=20 >=20 >=20 >=20 > =20 > This SF.Net email is sponsored by: Oracle 10g=20 > Get certified on the hottest thing ever to hit the market... = Oracle 10g.=20 > Take an Oracle 10g class now, and we'll give you the exam FREE.=20 > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 > _______________________________________________=20 > GDAlgorithmslist mailing list=20 > GDAlgorithmslist@...=20 > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 > Archives:=20 > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 >=20 =20 This SF.Net email is sponsored by: Oracle 10g=20 Get certified on the hottest thing ever to hit the market... = Oracle 10g.=20 Take an Oracle 10g class now, and we'll give you the exam FREE.=20 http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 _______________________________________________=20 GDAlgorithmslist mailing list=20 GDAlgorithmslist@...=20 https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 Archives:=20 http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 =20 Andrey Iones=20 Project Leader PhD in Computer Science=20 http://www.saber3d.com=20 =20 
From: <Paul_Firth@sc...>  20040429 12:47:52

On 29/04/2004 13:12:11 gdalgorithmslistadmin wrote: >It's doable in 1 pass... colors will be nothing more and nothing less than > the original 24 bit lightmap. ;) I did hear a way of doing it by storing another offscreen target which you draw all your light maps into (coloured, whatever) and then do one final composite multiply with the whole buffer over the screen. But its pretty slow due to the weird things you need to do to get each colour channel into the alpha where the multiply can happen. And who has the video mem available for that? The only other way I know is by using a approximation where you multiply using alpha and subtract in the colour channels to give a half way house between the two. If you know better than that, do tell ;) Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** SCEE 2004 
From: Emanuele Salvucci <info@fo...>  20040429 12:12:25

It's doable in 1 pass... colors will be nothing more and nothing less than the original 24 bit lightmap. ;) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 12:52 PM Subject: RE: [Algorithms] Stripes  how efficient and useful they really are? > On 29/04/2004 11:45:21 gdalgorithmslistadmin wrote: > > >> >Speaking of multiple UV sets. > > > > As far as I understand lightmaps are not really that useful > > > on PS2, and > > > > environment > > > > lighting is usually done using vertex lighting. Is this true? > > > > > > Usually yes. Lightmaps are tricky because there is no colour src*dst > > > blending mode on ps2. You can > > > do greyscale lightmaps though and there are approximations to colour > > > src*dst which work quite > > > nicely. Look on the ps2 newsgroups for more details. > > > > Surely that should read "there is no single pass colour src*dst blending > > mode on the ps2" ??? > > Not really. Since the hardware doesn't have that blending mode and has > internally > no concept of passes, my statement holds. > > What you do in multiple passes is up to you, and yes you can "fake" > coloured lightmaps > by doing three passes with colour write disabled for the correct colour. > But who > wants to be doing three passes? :) > > Cheers, Paul. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > > > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Emanuele Salvucci <info@fo...>  20040429 11:17:48

Well, it always depends on what you want to achieve even on PS2. As a general rule...at least for what I observed, 24 bit lightmaps are = not very used on PS2... even though they could be. And yes, PS2 developers prefer vertex lighting... but I don't believe = *they* prefer it..it's just the hardware it's not very texturefriendly, = but rather vertexfriendly. Vertex lighting obviously won't do much "as lighting", IMHO... = everything looks often very flat on the environments... and if you want = to make shadows that way, you split by hand...or waste time on some = complicated algorithm that splits polygons according to incoming = illumination. (as Lightscape did...) FYI, multiple UV sets and 24bit lightmaps have been used in Broken Sword = 3 even on PS2... but you have to plan this since the very beginning as = the art dept. has to follow a very different workflow compared to vertex = lighting. Best, Emanuele Salvucci MayaLightwave Game Technical Artist Lscript developer http://www.forwardgames.com emanueles@... "#3. He causes things to look different so it would appear time has = passed." =   Original Message =20 From: Andrey Iones=20 To: gdalgorithmslist@...=20 Sent: Thursday, April 29, 2004 12:19 PM Subject: Re: [Algorithms] Stripes  how efficient and useful they = really are? Speaking of multiple UV sets.=20 As far as I understand lightmaps are not really that useful on PS2, = and environment=20 lighting is usually done using vertex lighting. Is this true?=20 Thanks,=20 Andrey.=20 Emanuele Salvucci wrote:=20 Sure, but I wasn't talking characters.=20 It's usually environments that suffer from poor optimizations and = especially=20 when lightmapped (2 UV set for each material/object).=20 Moreover, once your environment objects are mappingoptimized = they're still=20 subject to any further "algorithmic" optimization...as this is not = any=20 compression technique which excludes others. Obviously if you = optimize the=20 "source" already by a factor of 3... well, you can see the = advantage. ;)=20 Best,=20 Emanuele.=20  Original Message =20 From: "Tom Forsyth" <tom.forsyth@...>=20 To: <gdalgorithmslist@...>=20 Sent: Thursday, April 29, 2004 8:45 AM=20 Subject: RE: [Algorithms] Stripes  how efficient and useful they = really=20 are?=20 > > On PC, we've noticed that manually optimized UV mapping with=20 > > 2 UV sets on=20 > > each object can save up to 2.7 times the number of total=20 > > vertices compared=20 > > to the worst case scenario (i.e. 3 vertices/triangle).=20 > > (also, with this optimization, indexed arrays and strips perform = quite=20 > > similarly, from a vertexcount point of view)=20 >=20 > That's not actually very good. With a good vertexcache optimiser = (e.g.=20 the=20 > D3DX one) you should be getting down to around 0.7 verts/tri for = something=20 > like a 10k poly character mesh. Which is a factor of over 4.=20 >=20 > TomF.=20 >=20 >=20 > > Original Message=20 > > From: gdalgorithmslistadmin@...=20 > > [mailto:gdalgorithmslistadmin@...] On=20 > > Behalf Of Emanuele Salvucci=20 > > Sent: 28 April 2004 03:12=20 > > To: gdalgorithmslist@...=20 > > Subject: Re: [Algorithms] Stripes  how efficient and useful=20 > > they really are?=20 > >=20 > >=20 > > For what I've experienced on PS2... (but it's a rather=20 > > general obvservation)=20 > > strips are useful only if you have wise artists.=20 > > If you also have more than one UV set on your objects,=20 > > artists will have to=20 > > be doublewise.=20 > > (I'm talking environment graphics only)=20 > >=20 > > Since strips break also according to material changes and UV=20 > > tiling/continuity this is going to be the main reason for=20 > > "short strips" and=20 > > high vertexcount in "practical life" situations.=20 > >=20 > > If artists make a good job on continuous UV mapping you can=20 > > save tons of=20 > > vertices.=20 > > But if meshes' topology and artistic design don't marry with=20 > > continuous UV=20 > > mapping, then I believe you'd be better off don't wasting=20 > > extra work on=20 > > strips...the actual gain wouldn't be worth the effort.=20 > >=20 > > On PC, we've noticed that manually optimized UV mapping with=20 > > 2 UV sets on=20 > > each object can save up to 2.7 times the number of total=20 > > vertices compared=20 > > to the worst case scenario (i.e. 3 vertices/triangle).=20 > > (also, with this optimization, indexed arrays and strips perform = quite=20 > > similarly, from a vertexcount point of view)=20 > >=20 > > The point is, frequent material changes and especially = unoptimized=20 > > automatic mapping for lightmaps can easily become the worst case = > > scenario...leading to gigantic amounts of vertices for a few = tris.=20 > >=20 > > ...you might want to have a brainstorm with your lead artist=20 > > (or your more=20 > > experienced technical artist..since often they're not the=20 > > same person ;))=20 > > ...and see how he can help on this.=20 > >=20 > >=20 > > Best,=20 > >=20 > > Emanuele.=20 > >=20 > >=20 > >  Original Message =20 > > From: "Andrey Iones" <iones@...>=20 > > To: <gdalgorithmslist@...>=20 > > Sent: Tuesday, April 27, 2004 12:05 PM=20 > > Subject: [Algorithms] Stripes  how efficient and useful they=20 > > really are?=20 > >=20 > >=20 > > > Hello everybody,=20 > > >=20 > > > Could you share you experience on using stripified geometry=20 > > for rendering?=20 > > > I am particularly interested on stripe usefulness on PS2=20 > > platform. So far=20 > > I've heard=20 > > >=20 > > > mixed opinions on this  some people say we HAVE TO use=20 > > stripes 'cause=20 > > > they conserve VU memory and improve performance; others say=20 > > > we would be better of using indexed primitives because it = simplifies=20 > > building the=20 > > > geometry, and that level geometry is not really easily = stripifiable.=20 > > > Maybe the answer is to use stripes for character models=20 > > (which should be=20 > > better=20 > > > stripifiable), and use indexed primitives for level geometry?=20 > > >=20 > > > What do you people think?=20 > > >=20 > > > Thanks,=20 > > >=20 > > > Andrey.=20 > > >=20 > > > =20 > > > Andrey Iones=20 > > > Project Leader PhD in Computer Science=20 > > > http://www.saber3d.com=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > This SF.net email is sponsored by: The Robotic Monkeys at = ThinkGeek=20 > > > For a limited time only, get FREE Ground shipping on all=20 > > orders of $35=20 > > > or more. Hurry up and shop folks, this offer expires April = 30th!=20 > > > http://www.thinkgeek.com/freeshipping/?cpg=3D12297=20 > > > _______________________________________________=20 > > > GDAlgorithmslist mailing list=20 > > > GDAlgorithmslist@...=20 > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist = > > > Archives:=20 > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 > > >=20 > >=20 > >=20 > >=20 > > =20 > > This SF.Net email is sponsored by: Oracle 10g=20 > > Get certified on the hottest thing ever to hit the market...=20 > > Oracle 10g.=20 > > Take an Oracle 10g class now, and we'll give you the exam FREE.=20 > > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 > > _______________________________________________=20 > > GDAlgorithmslist mailing list=20 > > GDAlgorithmslist@...=20 > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 > > Archives:=20 > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 > >=20 >=20 >=20 >=20 > =20 > This SF.Net email is sponsored by: Oracle 10g=20 > Get certified on the hottest thing ever to hit the market... = Oracle 10g.=20 > Take an Oracle 10g class now, and we'll give you the exam FREE.=20 > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 > _______________________________________________=20 > GDAlgorithmslist mailing list=20 > GDAlgorithmslist@...=20 > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 > Archives:=20 > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 >=20 =20 This SF.Net email is sponsored by: Oracle 10g=20 Get certified on the hottest thing ever to hit the market... Oracle = 10g.=20 Take an Oracle 10g class now, and we'll give you the exam FREE.=20 http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick=20 _______________________________________________=20 GDAlgorithmslist mailing list=20 GDAlgorithmslist@...=20 https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 Archives:=20 http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 =20 Andrey Iones=20 Project Leader PhD in Computer Science=20 http://www.saber3d.com=20 =20 
From: Andrey Iones <iones@sa...>  20040429 10:55:59

My question was more of a practical nature ;). What do you people usually do to lit environments  texturebased lightmaps or vertex lighting? Paul_Firth@... wrote: > On 29/04/2004 11:45:21 gdalgorithmslistadmin wrote: > > >> >Speaking of multiple UV sets. > > > > As far as I understand lightmaps are not really that useful > > > on PS2, and > > > > environment > > > > lighting is usually done using vertex lighting. Is this true? > > > > > > Usually yes. Lightmaps are tricky because there is no colour src*dst > > > blending mode on ps2. You can > > > do greyscale lightmaps though and there are approximations to colour > > > src*dst which work quite > > > nicely. Look on the ps2 newsgroups for more details. > > > > Surely that should read "there is no single pass colour src*dst blending > > mode on the ps2" ??? > > Not really. Since the hardware doesn't have that blending mode and has > internally > no concept of passes, my statement holds. > > What you do in multiple passes is up to you, and yes you can "fake" > coloured lightmaps > by doing three passes with colour write disabled for the correct colour. > But who > wants to be doing three passes? :) > > Cheers, Paul. > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Andrey Iones Project Leader PhD in Computer Science http://www.saber3d.com 
From: <Paul_Firth@sc...>  20040429 10:52:48

On 29/04/2004 11:45:21 gdalgorithmslistadmin wrote: >> >Speaking of multiple UV sets. > > > As far as I understand lightmaps are not really that useful > > on PS2, and > > > environment > > > lighting is usually done using vertex lighting. Is this true? > > > > Usually yes. Lightmaps are tricky because there is no colour src*dst > > blending mode on ps2. You can > > do greyscale lightmaps though and there are approximations to colour > > src*dst which work quite > > nicely. Look on the ps2 newsgroups for more details. > > Surely that should read "there is no single pass colour src*dst blending > mode on the ps2" ??? Not really. Since the hardware doesn't have that blending mode and has internally no concept of passes, my statement holds. What you do in multiple passes is up to you, and yes you can "fake" coloured lightmaps by doing three passes with colour write disabled for the correct colour. But who wants to be doing three passes? :) Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** SCEE 2004 
From: Paul A. Hodgson <paul.hodgson@wa...>  20040429 10:43:06

> >Speaking of multiple UV sets. > > As far as I understand lightmaps are not really that useful > on PS2, and > > environment > > lighting is usually done using vertex lighting. Is this true? > > Usually yes. Lightmaps are tricky because there is no colour src*dst > blending mode on ps2. You can > do greyscale lightmaps though and there are approximations to colour > src*dst which work quite > nicely. Look on the ps2 newsgroups for more details. Surely that should read "there is no single pass colour src*dst blending mode on the ps2" ??? Paul A. Hodgson TNT (60ODT) MAILTO:paul.hodgson@... HTTP:\\www.warthog.co.uk 