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.
doc;
http://www.blender3d.org/cms/Hair_Strand_Rendering.722.0.html
- added width control for strands
- made tangent (anisotropic) render an option
(so you can render strands more solid, like metal/wood)
Also:
- ALT+A anim playback with static particles made cursor flashing
"Additive" Guides. See also:
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
This Guide type uses the falloff distance to also define how much the
particle (or hair strand) goes over the path, allowing to create local
extremes, or only local particle generating or hairgrowth. Nice for
spiky haircuts!
Note that the current default generates particles based on the original
amount of vertices and faces, this for vertex group support (which is not
subdivided with modifiers). That means that particles generated on
subsurfed faces still have minor approximation errors.
Note for DerivedMesh users; I've added a new API call:
float *mesh_get_mapped_verts_nors(Object *ob);
Which returns an array of 2 * 3 * float size, containing the vertices and
normals, deformed and subsurfered, but only the original me->mvert amount.
Works in all non-editmode cases.
Is in use now for vertex/weight paint and particles.
- "Disp" option allows to go back to zero, effectively disabling the entire
particle generating.
- When parenting guides to an emitter the depgraph sees a cyclic relation,
which caused not updating the particles correct on loading it.
- Moved creating guide Cache completely outside of the particle loop,
should make it faster to use with large amounts of particles and objects.
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
There's no doubt this patch had a lot of good ideas for features, and I
want to compliment Janne again for getting it all to work even!
A more careful review of the features and code did show however quite some
flaws and bugs... partially because the current particle code was very much
polluted already, but also because of the implementation lacked quality.
However, the patch was too good to reject, so I've fixed and recoded the
parts that needed it most. :)
Here's a list of of most evident changes in the patch;
- Guides support recoded. It was implemented as a true 'force field',
checking all Curve path points for each particle to find the closest. Was
just far too slow, and didn't support looping or bends well.
The new implementation is fast (real time) and treats the paths as actual
trajectory for the particle.
- Guides didn't integrate in the physics/speed system either, was added as
exception. Now it's integrated and can be combined with other velocities
or forces
- Use of Fields was slow code in general, made it use a Cache instead.
- The "even" distribution didn't work for Jittered sample patterns.
- The "even" or "vertexgroup" code in the main loops were badly constructed,
giving too much cpu for a simple task. Instead of going over all faces
many times, it now only does it once.
Same part of the code used a lot of temporal unneeded mallocs.
- Use of DerivedMesh or Mesh was confused, didn't work for Subsurfs in all
cases
- Support for vertex groups was slow, evaluating vertexgroups too often
- When a vertexgroup failed to read, it was wrongly handled (set to zero).
VertexGroup support now is with a name.
- Split up the too huge build_particle() call in some parts (moving new code)
- The "texture re-timing" option failed for moving Objects. The old code used
the convention that particles were added with increasing time steps.
Solved by creating a object Matrix Cache.
Also: the texture coordinates had to be corrected to become "OrCo".
- The "Disp" option only was used to draw less particles. Changed it to
actually calculate fewer particles for 3D viewing, but render all still.
So now it can be used to keep editing realtime.
Removed;
The "speed threshold" and "Tight" features were not copied over. This
resembled too much to feature overkill. Needs re-evaluation.
Also the "Deform" option was not added, I prefer to first check if the
current particle system really works for the Modifier system.
And:
- Added integration for particle force fields in the dependency graph
- Added TAB completion for vertexgroup names!
- Made the 'wait cursor' only appear when particles take more than 0.5 sec
- The particle jitter table order now is randomized too, giving much
nicer emitting of particles in large faces.
- Vortex field didn't correctly use speed/forces, so it didn't work for
collisions.
- Triangle distribution was wrong
- Removed ancient bug that applied in a *very* weird way speed and forces.
(location changes got the half force, speed the full...???)
So much... might have forgotten some notes! :)
He noted that static particles don't work with force fields yet, and
added a fix for it. This however didn't work for the depgraph yet, and
didn't correct the static particle's local space to world coordinates for
the fields. Nevertheless, while reviewing this small patch I thought it
would be fun to add now.
So: static particles now update realtime on forcefield relations. Warning
for potential slowdowns! Also note that work on the real particle patch
still has to be done... something I really will do, but in time. To get
particles correctly integrated in the animation system, quite some new
development has to be done still.
to finetune deform further as well.
Note that curve deform requires object buttons 'track' and 'up' axes set
properly. Curve deform can twist/flip a lot, making Vertex Group based
deform hard to set up.
to get rid of faces with MFace.v3==0
- change all Mesh's to have ->medge now. This is forced by make_edges
on readfile, and in the various exotic important routines, and on
conversion back in python.
- make python NMesh structure always have medges now (needs testing)
- with above two changes it is guarenteed that mf->v3 is never ==0
in main blender code (i.e., all MFace's are actually triangles
or quads) and so I went through and removed all the historic tests
to deal with MFace.v3==0. Equals lots of deleting, I am in heaven!
- removed MEdge edcode flag, no longer needed
- added experimental replacement for edge flag system
Still are some inconsistencies in FACESELECT mode edge drawing to
be ironed out.
NOTE: This commit adds an experimental edge flag calc system, based
on 10-seconds-of-thought algorithm by yours truly. Would appreciate
feedback on how this system works, esp compared to old one and esp
on complex or interesting models.
To Use: New system is enabled by setting G.rt to a value between
1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for
"auto" edge, which is more or less identical to old system but also
makes sure that at least 10% of edges are drawn (solves errors for
super subdivided meshes). Values between 1 and 999 act as percent
(out of 1000) of edges that should be drawn, starting with "most
interesting" edges first. Please try it and comment!
make softbodies collide with objects patented to armatures (bones), lattices .. )
Softbody deflectors always use the new modifier stack. (thanks ZR)
Softbody deflector code checks for identity of colliding objects so,
there is no need to prohibit softbodies to be a deflector.
So now you can put some soft balls in a box and see them bounce.
see : http://wund.privat.t-online.de/bt/sb_sb_coll.blend
A deflector cube parented to SB lattice:
http://wund.privat.t-online.de/bt/sb_lattice.blend
BM
- Option is in EditButtons, Armature panel.
- Currently only local X-axis mirror (seems to be default anyway)
- Transform then applies changes to the mirrored-name bone as well.
- Extrude: also does the counterpart Bone
- New: SHIFT+E extrude: extrudes 2 mirrored Bones out of a normal Bone.
(creating names by appening _L and _R)
Or in short: you can now model a full rig without any manual naming!
Of course the names are not too nice... a couple of ideas to explore;
- rename a mirrored bone renames counterpart too
- allow in weightpaint mode to select Bones
- and of course mirrored edit in PoseMode (if that's useful...)
Important note: I tweaked the naming convention a bit; names like
Bone_L.005 and Bone_R.005 are considered counterparts. However, if
you use the "Flip names" option, the number extension is still
truncated.
BTW: Commits in Zr's code are fixes for gcc warnings. :)
with "loose" edges (edges without a face) and drawing in
solid mode. they would either not draw, or draw with a nasty
selection outline. Added a ME_LOOSEEDGE flag to mark such
edges in displists/mesh and editmode sets it.
- changed DerivedMesh drawEdges to take an argument whether
it should draw loose edges or not
I removed config.h code from the files that had them.
effect.c had nested /* so cleaned that up...
added a newline to vector.c to shut gcc up ;)
buttons_editing.c had a possible unintalized var (height) so I gave
it a default value.
removed an unused var i in interface_draw.c
removed an unused var mti in outliner.c
in BL_SkinDeformer.cpp
commented out a call to bDeformGroup->data which no longer exists so it
compiles again.
Kent
