CSE 40166 / 60166 - Computer Graphics

For this assignment, you will write an OpenGL/GLUT application that simulates several uses of Particle Systems. To facilitate this task, you will need to create a Particle class that contains all the necessary information an individual Particle would need to keep track of (position, velocity, etc.). You will also need to create a ParticleSystem class that contains a list of Particles. We can then apply a set of rules to a ParticleSystem and every Particle in that System will follow those rules. One these rules must be gravity. Gravity should be a force that is acting on all Particles in a System.

There will be two different Particle System implementations that you must implement. Each particle system must be placed into a Skybox using textures. There is an example sky box on the Resources page along with links to other pages but feel encouraged to find your own. If you find a repository with useful sky boxes, please send the link to the instructor so it can be added to the Resources page. Remember a complete sky box will have a ground and a sky in addition to just the horizon. It is recommended that you create a Texture class to handle the loading and registration of a texture.

Feel free and encouraged to add in any extra features from prior assignments such as (but not limited to): sound, overhead map, text, object models, etc. You are expected to use appropriate lighting and materials on all objects in your scene as well as a sensible camera. A greater emphasis should be placed on making your scene visually appealing. Extra points may be awarded for well detailed scenes.

The first Particle System will simulate a fountain effect. A fountain can be used to simulate many different components in a graphics application (water fountain, sparks/fireworks). A fountain works by having a source point and a cone bounding the initial direction particles can move. Your particles will all have initial position equal to the System's source point (the emitter) and an initial velocity within the System's cone. Once a particle is spawned, it will continue along its current trajectory acting only under the force of gravity. The particle will continue to act under gravity for the lifespan of the particle. Once the particle's lifespan has elapsed, the particle will die, be deleted, and no longer a part of the System.

For this Particle System, each Particle will be a textured transparent quad. Choose a suitable image to texture on each quad and supply an alpha-channel texture as well for transparency on the quad. The textured quads should also exhibit a Billboarding effect: no matter what direction the user views the particles from, the particles should be rotated to face the user. Remember, the particles must also be drawn back-to-front from the user's point-of-view to display the textured transparent quads correctly using blending.

The actual context of the particle system is up to you. It could be a water fountain, fireworks, sparks, etc. Ensure the context is clear and choose an appropriate texture for each particle.

The rules for the Particle System will be specified by a control file. A single line will represent a single Particle System. At a minimum, each line must specify the following information:

1. Type of particle system (more below)
2. Particle system source point
3. Particle system max cone angle
4. Particle system min & max initial velocity
5. Particle system min & max lifespan
6. Particle system spawn rate (# particles / second)

These parameters will create bounds for the initial values of a Particle. A new Particle should have a random value within these bounds. Since it is possible to have multiple types of particle systems (like in the next part) so the first parameter on the line, the type of system, will dictate the expected input for the rest of the line. See example following the next description. Provide an example control file demonstrating the fountain particle system.

To simulate rain, we must first create a source (emitter) for the rain to fall from. Create a cloud that will be the holder for the Particle System. Each drop of rain will be an individual Particle. Again, the Particle System will have an emitter and this point will be the center of the cloud. When a particle is spawned, it will have an initial position within the bounding box of the cloud. Once a rain drop is spawned, it will act with gravity as an outside force. The rain drop can be a textured quad, or a 3D drawn object; think about the benefits of using both. The user should be able to move the cloud in the XZ-Plane and particles will always spawn from where ever the cloud is.

Once a rain drop hits the ground plane, it should then create a splash. At this point, the rain drop particle will die and spawn a new particle system. This new Particle System should be very similar to the fountain from Part I above. The splash system will move in a cone acting only under gravity and once the splash droplets hit the ground plane, they will die as well.

In addition to the rain drops falling under gravity, they will also be acting under wind. The wind should have a direction and a speed. This additional force will be acting on the rain drops. For EXTRA CREDIT: Give the wind a source point, a direction, and a bounding box. If rain enters this bounding box, then it will be blown accordingly. Think of a fan sitting in space, if rain falls in front of the fan then they will be blown. You must be able to have some sort of debug visual that can be toggled on and off to display where the wind volume is. Hint: this is a basic collision detection test.

Just as above, the Particle System specifications will be done via control file. A single line represents a single Particle System. The line should contain the necessary information for the rain Particle System (cloud position, cloud size, rain drops / second, wind speed, wind direction, wind position, etc). It can now be possible to have a single control file that specifies both a rain particle system and a fountain particle system in the same application. An example control file that specifies both particle systems is below:

# System Type, System Inputs # Type = F, Fountain. System Inputs: #    Emitter X, Y, Z, Cone Angle, Min Velocity, Max Velocity, Min Life, Max Life, #    Spawn Rate # Type = R, Rain. System Inputs: #    Emitter X, Y, Z, Emitter Width, Depth, Min Velocity, Max Velocity, Spawn Rate F, 0, 10, 0, 15, 2.5, 4, 4, 6, 10 R, 5, 25, 10, 4, 7, 0.2, 0.4, 15

This will place a fountain particle system at (0, 10, 0) which corresponds to the tip of a fountain object in our scene. There also is a rain cloud centered at (5, 25, 10) that is dropping rain in the distance. Provide an example control file demonstrating the rain particle system.

This section is extra credit for all students.
For extra credit, create a third type of particle system that implements flocking. It is up to you to determine in what context flocking will take place. One possible scenario is a set of birds moving towards the lead bird (this case can be thought of in 2D). A second scenario is a school of fish swimming towards the lead fish (this case extends the bird scenario into 3D). Of course in whichever scenario you think of, particles must not overlap and should make an attempt to stay a minimum distance apart (two birds/fish cannot fly/swim in the same spot at the same time). Whichever context you decide on, the scene and surrounding environment should reflect the context (fish shouldn't swim in the sky and birds don't swim in the ocean for example). The type of flocking used should also be described in the README.txt file.

Update the webpage that you submitted with the Midterm Project to include an entry for this homework assignment. As usual, include a screenshot (or two) and a brief description of the program, intended to showcase what your program does to people who are not familiar with the assignment.

With this and all future assignments, we expect you to appropriately document your code. This includes writing comments in your source code - remember that your comments should explain what a piece of code is supposed to do and why; don't just re-write the code says in plain English. Comments serve the dual purpose of explaining your code to someone unfamiliar with it and assisting in debugging. If you know what a piece of code is supposed to be doing, you can figure out where it's going awry more easily.

Proper documentation also means including a README.txt file with your submission. In your submission folder, always include a file called README.txt that lists:

• Your Name / netID
• Homework Number / Project Title
• A brief, high level description of what the program is / does
• A usage section, explaining how to run the program, which keys perform which actions, etc.
• Instructions on compiling your code
• Notes about bugs, implementation details, etc. if necessary

• For all students: This section will count as an additional 1% of your final course grade, with the 1% being broken down as follows.

Please update your Makefile so that it produces an executable with the name hw5. When you are completed with the assignment, submit the source code, Makefile, and READEME.txt to the following directory:

/afs/nd.edu/coursefa.12/cse/cse40166.01/dropbox/<afsid>/hw5/
Similarly, title your webpage <afsid>.html (e.g. jpaone.html) and submit it to:

/afs/nd.edu/coursefa.12/cse/cse40166.01/dropbox/<afsid>/www/
Place any screenshots or other images used on the webpage in:

/afs/nd.edu/coursefa.12/cse/cse40166.01/dropbox/<afsid>/www/images/