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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(17) 
2

3

4

5

6
(13) 
7
(19) 
8
(5) 
9
(5) 
10

11

12
(1) 
13

14
(15) 
15
(21) 
16
(16) 
17

18

19

20
(1) 
21
(5) 
22
(2) 
23
(3) 
24
(2) 
25
(2) 
26
(1) 
27
(5) 
28
(11) 



From: Mark Wayland <Mwayland@to...>  20070222 00:19:30

I've always extracted the near, far and projection type then recalculated the z and w parts of the matrix  I can then convert from DX to any projection matrix even those with inverted Z (you know who you are! ;)). Cheers, Mark > Original Message > From: gdalgorithmslistbounces@...=20 > [mailto:gdalgorithmslistbounces@...] On=20 > Behalf Of Aras Pranckevicius > Sent: Thursday, 15 February 2007 12:06 AM > To: Game Development Algorithms > Subject: [Algorithms] Converting raw projection matrices=20 > between GL and D3D? >=20 > Hi, >=20 > Is there a way to convert just the raw projection matrix=20 > (i.e. 16 floats, no other data known) between=20 > coordinate/projection conventions of OpenGL and D3D? >=20 > What I'm looking for is a function that gets 16 floats on=20 > input and spits out 16 floats in return; handling ortho,=20 > perspective and other (think oblique) projections equally well. >=20 > I can't think of a generic method myself (just scale/bias=20 > works for ortho, but not for perspective for example), and my=20 > homogeneous math is in not very good shape... >=20 >=20 >  > Aras Pranckevicius > work: http://www.unity3d.com > home: nesnausk.org/nearaz >=20 >  >  > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveysand earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 
From: <jvsquare@nc...>  20070221 18:06:30

You could try using a symplectic integrator instead, which does a much better job of conserving energy over time than standard Euler. A simple symplectic Euler integrator just swaps the position and velocity calculations, i.e. v_{i+1} = v_i + a*dt x_{i+1} = x_i + v_{i+1}*dt While this isn't guaranteed to give you a perfect orbit, it should do a better job of keeping things from winging away from the center. There are variants of this that increment the velocity at halftime steps that are more stable still, and are related to Verlet integration. This paper might help some: http://citeseer.ist.psu.edu/hairer03geometric.html  Jim Van Verth http://www.essentialmath.com 
From: Michael Walter <michael.walter@gm...>  20070221 10:32:19

Supposedly the idea is to adjust the _speed_ ;) Regards, Michael On 2/21/07, Willem de Boer <wdeboer@...> wrote: > > > > > Velocity in 3d must be represented by 3 coordinates, and conservation of > mechanical energy is 1 equation. So > > that leaves an underconstrained problem, or a whole hyperplane of solutions > for velocity. > > Unless I'm not understanding your point.? > > > > > > From: gdalgorithmslistbounces@... > [mailto:gdalgorithmslistbounces@...] On > Behalf Of Dan White > Sent: 21 February 2007 00:36 > > To: Game Development Algorithms > Subject: Re: [Algorithms] orbital motion of particles > > > > > If you have several conservative force fields acting, you could just adjust > the velocity at the end of each step to keep the total energy (potential + > kinetic) constant. > > > > > > DanW > > > ________________________________ > > > From: gdalgorithmslistbounces@... > [mailto:gdalgorithmslistbounces@...] On > Behalf Of Juhani Honkala > Sent: Thursday, February 15, 2007 11:01 PM > To: Game Development Algorithms > Subject: Re: [Algorithms] orbital motion of particles > > Yeah, sorry about the double posting. I just started using Gmail as my > primary account and didn't recognize that it automatically filters out the > copy of my own posting. Not sure why Tom is seeing five(?) posts though. oh > well.. > > Anyway, > > There are more than a one force field in the particle system and I'm > calculating the motion of a particle by using the net sum of all forces > affecting it, for this reason just keeping the particle in the same distance > from the center wouldn't work as potentially other forces are affecting it > and moving it another direction. I also want to create smooth blendins and > make particles gradually to be affected by the vortex force. > > > Juhani > > > On 2/16/07, Tom Forsyth > <tom.forsyth.gdalgo@...> wrote: > > Five posts? Give it a rest. > > Why don't you take the distance of the particle from the centre before you > move it, then move it, then reset it to the same distance afterwards? > > TomF. > > > > Original Message > > From: gdalgorithmslistbounces@... > > [mailto:gdalgorithmslistbounces@...] > On > > Behalf Of Juhani Honkala > > Sent: 15 February 2007 21:31 > > To: Game Development Algorithms > > Subject: [Algorithms] orbital motion of particles > > > > > > Hi, > > > > I'm currently working on a particle system and trying to implement a > > Maya like vortexforce field, which should give particles > > orbital motion > > around center point on a 2Dplane(kind of a revolving cylinder). The > > problem I'm having is that everything works fine when particle > > velocities are relatively small, but due to errors in numerical > > integration, fast moving particles gradually gain nontangentical > > velocity and move away from center. I'm using constant > > timestep physics > > and classic Eulerintegration. I guess I'm looking for some > > sort of hack > > here to make this work..I could possibly take advantage of > > the constant > > timestep and add some correction factors to the velocity, but > > the exact > > math/idea escapes me. Anyone? > > > > I'm doing something like this: > > > > float currentTangentialVelocity = > > DotProduct(particleVelocity, > > tangent); //How much tangential speed a particle has > > (projection of the > > particle velocity onto tangent) > > > > //calculating tangential force accounting friction of > > the force > > field. When friction=1 particles should keep the same orbit. > > float > > tangentialForce=vortexVelocitycurrentTangentialVelocity > * > > friction; > > > > //Calculating the force applied to particle to keep it in > > orbital motion (if it didn't have any nontangential speed in > > the first > > place) > > float3 vortex = tangent * tangentialForce + (normal * > > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > > > //Euler 1st order integration step > > particleVelocity += (vortex + gravity + ... ) * dt; > > //net sum of > > forces > > particlePosition += particleVelocity * dt; > > > > > > Juhani > > > > >  > >  > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the > > chance to share your > > opinions on IT & business topics through brief surveysand earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  > Internal Virus Database is outofdate. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 > 23:39 > >  > Internal Virus Database is outofdate. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.21 /665  Release Date: > 02/02/2007 > 23:39 > > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Willem de Boer <wdeboer@mi...>  20070221 10:11:22

Velocity in 3d must be represented by 3 coordinates, and conservation of me= chanical energy is 1 equation. So that leaves an underconstrained problem, or a whole hyperplane of solutions= for velocity. Unless I'm not understanding your point.? From: gdalgorithmslistbounces@... [mailto:gdalgorithms= listbounces@...] On Behalf Of Dan White Sent: 21 February 2007 00:36 To: Game Development Algorithms Subject: Re: [Algorithms] orbital motion of particles If you have several conservative force fields acting, you could just adjust= the velocity at the end of each step to keep the total energy (potential += kinetic) constant. DanW ________________________________ From: gdalgorithmslistbounces@... [mailto:gdalgorithms= listbounces@...] On Behalf Of Juhani Honkala Sent: Thursday, February 15, 2007 11:01 PM To: Game Development Algorithms Subject: Re: [Algorithms] orbital motion of particles Yeah, sorry about the double posting. I just started using Gmail as my prim= ary account and didn't recognize that it automatically filters out the copy= of my own posting. Not sure why Tom is seeing five(?) posts though. oh wel= l.. Anyway, There are more than a one force field in the particle system and I'm calcul= ating the motion of a particle by using the net sum of all forces affecting= it, for this reason just keeping the particle in the same distance from th= e center wouldn't work as potentially other forces are affecting it and mov= ing it another direction. I also want to create smooth blendins and make p= articles gradually to be affected by the vortex force. Juhani On 2/16/07, Tom Forsyth <tom.forsyth.gdalgo@...<mailto:tom.for= syth.gdalgo@...>> wrote: Five posts? Give it a rest. Why don't you take the distance of the particle from the centre before you move it, then move it, then reset it to the same distance afterwards? TomF. > Original Message > From: gdalgorithmslistbounces@... <mailto:gdalgorithm= slistbounces@...> > [mailto:gdalgorithmslistbounces@...<mailto:gdalgorith= mslistbounces@...>] On > Behalf Of Juhani Honkala > Sent: 15 February 2007 21:31 > To: Game Development Algorithms > Subject: [Algorithms] orbital motion of particles > > > Hi, > > I'm currently working on a particle system and trying to implement a > Maya like vortexforce field, which should give particles > orbital motion > around center point on a 2Dplane(kind of a revolving cylinder). The > problem I'm having is that everything works fine when particle > velocities are relatively small, but due to errors in numerical > integration, fast moving particles gradually gain nontangentical > velocity and move away from center. I'm using constant > timestep physics > and classic Eulerintegration. I guess I'm looking for some > sort of hack > here to make this work..I could possibly take advantage of > the constant > timestep and add some correction factors to the velocity, but > the exact > math/idea escapes me. Anyone? > > I'm doing something like this: > > float currentTangentialVelocity =3D > DotProduct(particleVelocity, > tangent); //How much tangential speed a particle has > (projection of the > particle velocity onto tangent) > > //calculating tangential force accounting friction of > the force > field. When friction=3D1 particles should keep the same orbit. > float > tangentialForce=3DvortexVelocitycurrentTangentialVelocity * > friction; > > //Calculating the force applied to particle to keep it in > orbital motion (if it didn't have any nontangential speed in > the first > place) > float3 vortex =3D tangent * tangentialForce + (normal * > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > //Euler 1st order integration step > particleVelocity +=3D (vortex + gravity + ... ) * dt; > //net sum of > forces > particlePosition +=3D particleVelocity * dt; > > > Juhani > >  >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@...<mailto:GDAlgorithmslist@...= ceforge.net> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 23:39  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21 /665  Release Date: 02/02/200= 7 23:39  Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share you= r opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@...<mailto:GDAlgorithmslist@...= ceforge.net> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Dan Thompson <dan@ar...>  20070221 06:15:50

Did you have a clean OS? I had a closesocket BSOD because of Norton antivirus, and I wouldn't really put it past them to break the atomic nature of the FS. Andy Finkenstadt wrote: > I maintain what I said. The rename occurred, but the file contents > within the renamed file were missing, always at a 4k and possibly > always along a 64k boundary. This was in the face of a BSOD or a > hardlockup. My log file shows the result of writing out the file, > the result of committing the file to disk, and the results of the > renames. But the file writes were not completed, even though the file > renames were. > > a > > Conor Stokes wrote: >> NTFS metadata operations are full atomic transactions, and are >> recoverable. Renames on NTFS only involve metadata, if the file is on >> the same volume. Of course, you require the write through tag to make >> sure this is flushed to disk :). >> >> http://technet2.microsoft.com/WindowsServer/en/library/8cc5891dbf8e4164862ddac5418c59481033.mspx?mfr=true >> >> >>  Original Message  >> From: Andy Finkenstadt <andyf@...> >> To: Game Development Algorithms <gdalgorithmslist@...> >> Sent: Thursday, February 15, 2007 2:41:07 PM >> Subject: Re: [Algorithms] HighSpeed Flat File System >> >> Jon Watte wrote: >>> Adrian Bentley wrote: >>> >>>> The swap operation is not totally atomic, thus not fool proof. >>>> However, it could be hardened against serious errors (e.g. checksums, >>>> OS goes down in middle of rename). >>>> >>>> >>> I believe that renames are atomic when using NTFS, as with most >>> journaling file systems. >>> >>> Cheers, >>> >>> / h+ >>> >> >> It is an unfortunate fact of life that even Windows XP on top of NTFS >> file system can get incomplete file writes despite best efforts to >> commit all information to physical disk. I've had the rename happen, >> be recorded, but the data in the closed and then renamed file is >> incomplete  filled with blocks of zero, which fails the checksum >> armoring I had placed on the file. >> >> :( >> >> andy >> >>  >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveysand earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>; >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >>  >> Check out the allnew Yahoo! Mail beta >> <http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/mailbeta>; >>  Fire up a more powerful email and get things done faster. >>  >> >>  >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveysand earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>  >> >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >  > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Dan White <DanW@PIPEWORKS.com>  20070221 00:36:43

If you have several conservative force fields acting, you could just adjust the velocity at the end of each step to keep the total energy (potential + kinetic) constant. =20 =20 DanW ________________________________ From: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Juhani Honkala Sent: Thursday, February 15, 2007 11:01 PM To: Game Development Algorithms Subject: Re: [Algorithms] orbital motion of particles Yeah, sorry about the double posting. I just started using Gmail as my primary account and didn't recognize that it automatically filters out the copy of my own posting. Not sure why Tom is seeing five(?) posts though. oh well.. Anyway,=20 There are more than a one force field in the particle system and I'm calculating the motion of a particle by using the net sum of all forces affecting it, for this reason just keeping the particle in the same distance from the center wouldn't work as potentially other forces are affecting it and moving it another direction. I also want to create smooth blendins and make particles gradually to be affected by the vortex force. Juhani On 2/16/07, Tom Forsyth <tom.forsyth.gdalgo@...> wrote:=20 Five posts? Give it a rest. =09 Why don't you take the distance of the particle from the centre before you=20 move it, then move it, then reset it to the same distance afterwards? =09 TomF. =09 =09 > Original Message > From: gdalgorithmslistbounces@...=20 > [mailto:gdalgorithmslistbounces@...] On > Behalf Of Juhani Honkala=20 > Sent: 15 February 2007 21:31 > To: Game Development Algorithms=20 > Subject: [Algorithms] orbital motion of particles > > > Hi, > > I'm currently working on a particle system and trying to implement a > Maya like vortexforce field, which should give particles=20 > orbital motion > around center point on a 2Dplane(kind of a revolving cylinder). The > problem I'm having is that everything works fine when particle > velocities are relatively small, but due to errors in numerical=20 > integration, fast moving particles gradually gain nontangentical > velocity and move away from center. I'm using constant > timestep physics > and classic Eulerintegration. I guess I'm looking for some=20 > sort of hack > here to make this work..I could possibly take advantage of > the constant > timestep and add some correction factors to the velocity, but > the exact > math/idea escapes me. Anyone?=20 > > I'm doing something like this: > > float currentTangentialVelocity =3D > DotProduct(particleVelocity, > tangent); //How much tangential speed a particle has > (projection of the=20 > particle velocity onto tangent) > > //calculating tangential force accounting friction of > the force > field. When friction=3D1 particles should keep the same orbit. > float=20 > tangentialForce=3DvortexVelocitycurrentTangentialVelocity * > friction; > > //Calculating the force applied to particle to keep it in > orbital motion (if it didn't have any nontangential speed in=20 > the first > place) > float3 vortex =3D tangent * tangentialForce + (normal * > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > //Euler 1st order integration step=20 > particleVelocity +=3D (vortex + gravity + ... ) * dt; > //net sum of > forces > particlePosition +=3D particleVelocity * dt; > > > Juhani > >  >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveysand earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________=20 GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 =09  Internal Virus Database is outofdate. Checked by AVG Free Edition.=20 Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 23:39 =09  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21 /665  Release Date: 02/02/2007 23:39 =09 =09 =09 =09   Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your=20 opinions on IT & business topics through brief surveysand earn cash =09 http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V=20 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 =09 
From: Rashid Tanweer <quantum_cook@ya...>  20070220 05:17:04

HI, There are two points of concern, one is the time step and Integration method and other is the force calculation. for time step and integration method selection i seriously recommend you Implicit integration. Now, if the force calculation is being done by some stiff equation, then you can use Energy Equations for accurate modelling. refer to SIGGRAPH 2001 course notes "Physically based modelling" by Andrew Witckin and David Baraff especially "Differential equation basics", "Implicit Methods" and "Energy Constraints". Hope this will help, Rashid Tanweer quantum_cook@...  Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. 
From: Darren Grant <dgrant@ke...>  20070216 21:08:00

At 12:30 PM 16/02/2007, phil_wilkins@... wrote: > > Euler=E2=80=99s method is cute=85 for kindergarten. > > >Or for particle systems where perfomance is more important than accuracy. >Which is almost all of them. > >Cheers, >Phil > >PS We did our vortex style systems by dropping the vortex field, and >rotating the system as a whole. I have support for RK4 in my code, but none >of the artists I consulted thought the tradeoff was worth it. Good point. I like the verlet integration approach that has been mentioned. It is=20 likewise simple and may help keep the particle velocities in check.  Darren Grant Lead Programmer http://www.kerberosproductions.com/ Sword of the Stars is Released! http://solforce.swordofthestars.com/buythegame/  No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.412 / Virus Database: 268.18.1/690  Release Date: 16/02/2007 
From: <phil_wilkins@pl...>  20070216 20:30:32

PiBFdWxlcuKAmXMgbWV0aG9kIGlzIGN1dGXigKYgZm9yIGtpbmRlcmdhcnRlbi4NCg0KT3IgZm9y IHBhcnRpY2xlIHN5c3RlbXMgd2hlcmUgcGVyZm9tYW5jZSBpcyBtb3JlIGltcG9ydGFudCB0aGFu IGFjY3VyYWN5Lg0KV2hpY2ggaXMgYWxtb3N0IGFsbCBvZiB0aGVtLg0KDQpDaGVlcnMsDQpQaGls DQoNClBTIFdlIGRpZCBvdXIgdm9ydGV4IHN0eWxlIHN5c3RlbXMgYnkgZHJvcHBpbmcgdGhlIHZv cnRleCBmaWVsZCwgYW5kDQpyb3RhdGluZyB0aGUgc3lzdGVtIGFzIGEgd2hvbGUuIEkgaGF2ZSBz dXBwb3J0IGZvciBSSzQgaW4gbXkgY29kZSwgYnV0IG5vbmUNCm9mIHRoZSBhcnRpc3RzIEkgY29u c3VsdGVkIHRob3VnaHQgdGhlIHRyYWRlLW9mZiB3YXMgd29ydGggaXQuDQo= 
From: Jon Watte <hplus@mi...>  20070216 19:35:00

Benjamin Rouveyrol wrote: > IMHO, you can't just scale/bias the z element by 0.5, 0.5 because in > direct3d, z increases as you get away from the camera, while in opengl > it decreases. I guess that instead of doing Zogl = 2*Zd3d1, you > should have Zogl = 12*Zd3d. So the scale bias should be reversed for > the 3rd component of the matrix. > I believe that OpenGL, once you've done the viewport transform, also maps the Z buffer from 0 at the near plane to 1 at the far plane (or whatever else you've set using glDepthRange()). Cheers, / h+ 
From: Greg James <gregj@nv...>  20070216 19:05:26

Search for "RungeKutta" related to numerical integration. It's 4th order and more stable. You ought to find eqns already worked out for 1/r^2 gravity. If you're interacting the particles only with the center mass (not interacting them with eachother), the orbit of each is an elipse. You can path them analyticaly, though speed should decrease as you approach apogee. Use conservation of energy to calculate the speed along the elipse. Greg Original Message From: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Jon Watte Sent: Thursday, February 15, 2007 10:36 PM To: Game Development Algorithms Subject: Re: [Algorithms] orbital motion of particles That's the problem of firstorder Euler  it is unstable at any time=20 step under this kind of circumstance. Here's what I would do: Mark each particle with a desired distance from=20 center. When applying a force, check whether the particle is not in its=20 intended orbit, and apply an additional correcting force accordingly. Cheers, =20 / h+ Juhani Honkala wrote: > Hi, > > I'm currently working on a particle system and trying to implement a=20 > Maya like vortexforce field, which should give particles orbital=20 > motion around center point on a 2Dplane(kind of a revolving=20 > cylinder). The problem I'm having is that everything works fine when=20 > particle velocities are relatively small, but due to errors in=20 > numerical integration, fast moving particles gradually gain=20 > nontangentical velocity and move away from center. I'm using constant > timestep physics and classic Eulerintegration. I guess I'm looking=20 > for some sort of hack here to make this work..I could possibly take=20 > advantage of the constant timestep and add some correction factors to=20 > the velocity, but the exact math/idea escapes me. Any one? > > I'm doing something like this: > > float currentTangentialVelocity =3D DotProduct(particleVelocity= , > tangent); //How much tangential speed a particle has (projection of=20 > the particle velocity onto tangent) > float tangentialForce=3DvortexVelocitycurrentTangentialVelocit= y > * friction; //Friction of the force field. When friction=3D1 particles = > should keep the same orbit. > float3 vortex =3D tangent * tangentialForce + (normal *=20 > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction;=20 > //Calculating the force applied to particle to keep it in orbital=20 > motion (if it didn't have any nontangential speed in the first place) > //Euler 1st order integration step > particleVelocity +=3D (vortex + gravity + ... ) * dt; //net sum= =20 > of forces > particlePosition +=3D particleVelocity * dt; > > > Juhani >  > >   > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V >  > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188   Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 =  This email message is for the sole use of the intended recipient(s) and m= ay contain confidential information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please contact the= =20sender by reply email and destroy all copies of the original message. =  
From: Aras Pranckevicius <nearaz@gm...>  20070216 14:42:53

Hi, Doh, my multiplyingmatricesonpaper skills are really getting rusty! Of course scaling and biasing just works (also with taking care of negated Z axis and inverted culling somewhere). Sorry for the trouble and thanks!  Aras Pranckevicius work: http://www.unity3d.com home: nesnausk.org/nearaz 
From: Paul Johnson <Paul@ru...>  20070216 09:25:17

RungeKutta integration is the Daddy, but it might be too slow/overkill for use in a particle system. There are loads of different methods here: http://burtleburtle.net/bob/math/multistep.html And a decent description of lots of halfway houses here and onwards: http://www.its.caltech.edu/~matthewf/Chatter/Integrator.html I've used one of those (that's basically a verlet integration taking velocity into account) in my fluids sim and it's pretty solid.(sic) Regards, Paul Johnson. =20 Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com =20 =20 Original Message From: Juhani Honkala [mailto:juhnu@...]=20 Sent: 16 February 2007 05:31 To: Game Development Algorithms Subject: [Algorithms] orbital motion of particles Hi, I'm currently working on a particle system and trying to implement a=20 Maya like vortexforce field, which should give particles orbital motion around center point on a 2Dplane(kind of a revolving cylinder). The=20 problem I'm having is that everything works fine when particle=20 velocities are relatively small, but due to errors in numerical=20 integration, fast moving particles gradually gain nontangentical=20 velocity and move away from center. I'm using constant timestep physics and classic Eulerintegration. I guess I'm looking for some sort of hack here to make this work..I could possibly take advantage of the constant=20 timestep and add some correction factors to the velocity, but the exact=20 math/idea escapes me. Anyone? I'm doing something like this: float currentTangentialVelocity =3D DotProduct(particleVelocity, = tangent); //How much tangential speed a particle has (projection of the=20 particle velocity onto tangent) =20 //calculating tangential force accounting friction of the force=20 field. When friction=3D1 particles should keep the same orbit. float tangentialForce=3DvortexVelocitycurrentTangentialVelocity = * friction; =20 //Calculating the force applied to particle to keep it in=20 orbital motion (if it didn't have any nontangential speed in the first=20 place) float3 vortex =3D tangent * tangentialForce + (normal *=20 (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; =20 //Euler 1st order integration step particleVelocity +=3D (vortex + gravity + ... ) * dt; //net sum = of forces particlePosition +=3D particleVelocity * dt; Juhani   Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Willem de Boer <wdeboer@mi...>  20070216 08:56:05

Euler's method is cute... for kindergarten. Really, you should never have to use Euler's method in a serious project. S= witch to standard RungeKutta, increase your timestep and it should all work. That, or do what Tom or Jon say. Willem From: gdalgorithmslistbounces@... [mailto:gdalgorithms= listbounces@...] On Behalf Of Juhani Honkala Sent: 16 February 2007 07:01 To: Game Development Algorithms Subject: Re: [Algorithms] orbital motion of particles Yeah, sorry about the double posting. I just started using Gmail as my prim= ary account and didn't recognize that it automatically filters out the copy= of my own posting. Not sure why Tom is seeing five(?) posts though. oh wel= l.. Anyway, There are more than a one force field in the particle system and I'm calcul= ating the motion of a particle by using the net sum of all forces affecting= it, for this reason just keeping the particle in the same distance from th= e center wouldn't work as potentially other forces are affecting it and mov= ing it another direction. I also want to create smooth blendins and make p= articles gradually to be affected by the vortex force. Juhani On 2/16/07, Tom Forsyth <tom.forsyth.gdalgo@...<mailto:tom.for= syth.gdalgo@...>> wrote: Five posts? Give it a rest. Why don't you take the distance of the particle from the centre before you move it, then move it, then reset it to the same distance afterwards? TomF. > Original Message > From: gdalgorithmslistbounces@... <mailto:gdalgorithm= slistbounces@...> > [mailto:gdalgorithmslistbounces@...<mailto:gdalgorith= mslistbounces@...>] On > Behalf Of Juhani Honkala > Sent: 15 February 2007 21:31 > To: Game Development Algorithms > Subject: [Algorithms] orbital motion of particles > > > Hi, > > I'm currently working on a particle system and trying to implement a > Maya like vortexforce field, which should give particles > orbital motion > around center point on a 2Dplane(kind of a revolving cylinder). The > problem I'm having is that everything works fine when particle > velocities are relatively small, but due to errors in numerical > integration, fast moving particles gradually gain nontangentical > velocity and move away from center. I'm using constant > timestep physics > and classic Eulerintegration. I guess I'm looking for some > sort of hack > here to make this work..I could possibly take advantage of > the constant > timestep and add some correction factors to the velocity, but > the exact > math/idea escapes me. Anyone? > > I'm doing something like this: > > float currentTangentialVelocity =3D > DotProduct(particleVelocity, > tangent); //How much tangential speed a particle has > (projection of the > particle velocity onto tangent) > > //calculating tangential force accounting friction of > the force > field. When friction=3D1 particles should keep the same orbit. > float > tangentialForce=3DvortexVelocitycurrentTangentialVelocity * > friction; > > //Calculating the force applied to particle to keep it in > orbital motion (if it didn't have any nontangential speed in > the first > place) > float3 vortex =3D tangent * tangentialForce + (normal * > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > //Euler 1st order integration step > particleVelocity +=3D (vortex + gravity + ... ) * dt; > //net sum of > forces > particlePosition +=3D particleVelocity * dt; > > > Juhani > >  >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@...<mailto:GDAlgorithmslist@...= ceforge.net> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 23:39  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21 /665  Release Date: 02/02/200= 7 23:39  Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share you= r opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@...<mailto:GDAlgorithmslist@...= ceforge.net> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Benjamin Rouveyrol <benjaminrouveyrol@gm...>  20070216 08:42:32

IMHO, you can't just scale/bias the z element by 0.5, 0.5 because in direct3d, z increases as you get away from the camera, while in opengl it decreases. I guess that instead of doing Zogl = 2*Zd3d1, you should have Zogl = 12*Zd3d. So the scale bias should be reversed for the 3rd component of the matrix. On 15/02/07, Aras Pranckevicius <nearaz@...> wrote: > > > The only difference I can think of is that in OpenGL clip space, the Z > > range is 1 to 1, whereas in Direct3D, the Z range is 0 to 1. Thus, you > > can scale and offset the Z coordinate (column, if you're rowvector on > > left; row, if you're columnvector on right) to adjust for this. Scale > > elements 0,1,2 by 0.5, add 0.5 to the 3rd element. > > That was my first idea as well, but somehow it does not seem to work. > > Take the canonical GL perspective matrix, third row (assuming no > negative scaling on Z): > 0 0 (f+n)/(fn) 2*f*n/(fn) > And the canonical D3D perspective matrix: > 0 0 f/(fn) f*n/(fn) > > Scaling by 0.5 (first 3 elements) and biasing by 0.5 (4th element) on > GL matrix row would not produce the D3D values. But scaling&biasing on > the orthogonal projection matrix would produce the correct result. > > Or am I missing something obvious here? > >  > Aras Pranckevicius > work: http://www.unity3d.com > home: nesnausk.org/nearaz > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Juhani Honkala <juhnu@al...>  20070216 07:00:55

Yeah, sorry about the double posting. I just started using Gmail as my primary account and didn't recognize that it automatically filters out the copy of my own posting. Not sure why Tom is seeing five(?) posts though. oh well.. Anyway, There are more than a one force field in the particle system and I'm calculating the motion of a particle by using the net sum of all forces affecting it, for this reason just keeping the particle in the same distance from the center wouldn't work as potentially other forces are affecting it and moving it another direction. I also want to create smooth blendins and make particles gradually to be affected by the vortex force. Juhani On 2/16/07, Tom Forsyth <tom.forsyth.gdalgo@...> wrote: > > Five posts? Give it a rest. > > Why don't you take the distance of the particle from the centre before you > > move it, then move it, then reset it to the same distance afterwards? > > TomF. > > > > Original Message > > From: gdalgorithmslistbounces@... > > [mailto:gdalgorithmslistbounces@...] On > > Behalf Of Juhani Honkala > > Sent: 15 February 2007 21:31 > > To: Game Development Algorithms > > Subject: [Algorithms] orbital motion of particles > > > > > > Hi, > > > > I'm currently working on a particle system and trying to implement a > > Maya like vortexforce field, which should give particles > > orbital motion > > around center point on a 2Dplane(kind of a revolving cylinder). The > > problem I'm having is that everything works fine when particle > > velocities are relatively small, but due to errors in numerical > > integration, fast moving particles gradually gain nontangentical > > velocity and move away from center. I'm using constant > > timestep physics > > and classic Eulerintegration. I guess I'm looking for some > > sort of hack > > here to make this work..I could possibly take advantage of > > the constant > > timestep and add some correction factors to the velocity, but > > the exact > > math/idea escapes me. Anyone? > > > > I'm doing something like this: > > > > float currentTangentialVelocity = > > DotProduct(particleVelocity, > > tangent); //How much tangential speed a particle has > > (projection of the > > particle velocity onto tangent) > > > > //calculating tangential force accounting friction of > > the force > > field. When friction=1 particles should keep the same orbit. > > float > > tangentialForce=vortexVelocitycurrentTangentialVelocity * > > friction; > > > > //Calculating the force applied to particle to keep it in > > orbital motion (if it didn't have any nontangential speed in > > the first > > place) > > float3 vortex = tangent * tangentialForce + (normal * > > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > > > //Euler 1st order integration step > > particleVelocity += (vortex + gravity + ... ) * dt; > > //net sum of > > forces > > particlePosition += particleVelocity * dt; > > > > > > Juhani > > > >  > >  > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the > > chance to share your > > opinions on IT & business topics through brief surveysand earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  > Internal Virus Database is outofdate. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: > 02/02/2007 > 23:39 > >  > Internal Virus Database is outofdate. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.21 /665  Release Date: > 02/02/2007 > 23:39 > > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Jon Watte <hplus@mi...>  20070216 06:35:33

That's the problem of firstorder Euler  it is unstable at any time step under this kind of circumstance. Here's what I would do: Mark each particle with a desired distance from center. When applying a force, check whether the particle is not in its intended orbit, and apply an additional correcting force accordingly. Cheers, / h+ Juhani Honkala wrote: > Hi, > > I'm currently working on a particle system and trying to implement a > Maya like vortexforce field, which should give particles orbital > motion around center point on a 2Dplane(kind of a revolving > cylinder). The problem I'm having is that everything works fine when > particle velocities are relatively small, but due to errors in > numerical integration, fast moving particles gradually gain > nontangentical velocity and move away from center. I'm using constant > timestep physics and classic Eulerintegration. I guess I'm looking > for some sort of hack here to make this work..I could possibly take > advantage of the constant timestep and add some correction factors to > the velocity, but the exact math/idea escapes me. Any one? > > I'm doing something like this: > > float currentTangentialVelocity = DotProduct(particleVelocity, > tangent); //How much tangential speed a particle has (projection of > the particle velocity onto tangent) > float tangentialForce=vortexVelocitycurrentTangentialVelocity > * friction; //Friction of the force field. When friction=1 particles > should keep the same orbit. > float3 vortex = tangent * tangentialForce + (normal * > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > //Calculating the force applied to particle to keep it in orbital > motion (if it didn't have any nontangential speed in the first place) > //Euler 1st order integration step > particleVelocity += (vortex + gravity + ... ) * dt; //net sum > of forces > particlePosition += particleVelocity * dt; > > > Juhani >  > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >  > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tom Forsyth <tom.forsyth.gdalgo@ee...>  20070216 06:06:38

Five posts? Give it a rest. Why don't you take the distance of the particle from the centre before you move it, then move it, then reset it to the same distance afterwards? TomF. > Original Message > From: gdalgorithmslistbounces@... > [mailto:gdalgorithmslistbounces@...] On > Behalf Of Juhani Honkala > Sent: 15 February 2007 21:31 > To: Game Development Algorithms > Subject: [Algorithms] orbital motion of particles > > > Hi, > > I'm currently working on a particle system and trying to implement a > Maya like vortexforce field, which should give particles > orbital motion > around center point on a 2Dplane(kind of a revolving cylinder). The > problem I'm having is that everything works fine when particle > velocities are relatively small, but due to errors in numerical > integration, fast moving particles gradually gain nontangentical > velocity and move away from center. I'm using constant > timestep physics > and classic Eulerintegration. I guess I'm looking for some > sort of hack > here to make this work..I could possibly take advantage of > the constant > timestep and add some correction factors to the velocity, but > the exact > math/idea escapes me. Anyone? > > I'm doing something like this: > > float currentTangentialVelocity = > DotProduct(particleVelocity, > tangent); //How much tangential speed a particle has > (projection of the > particle velocity onto tangent) > > //calculating tangential force accounting friction of > the force > field. When friction=1 particles should keep the same orbit. > float > tangentialForce=vortexVelocitycurrentTangentialVelocity * > friction; > > //Calculating the force applied to particle to keep it in > orbital motion (if it didn't have any nontangential speed in > the first > place) > float3 vortex = tangent * tangentialForce + (normal * > (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; > > //Euler 1st order integration step > particleVelocity += (vortex + gravity + ... ) * dt; > //net sum of > forces > particlePosition += particleVelocity * dt; > > > Juhani > >  >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 23:39  Internal Virus Database is outofdate. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.21/665  Release Date: 02/02/2007 23:39 
From: Juhani Honkala <juhnu@al...>  20070216 05:30:52

Hi, I'm currently working on a particle system and trying to implement a Maya like vortexforce field, which should give particles orbital motion around center point on a 2Dplane(kind of a revolving cylinder). The problem I'm having is that everything works fine when particle velocities are relatively small, but due to errors in numerical integration, fast moving particles gradually gain nontangentical velocity and move away from center. I'm using constant timestep physics and classic Eulerintegration. I guess I'm looking for some sort of hack here to make this work..I could possibly take advantage of the constant timestep and add some correction factors to the velocity, but the exact math/idea escapes me. Anyone? I'm doing something like this: float currentTangentialVelocity = DotProduct(particleVelocity, tangent); //How much tangential speed a particle has (projection of the particle velocity onto tangent) //calculating tangential force accounting friction of the force field. When friction=1 particles should keep the same orbit. float tangentialForce=vortexVelocitycurrentTangentialVelocity * friction; //Calculating the force applied to particle to keep it in orbital motion (if it didn't have any nontangential speed in the first place) float3 vortex = tangent * tangentialForce + (normal * (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; //Euler 1st order integration step particleVelocity += (vortex + gravity + ... ) * dt; //net sum of forces particlePosition += particleVelocity * dt; Juhani 
From: Juhani Honkala <juhnu@al...>  20070216 04:12:54

Hi, I'm currently working on a particle system and trying to implement a Maya like vortexforce field, which should give particles orbital motion around center point on a 2Dplane(kind of a revolving cylinder). The problem I'm having is that everything works fine when particle velocities are relatively small, but due to errors in numerical integration, fast moving particles gradually gain nontangentical velocity and move away from center. I'm using constant timestep physics and classic Eulerintegration. I guess I'm looking for some sort of hack here to make this work..I could possibly take advantage of the constant timestep and add some correction factors to the velocity, but the exact math/idea escapes me. Any one? I'm doing something like this: float currentTangentialVelocity = DotProduct(particleVelocity, tangent); //How much tangential speed a particle has (projection of the particle velocity onto tangent) float tangentialForce=vortexVelocitycurrentTangentialVelocity * friction; //Friction of the force field. When friction=1 particles should keep the same orbit. float3 vortex = tangent * tangentialForce + (normal * (currentTangentialVelocity^2 / Length(tangent)^2 )) * friction; //Calculating the force applied to particle to keep it in orbital motion (if it didn't have any nontangential speed in the first place) //Euler 1st order integration step particleVelocity += (vortex + gravity + ... ) * dt; //net sum of forces particlePosition += particleVelocity * dt; Juhani 
From: Jon Watte <hplus@mi...>  20070216 01:00:19

fflush() does not force a flush of file system metadata to disk. It only forces the buffering system inside the stdio library to flush to the system file buffers. And it can only be used with a FILE* you get from the standard C library. Btw: I also want to add that you probably want to add the FILE_FLAG_WRITE_THROUGH to your open flags in addition to NO_BUFFERING. Cheers, / h+ Sylvain G. Vignaud wrote: > From: Jon Watte <hplus@...> > >> Just calling write doesn't ensure that the data is flushed. You >> must >> call a separate flush function. This is true on any system I've >> worked >> with in the last 15 years or so. On UNIX, it's fsync(), on Windows, >> you >> can open with FILE_FLAG_NO_BUFFERING. You also need to call >> FlushFileBuffers() on Windows to make sure you're committed. >> > > Doesn't fflush does that? And it is supposed to be present on any platform. > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > 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...>  20070216 00:47:38

Thursday, February 15, 2007, 7:49:50 PM, Aras wrote: >> The only difference I can think of is that in OpenGL clip space, the Z >> range is 1 to 1, whereas in Direct3D, the Z range is 0 to 1. Thus, you >> can scale and offset the Z coordinate (column, if you're rowvector on >> left; row, if you're columnvector on right) to adjust for this. Scale >> elements 0,1,2 by 0.5, add 0.5 to the 3rd element. > That was my first idea as well, but somehow it does not seem to work. > Take the canonical GL perspective matrix, third row (assuming no > negative scaling on Z): > 0 0 (f+n)/(fn) 2*f*n/(fn) > And the canonical D3D perspective matrix: > 0 0 f/(fn) f*n/(fn) > Scaling by 0.5 (first 3 elements) and biasing by 0.5 (4th element) on > GL matrix row would not produce the D3D values. But scaling&biasing on > the orthogonal projection matrix would produce the correct result. > Or am I missing something obvious here? It's too late in the evening for me now to get into dissecting the math behind it (to see if this is equivalent to the scale&bias mentioned), but this formula derived a few years ago for conversion from OpenGL to D3D matrices still seems to work correctly in our codebase: mAdj = { 1 0 0 0 0 1 0 0 0 0 0.5 0.5 0 0 0 1 } mAdjustedProjection = mAdj * mProj; That is for column vector on the right. Note that you can also add subpixel correction and fake scissor clipping by adding some more complicated coefficients to the mAdj matrix. HTH, Alen 
From: Michael Walter <michael.walter@gm...>  20070216 00:00:47

I believe fflush() flushes stdio buffers only by default. See http://msdn.microsoft.com/library/default.asp?url=/library/enus/vclib/html/_crt_fopen.2c_._wfopen.asp (especially "c" and "n" flags). Regards, michael On 2/16/07, Sylvain G. Vignaud <vignsyl@...> wrote: > From: Jon Watte <hplus@...> > > Just calling write doesn't ensure that the data is flushed. You > > must > > call a separate flush function. This is true on any system I've > > worked > > with in the last 15 years or so. On UNIX, it's fsync(), on Windows, > > you > > can open with FILE_FLAG_NO_BUFFERING. You also need to call > > FlushFileBuffers() on Windows to make sure you're committed. > > Doesn't fflush does that? And it is supposed to be present on any platform. > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Sylvain G. Vignaud <vignsyl@ii...>  20070215 23:23:28

From: Jon Watte <hplus@...> > Just calling write doesn't ensure that the data is flushed. You > must > call a separate flush function. This is true on any system I've > worked > with in the last 15 years or so. On UNIX, it's fsync(), on Windows, > you > can open with FILE_FLAG_NO_BUFFERING. You also need to call > FlushFileBuffers() on Windows to make sure you're committed. Doesn't fflush does that? And it is supposed to be present on any platform. 
From: Adrian Stephens <adrians@is...>  20070215 23:11:19

If you multiply out the matrices, you will get the correct answer. The magic of homogeneous matrices makes it 'just work' (in this case, because of the zero in the bottom right corner of the perspective matrix). i.e. multiply your GL matrix by  1 0 0 0   0 1 0 0   0 0 .5 .5   0 0 0 1  (which represents the scale and bias of the z component), and you will get the answer you expect. Original Message From: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Aras Pranckevicius Sent: Thursday, February 15, 2007 10:50 AM To: Game Development Algorithms Subject: Re: [Algorithms] Converting raw projection matrices between GL andD3D? > The only difference I can think of is that in OpenGL clip space, the Z > range is 1 to 1, whereas in Direct3D, the Z range is 0 to 1. Thus, you > can scale and offset the Z coordinate (column, if you're rowvector on > left; row, if you're columnvector on right) to adjust for this. Scale > elements 0,1,2 by 0.5, add 0.5 to the 3rd element. That was my first idea as well, but somehow it does not seem to work. Take the canonical GL perspective matrix, third row (assuming no negative scaling on Z): 0 0 (f+n)/(fn) 2*f*n/(fn) And the canonical D3D perspective matrix: 0 0 f/(fn) f*n/(fn) Scaling by 0.5 (first 3 elements) and biasing by 0.5 (4th element) on GL matrix row would not produce the D3D values. But scaling&biasing on the orthogonal projection matrix would produce the correct result. Or am I missing something obvious here?  Aras Pranckevicius work: http://www.unity3d.com home: nesnausk.org/nearaz  Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 