Issue was caused by mismatched logic in counting child/parent particles in
job initialization and actual job execution. Confusion here came from mixed
usage of psys->renderdata and G.is_rendering.
We need to get rid of G.is_rendering and use eval_ctx if it's really needed,
but we also might just use psys->renderdata check since it's expected psys
to have this structure anyway.
Speedup is non-linear, 2x-10x faster is quite normal.
Patch T43678.
- Switched from an Octree to BVH.
- Finding first points of surface no longer "wastes" density function evaluation: every result is cached.
- Use MemArena instead of using own memory management.
- Correct calculation of metaelem bounding box.
- Remove mball_count(): mballs are now counted "on the go".
* Revert 776bfa64a5 and c3dad7953a (some X11 systems are doing
stupid things forcing me to do an extra check that completely breaks the
click type handling on other systems using the slightly changed
implementation from those commits - see T44278)
* Fix sample lines in Compositor+VSE
(And yes, this time I tested on both of my systems to make sure
everything is fine)
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
It is still possible to free a bit more memory by detecting buildin images
which are not used by shaders, but that's not going to improve memory usage
that much to bother about this now.
Such change brings peak memory usage from 4.1GB to 3.4GB when rendering
01_01_01_D layout scene from the Gooseberry project. Mainly because of
freeing memory used by rather huge environment map in the viewport.
Reviewers: campbellbarton, juicyfruit
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1215
Seems like a fix that is needed for some X11 systems causes this bug on
others :| Not sure if the systems that needed this fix are now still
fine (since I did a slight change to the click type check procedure),
but I need to check that on my system in the institute in a bit.
Just add KM_CLICK to the already sent KM_RELEASE, don't send a new one
for this.
This might help us to get rid of quite some glitches and workarounds \o/
(why didn't this come earlier to my mind? :S)
extruding
More practical description of the bug: extruding with ctrl to use
snapping and confirming the action added another extrusion to the mouse
position.
This was caused from the second event that is now sent if a key release
happens within the click timeout. It triggers the "Extrude to Cursor"
operator since it is called by CTRL+LMB wich is exactly the event that
is sent in this case.
I'm not totally happy with this workaround since it changes the Confirm/
Abort event for all transformation actions to key release which *might*
result in more conflicts (fingers crossed this isn't the case). If this
happens we might need to write some special transformation handling for
extrusion.
This is an example of the difficulties we get from loading too much
functions on the same keys - we need to be careful with that!
For KM_ANY I've filtered out every event that has a click type, although
that was only needed for the additional event sent on KM_HOLD. A bit weird
that this only happened on a few machines though.
After looking into this more carefully, I've found that we do in fact need a dedicate
operator to add some custom logic when trying to unlink an action from the editor/datablocks.
Specifically, this new operator does the following:
1) When in Tweak Mode, it shouldn't be possible to unlink the active action,
or else, everything turns to custard.
2) If the Action doesn't have any other users, the user should at least get
a warning that it is going to get lost.
3) We need a convenient way to exit Tweak Mode from the Action Editor
4) If none of the above apply, we can just unlink normally
This commit implements this for the Action Editor, with stubs for the NLA Editor too.
Those will be fixed next.
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
Only basic fix, the whole 'dir' field handling needs rework to correctly support
lib stuff (will be done as part of asset-experiment rewriting work)...
All this code is doing way too much filesystem inspection by itself, instead of
reusing flielist.c work - this is stupid, and will completely break with future
asset engines!
