Welcome, Guest

Want to take part in these discussions? Sign in if you have an account, or apply for one below

• Forgot your password?
• Apply for membership

1. • CommentAuthorColin
   • CommentTimeSep 21st 2010

    
   Hi,
   
   I'm writing a custom action to implement the Lennard-Jones potential to simulate atoms interacting with one another. Unfortunately, this potential has very strong repulsion at short inter-particle separations, which always leads to the system blowing up. I've already tried using the epsilon approach used in MutualGravity, et. al and that kind of worked but it's still not great. Even using this approach, the particles gain energy constantly and the whole system speeds up over time. I'd prefer not to use SpeedLimit if possible.
   
   My next thought is to try to run the simulation using a very short frame duration. However, this makes the system move very slowly. I could be wrong, but it seems to me that drawing the system is more computationally expensive than actually running the actions. So, I was thinking about trying to implement in Flint something I had done a couple of years ago in Java: using a very short time step for the calculations and only drawing the system every 10+ time steps. My naive first stab at this was to add a bunch of the same type of action to the emitter. However, they seem to get sorted by type. I had LennardJones, Move, and BoundingBox in that order multiple times. However, instead of executing in that order, the emitter ran LennardJones multiple times and then Move multiple times, etc. This made the system blow up super fast. Even if there is some method by which I could get this approach to work, it seems like there should be a more elegant approach.
   
   I know you can use runAhead() to run your emitter's actions a bunch of times before you draw it for the first time. Is it possible to do this type of thing repeatedly? If so, how? Is this approach even worth pursuing?
   
   Any input that people can offer would be much appreciated. Thanks!
2. • CommentAuthorColin
   • CommentTimeSep 21st 2010

    
   I realized that the grouping issue I had with actions of the same type was due to their priorities. I guess I could add 10 of each type of action I want to execute to the emitter and then give them priorities that would enforce that they run in the intended order but that seems like a bad kludge. Any more elegant suggestions?
3. • CommentAuthorRichard
   • CommentTimeSep 23rd 2010 edited

    
   There's probably lots of ways you could do this. The two that come to mind are...
   
   1. Override the Emitter class
   
   class MyEmitter2D extends Emitter2D
{
override pubic function update( time:Number ) : void
{
var microtime:Number = time * 0.1;
for( var i:int = 0; i < 10; i++ )
{
super.update( microtime );
}
}
}
   
   2. Take control of the update yourself
   
   emitter.useInternalTick = false;
FrameUpdater.instance.addEventListener( UpdateEvent.UPDATE, updateParticles, false, 0, true );

private function updateParticles( event:UpdateEvent ):void
{
var microtime:Number = event.time * 0.1;
for( var i:int = 0; i < 10; i++ )
{
emitter.update( microtime );
}
}
   
   P.S. I haven't tested this code so I apologise if it contains errors.