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 <[email protected]> To: bf-blender developers <[email protected]> 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 [email protected] http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
