You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(21) 
2
(12) 
3
(7) 
4
(40) 
5
(67) 
6
(50) 
7
(21) 
8
(31) 
9
(8) 
10
(3) 
11
(26) 
12
(50) 
13
(56) 
14
(56) 
15
(36) 
16
(15) 
17
(17) 
18
(16) 
19
(29) 
20
(45) 
21
(52) 
22
(25) 
23
(16) 
24
(2) 
25
(6) 
26
(4) 
27
(13) 
28
(4) 
29
(19) 
30
(10) 
31
(5) 






From: Cuban <amperez+3dalg@an...>  20001220 22:21:44

We use Python in Alice (no, not McGee's Alice) for all of the scripting and the results in general have been very good. We're currently using JPython, which lets you do neat things like derive python classes from java classes or call java code natively. The previous version used a C++ version of python. The only complaint I've had is Python is unforgivably slow as most scripting languages go, it's actually one of the slowest I've ever seen. This usually doesn't end up being a problem, if a script ends up being too slow we just rewrite it in Java. IIRC the reason Python is so slow is because practically /everything/ in the language requires a dictionary lookup to execute. This is the price you pay for having the language take care of all the details for you. In terms of writing it, Python is amazing. The semantics is really closely bound to the syntax. Once you understand the way it works, you just write correct code quickly and easily, and it works the first try. Cuban ______________________________________________________________________ Adrian Perez  http://www.cubonics.com  15462 TA  CMU Originals Presidente "The pathway to heaven is paved with computer graphics." Henninger On Wed, 20 Dec 2000, Matthew MacLaurin wrote: > Is anyone out there using Python for a scripting language? If so, I'd like > to hear about the experience. > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Adam Moravanszky <amoravanszky@dp...>  20001220 21:40:18

>> This confusion may originate from the fact that in my BRDF >> renderer, my >> assumption is correct/works, and I thought that bump mapping >> was similar >> enough. > >IIRC, you need identical basis matrices for BRDF, and indeed loads of other >effects as well. Tom, I have to admit, amidst great public humiliation, that you are, of course, again, right. I just did some tests, and my BRDF results are not at all invariant with respect to the basis chosen. Not even 'almost'. :( Could you or someone else point me to a good resource that gives me a thorough explanation of the construction of correct per vertex bases for these problems? I do have a DirectX bump mapping demo's source code, but I like to have more theory than that.  Adam Moravanszky http://www.n.ethz.ch/student/adammo 
From: Graham Rhodes <grhodes@se...>  20001220 20:15:48

We have been playing with the Blender modeling package, that uses Python for scripting. I wrote a file exporter. Works pretty well, once you know the language syntax. The big problems I have are Blenderspecific: first, the documentation to Blender objects is currently quite poor, and a significant amount of experimentation is required to figure out how to get to certain data; and second, Blender does not provide access to most important data, such as meaningful texture coordinates. But those problems have nothing at all to do with the Python language. I would have to say that I generally like Python as a scripting language. Graham Rhodes Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Matthew MacLaurin Sent: Wednesday, December 20, 2000 12:35 PM To: gdalgorithmslist@... Subject: [Algorithms] Python for scripting? Is anyone out there using Python for a scripting language? If so, I'd like to hear about the experience. _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Jorrit Tyberghein <Jorrit.Tyberghein@uz...>  20001220 19:56:07

Matthew MacLaurin wrote: > Is anyone out there using Python for a scripting language? If so, I'd like > to hear about the experience. The Crystal Space 3D engine supports Python as a scripting language. I'm using Crystal Space with Python for my Dreams Eternal FPS game (http://dreams.sourceforge.net). It is working very well. Dreams Eternal has a entity system which is defined in C++. The C++ entity system however only describes the 'physics' and hard rules of the world. i.e. physical characteristics, and how the world in general works. Every entity also has a Python object attached to it which is responsible for controlling the behaviour of that object. There is a design document on the Dreams Eternal home page that describes the interaction between the C++ and the Python entity systems. Greetings, 
From: Felix Fontein <felix@am...>  20001220 19:52:16

Hi! > I'm looking for some code to draw a circle, who's plane is rotated > arbitrarily in 3d, like you might use to draw a light cone in an > editor. Draw the circle by first generating n points on the circle and connect them with lines :) To generate the points, create some matrix which maps (1, 1, 0) to (1, 1, 0) onto the area on the place which contains the circle. Some C++ pseudocode: (norm is the normal of the plane, center the center of the circle, r the radius of the circle.) void GenerateCirclePoints(int n, vector *points, vector norm, vector center, float radius) { float angleadd = PI * 2 / n, angle = 0; Vector x = Normalize(FindOrthogonalVectorTo(norm)) * radius; Vector y = Normalize(CrossProduct(norm, left)) * radius; for (int i = 0; i < n; i++, angle += angleadd) points[i] = center + x * sin(angle) + y * cos(angle); } Felix 
From: Gil Gribb <ggribb@ra...>  20001220 19:50:35

This does not produce a uniform distribuion. It is clumped near z = r and z = r. To see this note that a unifrom distribution on a sphere is not uniform along the z axis, but the distribution you are creating is. Gil > > here is the code I've use for this ... > > 10,000 points with no apparent clumping.... > > > z = 2.0 * ( float ) rand( ) / RAND_MAX  1.0; > float t = 2.0 * D3DX_PI * ( float ) rand( ) / RAND_MAX; > float w = sqrt( 1  z * z ); > x = w * cos( t ); > y = w * sin( t ); > > // scale by radius > x *= radius; > y *= radius; > z *= radius; > > > Carl, > > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...]On Behalf Of > > Michael Tatro > > Sent: Wednesday, December 20, 2000 11:09 AM > > To: gdalgorithmslist@... > > Subject: [Algorithms] Random distribution of points on sphere? > > > > > > I'm looking for an algorithm that randomly distributes points > > on a sphere. > > Not to be confused with the popular "uniform distribution of > > points on a > > sphere" problem, I'm looking for a chaotic, random distribution. My > > attempts have produced clumps near the "poles" or the > > "equator" Any ideas? > > > > Thanks, > > Mike > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Brown, Greg <BrownG@ct...>  20001220 19:34:49

I'm looking for some code to draw a circle, who's plane is rotated arbitrarily in 3d, like you might use to draw a light cone in an editor. Thanks 
From: Stephen J Baker <sjbaker@li...>  20001220 19:26:49

On Wed, 20 Dec 2000, Matthew MacLaurin wrote: > Is anyone out there using Python for a scripting language? If so, I'd like > to hear about the experience. Yes  it's works pretty well  slow compared to C++ (of course)  but perfectly usable. I like it better than PERL and some of the other interpreted languages out there because it looks more like C++ and less like a badly corrupted disk sector. :) Take a look at 'SWIG' which is a headermangler that can automate the generation of Python bindings for whatever API you export from your main application...it's not *perfect* but it beats the heck out of writing binding layers by hand. We are using Python as the scripting and 'glue' language for the PrettyPoly OpenSourced modeller  and it's working out rather nicely.  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://web2.airmail.net/sjbaker1 
From: Carl Storstroen <cstortro@Matrox.COM>  20001220 19:24:59

here is the code I've use for this ... 10,000 points with no apparent clumping.... z = 2.0 * ( float ) rand( ) / RAND_MAX  1.0; float t = 2.0 * D3DX_PI * ( float ) rand( ) / RAND_MAX; float w = sqrt( 1  z * z ); x = w * cos( t ); y = w * sin( t ); // scale by radius x *= radius; y *= radius; z *= radius; Carl, > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > Michael Tatro > Sent: Wednesday, December 20, 2000 11:09 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Random distribution of points on sphere? > > > I'm looking for an algorithm that randomly distributes points > on a sphere. > Not to be confused with the popular "uniform distribution of > points on a > sphere" problem, I'm looking for a chaotic, random distribution. My > attempts have produced clumps near the "poles" or the > "equator" Any ideas? > > Thanks, > Mike > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Jeffrey Rainy <jrainy@dy...>  20001220 18:39:53

> Can you elaborate on the methods that don't require an indeterminate number > of point tests? ( let's assume radius of 1 ) You take an arbitrary axis. ( y is easy for me, cause it figure it as updown ) You determine the distribution of surface area on the sphere along that axis. Something like circonference * dy / cos(angle between surface and y axis at x = 0 ) more precisely PI (1  y^2) dy / cos( asin ( y ) ) <== unsure You integrate that. ( No, I do not remember how to do that ) You calculate the integral between 1 and 1 of that. This gives you the total surface. < good point to check validity Now, you choose a random value between 0 and the total surface. You find the y value where the integral above equals the random chosen value. This allow you to find a xz slice with an amount of surface under it randomly distributed. You select a x and z value by selecting a random angle on the circle at that height on the sphere. If someone is able to carry on the mathematics of this, I'd appreciate it much... Thanks. 
From: Michael Tatro <mike@st...>  20001220 18:04:38

Can you elaborate on the methods that don't require an indeterminate number of point tests? Thanks, Mike  Original Message  From: "Gil Gribb" <ggribb@...> To: <gdalgorithmslist@...> Sent: Wednesday, December 20, 2000 12:14 PM Subject: Re: [Algorithms] Random distribution of points on sphere? > > Would randomly generating a vector (1..1), > > normalizing it and scaling it by the radius work? > > I need to do this also... > > Nope, the corners of the box have more points. > > The dead simple thing to do is generate points in (1,1)^3, until you get > one inside of the unit sphere, then normalize it. > > There are other ways that don't require an indeterminate number of rands(), > but the discard method is the simplest. > Gil > > > > > > Jaimi > > > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...]On Behalf Of > > Michael Tatro > > Sent: Wednesday, December 20, 2000 10:09 AM > > To: gdalgorithmslist@... > > Subject: [Algorithms] Random distribution of points on sphere? > > > > > > I'm looking for an algorithm that randomly distributes points on a sphere. > > Not to be confused with the popular "uniform distribution of points on a > > sphere" problem, I'm looking for a chaotic, random distribution. My > > attempts have produced clumps near the "poles" or the "equator" Any > ideas? > > > > Thanks, > > Mike > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Michael Tatro <mike@st...>  20001220 17:38:41

No, this wouldn't give you a nice even random distribution. Your method is analagous to creating random points within a unit cube, and then linearly projecting them onto a sphere. This intuitive method unfortunately creates clumps near the eight vertices of the unit cube. This occurs because the distance from the origin to a cube vertex is farther than from the origin to the middle of cube face. And if the distance is greater, then more random points will be created along that direction. Mike  Original Message  From: "Jaimi McEntire" <jaimi@...> To: <gdalgorithmslist@...> Sent: Wednesday, December 20, 2000 11:49 AM Subject: RE: [Algorithms] Random distribution of points on sphere? > Would randomly generating a vector (1..1), > normalizing it and scaling it by the radius work? > I need to do this also... > > Jaimi > > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > Michael Tatro > Sent: Wednesday, December 20, 2000 10:09 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Random distribution of points on sphere? > > > I'm looking for an algorithm that randomly distributes points on a sphere. > Not to be confused with the popular "uniform distribution of points on a > sphere" problem, I'm looking for a chaotic, random distribution. My > attempts have produced clumps near the "poles" or the "equator" Any ideas? > > Thanks, > Mike > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: <ron@do...>  20001220 17:36:51

Alex Morano wrote: > I was wondering if anyone has run across this method of dealing with= affine transformations, just found it, in of all things, a VB WIN API = graphics programming book (don't ask), they use the following idea: > > Instead of the regular=20 > > =20 > C S 0 0 > S C 0 0 > 0 0 1 0 > 0 0 0 1 > > for rotation about the Z axis, they make it a 2dimensional = transformation: > > Distance of X and Y (d) =3D Sqrt(X ^ 2 + Y ^ 2) > > x/d y/d 0 0 > y/d x/d 0 0 > 0 0 1 0 > 0 0 0 1 > > Now, I tried some quick benchmarks, changed the divs into multiplies= (1/d) and sure enough, I get a 16% increase on my transformations. And = the accuracy is exactly the same. Is this something I have missed that = is a known trick, or is it an accepted algo to use the cos/sin, or even = lookup tables? My only gripe about lookups is that they can never be = accurate enough without the sarifice of a huge swat of memory. > > So I am curious if this is a used standard? > =20 This is just an elementary trig identity combined with the pythagorean distance formula. In fact, you haven't stated what are x and y in relation to the angle of the rotation, but with appropriate definitions involving a right triangle, recall that=20 cos(angle) =3D x/d and sin(angle) =3D y/d are the VERY DEFINITIONS of sin and cos.=20 So, if you HAVE x AND y at hand, appropriately related to the angle of rotation, then you really don't need the angle and you get the sin and cos with a single call to a function routine (sqrt) involving iterative evaluation. If you know that your (x, y) vector is normalized, then you don't even need the sqrt call. But if you do not have an x and a y, but you just have the angle, then you have to call cos and sin, that's two iteratively evaluated functions. BTW if you have cos and the quadrant, then, by a well known related trig identity, you can get sin by sin =3D (+/) sqrt(1  cos^2) and some branch decisions based on the quadrant to get the sign of sin. 
From: Stephen J Baker <sjbaker@li...>  20001220 17:36:15

Michael Tatro said: > > I'm looking for an algorithm that randomly distributes points on a sphere. > Not to be confused with the popular "uniform distribution of points on a > sphere" problem, I'm looking for a chaotic, random distribution. My > attempts have produced clumps near the "poles" or the "equator" Any > ideas? Well, you could fill a cube with randomly distributed points  then project them onto the surface of the sphere by normalizing their coordinates  maybe not the most efficient thing  but easy to understand and implement.  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://web2.airmail.net/sjbaker1 
From: Matthew MacLaurin <matt@me...>  20001220 17:35:31

Is anyone out there using Python for a scripting language? If so, I'd like to hear about the experience. 
From: Gil Gribb <ggribb@ra...>  20001220 17:09:10

> Would randomly generating a vector (1..1), > normalizing it and scaling it by the radius work? > I need to do this also... Nope, the corners of the box have more points. The dead simple thing to do is generate points in (1,1)^3, until you get one inside of the unit sphere, then normalize it. There are other ways that don't require an indeterminate number of rands(), but the discard method is the simplest. Gil > > Jaimi > > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > Michael Tatro > Sent: Wednesday, December 20, 2000 10:09 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Random distribution of points on sphere? > > > I'm looking for an algorithm that randomly distributes points on a sphere. > Not to be confused with the popular "uniform distribution of points on a > sphere" problem, I'm looking for a chaotic, random distribution. My > attempts have produced clumps near the "poles" or the "equator" Any ideas? > > Thanks, > Mike > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Alex Morano <Amorano@Bworks.Com>  20001220 17:02:00

P.S. I realize that y/d and x/d is an identity for cos and sin, I am = more interested in whether or not this is used in hand optimizing matrix = routines rather than the infamous FCOS and FSIN  Original Message =20 From: Alex Morano=20 To: gdalgorithmslist@...=20 Sent: Wednesday, December 20, 2000 11:48 AM Subject: [Algorithms] SQRT vs. SIN and COS I was wondering if anyone has run across this method of dealing = with affine transformations, just found it, in of all things, a VB WIN = API graphics programming book (don't ask), they use the following idea: Instead of the regular=20 =20 C S 0 0 S C 0 0 0 0 1 0 0 0 0 1 for rotation about the Z axis, they make it a 2dimensional = transformation: Distance of X and Y (d) =3D Sqrt(X ^ 2 + Y ^ 2) x/d y/d 0 0 y/d x/d 0 0 0 0 1 0 0 0 0 1 Now, I tried some quick benchmarks, changed the divs into = multiplies (1/d) and sure enough, I get a 16% increase on my = transformations. And the accuracy is exactly the same. Is this = something I have missed that is a known trick, or is it an accepted algo = to use the cos/sin, or even lookup tables? My only gripe about lookups = is that they can never be accurate enough without the sarifice of a huge = swat of memory. So I am curious if this is a used standard? =20 
From: Jaimi McEntire <jaimi@al...>  20001220 16:50:06

Would randomly generating a vector (1..1), normalizing it and scaling it by the radius work? I need to do this also... Jaimi Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Michael Tatro Sent: Wednesday, December 20, 2000 10:09 AM To: gdalgorithmslist@... Subject: [Algorithms] Random distribution of points on sphere? I'm looking for an algorithm that randomly distributes points on a sphere. Not to be confused with the popular "uniform distribution of points on a sphere" problem, I'm looking for a chaotic, random distribution. My attempts have produced clumps near the "poles" or the "equator" Any ideas? Thanks, Mike _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Alex Morano <Amorano@Bworks.Com>  20001220 16:46:50

I was wondering if anyone has run across this method of dealing with = affine transformations, just found it, in of all things, a VB WIN API = graphics programming book (don't ask), they use the following idea: Instead of the regular=20 =20 C S 0 0 S C 0 0 0 0 1 0 0 0 0 1 for rotation about the Z axis, they make it a 2dimensional = transformation: Distance of X and Y (d) =3D Sqrt(X ^ 2 + Y ^ 2) x/d y/d 0 0 y/d x/d 0 0 0 0 1 0 0 0 0 1 Now, I tried some quick benchmarks, changed the divs into multiplies = (1/d) and sure enough, I get a 16% increase on my transformations. And = the accuracy is exactly the same. Is this something I have missed that = is a known trick, or is it an accepted algo to use the cos/sin, or even = lookup tables? My only gripe about lookups is that they can never be = accurate enough without the sarifice of a huge swat of memory. So I am curious if this is a used standard? =20 
From: Smith Chris <chris.smith@ua...>  20001220 16:43:40

How about repeatedly generating two uniform random variables on [0,1]. Then use these random values to generate two angles theta1 and theta2 in radians. Theta 1 is deflection from the zenith so it should be a completely random value on [0,pi], and theta2 is deflection around the sphere, so it should be random on [0,2pi] then use these formulas for the point coordinates: xCoord = sin(theta1)*sin(theta2)*SphereRadius; yCoord = cos(theta1)*SphereRadius; zCoord = sin(theta1)*cos(theta2)*SphereRadius; and you should get completely random distribution of points around the sphere. I haven't tried it, so I don't know if this generates clumping or not. If it does, you could always try something like add in another random variable that determines the likelihood of a point being added based on theta1 and theta2. Use a distribution that makes it less likely for a point to be added if it is close to one of the poles and more likely towards the equator. Good luck! chris 
From: Javier Arevalo <jare@py...>  20001220 16:32:10

Check the graphics gems, there was exactly one gem about that problem, I think in the first volume. IIRC it involved generating a starting point and then applying random rotation quaternions which don't exhibit any alignment. Javier Arevalo Pyro Studios  Original Message  From: "Michael Tatro" <mike@...> To: <gdalgorithmslist@...> Sent: Wednesday, December 20, 2000 5:08 PM Subject: [Algorithms] Random distribution of points on sphere? > I'm looking for an algorithm that randomly distributes points on a sphere. > Not to be confused with the popular "uniform distribution of points on a > sphere" problem, I'm looking for a chaotic, random distribution. My > attempts have produced clumps near the "poles" or the "equator" Any ideas? > > Thanks, > Mike > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Stewart Lynch <Stewart@cl...>  20001220 16:24:28

generate 2 random angles angZ and angX in the range 0  2PI the formula to get rid of the "poles" is; angZ = acosf(angZ / (2.0f * PI)) if(rand() & 1) // this is because we lose the sign in the acos angZ = PI  angZ; then just rotate the point (radius, 0, 0) by angZ and then angX Stew. Original Message From: Michael Tatro [mailto:mike@...] Sent: 20 December 2000 16:09 To: gdalgorithmslist@... Subject: [Algorithms] Random distribution of points on sphere? I'm looking for an algorithm that randomly distributes points on a sphere. Not to be confused with the popular "uniform distribution of points on a sphere" problem, I'm looking for a chaotic, random distribution. My attempts have produced clumps near the "poles" or the "equator" Any ideas? Thanks, Mike _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Tom Forsyth <tomf@mu...>  20001220 16:23:52

> From: Adam Moravanszky [mailto:amoravanszky@...] > > Sim and Tom, thanks for the replies. > > Tom, you write: > > > Problem is  it's frequently wrong. What you need is the two tangent > > vectors, which may not (and indeed are rarely) at 90 > degrees. It is still > OK > > in to do the dotproduct in most cases, but can look > slightly funny in > > others. > > > > You can also store the two tangent vectors and find the > normal by doing > the > > cross product between them and normalising, but that's going to be > > expensive. Without the normalise, things are going to be bad. > > > > > I was under the impression that the only constraint on the > other two vectors > is that they have to form an orthonormal basis with the > normal vector. (and > especially that the bases of the three vertices of the > triangle don't have > to correspond in any way) You are saying that that is not > the case  what > are the exact conditions then, for this pervertex matrix? Well it's not a "constraint" as such. But to give correct lighting for a single triangle, the U and V tangent vectors should be in the trangle's plane, pointing along the lines of constant U/V (as applicable)*. In many meshes, these lines are not at 90 degrees, but they are in the right sort of area  otherwise you get your texels sheared quite badly, and that looks pretty ugly, so artists try to avoid it as much as possible. So saying they are at rightangles is often a good enough approximation, but it is only an approximation, and can look very wrong in some cases. > This confusion may originate from the fact that in my BRDF > renderer, my > assumption is correct/works, and I thought that bump mapping > was similar > enough. IIRC, you need identical basis matrices for BRDF, and indeed loads of other effects as well. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. *I may have got this wrong and they need to be _perpendicular_ to the lines of constant U/V  I always get confused about "lines of constant blah" stuff unless I sit down and work them out on a bit of paper. 
From: Alex Clarke <alexc@ar...>  20001220 16:20:34

I have to admit that I don't seem to encounter the problems Tom is referring to. We just store the normal, the binormal and a one bit flag per vertex (ouch!!!). Due to the fact that textures can have arbitrary mappings, the correct binormal can be minus normal cross tangent... (hence the flag) Computing the cross product in SSE code is not a big deal (memory access times swamp the extra cycles needed, in fact reducing the data set was a big win). (If you are brave, you can pack the normals as unsigned shorts (and stuff the one bit flag in the lsb of one element)...) In many cases the tangent and the binormal are definitely not perpendicular, however in a significant number (for us), they are... Normalization would be painful, but fortunately I can't tell the difference (this is with game art too). I think the cube map normalization does help with big polys or when there is a high degree of curvature. In both cases, tessellation is a good alternative. Alex Clarke, Programmer Argonaut Games PLC Original Message From: Adam Moravanszky [mailto:amoravanszky@...] Sent: 20 December 2000 15:56 To: gdalgorithmslist@... Subject: Re: [Algorithms] Dot3 bump mapping Sim and Tom, thanks for the replies. Tom, you write: > Problem is  it's frequently wrong. What you need is the two tangent > vectors, which may not (and indeed are rarely) at 90 degrees. It is still OK > in to do the dotproduct in most cases, but can look slightly funny in > others. > > You can also store the two tangent vectors and find the normal by doing the > cross product between them and normalising, but that's going to be > expensive. Without the normalise, things are going to be bad. > I was under the impression that the only constraint on the other two vectors is that they have to form an orthonormal basis with the normal vector. (and especially that the bases of the three vertices of the triangle don't have to correspond in any way) You are saying that that is not the case  what are the exact conditions then, for this pervertex matrix? This confusion may originate from the fact that in my BRDF renderer, my assumption is correct/works, and I thought that bump mapping was similar enough. ________________________________________________________________________ p e r s p e c t i x  interactive visual computing adam moravanszky adam@... perspectix ag phone: +411277 57 97 hardturmstrasse 171 fax: +411277 57 78 8005 zurich, switzerland http://www.perspectix.com ________________________________________________________________________  Original Message  From: "Tom Forsyth" <tomf@...> To: <gdalgorithmslist@...> Sent: Wednesday, December 20, 2000 3:41 PM Subject: RE: [Algorithms] Dot3 bump mapping > > From: Adam Moravanszky [mailto:amoravanszky@...] > > > > Hi there, > > > > I'm attacking computer graphics on two fronts at the moment. One is > > BRDFs  see pix in other post  the other is dot3 bump mapping. > > > > I have some questions about using them in practice, I think I > > understand the > > theory already. > > > > 1) The NVShaderAid app has 3 flavors of bump mapping  > >  a 3 pass one (diffuse tex + diffuse bump + specular bump) where the > > second two passes dot the bump map with the texel from a > > normalization cube > > map. > >  two single pass methods which are approximately the same, > > and don't use > > the cube map. > > > > Is it a serious disadvantage in practice not to use the > > normal maps and save > > 2 passes? > > I've never noticed anything glaringly wrong, and I've never used the > cubemap normaliser. > > > I doubt it as the results in the shader aid look > > very similar. > > Is it correct that this is directly a function of triangle > > size, as the > > larger the triangle is, the larger the drift from the > > normalized vector due > > to denormalization due to bilinear interpolation of color across the > > triangle surface? This doesn't seem to be confirmed in > > practice: if you > > select the cube model in the shader aid, it has only 12 > > triangles, but it > > still looks great. > > Slightly wrong, but still great, yes. If you have a bumpy surface, it's very > hard to see the difference. It's only when you have large areas that are > poorly tesselated _and_ not bumpy that there is much difference. Usually, > this never happens, and when it does, it seems to me to be far easier, and > faster (why burn a cubemap stage?), just to ask an artist to tesselate the > area a few more times. > > > (NB: I found a way with the reg combiners to square the > > specular term an > > additional time in the robust version. :) ) > > Cunning. Specular's a pig. The specular term really needs to be done using a > 1D texture lookup, e.g. using EMBM or something. > > > 2) Are people really doing several passes when there are > > several lights in > > play, or are they just picking the single most dominant > > light? Is it not a > > problem when there is a visual discontinuity due to the dominant light > > changing? I think it is really prohibitive to do the 3 pass > > method for, > > say, 3 lights, resulting in 7 passes. > > I would only do two passes at most. However many you decide to do, the last > pass should use a light vector that is a blend between the least brightest > lights. Hmmm, pseudocode time. > > Sort lights by brightness. > Doing n bumpmap passes. > Light 0 is the brightest light, light 1 the next brightest, etc. > for ( i = 0; i < (n1); i++ ) > { > Do bumpmap pass n with light n. > } > > float weighting = light(n).brightness  light(n+1).brightness; > weighting /= light(n1).brightness  light(n+1).brightness; > vec3 light_dir = light(n1).direction; > light_dir += wighting * light(n).direction; > > Do bumpmap pass with light_dir. > > > That way, the last bumpmap pass is light (n1), with a proportion of > light(n). If light(n1) and light(n) are the same brightness, they > contribute equally to light_dir, so they can swap over in brightness without > a bad pop. If light(n) and light(n+1) (which isn't in the blend yet) are the > same, then they can also swap order in the brightness league, and again you > won't notice any pop. > > I had a demo with eight lights orbiting a sphere, and only one actual > bumpmap pass, but using the above algorithm. Worked very well  no pops, > looked good. > > > 3) Generating the light and mirror angle vectors that go into > > the diffuse > > and specular colors: this needs a tangent space basis matrix > > per vertex. > > This consists of 3 vectors: the normal, which we already > > have, a tangent > > vector, and a third vector which is the cross product of the > > first two. Do > > people store all three vectors with the model, or do you > > think the cross > > product is cheap enough to always recompute per vertex? I am > > doing that at > > the moment and it seems to go fast enough. > > I just store them. > > > 3.5) Inverting the object transform matrix. First I thought it was > > completely loony the way the NV DX multilight bump mapping > > example actually > > uses code to invert an arbitrary 4x4 affine matrix to do this > >  I always > > just stored the transforms as scaling,3x3 rotate and > > translation, and that > > way the matrix can just be assembled either as the forward or > > the inverse > > transform relatively easily. However, I just realized that > > the inversion, > > though expensive, needs to be done only once per object > > regardless of the > > depth of the scene graph, whereas to assemble the inverse > > matrix, I have to > > traverse the whole scene graph and collect all the scalings, > > rotations, and > > translations up to the leaf I have the object in. I will > > have to try both > > and profile I guess. I am always too lazy to do that. > > Doing the full 4x4 isn't necessary  if you know that a row or column is > 0,0,0,1 a lot of the more evil maths goes away. I've never seen any matrix > inverts on any profile though, so I don't worry about them :) > > > 4) One of the demos I saw was computing normal maps on the fly, and > > computing mipmaps in a particularly clever way I didn't > > really understand. > > Mipmapping normal maps (or indeed filtering them in any way) is tricky to > get good. I think PeterPike Sloan (a Microsoft researcher) has done quite a > lot of work on this. A Google search will probably get good results. > > > At the moment I just create normal maps with a command line tool and > > generating mipmaps with the standard built in functs of the > > API, which seems > > to be ok. I'm not missing some great opportunity this way, right? > > They will be blurrier than necessary  some smarter filtering will make them > mor interesting even when mipmapped. > > > thanks, > >  > > Adam Moravanszky > > http://www.n.ethz.ch/student/adammo > > > > Tom Forsyth  purely hypothetical Muckyfoot bloke. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Dirk Reiners <reiners@ig...>  20001220 16:17:06

On Dec 18, 3:18am, Tom Hubina wrote: > Subject: Re: [Algorithms] Quadtree in 3d space, Frame coherence and Screen > At 06:02 PM 12/17/2000, you wrote: > > We don't. I don't know of anyone doing occlusion with their height field > based terrain engine right now. > > End of excerpt from Tom Hubina That's actually an interesting question. Looking at Delta Force: Land Warrior I got the impression that they do have something like visiblity on their terrain. For DFLW I can imagine it being practical and usable, as you can't get away from the surface by more than the jump height. There are some artifacts at the silhouettes of near geometry that led me to the conclusion. Can anyone confirm or deny this? On a side note: I don't like the DLFW engine much. It uses too little hysteresis, so that visible boundaries, especially silhouettes, areas of high spatial frequency (small valleys) and strong lighting differences (shadow boundaries) jump around a lot. The frame rates are ok, but the quality is worse than the old voxelbased engines, IMHO. Just my $.01 (the Euro is weak...) Dirk    Dirk Reiners reiners@..., Dirk.Reiners@...  OpenSG Forum http://www.opensg.org  Rundeturmstrasse 6 http://www.igd.fhg.de/~reiners  D64283 Darmstadt All standard disclaimers apply.  Truth is stranger than fiction because fiction has to make sense. 