Most people are unaware that VRML 2.0 can be combined with Java support to provide a way of creating powerful effects. By exploiting the power inherent in the Java side of the system, we can create some extremely powerful effects and worlds. In this article I'll both discuss implementing particle systems in your VRML worlds, as well as talk about what kinds of optimizations you'll need to make.

Particle Systems

Particle Systems are innovations in computer graphics that have led to some very realistic special effects in film and television. Particle systems are ways of controlling a large group of small objects, or "particles." By attributing rules and mannerisms to each particle, we can control the behavior of the group as a whole. As a side benefit, sometimes some very beautiful and intricate patterns emerge from a set of very simple rules! This phenomenon is called "emergent behavior" and can be exploited in your VRML worlds for increased realism.

To create a particle system in a VRML+Java-based system, there are a few steps to take. First, we must create a group of simple objects in your VRML scene (20 or so will do). These objects must be simple because we will have a large number of them. A good way of creating such an object is to create a diamond-like shape, which is small yet retains visibility from every angle. (Using primitives like spheres, or nodes like Billboards for single faces is not recommended due to the additional overhead for the browser to handle. Remember, the key here is realism, and frame rate is crucial to realism. The fewer polygons per particle, the better.)

Second, we must attribute some "behaviors" to each particle. These behaviors will ultimately define how the group functions – a slight variation in local behaviors will have a large impact on the behavior of the group. For example, the behaviors attributed to particles in an explosion are radically different from the behaviors attributed to particles in a flock of birds.

This image is a screen shot of a particle system representing virtual gnats, or mosquitoes. The attributes of this particle system can be altered via the Java AWT window shown above.

Consider a simple explosion. We can model this as a bunch of objects, say a simple diamond-shaped structure. In order for the explosion to look realistic, we can model this as the following:

1. Give each element an initial random trajectory.
2. Decay its speed over time.
3. (optional) apply the force of gravity to each particle.

Problems Underneath the Surface

However, there is a subtle problem here. Consider the fact that most realistic explosions consist of a number of particles far greater than three! The more particles we introduce into the system, the more overburdened the Java program will be. Remember, it essentially "sleeps" every tenth of a second, and then is asked to perform many translations immediately. If the number of particles is too much for the system to handle in a tenth of a second, the system as a whole will hang, or have other unsavory effects.

The solution to this problem is to somehow "distribute" the work along that small interval. One could write a system which sleeps for a time interval inversely proportional to the number of the particles in the system. However, this approach is not very extensible -- if the number of particles in the system rises and falls, this "sleep" period would have to be changed frequently, leading to some strange effects. A far better approach is to exploit concurrency -- to make your worlds multithreaded.

Exploiting Parallelism

Concurrency is one of the most overlooked sources of power that potentially exists in VRML worlds. In the quest for faster frame rates, a higher polygon count, and better-looking worlds, concurrency will provide a profound difference. Making your VRML worlds multi-threaded is possibly the greatest single positive change you can make in your worlds, if they are designed intelligently.

Concurrency has a considerable history in computer science. In a nutshell, it involves making programs appear to do multiple things at once. Obviously, the more things you run at once, the more you will achieve in a shorter time. Now of course, not everything is adaptable to this scheme (anyone who has tried patting their head and rubbing their tummy at the same time will quickly realize this), but most problems that VRML content creators face are actually potentially parallelizable.

Back to our explosion. A better solution than the one above would be to make a "thread" responsible for each particle. A thread is a pseudo-independent program in execution, which can be run in parallel with other threads. By giving each particle a thread, we can simulate hundreds of particles in parallel. This way, each thread is only responsible for one particle, thus freeing it from the overburdening that we saw before. The system will uniformly distribute the load amongst the different threads. However, you may hit the other extreme. The time spent setting up a thread is not negligible -- taking the time to set up hundreds of threads might be a hindrance rather than a benefit.

The obvious compromise is to set up a few number of threads. Each thread should be responsible for several particles. By doing this, we can achieve a smooth frame rate with a large number of particles, while not overloading the CPU with too many thread-creation requests.

Communicating Particles

However, examples like the explosion I just covered are simplistic. The single most important drawback in this scheme is that the particles have no communication with each other. In order to create really dynamic scenes, some method of communication between discrete elements must be made, or the system will quickly become boring.

This is a screen shot of a dynamic flag blowing in the wind. It was created via a spring-and-weight particle system. Again, attributes of the system (wind, direction, etc.) can be altered by the user for real-time feedback.

In the next example I will cover something found in nature: a flock of birds. Bird flocking seems like a very complicated process, but it is really quite simple, stemming from three simple rules (called Reynolds' Algorithm):

1. Try to match the speed of my neighbor
2. Try to match the trajectory (direction) of my neighbor
3. Try to fly towards the center of the flock

In any case, writing flock routines using normal VRML and Java code might quickly get bogged down, especially with a dense flock. Remember, each bird has to coordinate with every other bird (most notably in rule #3) so the more birds you add, the more work each bird has to do. Parallelism to the rescue!

By making this routine multithreaded, we can again set up a few threads and make each thread responsible for several birds. However, the main problem here is that the birds must communicate. Rule #1 and #2 require communication with nearby birds, and rule #3 requires some knowledge about the flock as a whole. Because variables like speed, trajectory, etc. are well-known to the system and can be read at all times, there should not be a problem.

However, there is a well-known phenomenon in parallelism called deadlock. If thread A requires some information from thread B, but thread B requires some information from thread A, we have deadlock -- a state where no one can progress. When writing parallel programs, and you find your programs suddenly lock up -- you are most likely looking at a state of deadlock. You must be careful to avoid such scenarios! Another potential problem is a lack of synchronization. This occurs mainly when writing to shared areas in memory. If two threads decide to write to a certain shared variable, then it is probable that one thread will overwrite the other, leading to strange results. The solution lies in synchronizing the threads so that they don’t compete. Deadlock avoidance and synchronization are large topics and outside the scope of this article, but if interested please see the list of references below.

Other Applications

While multithreading is certainly well-adaptable to particle systems like the ones discussed, it is definitely not restrained to them! Many problems in creating VRML worlds can be solved using threads. Examples include gravitational models, threads for independent objects in worlds, and any situation where you have a large number of objects interacting with the user or themselves.

It should be noted that while multithreading your VRML worlds is a good idea, it is not completely supported in current VRML 2.0 browsers. As they say, your mileage may vary, so be sure to check if your browser supports multi-threaded worlds before jumping in.

VRML 2.0, together with Java support, provides an unbeatable combination for creating powerful, complicated worlds. Including special effects inside your VRML worlds will both make them very realistic as well as help to continue to push the frontier of VRML technology further. Sitting on the bleeding edge of technology sometimes hurts, but the consolation is that you get to play with the cool stuff before anyone does!

Happy coding.

References:

• "Java for 3D and VRML Worlds", Lea, Matsuda, Miyashita. New Riders, 1996.
• "Concurrent Programming in Java: Design Principles and Patterns", Lea. Addison-Wesley, 1997.
• "Artificial Life Lab", Rucker. Waite Group Press, 1993.