[Bf-committers] Some design questions on particle emission

[Roger Wickes]

to my limited mind, what you are doing is like in basic calculus where you integrate a function. 
the old way used a frame as delta-x = (b-a)/n and you are providing lim n->infinity as dx->0. 
So, instead of being able to specify just three numbers, we need a way to express the function. 
Thus, for the "amount" mode, I would suggest using an F-curve. That would allow
the user to specify the emission rate as a function, either continuous, or discrete
(using the constant interpolation). Using a constant interpolation would result in
a burst or intermittent spray, whereas linear would be a constant flow rate, and the 
normal spline would be a rate-of-change kind of increasing or decreasing flow rate.

Practically speaking, you cannot calculate infinite divisions, so the user could define 
the fidelity/graininess of the calculation, (how many steps, or n, to use for the simulation.
 Using area-under-the curve integration or approximate via dx(f(a)+(f(b)-f(a))/2)) for that interval 
would tell you how many particles to emit for that step. (divide the total area-under-the-curve by 
the area for that interval times the total lifetime number of particles)

to me, as a user, the grid option maps emission of that number of 
particles for the time interval
in a known and orderly fashion from a constant set of emission points, 
like a pulsating shower head. 
Jittered mixes it all up, which is what we normally use for broad-based 
emssions like smoke. Call me 
crazy, but that is all just hacks to approximate a texture. If you can think of an texture mapped to a surface
where black=0 and white =1, then you could use it as an "emission" texture to tell the simulation
where to map the particles to emit from. The grid option looks like a checker texture, totally even looks like a
white texture, and jitter is a noise texture. Burning wood probably looks like the wood texture mixed with the 
ever-useful clouds texture, or perhaps a hard-noise cloud texture. If we could also use image (static and seq/movie) 
texture (nodes to make a changing emission map over time) then you avoid a lot of hacks and give the artist
flexiblity they need for quality simulations, and not have to invent different parameters and settings to get around
the issue (imho). 

 For pre-grown hair, then you have a constant interpolation curve where 100% is emitted at frame 0, and 
then drops to 0 emission at frame 1 on. (or whatever timescale is used) and a texture map that says where to emit
hair from; the grayness of the map pixel specifies length. This would be easy to paint UV. Starting off with less than
white would allow the artist to use an image sequence to allow hair to grow by brightening the image over time.
Since the curve is known at the beginning of the sim, you would know how many to pre-emit. 

A challenge introduced by my humble opinion that I can see is like, having some of your hair ripped out or sliced off.
The artist would, at that frame/frames, change the texture to have a black spot where the hair goes missing. that implies
mapping individual strands of hair, which i think are the particles themselves - effectively letting those particles "die" based
on the texture. Cutting the hair (trimming) actually modulates the texture by changing it to be darker for those strands.

my .02 --Roger




----- Original Message ----
From: Lukas Tönne <lukas.toenne at googlemail.com>
To: bf-blender developers <bf-committers at blender.org>
Sent: Sat, June 26, 2010 8:02:17 AM
Subject: [Bf-committers] Some design questions on particle emission

I'm currently trying to reimplement some more or less important
features of current particles and have some questions that should be
discussed. These are regarding issues with the emission procedure,
which will be much more flexible with paged buffers, but also break
some simplifying assumptions that make the current system work.

The new code can be found in the particles-2010 branch, more info can
be found in the wiki:
http://wiki.blender.org/index.php/User:Phonybone/Modular_particle_system

1) Jittered and Grid distribution:
These depend on a fixed amount of particles to avoid repetition (or at
least determine how many particles can be emitted before the pattern
repeats). This was no problem with the current fixed-size buffers and
their inherent "amount" value.
The new rate-based emitter mode does not have such an upper limit. It
could either disable these distributions or provide an arbitrary user
defined number. Emitters will also have "amount" modes, where a fixed
amount of particles is emitted over a frame interval or right at
simulation start (useful for hair with infinite lifetime), these modes
can still make use of jitter and grid distributions naturally.

2) Hair emission and lifetimes:
Currently hair particles are basically treated as "paths" of their
root particles. This means that when hair is calculated initially, the
normal particles are simulated over (arbitrarily) 100 frames and their
locations used as keys for the hair particle strands. This is not
totally wrong, since it somewhat resembles the process of hair or
grass "growing" out of their roots (which in turn are located in earth
or skin, represented by mesh surfaces). Good hair geometry usually
needs a lot of modification in particle edit mode afterwards. Actual
dynamic hair behaviour is done with a completely separate system,
which interprets the "finished" strands as cloth (and has its own
problems, see Durian).

I'd like to somehow make a separate simulation step for initial hair
growth to avoid fast-forwarding the whole particle system through the
100-frame lifetime of hairs as it happens now. This would probably
cause trouble, since particles can be emitted in any frame now, so
they can't be pre-calculated at simulation start. A quick solution
could be to just disable emissions other than "all at the same time"
for hair. Any opinions?
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers