| Age | Commit message (Collapse) | Author |
|---|
|
A nice bug combining all the broken features of blender:
Particles, duplis and multiple scene dependencies.
Fortunately this was solvable: Basically, we need to
make sure derivedmesh for dupli instance is generated before
obmat is overriden. This also makes sense, since no instance
has "true" obmat apart from original. Lazy initialization of
derivedmesh just does not work here (or it -does- work but first
use should be before instance drawing).
Fingers crossed nothing else breaks after this...
|
|
|
|
correctly.
Problem was that object layers are defined by duplis as the top-level
duplicator layers. This happens //during// the duplilist construction,
which breaks group layer checks for subsequent instances and hides them.
Now the duplilist generators leave Object DNA untouched, the
modification of layers for drawing, rendering, etc. happens afterward
in the duplilist_apply/restore functions, as a kind of second pass.
|
|
textured viewport shading
Usual dupli object issue, sometimes it's needed that all the object in
dupli group have modified obmat.
Made it an utility function now, which is used by convertblender and
dupli draw code now.
|
|
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
|
|
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
|
|
functions.
|
|
Generated and UV coordinates from the duplicator of instance instead of the
object itself.
This was used in e.g. Big Buck Bunny for texturing instanced feathers with
a UV map on the bird. Many files changed, mainly to do some refactoring to
get rid of G.rendering global in duplilist code.
|
|
group/dupligroups (unlikely/intentional)
calling BKE_ptcache_ids_from_object() could recursively call BKE_object_handle_update(), when there is no reason to update object transforms at all. Add option not to do any updates and just return an object list.
|
|
|
|
normalise->normalize).
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
comments is silly, may as well have in declaration)
|
|
* Made it impossible to try to calculate/create new motion paths lasting 0
frames (i.e. 250 to 250) since we cannot allocate a zero-length array for these.
Start frame can now be at most end-frame - 1, and end frame at least start frame
+ 1
* If an invalid configuration does occur, warnings/reports will now be issued in
response to this instead of silently failing (as per this bugreport).
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
|
|
|
|
- removed DNA_brush_types.h from DNA_scene_types.h (and some other similar cases)
- removed DNA_wave_types.h (never used)
- removed Main.wave
|
|
|
|
|
|
This commit makes the new-style Motion Paths work for Objects and Bones. Motion Paths can either be added for Objects (Object buttons) or for Selected Bones in PoseMode (Armature Buttons), and/or removed from these panels too.
Changes:
* Changed the way the baking code worked, since it was better to be able to bake a bunch of objects at once, instead of doing it per object
* Fixed a variety of bugs regarding initialising defaults and reading old files
* Added operators for Objects (like for bones), and replaced the existing code for bones.
* Fixed bug with baking code that was causing it to bake the wrong ranges
Todos:
* Frame number drawing is currently messed up, since the "cached" text drawing takes into account the object transforms.
* The new MotionPath panels currently appear as the first panels in the respective contexts, probably due to the order in which the files are included. This needs some fixing, though not sure what the best way is yet.
|
|
* Finished baking code for motion paths, generalising it so that it works for both Objects and Bones.
It is based on the old code for baking bones, although I have modified the updating code to use a more 'correct' method of updating dependencies. However, this may turn out to be too slow, and another API method should be added for that...
* Moved some of the old version-patching code for animviz settings out of the drawing functions, instead doing this on the version patching proper.
* Added RNA support for the new AnimViz types, and included RNA access via their users too. The old settings have still been left in for now, since there are still some things not ready to use yet.
----
* F-Curve's with sample points (i.e. sounds to F-Curves) now perform linear interpolation between sample points instead of using constant interpolation.
|
|
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
|
|
* copied I/O scripts
* copied, modified rna_*_api.c and rna_*.c
I/O scripts not working yet due to slight BPY differences and RNA changes. Will fix them later.
Not merged changes:
* C unit testing integration, because it is clumsy
* scons cross-compiling, can be merged easily later
|
|
store radius and quaternion
Added optional quat and radius args to anim.c's where_on_path(...), currently unused.
also cleanup some warnings.
|
|
Object.create_dupli_list now works ok.
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
non-animated dupligroups.
|
|
|
|
- Allow Random and Even distribution settings to be set after hair
is made editable, since they also affect children.
|
|
====================
- "From Dupli" option for orco and uv texture coordinates. For dupliverts,
duplifaces and dupli particles, this uses the orco and uv at the point
on the parent surface. Can for example be used for texturing feathers
and leafs. Note that uv only works for duplifaces and particles emitted
from faces, these are not defined at vertices.
- "Width Fade" option for strand render, to fade out along the width of the
strand. Committing this so it can be tested, might be changed or removed
even, if it doesn't give nice results.
|
|
- Possible fix for a dupli render memory leak, but i'm not sure.
|
|
- Groups with hidden parts didn't render OK
- Layer buttons sent out wrong events
|
|
After a couple of experiments with variable blur filters, I tried
a more interesting, and who knows... original approach. :)
First watch results here:
http://www.blender.org/bf/rt0001_0030.avi
http://www.blender.org/bf/hand0001_0060.avi
These are the steps in producing such results:
- In preprocess, the speed vectors to previous and next frame are
calculated. Speed vectors are screen-aligned and in pixel size.
- while rendering, these vectors get calculated per sample, and
accumulated in the vector buffer checking for "minimum speed".
(on start the vector buffer is initialized on max speed).
- After render:
- The entire image, all pixels, then is converted to quad polygons.
- Also the z value of the pixels is assigned to the polygons
- The vertices for the quads use averaged speed vectors (of the 4
corner faces), using a 'minimum but non-zero' speed rule.
This minimal speed trick works very well to prevent 'tearing' apart
when multiple faces move in different directions in a pixel, or to
be able to separate moving pixels clearly from non-moving ones
- So, now we have a sort of 'mask' of quad polygons. The previous steps
guaranteed that this mask doesn't have antialias color info, and has
speed vectors that ensure individual parts to move nicely without
tearing effects. The Z allows multiple layers of moving masks.
- Then, in temporal buffer, faces get tagged if they move or not
- These tags then go to an anti-alias routine, which assigns alpha
values to edge faces, based on the method we used in past to antialias
bitmaps (still in our code, check the antialias.c in imbuf!)
- finally, the tag buffer is used to tag which z values of the original
image have to be included (to allow blur go behind stuff).
- OK, now we're ready for accumulating! In a loop, all faces then get
drawn (with zbuffer) with increasing influence of their speed vectors.
The resulting image then is accumulated on top of the original with a
decreasing weighting value.
It sounds all quite complex... but the speed is still encouraging. Above
images have 64 mblur steps, which takes about 1-3 seconds per frame.
Usage notes:
- Make sure the render-layer has passes 'Vector' and 'Z' on.
- add in Compositor the VectorBlur node, and connect the image, Z and
speed to the inputs.
- The node allows to set amount of steps (10 steps = 10 forward, 10 back).
and to set a maximum speed in pixels... to prevent extreme moving things
to blur too wide.
|
|
duplicates, enabling lighting and layer-render properly.
|
|
-> Any Group Duplicate now can get local timing and local NLA override. This
enables to control the entire animation system of the Group.
Two methods for this have been implemented.
1) The quick way: just give the duplicator a "Startframe" offset.
2) Advanced: in the NLA Editor you can add ActionStrips to the duplicator
to override NLA/action of any Grouped Object.
For "Group NLA" to work, an ActionStrip needs to know which Object in a
group it controls. On adding a strip, the code checks if an Action was
already used by an Object in the Group, and assigns it automatic to that
Object.
You can also set this in the Nkey "Properties" panel for the strip.
Change in NLA: the SHIFT+A "Add strip" command now always adds strips to
the active Object. (It used to check where mouse was). This allows to add
NLA strips to Objects that didn't have actions/nla yet.
Important note: In Blender, duplicates are fully procedural and generated
on the fly for each redraw. This means that redraw speed equals to stepping
through frames, when using animated Duplicated Groups.
-> Recoded entire duplicator system
The old method was antique and clumsy, using globals and full temporal
copies of Object. The new system is nicer in control, faster, and since it
doesn't use temporal object copies anymore, it works better with Derived
Mesh and DisplayList and rendering.
By centralizing the code for duplicating, more options can be easier added.
Features to note:
- Duplicates now draw selected/unselected based on its Duplicator setting.
- Same goes for the drawtype (wire, solid, selection outline, etc)
- Duplicated Groups can be normally selected too
Bonus goodie: SHIFT+A (Toolbox) now has entry "Add group" too, with a
listing of all groups, allowing to add Group instances immediate.
-> Library System
- SHIFT+F4 data browse now shows the entire path for linked data
- Outliner draws Library Icons to denote linked data
- Outliner operation added: "Make Local" for library data.
- Outliner now also draws Groups in regular view, allowing to unlink too.
-> Fixes
- depsgraph missed signal update for bone-parented Objects
- on reading file, the entire database was tagged to "recalc" fully,
causing unnecessary slowdown on reading.
Might have missed stuff... :)
|
|
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...
|
|
Playback of sequencer sound crashed in combination with dupliverted
Objects. (confirmed in osx only btw).
Found out there's old not-needed code in the update_for_newframe() call,
that was intended to do updates for Manipulators (calling countall()).
In countall(), the entire duplilists were generated over, just for
counting the totals.
First step was removing the countall from update_for_newframe, and added
a count_duplilist() call which doesn't generate the full duplilist. That
made Blender not crashing anymore, but gives "Error totblock", without
printing the block names even...
The weird thing also was that the crash showed severe memory corruption in
the malloc library, when combining audio scrubbing (SDL) and duplilists.
I now suspect there's a remaining issue with DerivedMesh, but for that I
need help from Daniel.
|
|
little minor spacing issues.
|
|
|
