Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Particle Systems #5212

Merged
merged 116 commits into from
Jun 22, 2017
Merged

Particle Systems #5212

merged 116 commits into from
Jun 22, 2017

Conversation

jasonbeverage
Copy link
Contributor

@jasonbeverage jasonbeverage commented Apr 17, 2017

Me again 😄

This PR adds particle system support to Cesium. This work is a conglomeration of ideas from:

  • The original particles branch that @bagnell did
  • osgParticle from OpenSceneGraph
  • Unity's particle system
  • My own ideas :)

I'm sure you'll have plenty of feedback on this one so I wanted to get it out early.

I've got a live demo you can play with here:
http://cesiumparticles.netlify.com/apps/sandcastle/?src=ParticleSystem.html&label=Showcases

Originally I was going to write a fully GPU based particle system (I hacked one together using OpenSceneGraph, see this video) but ultimately just ended up doing it all on the CPU. The GPU solution is really interesting for when you need to render a massive amount of particles for something like a water or super realistic fire effect, but it also complicates integrating logic that doesn't lend itself well to being fully implemented on the GPU. For example, in my early work on this I was able to integrate the Cannon.js rigid body engine into Cesium with pretty minimal code which would have been really difficult to do on the GPU. You can see a prototype video here

Some notes about the design

  • A ParticleSystem has an emitter. The emitter defines the initial position of a particle as well as it's initial direction. This is similar to Unity's "shape" property. I've implemented a few emitters, each with their own properties defining the shape. You can select various emitter shapes in the sand castle demo from the drop down menu.
    • BoxEmitter
    • CircleEmitter
    • ConeEmitter
    • SphereEmitter
  • The ParticleSystem has it's own modelMatrix, making it easy to attach to an entity through the Entity framework. This only effects the initial position and direction of the particle. Once a particle is emitted it is independent of that modelMatrix. For example, you can click the "fly" checkbox in the demo and the plane will fly, emitting particles along the way. But each particle will still maintain it's own frame of reference.
  • ParticleSystem also has an emitterModelMatrix. This is an additional transform that occurs within the localized space of the modelMatrix. For example, it is how I'm positioning the emitter on the propeller of the plane instead of the center of the model. If you modify the translation or rotation parameters in the UI it will change the position of the emitter within the model.
  • The number of particles emitted is controlled by the rate parameter, which is simply the number of particles to to emit each second. You'll also notice an explosion every 5 seconds in the demo. That is controlled by the "burst" array (which is an idea I took from Unity). You can define timed bursts of particles like this:
bursts: [
            {time: 5.0, min: 300, max: 500},
            {time: 10.0, min: 50, max: 100},
            {time: 15.0, min: 200, max: 300}
        ]

The time is the amount of time into the particle system simulation loop before the burst is applied and it will emit somewhere between min and max particles on the burst. ParticleSystem also has a loop option, which is mostly just used to reset the bursts when it's done looping.

  • The lifetime property of a particle system defines how long the system is active. For example, if you set it to 10 particles will emit for 10 seconds and then stop. By default it's infinite.
  • Properties that define the initial state of the particle that can vary are prefixed with min/max. For example, min/maxSpeed, min/maxLife, etc. Properties will be a random value between the min and max.
  • The scale and color of a particle can change over the lifetime of a particle. These can be set with start/endColor and start/endScale. This lets you do things like make the particles get smaller as they die, or become more transparent so they fade out.

Things I know that still need to be done:

  • Update CHANGES.md
  • Unit tests
  • Wiring up the "complete" event on particle systems through the entity framework so you can script particle systems.
  • replace fire.png, Particle Systems #5212 (comment)
  • Any feedback you have :)

particlesystem

Thanks!

Jason

Making the placer control the initial velocity vector.
Fixed startScale/endScale initializers.
@bagnell
Copy link
Contributor

bagnell commented Jun 20, 2017

@pjcozzi This is ready for another review. Since your last review, I added tests, updated CHANGES.md, and addressed all of your comments. I'm working on an additional Sandcastle example, but that can be a separate PR.

@bagnell
Copy link
Contributor

bagnell commented Jun 21, 2017

I added better memory management so its not adding and removing billboards causing constant VAO creation/destruction. Also, added a new Sandcastle example.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 21, 2017

Apps/SampleData/fire.png

Are we sure this should have so much alphaed blank space around it? That is a lot of wasted fillrate.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 21, 2017

In the Sandcastle example, the "Show" button turns off the aircraft but not the particle system.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 21, 2017

In the fireworks Sandcastle example, I would not expect this to be 10% of the profile? Is this an easy fix for this PR or should we submit an issue?

image

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 21, 2017

Just those comments. Very close!

@bagnell
Copy link
Contributor

bagnell commented Jun 22, 2017

In the fireworks Sandcastle example, I would not expect this to be 10% of the profile? Is this an easy fix for this PR or should we submit an issue?

I would submit an issue. The problem is the memory management again. Sometimes more particles are created than was estimated and they get removed later. This causes the number of commands from the billboard collection to change. For every new command, it generates the OIT shader and looks it up in the cache.

@bagnell
Copy link
Contributor

bagnell commented Jun 22, 2017

@pjcozzi This is ready for another look.

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 22, 2017

Submitted #5522

@pjcozzi
Copy link
Contributor

pjcozzi commented Jun 22, 2017

Thanks again @jasonbeverage @bagnell!

@jasonbeverage what's next?!?!? 😃

@pjcozzi pjcozzi merged commit 40147c0 into CesiumGS:master Jun 22, 2017
@rahwang
Copy link
Contributor

rahwang commented Jun 22, 2017

This is so cool!

@jasonbeverage
Copy link
Contributor Author

Thanks again for working with me to get this merged! I'll hopefully have a couple more PRs before the end of the year ;)

@jasonbeverage jasonbeverage deleted the particlesystem branch July 26, 2017 14:40
@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 26, 2017

Really looking forward to them, any teasers???

@jasonbeverage
Copy link
Contributor Author

No teasers yet, still working on what they will actually be :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants