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
(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: David Whatley <david@pl...>  20040430 22:32:58

Yeah, Tom should know... he's the lead guy now on RAD Game Tool's Granny=20 2 which is all about spline based animation.  David [Christian Sch=FCler on 4/30/2004 9:39 AM] >>My unenlightened approach would be: >>1) Split all euler based rotation so the x, y, z=20 >>rotation curves have keyframes at the exact same=20 >>positions. >> =20 >> > >If you store the tangents at these points too, this could work in reprod= ucing the euler curves. However after converting the keyfranes to quatern= ions, the resultant playback could be quite different. > >The suggestion of Tom is quite appropriate: Supersample the animation an= d fit splines through the data. This way you really don't care what the a= rtists did in creating the animation. I'm doing a similar scheme here and= I can export a character from Maya directly out of the rigged scene with= all it's IKhandles, custom expressions and active constraints :) > > > > > >This SF.Net email is sponsored by: Oracle 10g >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. >http://ads.osdn.com/?ad_id149&alloc_id?66&op=3Dclick >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > =20 > 
From: <christer_ericson@pl...>  20040430 22:32:47

Hamilton Feltman wrote: > the question: > is x*y == x*y? Yes, it is consistent and not random. All it is, is that the PS2 FPUs don't correctly compute the least significant bit of the mantissa for certain values and a certain ordering of the arguments. It would have been nice if it had been fully IEEE754, but it isn't. It's not a very big deal. Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Hamilton Feltman <hfeltman@lu...>  20040430 20:45:05

Oops, I meant to say with y=3D1, x*y !=3D x But the question still holds :) Hamilton Feltman LucasArts Entertainment > Original Message > From: Hamilton Feltman=20 > Sent: Friday, April 30, 2004 1:37 PM > To: 'gdalgorithmslist@...' > Subject: RE: [Algorithms] EPA : working ? >=20 >=20 > But thats not what I asked. >=20 > with y=3D1, x*y !=3D 1 > and with y=3D0, x*y !=3D 0 >=20 > you said the order matters so we can assume: > x*y !=3D y*x >=20 > the question: > is x*y =3D=3D x*y? >=20 > i.e. is it really *random*, or deterministic depending on value? >=20 >=20 > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...]On=20 > Behalf Of Tom > > Forsyth > > Sent: Thursday, April 29, 2004 11:16 PM > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] EPA : working ? > >=20 > >=20 > > x*1 is not necessarily x, and x*0 is not necessarily 0. The=20 > > bottom bit of > > the mantissa is pretty random. > >=20 > > Perversely, 1*x IS always x, and 0*x IS always 0. So the=20 > > order matters. > > (er... it may be the other way around  I forget  not that=20 > > you can usually > > control the order when coding in C). > >=20 > > And to answer your question  it's true of all FP=20 > > calculations on the whole > > machine, since the EE FP unit _is_ a VU pipe. > >=20 > > TomF. > >=20 > > > Original Message > > > From: gdalgorithmslistadmin@...=20 > > > [mailto:gdalgorithmslistadmin@...] On=20 > > > Behalf Of Chapman, Greg > > > Sent: 29 April 2004 12:07 > > > To: gdalgorithmslist@... > > > Subject: RE: [Algorithms] EPA : working ? > > >=20 > > >=20 > > > Just some vector unit fun  there's an error of one bit,=20 > so a value > > > multiplied by one is not promised to be the same value.=20 > > There are some > > > easy workarounds, though. > > >=20 > > > It causes all sorts of fun while track bugs if you're not=20 > > aware of the > > > problem while writing your microcode. > > >=20 > > > Original Message > > >=20 > > > Are you saying that the ps2 comes up with different=20 > results for the > > > exact same computation? On which processor, the ee or the=20 > > vu's? I'd be > > > interested to know if this algorithm fails on that platform. > >=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.=20 > > 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 > >=20 > >=20 >=20 
From: Hamilton Feltman <hfeltman@lu...>  20040430 20:37:00

But thats not what I asked. with y=3D1, x*y !=3D 1 and with y=3D0, x*y !=3D 0 you said the order matters so we can assume: x*y !=3D y*x the question: is x*y =3D=3D x*y? i.e. is it really *random*, or deterministic depending on value? > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of Tom > Forsyth > Sent: Thursday, April 29, 2004 11:16 PM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] EPA : working ? >=20 >=20 > x*1 is not necessarily x, and x*0 is not necessarily 0. The=20 > bottom bit of > the mantissa is pretty random. >=20 > Perversely, 1*x IS always x, and 0*x IS always 0. So the=20 > order matters. > (er... it may be the other way around  I forget  not that=20 > you can usually > control the order when coding in C). >=20 > And to answer your question  it's true of all FP=20 > calculations on the whole > machine, since the EE FP unit _is_ a VU pipe. >=20 > TomF. >=20 > > Original Message > > From: gdalgorithmslistadmin@...=20 > > [mailto:gdalgorithmslistadmin@...] On=20 > > Behalf Of Chapman, Greg > > Sent: 29 April 2004 12:07 > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] EPA : working ? > >=20 > >=20 > > 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.=20 > There are some > > easy workarounds, though. > >=20 > > It causes all sorts of fun while track bugs if you're not=20 > aware of the > > problem while writing your microcode. > >=20 > > Original Message > >=20 > > Are you saying that the ps2 comes up with different results for the > > exact same computation? On which processor, the ee or the=20 > vu's? I'd be > > interested to know if this algorithm fails on that platform. >=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.=20 > 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 >=20 >=20 
From: Alen Ladavac <alenlml@cr...>  20040430 17:45:28

Thanks Pierre! /me Bangs head on the desk for not reading GPG4 already  its how lack of time for reading makes you spend even more time researching on your own. :/ Btw, while I wait for that copy of GPG4 to fly over here... do you have any similar references that are available online? Thanks, Alen  Original Message  From: "Pierre Terdiman" <pierre.terdiman@...> To: <gdalgorithmslist@...> Sent: Friday, April 30, 2004 13:08 Subject: Re: [Algorithms] Box<>Tri(Mesh) contact filtering > >No, I was refering to the convex hull idea as an eg of a way/situ in which > contacts can be discarded. > > FYI we wrote about this convex hull thing in our GPG4 article about contact > reduction.... I didn't follow the thread but it might be worth looking at ? > >  Pierre > > > > >  > 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...>  20040430 17:45:27

>I begin to wonder if we should take this conversation offlist as it >doesn't seem to be generating a whole lot of interest. Dunno... I prefer talking about stuff on the list, because it might provoke some nice ideas from other people, e.g. Pierre gave us something very nice to check. ;) > [eliminating edgebased contacts in favor of facebased, if they are coplanar] I believe that it cannot falsely discard info, but it would catch only cases between two coplanar triangles. But the same problem happens on edges between nocoplanar tris  e.g. on hilltops and in valleys on terrain. In these cases, separation normal directed along triangle normal is also dominant. Perhaps it would be good to always discard edgebased contacts in favor of facebased if the two are very close? Btw, this might be a good solution for boxes, but doesn't really fix the same problem that happens with other shapes, e.g. capsule (capped cylinder), or sphere. In case of a sphere rolling over terrain, if amount of penetration is not insignificant, when it reaches an edge, it will generate a very similar spurious contact with the edge, in addition to one with face of the triangle directly below its center. In this case the two contacts are not located near each other, yet the edge contact is completely bogus. Now that I'm thinking about it... I believe I remember someone sometimes said something about using gouraudstyle normal interpolation for colliding spheres with a mesh, for smoother transitions. Perhaps Pierre knows something about it  I believe Novodex was mentioned in the context. Now, interpolated normals might help here as well. Even for boxes. You might evaluate the interpolated triangle mesh normal at the contact point, and if it is more than say 45 degrees away from the contact normal, ignore the contact. Or some variation on that. Hm... will rethink this more and let you know what I find in the morning. Alen 
From: <c.schueler@ph...>  20040430 14:45:57

> My unenlightened approach would be: > 1) Split all euler based rotation so the x, y, z=20 > rotation curves have keyframes at the exact same=20 > positions. If you store the tangents at these points too, this could work in = reproducing the euler curves. However after converting the keyfranes to = quaternions, the resultant playback could be quite different. The suggestion of Tom is quite appropriate: Supersample the animation = and fit splines through the data. This way you really don't care what = the artists did in creating the animation. I'm doing a similar scheme = here and I can export a character from Maya directly out of the rigged = scene with all it's IKhandles, custom expressions and active = constraints :) 
From: Eric Chadwick <echadwick@wh...>  20040430 14:30:34

I can't provide any algorithm insight, but I can point out 3rd party plugins/scripts that work with max. I try to keep tabs on what's available. There isn't really a uvspider for max (yet... some similar plugins are in development, they should be released by summer's end). A few alternatives: http://w3.enternet.hu/godzola/ScriptSide/ A manuallyoperated uvspider. Doesn't curve the UVs though. And creates a ton of unique TVs (although autowelding can fix most of this). http://www.texturetools.com/TrUV.asp I haven't tried this one. http://www.maxplugins.de/comm.php?search=3Dspline%20segment Another splinemapping plugin. Simpler (and cheaper) than the Texture Layers plugin I mentioned before. http://www.scriptspot.com/Main_Scripts.asp?BrowseType=3DSearch&Sort=3DNam= e&S T=3D1&SearchField=3Dgametools http://www.chuggnut.com/scripts/unwraptools/unwraptools.htm You might be able to get some ideas from this examining these scripts. Anyhow, I hope this helps you (and your artists). Original Message From: Joris Mans [mailto:joris.mans@...]=20 Sent: Thursday, April 29, 2004 9:25 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Generating uv coordinates which follow a shape Is there such a thing as uv spider for max? 
From: Emanuele Salvucci <info@fo...>  20040430 13:58:56

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

Pierre, Thanks for the reference. I did take a brief look your article a few = days ago. The convex hull idea is a really nice one, you also talk about = use of edge/vert/face etc. "database" approach which seems very = sensible. Did you go for edgelists and so forth having failed with other = angles of attack? Bob. > Original Message > From: Pierre Terdiman [mailto:pierre.terdiman@...] > Sent: 30 April 2004 14:09 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Box<>Tri(Mesh) contact filtering >=20 >=20 > >No, I was refering to the convex hull idea as an eg of a=20 > way/situ in which > contacts can be discarded. >=20 > FYI we wrote about this convex hull thing in our GPG4 article=20 > about contact > reduction.... I didn't follow the thread but it might be=20 > worth looking at ? >=20 >  Pierre >=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.=20 > 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 >=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: Pierre Terdiman <pierre.terdiman@no...>  20040430 12:58:09

>No, I was refering to the convex hull idea as an eg of a way/situ in which contacts can be discarded. FYI we wrote about this convex hull thing in our GPG4 article about contact reduction.... I didn't follow the thread but it might be worth looking at ?  Pierre 
From: Bob Dowland <Bob.Dowland@bl...>  20040430 11:56:01

Hi Alen, I begin to wonder if we should take this conversation offlist as it = doesn't seem to be generating a whole lot of interest. I also feel that = I'm scratching around for ideas at the moment rather than offering = anything of general interest. Anyways... I should answer some of these = points in the meantime. > What exactly would classify as coplanar contact points? You=20 > can't remove any of four points if box lies on a plane, e.g., right? I'm proposing a slightly more restrictive definition of coplanar by = saying that two boxtri contacts are "coplanar" if the respective tris = are coplanar. Examples would be two contacts on the same tri or two = contacts on different tris which are coplanar with eachother. Because = tris are clipped to the interior of boxes this definition should always = give points that satisfy the usual one but not necessarily vice versa. = The intention is to find a way to group contacts that helps to recover = some of the highlevel structure of the mesh. > >contacts" can be dumped with impunity. for eg below >=20 > Is this also not a finished sentence? No, I was refering to the convex hull idea as an eg of a way/situ in = which contacts can be discarded. > that would be an excellent great simplification. sadly not mine  :) > >the whole lot can be discarded and the contact can be recomputed as a > >box<>plane contact. >=20 > But, you cannot really do that with one contact. Can you? It=20 > would need at > least 4 points to balance the box properly. Yes  if the box is just sitting there, but there could of course be = less than four points depending on the sort of contact eg. an impact = might just be one, a deep impact might yeild three(?). Again I'm really = just trying to find ways to infer highlevel mesh structure. > What with penetration? As you pointed out before you can get sep norms that are artefactual (if = this is a word) in that they arise becase of the pertri cd approach  = usually least penetrated direction is the normal right? Our penetration = values are dependent on the sep norm choice, if we change the one = (because we deduced that it was nonsense in the given context) then we = need to consider changing the other. > Btw, this still doesn't tack the problem at edges, does it? :/ Errhh, no.. although aspects of these ideas may help. Here's what I mean =  at a shared edge we get one of these screwy edge contacts because on = one side of the edge we're sitting on the flat of the tri, on the other = we're just touching it's edge. In our contact set there exist two = "coplanar" (in the above sense) contacts with points very close together = (spatially) but with sep norms that don't agree. If one of the contacts = is from the "good side" it will have sep norm parallel to tri norm and = only the other will have the edge direction sep norm. Now I've not fully = tested this but I'd say that is enough to eliminate srewy edge contacts = in this kind of scenario. Can you think of any cases that might be = missed or result in falsely discarded info from such a scheme? Bob. > Original Message > From: Alen Ladavac [mailto:alenlml@...] > Sent: 29 April 2004 17:13 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Box<>Tri(Mesh) contact filtering >=20 >=20 > > 1 eliminate duplicates: > [snip] > > So this is a no brainer. >=20 > Agreed. >=20 > > 2 identify coplanar contact points: >=20 > What exactly would classify as coplanar contact points? You=20 > can't remove any > of four points if box lies on a plane, e.g., right? >=20 > >this can be done quite cheaply as we keep both tri and sep=20 > normals in a > >boxtri contact: the trinormal and the sep normal. If one is=20 > 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 =20 > certain "coplanar > >contacts" can be dumped with impunity. for eg below >=20 > Is this also not a finished sentence? >=20 > > 3 convex hull points: > Clearly one can compute a 2D convex hull of the contacts=20 > (once grouped as in > 2) and at least in some cases discard everything except those=20 > hull points. >=20 > Yes, that would be an excellent great simplification. Speedup might be > questionable, but stability could be improved a bit with it. Perhaps. >=20 > >on a good day (not always) this will make a contact set with=20 > an unequivocal > >separating plane. If the convex hull contains only box=20 > surface points then > >the whole lot can be discarded and the contact can be recomputed as a > >box<>plane contact. >=20 > But, you cannot really do that with one contact. Can you? It=20 > would need at > least 4 points to balance the box properly. >=20 > >These are the sort of avenues I've been exploring, but there=20 > are lots of > >gotchas  penetration is one area that needs to be=20 > addressed. In general I > >think one can get away with a pretty redundant contact set=20 > (depending on > >solution method) but once you start filtering a lot of=20 > special cases can > >start being missed  so on a general note as is often the=20 > case the less one > >can get away with, the better. >=20 > What with penetration? >=20 > Btw, this still doesn't tack the problem at edges, does it? :/ >=20 > Alen >=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.=20 > 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 >=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: Chris Green <chrisg@lp...>  20040430 11:52:53

What you are trying to do here is very similar to cloth simulation (except that you are trying to preserve length in texture space instead of world space). You could try the technique from this url: http://www.ioi.dk/Homepages/thomasj/publications/gdc2001.htm. The ease of implementation definitely makes it worth a try. Joris Mans wrote: >Hi > >I ve been fiddling with this for some days, but don't seem to come up >with a "general" solution. >The problem is the following: >Assume a planar mesh. I want to define uvs over that mesh in the >following way. I have 4 corner vertices on the mesh which will contain >mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are >calculated by iterating over the border and using the piecewise distance >of each line segment to define the interpolated values: > >Mapping[ k ] > = Mapping[ corner_index ] > + ( Mapping[ next_corner_index ]  Mapping[ corner_index >] ) > * ( distance(corner_index,k) / >distance(corner_index,next_corner_index) > >Whereby distance just sums up all the edge lengths from one vertex upto >another, following the border of the mesh. > >Now this was the easy part, the hard part is assigning the uvs to the >nonborder vertices. And this is where I am getting stuck. The problem >is that the internal uvs should follow as good as possible, to minimize >distortion issues. I ve been trying by using a massspring system on the >mapping coordinates, and fixing the border verts so they cant move, but >getting a good configuration to start the simulation is already a >problem, coz you need to choose start positions for the internal >vertices, spring rest lengths and so on. >I tried several "project internal vertices on borders and interpolate" >approaches, but for all of those its quite easy to find a case where it >breaks down. > >Here you see an example of what I want to achieve: > >http://users.pandora.be/ir_fuel/face_mapping_problem.jpg > > >Oh, and I tried asking the artist to use Nurbs, which would give me a >nice parametrization to define the mapping, but that doesn't seem to be >the solution he is looking for ;) ;) > > >Joris > > > > >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > 
From: Emanuele Salvucci <info@fo...>  20040430 11:07:40

Interesting! ...but looks like there're missing images on the last two pages of your paper... would it be possible to see the results? Thanks! Best, Emanuele.  Original Message  From: "Gaël LEQUEUX" <gael.sc2x@...> To: <gdalgorithmslist@...> Sent: Friday, April 30, 2004 11:16 AM Subject: RE: [Algorithms] Generating uv coordinates which follow a shape Hi, A few years ago I wrote a MAX plugin that did exactly what your are trying to do :) (mapping a flag for example). Yes, border UV was the easy part, for the other points, I first assigned UV with a simple projection and then I used Discrete Smooth Interpolation (iterative relaxation) to equalize texel density. Here is where you'll find what you need : http://www.loria.fr/~levy/Papers/1998/s1998_textures.pdf Gaël Message d'origine De : gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] De la part de Joris Mans Envoyé : vendredi 30 avril 2004 01:54 À : gdalgorithmslist@... Objet : [Algorithms] Generating uv coordinates which follow a shape Hi I ve been fiddling with this for some days, but don't seem to come up with a "general" solution. The problem is the following: Assume a planar mesh. I want to define uvs over that mesh in the following way. I have 4 corner vertices on the mesh which will contain mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are calculated by iterating over the border and using the piecewise distance of each line segment to define the interpolated values: Mapping[ k ] = Mapping[ corner_index ] + ( Mapping[ next_corner_index ]  Mapping[ corner_index ] ) * ( distance(corner_index,k) / distance(corner_index,next_corner_index) Whereby distance just sums up all the edge lengths from one vertex upto another, following the border of the mesh. Now this was the easy part, the hard part is assigning the uvs to the nonborder vertices. And this is where I am getting stuck. The problem is that the internal uvs should follow as good as possible, to minimize distortion issues. I ve been trying by using a massspring system on the mapping coordinates, and fixing the border verts so they cant move, but getting a good configuration to start the simulation is already a problem, coz you need to choose start positions for the internal vertices, spring rest lengths and so on. I tried several "project internal vertices on borders and interpolate" approaches, but for all of those its quite easy to find a case where it breaks down. Here you see an example of what I want to achieve: http://users.pandora.be/ir_fuel/face_mapping_problem.jpg Oh, and I tried asking the artist to use Nurbs, which would give me a nice parametrization to define the mapping, but that doesn't seem to be the solution he is looking for ;) ;) Joris  This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_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: <gael.sc2x@la...>  20040430 09:17:00

Hi, A few years ago I wrote a MAX plugin that did exactly what your are = trying to do :) (mapping a flag for example). Yes, border UV was the easy part, for the other points, I first assigned = UV with a simple projection and then I used Discrete Smooth Interpolation (iterative relaxation) to equalize texel density. Here is where you'll find what you need : http://www.loria.fr/~levy/Papers/1998/s1998_textures.pdf Ga=EBl Message d'origine De=A0: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] De la part de = Joris Mans Envoy=E9=A0: vendredi 30 avril 2004 01:54 =C0=A0: gdalgorithmslist@... Objet=A0: [Algorithms] Generating uv coordinates which follow a shape Hi I ve been fiddling with this for some days, but don't seem to come up with a "general" solution. The problem is the following: Assume a planar mesh. I want to define uvs over that mesh in the following way. I have 4 corner vertices on the mesh which will contain mapping coords 0,0 1,0 1,1 0,1. The uvs on the border of the mesh are calculated by iterating over the border and using the piecewise distance of each line segment to define the interpolated values: Mapping[ k ]=20 =3D Mapping[ corner_index ]=20 + ( Mapping[ next_corner_index ]  Mapping[ corner_index ] )=20 * ( distance(corner_index,k) / distance(corner_index,next_corner_index) Whereby distance just sums up all the edge lengths from one vertex upto another, following the border of the mesh. Now this was the easy part, the hard part is assigning the uvs to the nonborder vertices. And this is where I am getting stuck. The problem is that the internal uvs should follow as good as possible, to minimize distortion issues. I ve been trying by using a massspring system on the mapping coordinates, and fixing the border verts so they cant move, but getting a good configuration to start the simulation is already a problem, coz you need to choose start positions for the internal vertices, spring rest lengths and so on. I tried several "project internal vertices on borders and interpolate" approaches, but for all of those its quite easy to find a case where it breaks down. Here you see an example of what I want to achieve: http://users.pandora.be/ir_fuel/face_mapping_problem.jpg Oh, and I tried asking the artist to use Nurbs, which would give me a nice parametrization to define the mapping, but that doesn't seem to be the solution he is looking for ;) ;) Joris  This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. = Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=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: Sergei Miloikov <sergei@ha...>  20040430 08:04:19

Do you batch skinned objects too? We couldn't pack more that 2 together, because of the limited amount of constants. We have similar systemfor instancing stones&grass patches  one stream with height/probability per patch. In vs we can collapse vertices by the 'probability' and thus getting almost different looking patches  trading vertex processing for memory of course. However, I expirienced very bad slowdowns of nv30 family on some multistream scenarios, probably a driver bug. Half the framerate just goes away...  Original Message  From: "Deano Calver" <deano@...> To: <gdalgorithmslist@...> Sent: Friday, April 30, 2004 10:20 AM Subject: Re: [Algorithms] Streaming Transforms > John W. Ratcliff wrote: > > >With the Nv40 coming out there are soon going to be cards that will let > >you render massive numbers of instanced objects without constantly > >stalling out. > > > >For quite some time we have been told to perform as few state changes as > >possible. However, when a transform is considered a 'state change' this > >has prevented developers from doing massive (on the order or tens of > >thousands) of dynamic objects at high framerate; even if the sum total > >of those objects did not actually come near the triangle throughput of > >the card. > > > > > Without the new vertex frequency API (had a quick look but haven't any > time for a serious play yet), on PC the method we use is the indexed > matrix transform method. For objects I know are going to be render alot > of times I create vertex and index buffers that repeat the vertices n > times (upto 48 on 256 vertex constants) with an additional element with > index number. Rendering a new instance then just consists of copying the > matrix and increasing the triangle count, when the batch needs flushing, > change material once, render the instances, repeat. > > >I'm currently exploring how to render the theoretical maximum number of > >instanced objects possible at high frame rate on the Nv40. > > > >Once you start dealing with massive numbers of low polygon instanced > >objects; very quickly you realize that just the transform data itself > >can add up to a lot of memory. > > > >I am curious if you guys can think of more efficient ways to send > >transform data in massive quantities. For example, representing all of > >your transforms as a quaternion and a translation would take less than > >half as much bandwidth as a full 4x4 matrix (assuming of course your > >objects have no scale.) > > > > > If you using an NV40 there are lots of interesting ways of effectively > compressing that amount of for data each instance. One method I've used > on a PS2 micromesh renderer in the past (that should be possible on > NV40) for grass and rocks was to pass a heightfield for all the batches > and each instance just has 2D heightfield coordinates and a single angle > (for rotation around a vertical y axis). Each instances parameter > (encoded in the stream once per object) was then just 3 floats (in > constant memory, compressed before stream decode). > I've also used quaternion and translation for more general cases, I > suspect that bandwidth won't be an issue with the frequency stuff. If > the objects only have a few hundred triangles, you used compressed > vertices and compressed instance data, the actual bandwidth used should > be minimal. Including index data (pity we don't have single byte > indices...) each instance should be around 200 * 6 bytes (3 indices of 2 > bytes) + 200 * 10 (e.g. extremely compressed vertex) + 16 bytes > (compressed quat+translation instance data) = 3216 bytes. Considering > that a fair amount will probably be in on chip caches for the other > instances, bandwidth shouldn't be a problem. > > >There is also the challenge of trying to manage this many entities > >without iterating through them in various portions of your pipeline. > > > >Thoughts? > > > > > Doing things like not putting flags in the body of each entities has > saved us time due to better cache hits. The best rule is not to pollute > the cache for entites that aren't important this frame, that tends to > mean things tightly packing on/off and visiblity info in a structure > seperate from the main entity info. > > Deano > > >  > 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: Sergei Miloikov <sergei@ha...>  20040430 07:59:40

Most of the skinned models just stands (right?)  so, single sin/cos + short4 position will do the job. For others  did matrices really take so much space? The transform stream samples each transform each vertex, but that is cached, isn't it? We skin our characters with different colors & masks too and it look quite fine. But it is quite an efford to pack into batch more that (even) one model with bones, I mean  <16 bones + colors/light pos/etc. and constants are over.  Original Message  From: "Jon Watte" <hplus@...> To: <gdalgorithmslist@...> Sent: Friday, April 30, 2004 8:58 AM Subject: RE: [Algorithms] Streaming Transforms > > Character animation is core to our business, but alas we can't afford to > target anything like this sexy hardware. That doesn't prevent me from > thinking about it, though ;) > > My thought is that animations, both quaternions and translations, and > blending/morph targets, will be uploaded as texture data. Because you can > specify separate derivatives for u and v directions, it should be possible > to use this to blend smoothly across time (u direction) while getting full > resolution along bone or vertex (v direction). > > Upload the world transform per mesh into a texture, and then all you render > per mesh is a list of indices for vertices (so you know which index to read > out of the texturetargetasvertexarray) and a, much coarser strided, list > of world transform indices; one per mesh instance. > > You can also blend between multiple separate animation kinds, either by > texturing out of more than one texture, or rendering all the blended > textures into a render target, and then using that as input when > transforming the vertices. Send a few blend targets and animation index > offsets extra per mesh, and you should be all set to go. > > And we get blending with 16bit floating point formats. I really think that > someone sitting down and doing a clean engine from scratch, based on this > hardware, will come up with something remarkable! > > You may, in the end, need to use matrices, or 32bit formats because of > precision issues, but thinking hard about it, that really seems like a > straight way forward. > > The only thing I haven't quite figured out is how to uniquely texture them. > Although you could send permesh color values (skin tone, clothing colors, > etc) and use those to map one or a few master "selector" textures and > overlay some detail. > > Cheers, > > / h+ > > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of John > W. Ratcliff > Sent: Thursday, April 29, 2004 6:25 PM > To: gdalgorithmslist@... > Subject: [Algorithms] Streaming Transforms > > > With the Nv40 coming out there are soon going to be cards that will let > you render massive numbers of instanced objects without constantly > stalling out. > > For quite some time we have been told to perform as few state changes as > possible. However, when a transform is considered a 'state change' this > has prevented developers from doing massive (on the order or tens of > thousands) of dynamic objects at high framerate; even if the sum total > of those objects did not actually come near the triangle throughput of > the card. > > I'm currently exploring how to render the theoretical maximum number of > instanced objects possible at high frame rate on the Nv40. > > Once you start dealing with massive numbers of low polygon instanced > objects; very quickly you realize that just the transform data itself > can add up to a lot of memory. > > I am curious if you guys can think of more efficient ways to send > transform data in massive quantities. For example, representing all of > your transforms as a quaternion and a translation would take less than > half as much bandwidth as a full 4x4 matrix (assuming of course your > objects have no scale.) > > There is also the challenge of trying to manage this many entities > without iterating through them in various portions of your pipeline. > > Thoughts? > > > > >  > 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: Deano Calver <deano@ra...>  20040430 07:20:46

John W. Ratcliff wrote: >With the Nv40 coming out there are soon going to be cards that will let >you render massive numbers of instanced objects without constantly >stalling out. > >For quite some time we have been told to perform as few state changes as >possible. However, when a transform is considered a 'state change' this >has prevented developers from doing massive (on the order or tens of >thousands) of dynamic objects at high framerate; even if the sum total >of those objects did not actually come near the triangle throughput of >the card. > > Without the new vertex frequency API (had a quick look but haven't any time for a serious play yet), on PC the method we use is the indexed matrix transform method. For objects I know are going to be render alot of times I create vertex and index buffers that repeat the vertices n times (upto 48 on 256 vertex constants) with an additional element with index number. Rendering a new instance then just consists of copying the matrix and increasing the triangle count, when the batch needs flushing, change material once, render the instances, repeat. >I'm currently exploring how to render the theoretical maximum number of >instanced objects possible at high frame rate on the Nv40. > >Once you start dealing with massive numbers of low polygon instanced >objects; very quickly you realize that just the transform data itself >can add up to a lot of memory. > >I am curious if you guys can think of more efficient ways to send >transform data in massive quantities. For example, representing all of >your transforms as a quaternion and a translation would take less than >half as much bandwidth as a full 4x4 matrix (assuming of course your >objects have no scale.) > > If you using an NV40 there are lots of interesting ways of effectively compressing that amount of for data each instance. One method I've used on a PS2 micromesh renderer in the past (that should be possible on NV40) for grass and rocks was to pass a heightfield for all the batches and each instance just has 2D heightfield coordinates and a single angle (for rotation around a vertical y axis). Each instances parameter (encoded in the stream once per object) was then just 3 floats (in constant memory, compressed before stream decode). I've also used quaternion and translation for more general cases, I suspect that bandwidth won't be an issue with the frequency stuff. If the objects only have a few hundred triangles, you used compressed vertices and compressed instance data, the actual bandwidth used should be minimal. Including index data (pity we don't have single byte indices...) each instance should be around 200 * 6 bytes (3 indices of 2 bytes) + 200 * 10 (e.g. extremely compressed vertex) + 16 bytes (compressed quat+translation instance data) = 3216 bytes. Considering that a fair amount will probably be in on chip caches for the other instances, bandwidth shouldn't be a problem. >There is also the challenge of trying to manage this many entities >without iterating through them in various portions of your pipeline. > >Thoughts? > > Doing things like not putting flags in the body of each entities has saved us time due to better cache hits. The best rule is not to pollute the cache for entites that aren't important this frame, that tends to mean things tightly packing on/off and visiblity info in a structure seperate from the main entity info. Deano 
From: Tom Forsyth <tom.forsyth@ee...>  20040430 06:15:39

x*1 is not necessarily x, and x*0 is not necessarily 0. The bottom bit of the mantissa is pretty random. Perversely, 1*x IS always x, and 0*x IS always 0. So the order matters. (er... it may be the other way around  I forget  not that you can usually control the order when coding in C). And to answer your question  it's true of all FP calculations on the whole machine, since the EE FP unit _is_ a VU pipe. TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Chapman, Greg > Sent: 29 April 2004 12:07 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] EPA : working ? > > > 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: Tom Forsyth <tom.forsyth@ee...>  20040430 06:11:10

By far the easiest and most reliable method (and the one Graany uses) is = to sample the animation at a "fast enough" rate (in this case, half the = period between the closest two Euler knots should do it). Then convert all the = 3x3 matrices to quats. The fit splines through them. I think the direct conversion from Euler splines to quat splines is fraught with woe and strife. Plus, not it doesnt matter what your input is  could be Eulers, could be keyframes, could be RNGs. Who cares? On the question of "how do I find the tangent to a Hermite curve"  a = bit of googling should get you what you need to know. Hermite curves (and most other curve types) can be evaluated by summing their basis functions multiplied by their control points. To find the tangents, differentiate = the basis functions and multiply and sum in the same way  voila  the = tangent. But you're quite correct that this might not be a terribly meaningful = value when you're using Euler curves, hence my recommendation to sample the = thing and then refit a spline to the samples. I think Casey Muratori has = posted before about how this splinefitting works. TomF. > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Joe Ante > Sent: 29 April 2004 11:40 > To: gdalgorithmslist@... > Subject: [Algorithms] Animation splines >=20 >=20 > Hi, >=20 > I want to convert some euler based rotation hermite splines=20 > into quaternion > based hermite splines. >=20 > 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. >=20 > I cant figure out how to solve the first problem. Basically=20 > how do I insert > a keyframe which will not change the appearance of the curve? >=20 > Is it enough to calculate the tangent at the position I want=20 > to insert the > keyframe and use that as the tangent? > How do I calculate the tangent at an arbitrary position in the curve? >=20 >=20 > 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=20 > different. Is this a > problem visible in a game? What are your experiences? > Or are you forcing artists to use quaternion splines for animation? >=20 > Joachim Ante=20 > http://www.otee.dk >=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_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 >=20 
From: Ryan Greene <rgreene@qu...>  20040430 06:03:10

How are you guys resolving NPC positions in your games? Right now in our = game the steering and formation code is determining an optimal position = for each NPC as they move through the world, which largely works on the = xz plane. However, we need to resolve the y component of an NPCs = position, as well as have external forces modify the position of NPCs = (ie gravity). So given a desired direction and magnitude, I see two = options: 1. Assume the NPC stepped however much it wanted to that frame, then add = a constant artificial value to the y component, and let the NPC "fall" = for a given distance. An example would be, move the NPC up by .25m, then = fall for .5m. If the NPC doesn't hit anything on his instantaneous = "fall", then it can be assumed the NPC stepped off the edge of a cliff = or something equally foolish, and then they switch to a state in which = gravity takes over. 2. Use a rigid body physics package to resolve positions. Use the = direction vector for where we want the NPC to go and apply this as a = momentum to the NPC's physics object. Right now I'm thinking the ideal = geometry for this would be an inverted cone, where the point of the cone = represents the tip of the characters feet. The height of the cone would = dictate the maximum vertical height the NPC could climb (ie, stairs). = This is nice because external forces are now implicitly solved by the = physics simulator. Problems: 1. If your stepup value is too low, you may enter a state of improper = falling. For instance, if you attempt to climb a large slope and for the = given step at that frame, you needed to move up by .3m, in our example, = we would start falling until we found something solid underfoot. Also, = we want our stepup value to be constant, and not dependent on time, = otherwise if we had a dip in framerate, we might allow the character to = warp up to the next level in a multfloor building; this implies that we = have to have a sufficiently large stepup (and fall down), yet one that = isn't too big such as to cause the character to jump up cliffs. 2. NPC movement code because much more complicated. Steering and = formation code now no longer have the ultimate say on where NPCs are = positioned, and have to be told where they are (this currently breaks = our formation code, but if this is a workable solution, I'm willing to = accept that). How about sliding on gentle slopes? If our cone is axis = locked (which it would be) the tip of the cone is going to be the only = contact point with a nearlevel terrain, however gravity would probably = be constantly pulling it down  can this be fixed by offering very high = friction coefficients? Both of these techniques offer some ugly problems, and neither one is = really looking all that good to me (although I prefer the second, simply = because I haven't done it yet :). What's the third option, or how have = you gotten around the problems that I have? Better yet, what problems = are there with the second approach that I haven't hit yet? 
From: Jon Watte <hplus@mi...>  20040430 05:58:48

> > same thing as assuming the mesh has a defined hairline crack, > > as above. Thus, follow each edge and assign the U, V in an > > interpolative fashion. > This I don't get, how can I interpolate from an edge vertex to a > nonedge vertex, when I only have 1 known uv pair, namely that of the > edge vertex? You have all of the vertices and their connectedness info; each vertex knows who its neighbors are and what the distances to those neighbors are. 1) Generate edge vertices, and interpolate these. I'm assuming this part is clear. 2) "color" each edge vert with one of four colors, let's call them "north", "south", "east" and "west". Typically, "south" will be the side from (0,0) to (1,0) (assuming u grows right and v grows up). 2) For each interior vert, find the shortest distance to each of the colored edges, by following connected edges. This is easiest done in O(n) by first precalculating by just floodfilling distance from each known vert, accumulating additional distance traveled as you go, a la Dijkstra's algorithm. (If memory serves  been a while since college :) 3) No, you have distance to north, south, east and west edges for each vertex. There are two ways to go: 3a) "south" means "v == 0" and "north" means "v == 1"; use distancetosouth/(distancetonorth + distancetosouth) as your V coordinate. Same with west/east/U. 3b) for each of the closest edge vertices, take their U/V coordianates, and weight them equally based on the respective distances. Cheers, / h+ 
From: Jon Watte <hplus@mi...>  20040430 05:58:48

Character animation is core to our business, but alas we can't afford to target anything like this sexy hardware. That doesn't prevent me from thinking about it, though ;) My thought is that animations, both quaternions and translations, and blending/morph targets, will be uploaded as texture data. Because you can specify separate derivatives for u and v directions, it should be possible to use this to blend smoothly across time (u direction) while getting full resolution along bone or vertex (v direction). Upload the world transform per mesh into a texture, and then all you render per mesh is a list of indices for vertices (so you know which index to read out of the texturetargetasvertexarray) and a, much coarser strided, list of world transform indices; one per mesh instance. You can also blend between multiple separate animation kinds, either by texturing out of more than one texture, or rendering all the blended textures into a render target, and then using that as input when transforming the vertices. Send a few blend targets and animation index offsets extra per mesh, and you should be all set to go. And we get blending with 16bit floating point formats. I really think that someone sitting down and doing a clean engine from scratch, based on this hardware, will come up with something remarkable! You may, in the end, need to use matrices, or 32bit formats because of precision issues, but thinking hard about it, that really seems like a straight way forward. The only thing I haven't quite figured out is how to uniquely texture them. Although you could send permesh color values (skin tone, clothing colors, etc) and use those to map one or a few master "selector" textures and overlay some detail. Cheers, / h+ Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of John W. Ratcliff Sent: Thursday, April 29, 2004 6:25 PM To: gdalgorithmslist@... Subject: [Algorithms] Streaming Transforms With the Nv40 coming out there are soon going to be cards that will let you render massive numbers of instanced objects without constantly stalling out. For quite some time we have been told to perform as few state changes as possible. However, when a transform is considered a 'state change' this has prevented developers from doing massive (on the order or tens of thousands) of dynamic objects at high framerate; even if the sum total of those objects did not actually come near the triangle throughput of the card. I'm currently exploring how to render the theoretical maximum number of instanced objects possible at high frame rate on the Nv40. Once you start dealing with massive numbers of low polygon instanced objects; very quickly you realize that just the transform data itself can add up to a lot of memory. I am curious if you guys can think of more efficient ways to send transform data in massive quantities. For example, representing all of your transforms as a quaternion and a translation would take less than half as much bandwidth as a full 4x4 matrix (assuming of course your objects have no scale.) There is also the challenge of trying to manage this many entities without iterating through them in various portions of your pipeline. Thoughts?  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: Simon Green <SGreen@nv...>  20040430 03:09:16

One idea I've been working on recently is what I call "render to = transform array". This is similar to rendertovertexarray, but allows = you to use the GPU to calculate the transform matrix of instanced = objects. This gives you a way to directly display the results of GPUbased rigid = body or flocking simulations, for example. You don't need to update the = transform stream on the CPU, and the size of the transform data is less = of an issue because it all stays resident in video memory. Even if you = don't want to do the full simulation on the GPU, you could use it to = build the transform matrices from euler angles, or whatever. This will be possible on NV40 in OpenGL with VBO/PBO and a forthcoming = instancing extension. Simon. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] > Sent: Thursday, April 29, 2004 6:25 PM > To: gdalgorithmslist@... > Subject: [Algorithms] Streaming Transforms >=20 >=20 > With the Nv40 coming out there are soon going to be cards=20 > that will let > you render massive numbers of instanced objects without constantly > stalling out. >=20 > For quite some time we have been told to perform as few state=20 > changes as > possible. However, when a transform is considered a 'state=20 > change' this > has prevented developers from doing massive (on the order or tens of > thousands) of dynamic objects at high framerate; even if the sum total > of those objects did not actually come near the triangle throughput of > the card. >=20 > I'm currently exploring how to render the theoretical maximum=20 > number of > instanced objects possible at high frame rate on the Nv40. >=20 > Once you start dealing with massive numbers of low polygon instanced > objects; very quickly you realize that just the transform data itself > can add up to a lot of memory. =20 >=20 > I am curious if you guys can think of more efficient ways to send > transform data in massive quantities. For example,=20 > representing all of > your transforms as a quaternion and a translation would take less than > half as much bandwidth as a full 4x4 matrix (assuming of course your > objects have no scale.) >=20 > There is also the challenge of trying to manage this many entities > without iterating through them in various portions of your pipeline. >=20 > Thoughts? >=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.=20 > 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 >=20 
From: Eric Chadwick <echadwick@wh...>  20040430 01:54:55

Loft is a good way to get parametric UVs in max. If that's too limiting (it often generates too many tris), you could look into a 3rd party plugin like Texture Layers, with its uvsplinegizmos... http://www.mankua.com/texturelayers.cfm >Well, it is in 3dsmax, and it is for road mapping. >And it is not as simple as applying bend modifiers on uvs and so on;) >Our artists want to apply my plugin to a subselection of faces of a >mesh. 