[Bf-committers] Some design questions on particle emission
lukas.toenne at googlemail.com
Mon Jun 28 16:58:43 CEST 2010
That's not the real problem here :)
If this was only about animating the emission rate your idea might
work (though there are better ways to do numerical integration). The
issue here is that there is _no_way_ to know the total amount of
particles as soon as customized emission events come into play.
Say, for example, a node spawns new particles when it collides with an
object. How would you determine the number of colliding particles and
therefore new particles spawned in advance?
However, after some discussion on IRC we decided it's probably best to
not invest much more time in recreating features of the current
particle systems, but instead work on a design for more flexible
node-based particles now.
On Sat, Jun 26, 2010 at 4:19 PM, Roger Wickes <rogerwickes at yahoo.com> wrote:
> 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:
> 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers