- For newtonian particles a "self effect" button in particle extras makes the particles be effected by themselves if a particle effector is defined for this system, currently this is a brute force method so things start getting slow with more than ~100 particles, but this will hopefully change in the future.
- Two new effector types: charge and a Lennard-Jones potential based force (inter-molecular forces for example).
-Charge is similar to spherical field except it changes behavior (attract/repulse) based on the effected particles charge field (negative/positive) like real particles with a charge.
-The Lennard-Jones field is a very short range force with a behavior determined by the sizes of the effector and effected particle. At a distance smaller than the combined sizes the field is very repulsive and after that distance it's attractive. It tries to keep the particles at an equilibrium distance from each other. Particles need to be at a close proximity to each other to be effected by this field at all.
- Particle systems can now have two effector fields (two slots in the fields panel). This allows to create particles which for example have both a charge and a Lennard-Jones potential.
somefile_##.png -> somefile_01.png
somefile_########-image.png -> somefile_00000001-image.png
Before, A hash at the end of the string would be replaced by a number with 4 characters. This is still default if no #'s are in the string, so nothing has changed.
To use this function from the python api use scene.render.getFrameFilename()
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewritehttp://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
Particle system was messing up depsgraph tags, causing bad results
in commandline renders especially (or in rendering first frame of
animation).
Fixed with introducing a temp storage tag in Objects. The real fix
should be to make particle systems behave nice inside the depsgraph.
Static particle option: maximum length. Button is next to "Vect" in first
particle panel. This allows weird forcefields and wind to act without
extreme long strands.
#4742 exported normals are now correct
#4821 & 4956 for complex movements in/outflows can now also
use the animated mesh option
- new features
* isosurface subdivision: directly
creates a finer surface mesh from the simulation data.
this increases simulation time and harddisk usage, though, so
be careful - usually values of 2-4 should be enough.
* fluidsim particles: extended model for particle
simulation and generation. When isosurface subdivision is enabled,
the particles are now included in the surface generation,
giving a better impression of a single connected surface.
Note - the particles are only included in the final surface
mesh, so the preview surface shows none of the particle
effects.
* particle loading: different types of particles can now be selected for
display: drops, floats and tracers. This is a bit obsolete
due to the extensions mentioned above, but might still be useful.
Floats are just particles floating on the fluid surface, could
be used for e.g. foam.
* moving objects impact factor: this is another tweaking option,
as the handling of moving objects is still not conserving
mass. setting this to zero simply deletes the fluid, 1 is
the default, while larger values cause a stronger
impact. For tweaking the simulation: if fluid disappears, try
increasing this value, and if too much is appearing reduce it.
You can even use negative values for some strange results :)
- more code cleanup, e.g. removed config file writing in fluidsim.c,
added additional safety checks for particles & fluidsim domains (these
currently dont work together). I also removed the "build particles"
debug message in effects.c (seemed to be unnecessary?).
Some more info on the new features:
Here are two test animations showing the difference between
using the particle generation with isosurface subdivision.
This is how it would look with the old solver version:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_1noparts.mpg
and this with the new one:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_2wparts.mpg
Both simulations use a resolution of 64, however, the version with particles
takes significantly longer (almost twice as long).
The .blend file for a similar setup can be found here:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_testmanc4.blend
(Minor Tips for this file: dont enable subdivions of characters until rendering,
thus leave off for simulation, as it uses the rendering settings! For making
nice pictures switch on subdivion, and OSA.)
And here's a picture of old vs. new (for webpage or so):
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_manc4compare.png
When using a particle system in a dupli-group, and the group is in the
current scene but not visible, the particles are calculated on wrong
position. This is the recurring trouble with particle calculating... which
doesn't do despgraph stuff.
This commit fixes the error, but it will still display particles *once*
(one draw) on the wrong location. That's a lag in the system I cannot
solve quickly...
Note that this system does work OK when you put the group in another Scene,
or linked from another file. That's what it was coded for...
Particle distribution error when using Vertex Weights.
In the unlucky case the last face in a Mesh has no weight (zero), the code
that tries to distribute particles evenly accidentally could assign it
still a particle, because of the 'remainder' calculus.
Also only happens in cases where the remainder has a value.
So a workaround is also to increase/decrease amount of particles.
of the fluidsim can now be disabled with the
flag: BF_NO_ELBEEM='true', e.g. for irix systems.
(The number of ifdefs from the original
patch was reduced, and the defines are now
only necessary when elbeem is switched off.)
- particle generation option is available again
When a curve guide animates, it doesn't correctly work on dynamic particles.
This because the guides work on a fixed starting position (the birth of
particle) and then defines a full path for the entire particle. It is clear
this was only coded with static particles in mind...
Nevertheless, I've added a line of code to at least put the curve guide
on correct location for the moment a particle gets born.
Report moved to the todo tracker; this should be a spec for particle recode
Particles keep fighting with the depsgraph... time to get a depsgraph with
time dependencies in it...
Anyhoo, this fixes lack of parenting updates in hierarchies where children
have particles.
Particles: option "even" failed when faces where all exactly same sized,
then it sometimes skipped entire faces.
Just the regular <1.0 that had to be <=1.0
- Selection wasn't possible on center dots in Object mode. I keep adding
it and it keeps disappearing again. Added clear comments in code too.
- Particles: (debug still) print "build particles" happened on each redraw
when "Display percentage" for particles was set to zero.
Each report was about a different failure with Particles, all related to
weak handling of animation systems and the depsgraph.
Fix has 2 parts; depsgraph now signals "object recalc" to be for time
changes; this then is used to bypass particle-building (since that's baked).
Other part is better object caching while makig particles.
- Found several places, where people explicitly casted the frame number
to short.
- Fixed the crash in BPY_interface by adding an empty line (to make it
recompile everywhere, make clean doesn't help...)
For the build system maintainers:
Problem was: The change in makesdna changed the position of the
scriptlink structure. BPY_interface.c somehow didn't get recompiled
(not even after a make clean!!!) which triggered crashes on adding
scriptlinks.
The issue was that particle emittors were still transformed by the object
matrix itself. That was solved in the previous commit, but there was
still an error in correctly evaluating dependencies for the object...
Current commit uses depsgraph to recalculate all objects that influence
the emittor.
The depsgraph code doesn't like particles much (because it uses baking).
Current construct is still weak, is on the list to solve nice.
- Added part of Austin's msvc8 fixes (vector::erase function
was "misused"), hopefully compiles better now.
- Ctrl-b now also bakes a selected fluidsim domain
similar to the softbodies.
- Added surface smoothing option for domains: default is
1, higher values result in a smoother surface (and probably
slightly higher comupation times), while 0 means the surface
is not modified at all.
- Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj,
if >0 quits blender when a not yet existing fluidsim
frame should be loaded. Useful for rendering simulations
as far as possible from the command line.
- Surface normals pointer is now set to NULL in readfile.c
- Fixed win32 error string handling, now uses a function
to return the string from the solver.
- Fixed fluidsim particle halo scaling problem.
- Solver update
issues in parallel... So this commit contains: an update of
the solver (e.g. moving objects), integration of blender IPOs,
improved rendering (motion blur, smoothed normals) and a first particle
test. In more detail:
Solver update:
- Moving objects using a relatively simple model, and not yet fully optimized - ok
for box falling into water, water in a moving glass might cause trouble. Simulation
times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
might also cause slowdowns.
- Additional obstacle settings: noslip (as before), free slip (move along wall freely)
and part slip (mix of both).
- Obstacle settings also added for domain boundaries now, the six walls of the domain are
obstacles after all as well
- Got rid of templates, should make compiling for e.g. macs more convenient,
for linux there's not much difference. Finally got rid of parser (and some other code
parts), the simulation now uses the internal API to transfer data.
- Some unnecessary file were removed, the GUI now needs 3 settings buttons...
This should still be changed (maybe by adding a new panel for domain objects).
IPOs:
- Animated params: viscosity, time and gravity for domains. In contrast
to normal time IPO for Blender objects, the fluidsim one scales the time
step size - so a constant 1 has no effect, values towards 0 slow it down,
larger ones speed the simulation up (-> longer time steps, more compuations).
The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
- For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
objects can be switched on (Active IPO>0) and off (<0) during the simulation.
- Movement, rotation and scaling of those 3 types is exported from the normal
Blender channels (Loc,dLoc,etc.).
Particles:
- This is still experimental, so it might be deactivated for a
release... It should at some point be used to model smaller splashes,
depending on the the realworld size and the particle generation
settings particles are generated during simulation (stored in _particles_X.gz
files).
- These are loaded by enabling the particle field for an arbitrary object,
which should be given a halo material. For each frame, similar to the mesh
loading, the particle system them loads the simulated particle positions.
- For rendering, I "abused" the part->rt field - I couldnt find any use
for it in the code and it seems to work fine. The fluidsim particles
store their size there.
Rendering:
- The fluidims particles use scaled sizes and alpha values to give a more varied
appearance. In convertblender.c fluidsim particle systems use the p->rt field
to scale up the size and down the alpha of "smaller particles". Setting the
influence fields in the fluidims settings to 0 gives equally sized particles
with same alpha everywhere. Higher values cause larger differences.
- Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
computed by the solver are used. This is basically done by switching off the
normal recalculation in convertblender.c (the function calc_fluidsimnormals
handles other mesh inits instead of calc_vertexnormals).
This could also be used to e.g. modify mesh normals in a modifier...
- Another change is that fluidsim meshes load the velocities computed
during the simulation for image based motion blur. This is inited in
load_fluidsimspeedvectors for the vector pass (they're loaded during the
normal load in DerivedMesh readBobjgz). Generation and loading can be switched
off in the settings. Vector pass currently loads the fluidism meshes 3 times,
so this should still be optimized.
Examples:
- smoothed normals versus normals from subdividing once:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.pnghttp://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
- fluidsim particles, size/alpha influence 0:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
size influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
size & alpha influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
- the standard drop with motion blur and particles:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
(here's how it looks without
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
- another inflow animation (moving, switched on/off) with a moving obstacle
(and strong mblur :)
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
Things still to fix:
- rotating & scaling domains causes wrong speed vectors
- get rid of SDL code for threading, use pthreads as well?
- update wiki documentation
- cool effects for rendering would be photon maps for caustics,
and motion blur for particles :)
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
particle generator can be duplicated.
Note that the particles are only generated once, on the original, and just
get duplicated.
For static particles it worked already OK.
Added note for previous grouping commit; group-duplicators should support
fully all animation systems, including modifiers and particles.
Previous experiment (in 2000) didn't satisfy, it had even some primitive
NLA option in groups... so, cleaned up the old code (removed most) and
integrated it back in a more useful way.
Usage:
- CTRL+G gives menu to add group, add to existing group, or remove from
groups.
- In Object buttons, a new (should become first) Panel was added, showing
not only Object "ID button" and Parent, but also the Groups the Object
Belongs to. These buttons also allow rename, assigning or removing.
- To indicate Objects are grouped, they're drawn in a (not theme yet, so
temporal?) green wire color.
- Use ALT+SHIFT mouse-select to (de)select an entire group
But, the real power of groups is in the following features:
-> Particle Force field and Guide control
In the "Particle Motion" Panel, you can indicate a Group name, this then
limits force fields or guides to members of that Group. (Note that layers
still work on top of that... not sure about that).
-> Light Groups
In the Material "Shaders" Panel, you can indicate a Group name to limit
lighting for the Material to lamps in this group. The Lights in a Group do
need to be 'visible' for the Scene to be rendered (as usual).
-> Group Duplicator
In the Object "Anim" Panel, you can set any Object (use Empty!) to
duplicate an entire Group. It will make copies of all Objects in that Group.
Also works for animated Objects, but it will copy the current positions or
deforms. Control over 'local timing' (so we can do Massive anims!) will be
added later.
(Note; this commit won't render Group duplicators yet, a fix in bf-blender
will enable that, next commit will sync)
-> Library Appending
In the SHIFT-F1 or SHIFT+F4 browsers, you can also find the Groups listed.
By appending or linking the Group itself, and use the Group Duplicator, you
now can animate and position linked Objects. The nice thing is that the
local saved file itself will only store the Group name that was linked, so
on a next file read, the Group Objects will be re-read as stored (changed)
in the Library file.
(Note; current implementation also "gives a base" to linked Group Objects,
to show them as Objects in the current Scene. Need that now for testing
purposes, but probably will be removed later).
-> Outliner
Outliner now shows Groups as optio too, nice to organize your data a bit too!
In General, Groups have a very good potential... for example, it could
become default for MetaBall Objects too (jiri, I can help you later on how
this works). All current 'layer relationships' in Blender should be dropped
in time, I guess...
Once an Object Ipo position was inserted, the object couldn't be moved when
a particle system was tied to it. Needed code to copy object settings,
before the particle animation was done.
- bug: posemode, bones were drawing names and axes even when hidden
- bug: using softbody guides actually worked on themselves, causing
an infinite loop
- feature: when a pose/bone is completely locked for transform, a grab
will change into rotate by default.
I've been going over the zbuf.c code, which is indeed very ancient,
with a load of old optimizing and redundant code in use.
Added more 'modern' Span support, which fills per face two arrays
with the scanline information in it. That way you can zbuffer a quad in one
run as well. It was also exactly that code that's copied all over in zbuf.c
For now, to prevent issues for the release, the 'render a quad in 1 run' is
only in use for the strand render. Tests reveil a speedup of about 33%.
Will work on this recode later... which would also result in making zbuf.c
threadsafe.
And: bugfix #3398
When using the new 'render emitter' for particles, the orco array for
particles was accidentally used by mesh too.
