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}

S  M  T  W  T  F  S 



1
(13) 
2
(18) 
3
(11) 
4
(11) 
5

6

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

21
(9) 
22
(9) 
23
(6) 
24
(16) 
25
(8) 
26

27

28
(4) 
29
(38) 
30
(18) 



From: Danny Kodicek <dragon@we...>  20051124 14:19:54

Willem, you're a star, this is great stuff. Part of my problem, I think, = has=20 been a lack of real understanding of what the field actually *is*, and th= is=20 kind of thing helps a lot. I knew you guys would come up with the goods on this  you wouldn't belie= ve=20 the number of physics experts I've gone to who've said 'I don't really kn= ow=20 much about magnetic field lines'. One of them is a professor specialising= in=20 the numerical solution of partial differential equations. Thanks again Danny  Original Message =20 From: "Willem de Boer" <wdeboer@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 1:35 PM Subject: RE: [Algorithms] Magnetic fields (probably OT, but maybe someone= =20 can help) "Come to think of it I have no idea either what a potential would mean in this case" Again, for the magnetic field, it makes no sense to talk about scalar potentials. "I vaguely remember a "vector potential" (as opposed to scalar potential) in [...]" Here's some things that I _do_ remember from studying electromagnetism: One of the properties of the _electric_ field, E, is that it is conservat= ive (i.e. curlfree), and therefore (only in R^n) it is the gradient of a scalarfield, which is called the scalar potential. This potential has a physical interpretation, it being the electric potential, expressed in Volts. This is the _only_ scalar potential in classical electromagnetism that I know of. Also, again in R^n only, since the _magnetic field_ , B, is divergence free it must be the curl of a vector field. This vector field is called the vector potential, A. Note that there exist an infinite number of valid vector potentials, A, since the nullspace of the curloperator consists of the space of conservative fields (since curl(grad(V))=3D0), s= o A =3D F + k*grad(V), where F is any vector field, k is a scalar, and V is any scalar field. And B =3D curl(A). The OP's problem seems to be that his B is not strictly divergencefree, possibly due to numerical issues. One solution to this problem is to force B to be divergencefree using the HelmholtzHodge decomposition. Cheers, Willem Original Message From: gdalgorithmslistadmin@...=20 [mailto:gdalgorithmslistadmin@...] On Behalf Of Bj=F6= rn=20 Smedman Sent: 24 November 2005 13:12 To: gdalgorithmslist@... Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone= =20 can help) Very true! Come to think of it I have no idea either what a potential wou= ld mean in this case. In the strict math sense of the word (B =3D grad P) th= ere can be no scalar potential since the magnetic field is obviously not curlfree. This is easy to see in the simple case of a single current carrying wire since you can walk in the direction of the field all the wa= y around the wire and end up in the same place. That means a path integral that follows such a path, which is sort of the definition of curl (at the limit), will have a positive value. Sort of like walking downhill all the way around a flagpole and ending up in the same place. :) I vaguely remember a "vector potential" (as opposed to scalar potential) = in electromagnetic field theory called "A", but I'm not sure how helpfull t= hat would be. I'm starting to think you have nontrivial problem on your hand= s. :) Good luck! /Bj=F6rn Smedman  Original Message =20 From: "Danny Kodicek" <dragon@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 12:04 PM Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone can help) > >I think you're right, there is something more fundamentally wrong in t= he > field calculations themselves... If you are solving with explicit Euler > integration as described, i.e. taking small successive steps in the fie= ld > direction to trace out a field line, and the vector field is > divergencefree, then your solutions should never spiral into current > carrying wires but rather out from them. > > Very good point. > >>So my guess is your field is probably not divergencefree. I'd suggest > drawing the potential on top of you vector field and see if it makes > sense. > > This is my feeling too (In fact, I managed to get quite close to a > loopfree solution by replacing my wire's inverse square law field with= an > inversepowerof2.5 law!). Can you tell me how I'd go about calculatin= g > the potential directly? I only have the vaguest understanding of what > 'potential' is in this case. > > Thanks > Danny > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188  This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88  This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 
From: Willem de Boer <wdeboer@mi...>  20051124 13:35:28

"Come to think of it I have no idea either what a potential would=20 mean in this case" Again, for the magnetic field, it makes no sense to talk about scalar=20 potentials. "I vaguely remember a "vector potential" (as opposed to scalar = potential)=20 in [...]" Here's some things that I _do_ remember from studying electromagnetism: One of the properties of the _electric_ field, E, is that it is = conservative (i.e. curlfree), and therefore (only in R^n) it is the gradient of a scalarfield, which is called the scalar potential. This potential has a physical interpretation, it being the electric potential, = expressed in Volts. This is the _only_ scalar potential in classical=20 electromagnetism that I know of. Also, again in R^n only, since the _magnetic field_ , B, is divergence free it must be the curl of a vector field. This vector field is called the vector potential, A. Note that there exist an infinite number = of valid vector potentials, A, since the nullspace of the curloperator consists of the space of conservative fields (since curl(grad(V))=3D0), = so A =3D F + k*grad(V),=20 where F is any vector field, k is a scalar, and V is any scalar field. And B =3D curl(A). The OP's problem seems to be that his B is not strictly divergencefree, possibly due to numerical issues. One solution to this problem is to force B to be divergencefree using the HelmholtzHodge decomposition. Cheers, Willem Original Message From: gdalgorithmslistadmin@... = [mailto:gdalgorithmslistadmin@...] On Behalf Of = Bj=F6rn Smedman Sent: 24 November 2005 13:12 To: gdalgorithmslist@... Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe = someone can help) Very true! Come to think of it I have no idea either what a potential = would=20 mean in this case. In the strict math sense of the word (B =3D grad P) = there=20 can be no scalar potential since the magnetic field is obviously not=20 curlfree. This is easy to see in the simple case of a single current=20 carrying wire since you can walk in the direction of the field all the = way=20 around the wire and end up in the same place. That means a path integral = that follows such a path, which is sort of the definition of curl (at = the=20 limit), will have a positive value. Sort of like walking downhill all = the=20 way around a flagpole and ending up in the same place. :) I vaguely remember a "vector potential" (as opposed to scalar potential) = in=20 electromagnetic field theory called "A", but I'm not sure how helpfull = that=20 would be. I'm starting to think you have nontrivial problem on your = hands.=20 :) Good luck! /Bj=F6rn Smedman  Original Message =20 From: "Danny Kodicek" <dragon@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 12:04 PM Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe = someone=20 can help) > >I think you're right, there is something more fundamentally wrong in = the > field calculations themselves... If you are solving with explicit = Euler > integration as described, i.e. taking small successive steps in the = field > direction to trace out a field line, and the vector field is > divergencefree, then your solutions should never spiral into current > carrying wires but rather out from them. > > Very good point. > >>So my guess is your field is probably not divergencefree. I'd suggest > drawing the potential on top of you vector field and see if it makes=20 > sense. > > This is my feeling too (In fact, I managed to get quite close to a=20 > loopfree solution by replacing my wire's inverse square law field = with an=20 > inversepowerof2.5 law!). Can you tell me how I'd go about = calculating=20 > the potential directly? I only have the vaguest understanding of what=20 > 'potential' is in this case. > > Thanks > Danny > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD = SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20  This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: <bjorn@si...>  20051124 13:12:15

Very true! Come to think of it I have no idea either what a potential wou= ld=20 mean in this case. In the strict math sense of the word (B =3D grad P) th= ere=20 can be no scalar potential since the magnetic field is obviously not=20 curlfree. This is easy to see in the simple case of a single current=20 carrying wire since you can walk in the direction of the field all the wa= y=20 around the wire and end up in the same place. That means a path integral=20 that follows such a path, which is sort of the definition of curl (at the= =20 limit), will have a positive value. Sort of like walking downhill all the= =20 way around a flagpole and ending up in the same place. :) I vaguely remember a "vector potential" (as opposed to scalar potential) = in=20 electromagnetic field theory called "A", but I'm not sure how helpfull t= hat=20 would be. I'm starting to think you have nontrivial problem on your hand= s.=20 :) Good luck! /Bj=F6rn Smedman  Original Message =20 From: "Danny Kodicek" <dragon@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 12:04 PM Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone= =20 can help) > >I think you're right, there is something more fundamentally wrong in t= he > field calculations themselves... If you are solving with explicit Euler > integration as described, i.e. taking small successive steps in the fie= ld > direction to trace out a field line, and the vector field is > divergencefree, then your solutions should never spiral into current > carrying wires but rather out from them. > > Very good point. > >>So my guess is your field is probably not divergencefree. I'd suggest > drawing the potential on top of you vector field and see if it makes=20 > sense. > > This is my feeling too (In fact, I managed to get quite close to a=20 > loopfree solution by replacing my wire's inverse square law field with= an=20 > inversepowerof2.5 law!). Can you tell me how I'd go about calculatin= g=20 > the potential directly? I only have the vaguest understanding of what=20 > 'potential' is in this case. > > Thanks > Danny > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20 > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&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: Willem de Boer <wdeboer@mi...>  20051124 11:55:16

"[...] then he computes the gradient of this pressure field=20 which he then subtracts from his original velocity field to=20 leave a divergence free field." This is a direct consequence of the HelmholtzHodge decomposition; the gradient of the pressure field is curlfree (because the gradient is conservative), so subtracting this from the velocity field leaves a divergencefree vector field. To the OP: If it is the divergencefree component of a vector field you're after, I recall a SIGGRAPH 2003 paper which discusses this for vector fields that are (IIRC) piecewise constant, which holds in your case too. Then they use the HelmholtzHodge decomposition to derive a variational method for calculating the best divergence free vector field. Ah, here it is: Tong Y., S. Lombeyda, A.N. Hirani, M. Desbrun, "Discrete Multiscale Vector Field Decomposition", ACM TOG (SIGGRAPH2003), p. 445452. Cheers, Willem 
From: Paul_F<irth@sc...>  20051124 11:36:14

gdalgorithmslistadmin@... wrote on 24/11/2005 11:10:09: > Willem wrote: > > >I think some sort of advection scheme > a la Stam might help here. > > I've done a little research into this and confess myself lost in a morass of > equations and proofs with very little in the way of practical explanation. > It seems that Stam's method (which as far as I understand it is designed for > dealing with turbulent flow rather than electromagnetic fields, but I can > see that the method may apply here) is a system for correcting a > numericallycalculated timevariant field to ensure zero divergence, which > is exactly what I'm looking for, but I can't quite get a handle on how > exactly it works. It's something to do with Helmholtz decomposition, which > in turn appears to have some relation to Fourier transforms, and after that > the whooshing sounds as the whole thing starts to go over my head are > getting quite audible. Does anyone have any links to practical, rather than > theoretical, explanations of this kind of problem? I can tell you how he creates a divergence free velocity field: (this is for fluid flow) He calculates the divergence of his velocity field, then uses this to calculate pressure (solving a linear system in the process), then he computes the gradient of this pressure field which he then subtracts from his original velocity field to leave a divergence free field. Ta, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** Sony Computer Entertainment Europe 
From: Willem de Boer <wdeboer@mi...>  20051124 11:30:04

Stam's GDC presentation on this might help. The presentation is all about an implementation of his stuff. The Helmholtz decomposition basically says that every vector field can be decomposed into the sum of a curlfree and a divergencefree vector field (IIRC). It is not related to the Fourier transform directly (AFAIK). Stam uses the FT to speed up his algorithm by making use of the fact that the FT can be used to solve differential equations algebraically in the frequency domain (much like the Laplace transform).=20 Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Danny Kodicek Sent: 24 November 2005 11:10 To: gdalgorithmslist@... Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone can help) Willem wrote: >I think some sort of advection scheme a la Stam might help here. I've done a little research into this and confess myself lost in a morass of=20 equations and proofs with very little in the way of practical explanation.=20 It seems that Stam's method (which as far as I understand it is designed for=20 dealing with turbulent flow rather than electromagnetic fields, but I can=20 see that the method may apply here) is a system for correcting a=20 numericallycalculated timevariant field to ensure zero divergence, which=20 is exactly what I'm looking for, but I can't quite get a handle on how=20 exactly it works. It's something to do with Helmholtz decomposition, which=20 in turn appears to have some relation to Fourier transforms, and after that=20 the whooshing sounds as the whole thing starts to go over my head are=20 getting quite audible. Does anyone have any links to practical, rather than=20 theoretical, explanations of this kind of problem? Best Danny=20  This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Danny Kodicek <dragon@we...>  20051124 11:10:15

Willem wrote: >I think some sort of advection scheme a la Stam might help here. I've done a little research into this and confess myself lost in a morass of equations and proofs with very little in the way of practical explanation. It seems that Stam's method (which as far as I understand it is designed for dealing with turbulent flow rather than electromagnetic fields, but I can see that the method may apply here) is a system for correcting a numericallycalculated timevariant field to ensure zero divergence, which is exactly what I'm looking for, but I can't quite get a handle on how exactly it works. It's something to do with Helmholtz decomposition, which in turn appears to have some relation to Fourier transforms, and after that the whooshing sounds as the whole thing starts to go over my head are getting quite audible. Does anyone have any links to practical, rather than theoretical, explanations of this kind of problem? Best Danny 
From: Danny Kodicek <dragon@we...>  20051124 11:04:15

>I think you're right, there is something more fundamentally wrong in the field calculations themselves... If you are solving with explicit Euler integration as described, i.e. taking small successive steps in the field direction to trace out a field line, and the vector field is divergencefree, then your solutions should never spiral into current carrying wires but rather out from them. Very good point. >So my guess is your field is probably not divergencefree. I'd suggest drawing the potential on top of you vector field and see if it makes sense. This is my feeling too (In fact, I managed to get quite close to a loopfree solution by replacing my wire's inverse square law field with an inversepowerof2.5 law!). Can you tell me how I'd go about calculating the potential directly? I only have the vaguest understanding of what 'potential' is in this case. Thanks Danny 
From: <bjorn@si...>  20051124 10:55:30

I think you're right, there is something more fundamentally wrong in the=20 field calculations themselves... If you are solving with explicit Euler=20 integration as described, i.e. taking small successive steps in the field= =20 direction to trace out a field line, and the vector field is=20 divergencefree, then your solutions should never spiral into current=20 carrying wires but rather out from them. To see this think of the simple example of only one current carrying wire= =20 where the field lines should be circles around the wire. At each point th= e=20 field direction will be the tangent of a circle with the wire in the cent= er.=20 Taking a finite step in the field direction will take you further from th= e=20 center, i.e. your solution will spiral out. The larger your step size the= =20 faster it will spiral out. Should be easy to see if you sketch it out on=20 paper. So my guess is your field is probably not divergencefree. I'd suggest=20 drawing the potential on top of you vector field and see if it makes sens= e.=20 The potential should also be usefull for correcting for integration and=20 numerical error along the calculated field line path... Hope it helps, Bj=F6rn Smedman  Original Message =20 From: "Danny Kodicek" <dragon@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 9:54 AM Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone= =20 can help) > Thanks, Greg > > >It sounds like you are starting from a point in space and stepping alo= ng > the perpendicular of the field (the direction of the maximum gradient) > by some distance. This will move you off of the true field line path b= y > some small amount if the field lines are curving  which they always ar= e > =3D) > > Actually, that's not exactly what I'm doing. Field lines move in the=20 > direction of the field. Not sure what 'direction of maximum gradient'=20 > means in this instance, but I'm pretty sure it's not perpendicular to t= he=20 > field. But I may be wrong! > > I understand your point about the numerical error, and you're right tha= t=20 > this is an issue, but I don't think it's the whole story in my case,=20 > because the error I get seems to be fairly independent of the size of m= y=20 > steps along the line. If this was due to the linearisation, I'd expect = the=20 > error to decrease as I take smaller steps. I think this may be somethin= g=20 > more fundamental in the field calculations themselves. > >> I can't think of a way to make a correction back to the true field lin= e > position. You're looking for a point at some given field value (along > an equipotential line in your 2D view), but the point depends on your > previous point and the gradient direction. When the gradient direction > is changing continuously over space, but you're taking a discreet step > across that space, I don't know a way to stay on the true line. > > I tried quite a neat algorithm (which I'm sure is standard although I c= ame=20 > up with it myself) that corrects up to a quadratic factor (and nearly=20 > cubic) by backprojecting the field from the end of each segment, findi= ng=20 > the size of the distance from the start point, and adding that factor b= ack=20 > on. In fact, the thought occurs to me that I should try removing this=20 > correction and see if it makes things better! > >> There is one thing you could try. The field lines intersect the > equipotential lines and are perpendicular to them. If the field lines > you choose to draw are equally spaced along one equipotential line, the= y > must be equally spaced along all of the other equipotential lines. > > Are you sure of this? Field lines get closer together at some points an= d=20 > further apart at others, and sometimes add whole curves that weren't in= =20 > their predecessors. Unless I'm misunderstanding you I think this isn't=20 > true. > > Thanks for your help > Danny > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20 > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&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: Danny Kodicek <dragon@we...>  20051124 08:54:30

Thanks, Greg >It sounds like you are starting from a point in space and stepping along the perpendicular of the field (the direction of the maximum gradient) by some distance. This will move you off of the true field line path by some small amount if the field lines are curving  which they always are =) Actually, that's not exactly what I'm doing. Field lines move in the direction of the field. Not sure what 'direction of maximum gradient' means in this instance, but I'm pretty sure it's not perpendicular to the field. But I may be wrong! I understand your point about the numerical error, and you're right that this is an issue, but I don't think it's the whole story in my case, because the error I get seems to be fairly independent of the size of my steps along the line. If this was due to the linearisation, I'd expect the error to decrease as I take smaller steps. I think this may be something more fundamental in the field calculations themselves. > I can't think of a way to make a correction back to the true field line position. You're looking for a point at some given field value (along an equipotential line in your 2D view), but the point depends on your previous point and the gradient direction. When the gradient direction is changing continuously over space, but you're taking a discreet step across that space, I don't know a way to stay on the true line. I tried quite a neat algorithm (which I'm sure is standard although I came up with it myself) that corrects up to a quadratic factor (and nearly cubic) by backprojecting the field from the end of each segment, finding the size of the distance from the start point, and adding that factor back on. In fact, the thought occurs to me that I should try removing this correction and see if it makes things better! > There is one thing you could try. The field lines intersect the equipotential lines and are perpendicular to them. If the field lines you choose to draw are equally spaced along one equipotential line, they must be equally spaced along all of the other equipotential lines. Are you sure of this? Field lines get closer together at some points and further apart at others, and sometimes add whole curves that weren't in their predecessors. Unless I'm misunderstanding you I think this isn't true. Thanks for your help Danny 
From: Jon Watte <hplus@mi...>  20051124 01:24:48

Option 1: Render the object first with ZWrite on (although still after all the opaque geometry), and then with ZTest as LEQUAL. That way, you will only touch one pixel per object. You won't see convex limbs behind the object, but that might be less important. Option 2: Render the object to an offscreen buffer, with destination alpha. Then use the offscreen buffer as a billboard in the world, with translucent alpha. Same visual effect as option 1. Option 3: Statically sort the triangles within the object for minmal overlap. If you bulid a directed graph of what triangles can be in front of what other triangles (BSPlike), and sort the triangles in an order that minimize drawing frontmoster triangles before hintermoster triangles, you can get a goodenough result. You can perfectly sort a "T" shape, but you cannot perfectly sort a "+" shape, because the latter will have infinite cycles in its possible overlap. But it's still better than what you get with totally unsorted geometry. Cheers, / h+ Mark Wayland wrote: > Hey all, > > I was wondering if there were any neat tricks to rendering translucent > (fading) objects (as a whole) correctly? > > The problem I have at the moment is that when I'm fading an object out, > the render states go from > ZTEST/ZWRITE to ZTEST only, causing the polygons of the object to > incorrectly selfsort resulting > in a nasty pop (obviously same problem when fading in). > The objects themselves are sorted from back to front for perobject > correct blending, but I can't > afford to do that perpolygon. > > Any ideas? > > Thanks and regards, > Mark > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >   The early bird gets the worm, but the second mouse gets the cheese. 
From: Mark Wayland <M<wayland@to...>  20051124 01:01:21

Richard,=20 > Leave ZWRITE on, and just render them twice, except turn=20 > colorwrites off for the first pass :) Thanks, sounds promising  I'll give this a try. Luckily there aren't too many of them fading at any one time, so I may be able to get away with rendering them twice. Thanks again, Mark 
From: Greg James <gregj@nv...>  20051124 00:15:35

It sounds like you are starting from a point in space and stepping along the perpendicular of the field (the direction of the maximum gradient) by some distance. This will move you off of the true field line path by some small amount if the field lines are curving  which they always are =3D) =20 I can't think of a way to make a correction back to the true field line position. You're looking for a point at some given field value (along an equipotential line in your 2D view), but the point depends on your previous point and the gradient direction. When the gradient direction is changing continuously over space, but you're taking a discreet step across that space, I don't know a way to stay on the true line. There is one thing you could try. The field lines intersect the equipotential lines and are perpendicular to them. If the field lines you choose to draw are equally spaced along one equipotential line, they must be equally spaced along all of the other equipotential lines. You can adjust the field lines to always be equally spaced along the curving equipotential lines, and that should keep them on track. If you think of the equipotential lines as splines, then a given field line will hit each of them at the same spline parameter value. =20 gj Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Danny Kodicek Sent: Wednesday, November 23, 2005 8:46 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Magnetic fields (probably OT, but maybe someone can help) >It's been a while since I did anything with electromagnetism, but I was under the impression that the magnetic field is in fact a vector field (more specifically it is a divergencefree vector field), and thus talking about equipotential field lines does not make sense in the first place? The *field* is a vector, but the potential is a scalar. In any case I'm not=20 quite clear on what this potential consists of (something to do with the work needed to push a wire through that distance, at a guess), but the basic=20 concept seems to work. >So it seems what you are really doing is finding parametrisations of curves in space the tangents of which coincide with the magnetic field. Absolutely right. > It's also been a while since I've done anything with PDE's but I think some sort of advection scheme a la Stam might help here. You're basically solving a differential equation. Ooh  two terms I don't know. That sounds promising :) I'll look 'em up and=20 get back to you. (I skipped most of my electromagnetism lectures too, and=20 never understood curve integrals. I've learned more calculus in the last few=20 weeks than I ever managed at university) Thanks Danny=20  This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Miles Macklin <gda@co...>  20051124 00:13:46

If you want to see intra object transparency probably the cheapest tr= ick is to do one pass rendering back faces first, then reverse your cull ord= er and render front faces. It's a hack that only really works for convex objects but it might do= the job. Miles  Original Message =20 =46rom: "Richard Mitton" <mitton@...> To: <gdalgorithmslist@...> Sent: Thursday, November 24, 2005 1:05 PM Subject: Re: [Algorithms] Entire object translucency fading > Leave ZWRITE on, and just render them twice, except turn colorwrit= es off > for the first pass :) > > Or alternatively, render them solid and then blend a copy of the backbuffer > on afterwards to achieve transparency. > > =20 > ()() Richard Mitton > ( '.') > (")_(") code jester .:. treyarch .:. mitton@... > > >  Original Message =20 > From: "Mark Wayland" <Mwayland@...> > To: <gdalgorithmslist@...> > Sent: Wednesday, November 23, 2005 3:56 pm > Subject: [Algorithms] Entire object translucency fading > > > > Hey all, > > > > I was wondering if there were any neat tricks to rendering transl= ucent > > (fading) objects (as a whole) correctly? > > > > The problem I have at the moment is that when I'm fading an objec= t out, > > the render states go from > > ZTEST/ZWRITE to ZTEST only, causing the polygons of the object to > > incorrectly selfsort resulting > > in a nasty pop (obviously same problem when fading in). > > The objects themselves are sorted from back to front for perobje= ct > > correct blending, but I can't > > afford to do that perpolygon. > > > > Any ideas? > > > > Thanks and regards, > > Mark > > > > > >  > > This SF.net email is sponsored by: Splunk Inc. Do you grep throug= h log > > files > > for problems? Stop! Download the new AJAX search engine that ma= kes > > searching your log files as easy as surfing the web. DOWNLOAD S= PLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through = log files > for problems? Stop! Download the new AJAX search engine that make= s > searching your log files as easy as surfing the web. DOWNLOAD SPL= UNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > 
From: Will Vale <will@se...>  20051124 00:09:43

You could perhaps render the object to the zbuffer (with colour writes turned off) and then rerender with colour writes and alpha blend on, Zwrite turned off and Ztest set to EQUAL (or LESSEQUAL). The idea being to render each of the pixels in the object's silhouette once. It means the object will be present in the Zbuffer until it has completely faded out though  which might look weird if it interacts with other transparent geometry when it's mostly faded out. HTH, Will Mark Wayland wrote: > Hey all, > > I was wondering if there were any neat tricks to rendering translucent > (fading) objects (as a whole) correctly? > > The problem I have at the moment is that when I'm fading an object out, > the render states go from > ZTEST/ZWRITE to ZTEST only, causing the polygons of the object to > incorrectly selfsort resulting > in a nasty pop (obviously same problem when fading in). > The objects themselves are sorted from back to front for perobject > correct blending, but I can't > afford to do that perpolygon. > > Any ideas? > > Thanks and regards, > Mark > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > 
From: Richard Mitton <mitton@tr...>  20051124 00:05:58

Leave ZWRITE on, and just render them twice, except turn colorwrites off= =20 for the first pass :) Or alternatively, render them solid and then blend a copy of the backbuff= er=20 on afterwards to achieve transparency. =20 ()() Richard Mitton ( '.') (")_(") code jester .:. treyarch .:. mitton@...  Original Message =20 From: "Mark Wayland" <Mwayland@...> To: <gdalgorithmslist@...> Sent: Wednesday, November 23, 2005 3:56 pm Subject: [Algorithms] Entire object translucency fading > Hey all, > > I was wondering if there were any neat tricks to rendering translucent > (fading) objects (as a whole) correctly? > > The problem I have at the moment is that when I'm fading an object out, > the render states go from > ZTEST/ZWRITE to ZTEST only, causing the polygons of the object to > incorrectly selfsort resulting > in a nasty pop (obviously same problem when fading in). > The objects themselves are sorted from back to front for perobject > correct blending, but I can't > afford to do that perpolygon. > > Any ideas? > > Thanks and regards, > Mark > > >  > This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20 > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 