Presentation is loading. Please wait.

Presentation is loading. Please wait.

Particle System Design. The Challenge Particle systems vary so much But want some code reuse Option 1: parameterization Option 2: inheritance Option 3:

Similar presentations


Presentation on theme: "Particle System Design. The Challenge Particle systems vary so much But want some code reuse Option 1: parameterization Option 2: inheritance Option 3:"— Presentation transcript:

1 Particle System Design

2 The Challenge Particle systems vary so much But want some code reuse Option 1: parameterization Option 2: inheritance Option 3: subroutine library Let’s look at actual systems

3 Look for Custom Code: Motion Rendering Orientation Interparticle Force Color Spawning Emitters Any of these could use custom code

4 Parameterization Simply not general enough

5 Inheritance Inheritance is usually helpful for code reuse. But in the case of particles, want to inherit motion from here, want to inherit rendering from there, want to inherit spawning from that, Inheritance doesn’t work that way.

6 Subroutine Library Each system is its own module, however, Library provides: routines for rendering routines for calculating motion routines for spawning etc Let’s design this library

7 Rendering Routines Render camera-aligned quads pos, size, color, tex, theta, blend Render soft trails ie, for jet engine exhaust or, for sparks from a grinder Render each particle as 3D model

8 Soft Trails For each point along trail generate two “side-points.”

9 Soft Trails For each point along trail generate two “side-points.”

10 Soft Trails For each point along trail generate two “side-points.” for each point P: eye = vector from cam to P lineseg1 = one of two segments connected to P lineseg2 = two of two segments connected to P v1 = cross(lineseg1,eye) v2 = cross(lineseg2,eye) if (dot(v1,v2) < 0) { v2= -v2; } v = normalize(average(v1,v2)) sidepoint1 = P + v sidepoint2 = P – v

11 Particle Motion Two ways to do it: Option 1: Timestep simulation. Calculate acceleration Position += Velocity Velocity += Acceleration Option 2: Closed form equations. Particle.X = f(t) Particle.Y = g(t) Why not always use timesteps?

12 Why closed form I Can be hardware accelerated. Example: simple fountain. struct vertex { float3 startpos; float3 initialvelocity; float lifespan; }; vertex shader globals { float3 gravity; float currentTime; };

13 Why closed form II Can use prerecorded paths. float positionX[1024]; float positionY[1024]; Can add several prerecorded paths multiple circles wiggle + parabola Can transform prerecorded path smoke example Library should contain many paths.

14 Why Timestepped Particles that “bounce.” or, interact with world in other ways. simply can’t do this in closed form. Decouple frame rate from renderer. This should be a class in your library. ps.elapsed = GetClock() – ps.createtime timesteps = (int)(ps.elapsed / ps.framerate) while (timesteps > ps.timesteps) { ps.update(); ps.timesteps += 1; }

15 Data Structures Every particle system needs some form of particle list. But, it seems every system has different particle attributes. pos, vel, accel, theta, direction, age, history, color, rand seed, opacity, lifespan, size, texture, 3D mesh, quat, etc, etc... My solution: class particlearray { int array_size; int array_fill; float3 *pos; float3 *vel; float3 *accel;...


Download ppt "Particle System Design. The Challenge Particle systems vary so much But want some code reuse Option 1: parameterization Option 2: inheritance Option 3:"

Similar presentations


Ads by Google