| By Mike Jacobs | Article Rating: |
|
| July 31, 2005 07:15 PM EDT | Reads: |
80,563 |
Emit New Particles
The particle system manager notifies the particle system that enough time has elapsed. This time is typically less than 50 milliseconds. The emitter determines how many particles need to be initialized and emitted based on the emission rate, emission rate variance, and the amount of time since the last notification. The speed of the particles is initialized based on the velocity and velocity variance while the generation shape determines the initial location. The generation shapes in the source code include point, line, disk, and radial shapes. Particles are assigned a lifetime using the same central value plus the variance approach used for other attributes.
Bury the Dead Particles
During the previous cycle, particles were aged based on the elapsed time. Now the particles that have exceeded their lifetime are collected and recycled for future emissions.
Update the Surviving Particles
The remaining particles are aged, changed by any external influences, moved, scaled, and rotated. Aging simply increments the age of the particle based on the elapsed time. External influences can affect visual characteristics such as color or transparency, or physical attributes such as scale, acceleration, velocity, or position. Updating physical attributes does involve a bit of physics, but hopefully it hasn't been too long since your last physics class.
As part of applying the influences, the accelerations are accumulated from each influence. For example, there may be a Gravity and Wind influence affecting the particles. Gravity would obviously apply a downward acceleration while wind would apply a horizontal acceleration. These accelerations and the existing velocity and position are used to move the particle. The particle is moved in the following method:
public void move(float dt) {
float[] position = getLocalPosition();
Vector3f v = getLocalVelocity();
Vector3f a = getLocalAcceleration();
v.scaleAdd(dt, a, v);
// Scale add not used with position
// to reduce number of objects created.
float x = position[0] + vx * dt;
float y = position[1] + vy * dt;
float z = position[2] + vz * dt;
setLocalPosition(x, y, z);
}
This implementation uses Euler's approach to numeric integration. This approach works for us provided the time differential (dt) between frames is small. The ParticleSystemManager controls the elapsed time so we can ensure the time differential is small. Other approaches to numeric integration such as Modified Euler, Heun, or Runge-Kutta could be used if we needed more accuracy for our particle simulation.
Because we are currently dealing with point particles, we'll skip scaling and rotation for now since these make little sense for points.
Render the Particles
This step is trivial in Java3D because the previous step changed the location of the points representing the particles. The previous step updated the geometry of the particle system shape using the GeometryUpdater interface and Java3D renders the new positions for us. As the particle system life cycle evolves, the position of the particles changes, creating the animation. Because we are dealing with points, some simulations can be disorienting unless we introduce motion blur.
It's All a Blur
You've probably seen motion blur when the Enterprise goes to light speed. Motion blur on film can occur when the subject moves quickly while the camera shutter is open. While you probably don't want the blur when taking photographs, motion blur makes animation look more lifelike and increases the perceived frame rate. How can we take our particle system to the next level and add motion blur?
Remember that each cycle of the particle system life cycle is repeated after a very short elapsed time. If we treat the elapsed time as an open camera shutter, then we want to blur the particle movement during this elapsed time. During the elapsed time, the particle moves from one location to the next. If a line segment is used instead of a point, we can connect the previous location with the new location and vary the transparency of the line to create the blur as depicted in Figure 4.
The MotionBlurredParticleSystem implements motion blurred points using the Java3D LineArray geometry array class. The ParticleEmitter supports both the previous and current location of the particle, enabling the particle system to use this information to create the line segments. The blurring is accomplished by assigning colors to the end points of the lines with different alpha values. The current location has a fully opaque alpha value while the previous location has a fully transparent alpha value. Java3D takes care of smoothly interpolating the transparency of the line, conveniently creating the motion blur for us.
Light Speed, Mr. Sulu!
Using points and motion-blurred lines for particles in Java3D performs very well. Several thousand particles can be used simultaneously on modest hardware with reasonable performance. I pushed my antiquated one-gigahertz machine to run three motion-blurred particle systems consisting of 8635 particles, gravity, and particle bouncing at 14 frames per second. The 14 frames per second is not stellar; it looks terrific with the blurring. Clearly the advantage of using points or lines is that they are fast and allow the use of thousands of particles. The disadvantage to using points or lines is the lack of scale. Each particle is one pixel in size regardless of the distance from the viewer. While you can change the pixel size of the particles via the PointAttributes and LineAttributes, the particles are still all the same size. Ideally our particles should have scale and, for performance sake, reduce the need for a large number of particles. An approach to solving these issues is to make the particles full-blown Java3D shapes. With this approach we can create fantastic effects like the tornado shown in Figure 5.
Published July 31, 2005 Reads 80,563
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Mike Jacobs
Mike Jacobs is a mild-mannered technical architect by day and recreational programmer by night. Mike works at the Mayo Clinic. Please provide feedback and guidance for future JDJ articles to mnjacobs.javadevelopersjournal.com.
![]() |
indie technologies 08/31/05 06:26:58 PM EDT | |||
http://www.indietechnologies.com now has this Java 3D technology available as a commercial product. |
||||
![]() |
indie technologies 08/06/05 07:05:33 PM EDT | |||
This technology is being commercialized for Java 3D game developers. Visit www.indietechnologies.com for more information. |
||||
![]() |
Java Developer's Journal 07/31/05 06:45:05 PM EDT | |||
Star Trek Technology for Java3D. The Star Trek universe has inspired many technology ideas but I'm disappointed I don't have a transporter yet. One Star Trek technology that has been available for sometime is the particle system. No, this is not an exotic propulsion system for your flying car. The particle system was invented to animate the Genesis effect in Star Trek II: The Wrath of Khan. While the Genesis device was used to transform a barren planet into one full of life, we can adopt this technology for more modest effects in Java3D. |
||||
![]() |
Mike Jacobs 07/11/05 09:04:30 AM EDT | |||
If you are looking for the source it is at the following link (my previous comment had a period at the end of the link). |
||||
![]() |
David Morris 07/01/05 09:25:29 AM EDT | |||
Mike, the stated link to the source code is invalid. Could you please update this link. Thanks, David |
||||
![]() |
Mike Jacobs 06/30/05 10:13:20 AM EDT | |||
The web editor decided to do things a bit different than the past. The first mention of the listings (Listing 1) is a link to all of the code. The link is http://res.sys-con.com/story/jun05/99792/source.html. |
||||
![]() |
Michael Yankowski 06/29/05 09:57:32 PM EDT | |||
I can't find any links to the source code. Thanks, |
||||
![]() |
Mike Jacobs 06/16/05 11:32:10 AM EDT | |||
The source code is now current. |
||||
![]() |
Mike Jacobs 06/16/05 09:20:07 AM EDT | |||
It looks like the source for this article is slightly down level. JDJ is working on it. Mike |
||||
- Kindle 2 vs Nook
- Why IBM’s Server Chief Got Busted
- Is Cloud Computing Like Teenage Sex?
- Industry Experts Discuss the State of Cloud Computing
- Performance Tuning Essentials for Java
- Confessions of a Ulitzer Addict
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- It's the Java vs. C++ Shootout Revisited!
- Cloud Computing Can Revitalize Your Career as Software Developer
- IBM Could "Reinvent" Java: Mills
- Oracle & Cloud Computing: Exclusive Q&A with SVP Richard Sarwal
- A Brief History of Cloud Computing
- Kindle 2 vs Nook
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- Why IBM’s Server Chief Got Busted
- Is Cloud Computing Like Teenage Sex?
- Industry Experts Discuss the State of Cloud Computing
- Performance Tuning Essentials for Java
- The Difference Between Web Hosting and Cloud Computing
- Cloud Computing Expo: Exclusive Q&A with Yahoo! SVP Cloud Computing
- Ajax in RichFaces 3.3, JSF 2 and RichFaces 4
- Confessions of a Ulitzer Addict
- My Thoughts on Ulitzer
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- What's New in Eclipse?
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- i-Technology Predictions for 2007: Where's It All Headed?









































