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}

_{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: 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 <G<uillaume@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_F<irth@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_F<irth@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 
From: Paul_F<irth@sc...>  20040429 10:31:34

On 29/04/2004 11:19:46 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. 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: Andrey Iones <iones@sa...>  20040429 10:15:34

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? Thanks, Andrey. Emanuele Salvucci wrote: > Sure, but I wasn't talking characters. > > It's usually environments that suffer from poor optimizations and especially > when lightmapped (2 UV set for each material/object). > > Moreover, once your environment objects are mappingoptimized they're still > subject to any further "algorithmic" optimization...as this is not any > compression technique which excludes others. Obviously if you optimize the > "source" already by a factor of 3... well, you can see the advantage. ;) > > Best, > > Emanuele. > >  Original Message  > From: "Tom Forsyth" <tom.forsyth@...> > To: <gdalgorithmslist@...> > Sent: Thursday, April 29, 2004 8:45 AM > Subject: RE: [Algorithms] Stripes  how efficient and useful they really > are? > > > > On PC, we've noticed that manually optimized UV mapping with > > > 2 UV sets on > > > each object can save up to 2.7 times the number of total > > > vertices compared > > > to the worst case scenario (i.e. 3 vertices/triangle). > > > (also, with this optimization, indexed arrays and strips perform quite > > > similarly, from a vertexcount point of view) > > > > That's not actually very good. With a good vertexcache optimiser (e.g. > the > > D3DX one) you should be getting down to around 0.7 verts/tri for something > > like a 10k poly character mesh. Which is a factor of over 4. > > > > TomF. > > > > > > > Original Message > > > From: gdalgorithmslistadmin@... > > > [mailto:gdalgorithmslistadmin@...] On > > > Behalf Of Emanuele Salvucci > > > Sent: 28 April 2004 03:12 > > > To: gdalgorithmslist@... > > > Subject: Re: [Algorithms] Stripes  how efficient and useful > > > they really are? > > > > > > > > > For what I've experienced on PS2... (but it's a rather > > > general obvservation) > > > strips are useful only if you have wise artists. > > > If you also have more than one UV set on your objects, > > > artists will have to > > > be doublewise. > > > (I'm talking environment graphics only) > > > > > > Since strips break also according to material changes and UV > > > tiling/continuity this is going to be the main reason for > > > "short strips" and > > > high vertexcount in "practical life" situations. > > > > > > If artists make a good job on continuous UV mapping you can > > > save tons of > > > vertices. > > > But if meshes' topology and artistic design don't marry with > > > continuous UV > > > mapping, then I believe you'd be better off don't wasting > > > extra work on > > > strips...the actual gain wouldn't be worth the effort. > > > > > > On PC, we've noticed that manually optimized UV mapping with > > > 2 UV sets on > > > each object can save up to 2.7 times the number of total > > > vertices compared > > > to the worst case scenario (i.e. 3 vertices/triangle). > > > (also, with this optimization, indexed arrays and strips perform quite > > > similarly, from a vertexcount point of view) > > > > > > The point is, frequent material changes and especially unoptimized > > > automatic mapping for lightmaps can easily become the worst case > > > scenario...leading to gigantic amounts of vertices for a few tris. > > > > > > ...you might want to have a brainstorm with your lead artist > > > (or your more > > > experienced technical artist..since often they're not the > > > same person ;)) > > > ...and see how he can help on this. > > > > > > > > > Best, > > > > > > Emanuele. > > > > > > > > >  Original Message  > > > From: "Andrey Iones" <iones@...> > > > To: <gdalgorithmslist@...> > > > Sent: Tuesday, April 27, 2004 12:05 PM > > > Subject: [Algorithms] Stripes  how efficient and useful they > > > really are? > > > > > > > > > > Hello everybody, > > > > > > > > Could you share you experience on using stripified geometry > > > for rendering? > > > > I am particularly interested on stripe usefulness on PS2 > > > platform. So far > > > I've heard > > > > > > > > mixed opinions on this  some people say we HAVE TO use > > > stripes 'cause > > > > they conserve VU memory and improve performance; others say > > > > we would be better of using indexed primitives because it simplifies > > > building the > > > > geometry, and that level geometry is not really easily stripifiable. > > > > Maybe the answer is to use stripes for character models > > > (which should be > > > better > > > > stripifiable), and use indexed primitives for level geometry? > > > > > > > > What do you people think? > > > > > > > > Thanks, > > > > > > > > Andrey. > > > > > > > >  > > > > Andrey Iones > > > > Project Leader PhD in Computer Science > > > > http://www.saber3d.com > > > > > > > > > > > > > > > > > > > >  > > > > 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 > > > >  > 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: <c.schueler@ph...>  20040429 09:42:39

For Multipass you can generate a second positionunique index buffer = that you use when you render untextured passes (for instance, = depthlayout). It might be especially advantageous when vertices have = otherwise little in common (like, 2 UV sets). Urspr=FCngliche Nachricht Von: gdalgorithmslistadmin@... = [mailto:gdalgorithmslistadmin@...] Im Auftrag von = Emanuele Salvucci Gesendet: Donnerstag, 29. April 2004 11:15 An: gdalgorithmslist@... Betreff: Re: [Algorithms] Stripes  how efficient and useful they really = are? Sure, but I wasn't talking characters. It's usually environments that suffer from poor optimizations and = especially when lightmapped (2 UV set for each material/object). Moreover, once your environment objects are mappingoptimized they're = still subject to any further "algorithmic" optimization...as this is not = any compression technique which excludes others. Obviously if you = optimize the "source" already by a factor of 3... well, you can see the = advantage. ;) Best, Emanuele. 
From: Bob Dowland <Bob.D<owland@bl...>  20040429 09:25:42

ehhmm... sorry about that  bitten by outlook's cunning secret "send" = keycombi.. :) Ideas so far: 1 eliminate duplicates: this at least gets the numbers down there are lots of simple cases that = come up like "interior" edges with the same sep norm, there may also be = a few subtler cases but I can't see any damage being done by just having = one instead of two copies of a contact. So this is a no brainer. 2 identify coplanar contact points:=20 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 3 convex hull points:=20 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. 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. 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. Bob. > Original Message > From: Alen Ladavac [mailto:alenlml@...] > Sent: 29 April 2004 10:10 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Box<>Tri(Mesh) contact filtering >=20 >=20 > Hey Bob, long time no see... ;) >=20 > Are you seeing problems on the edges between two triangles? When one > triangle's separation goes along triangle normal, and the=20 > other's goes along > axis orthogonal to edge between them? Because I'm looking for=20 > a solution to > that problem as well. And also as postprocess, if possible,=20 > though some > hints during detection wouldn't be bad either. Have you had=20 > any ideas so > far? >=20 > Alen >=20 >=20 >  Original Message  > From: "Bob Dowland" <Bob.Dowland@...> > To: <gdalgorithmslist@...> > Sent: Wednesday, April 28, 2004 14:23 > Subject: [Algorithms] Box<>Tri(Mesh) contact filtering >=20 >=20 > I am trying to make use of a collection of "contacts"=20 > detected between a box > and some tri's from a mesh. >=20 > More specifically, the contact set is the result of a=20 > collection of pertri > cd queries which take no account of the "highlevel"=20 > structure of the mesh > (the contacts are subsequently passed to a solver for=20 > purposes of collision > response). >=20 > Each contact carries: >=20 > contact point > separating plane normal > penetration > tri vert points >=20 > Contact "point"s are generated by (3D) clipping each tri to=20 > the interior of > the box. Separating normal and penetration value come from a=20 > seperating axis > (style) test. >=20 > Surprisingly enough such a contact set works passably "much=20 > of the time" but > gives rise to artefacts "often enough" to be a nonsolution.=20 > Although there > are obvious advantages in tackling this on the fly (ie during=20 > the cd stage), > for now I'm looking for a way to postprocess this set. >=20 > Can anyone shed some light or good references? >=20 > ********************************************************************** > The information contained in this email and its attachments is > confidential. It is intended only for the named addressees > and may not be disclosed to anyone else without consent from > Blue 52 Games Limited. Blue 52 give no warranty that this email > message (including any attachments to it) is free of any virus > or other harmful matter and accepts no responsibility for any > loss or damage resulting from the recipient receiving, opening > or using it. > ********************************************************************** >=20 >=20 >=20 >=20 >=20 >  > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market...=20 > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick > _______________________________________________ > 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: Oracle 10g > 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. > http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 ********************************************************************** The information contained in this email and its attachments is confidential. It is intended only for the named addressees=20 and may not be disclosed to anyone else without consent from Blue 52 Games Limited. Blue 52 give no warranty that this email=20 message (including any attachments to it) is free of any virus=20 or other harmful matter and accepts no responsibility for any=20 loss or damage resulting from the recipient receiving, opening or using it.=20 ********************************************************************** 
From: Emanuele Salvucci <info@fo...>  20040429 09:16:02

Sure, but I wasn't talking characters. It's usually environments that suffer from poor optimizations and especially when lightmapped (2 UV set for each material/object). Moreover, once your environment objects are mappingoptimized they're still subject to any further "algorithmic" optimization...as this is not any compression technique which excludes others. Obviously if you optimize the "source" already by a factor of 3... well, you can see the advantage. ;) Best, Emanuele.  Original Message  From: "Tom Forsyth" <tom.forsyth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 29, 2004 8:45 AM Subject: RE: [Algorithms] Stripes  how efficient and useful they really are? > > On PC, we've noticed that manually optimized UV mapping with > > 2 UV sets on > > each object can save up to 2.7 times the number of total > > vertices compared > > to the worst case scenario (i.e. 3 vertices/triangle). > > (also, with this optimization, indexed arrays and strips perform quite > > similarly, from a vertexcount point of view) > > That's not actually very good. With a good vertexcache optimiser (e.g. the > D3DX one) you should be getting down to around 0.7 verts/tri for something > like a 10k poly character mesh. Which is a factor of over 4. > > TomF. > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...] On > > Behalf Of Emanuele Salvucci > > Sent: 28 April 2004 03:12 > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] Stripes  how efficient and useful > > they really are? > > > > > > For what I've experienced on PS2... (but it's a rather > > general obvservation) > > strips are useful only if you have wise artists. > > If you also have more than one UV set on your objects, > > artists will have to > > be doublewise. > > (I'm talking environment graphics only) > > > > Since strips break also according to material changes and UV > > tiling/continuity this is going to be the main reason for > > "short strips" and > > high vertexcount in "practical life" situations. > > > > If artists make a good job on continuous UV mapping you can > > save tons of > > vertices. > > But if meshes' topology and artistic design don't marry with > > continuous UV > > mapping, then I believe you'd be better off don't wasting > > extra work on > > strips...the actual gain wouldn't be worth the effort. > > > > On PC, we've noticed that manually optimized UV mapping with > > 2 UV sets on > > each object can save up to 2.7 times the number of total > > vertices compared > > to the worst case scenario (i.e. 3 vertices/triangle). > > (also, with this optimization, indexed arrays and strips perform quite > > similarly, from a vertexcount point of view) > > > > The point is, frequent material changes and especially unoptimized > > automatic mapping for lightmaps can easily become the worst case > > scenario...leading to gigantic amounts of vertices for a few tris. > > > > ...you might want to have a brainstorm with your lead artist > > (or your more > > experienced technical artist..since often they're not the > > same person ;)) > > ...and see how he can help on this. > > > > > > Best, > > > > Emanuele. > > > > > >  Original Message  > > From: "Andrey Iones" <iones@...> > > To: <gdalgorithmslist@...> > > Sent: Tuesday, April 27, 2004 12:05 PM > > Subject: [Algorithms] Stripes  how efficient and useful they > > really are? > > > > > > > Hello everybody, > > > > > > Could you share you experience on using stripified geometry > > for rendering? > > > I am particularly interested on stripe usefulness on PS2 > > platform. So far > > I've heard > > > > > > mixed opinions on this  some people say we HAVE TO use > > stripes 'cause > > > they conserve VU memory and improve performance; others say > > > we would be better of using indexed primitives because it simplifies > > building the > > > geometry, and that level geometry is not really easily stripifiable. > > > Maybe the answer is to use stripes for character models > > (which should be > > better > > > stripifiable), and use indexed primitives for level geometry? > > > > > > What do you people think? > > > > > > Thanks, > > > > > > Andrey. > > > > > >  > > > Andrey Iones > > > Project Leader PhD in Computer Science > > > http://www.saber3d.com > > > > > > > > > > > > > > >  > > > 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 > 