| Age | Commit message (Collapse) | Author |
|---|
|
Trying to access rl's from full samples in non-full-OSA context (with uninitialized
sample index even :P ).
Caused by rBd5f1b9c2, probably a copy/paste typo or so.
|
|
|
|
|
|
|
|
And some general style cleanup as well (line length...).
|
|
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
|
|
|
|
Patch D1207 by @chrisr
|
|
Halo is not possible when using 'deep' buffer shadow - reflect that in UI.
When not using buffered shadows, switch lamp bufftype to 'regular' on render, as already
done with 'halfway' method.
|
|
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...
|
|
name in string.
Since we are already using BKE_reportf... This way, no more issue if/when we copy/paste
or rename that!
|
|
|
|
|
|
Still not ideal but getting closer. Main annoying thing so far is
dependency of Render structure for now. It is used to switch particles
to render mode and could probably also be eliminated.
|
|
|
|
|
|
|
|
|
|
|
|
range and extra frames.
Issue here is that the movie backend would unconditionally use the start
frame of the scene instead of the preview frame. Solved by passing an
explicit "preview" argument.
Strictly speaking, the preview argument is part of the renderdata
struct, that is also passed to the code, but when rendering the final
result we want to unconditionally render the full range regardless of
the preview setting of the render structure.
However, OpenGL rendering does use the preview range so we need to
account for that when making those exports.
This is also a nice chance to correct the filenames, which still used
the full range.
|
|
|
|
Normals are not vertices, we cannot apply matrix's scale to them...
|
|
accident
|
|
|
|
|
|
Is was possible that interface will be refreshed at thesame time
as render engine will start freeing render parts.
Not sure if we can get away without RW mutex here, seems we need
one way of synchronization or another..
|
|
|
|
Was wrong color management flag used for some bakers.
Actually goes back to 7997e38.
|
|
calculations and use the OCIO one instead.
|
|
This is totally broken, just making sure Blender does not crash and devs
can investigate other issues that are actually fixable.
|
|
The issue was caused by particles using billboard distribution, which
requires either object to be specified or camera in the scene to be
existing.
This commit prevents backing from crash, but bake result might not be
totally expected because of the thing mentioned above.
|
|
|
|
Potential crash reading freestyle modifiers from future blend-files
|
|
|
|
|
|
also minor warning cleanup
|
|
|
|
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
|
|
|
|
The issue was caused by the conflict between preview render which would set
R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of
the render pipeline trying to use this flag.
Now the sampler functions accepts extra argument so render pipeline can
still skip image load, but calls outside of the pipeline will nicely load
all the images.
Not cleanest change in the world but good enough to unlock gooseberry team,
and assuming we already had pool passed all over the place it should be all
fine.
Will need to reshuffle arguments into SamplerOptions structure later.
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
use bools for return values and some api naming consistency.
|
|
|
|
into account.
|
|
Conflicts:
source/blender/blenkernel/intern/particle.c
|
|
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
|
|
code.
The implicit solver itself should remain agnostic to the specifics of
the Blender data (cloth vs. hair). This way we could avoid the bloated
data conversion chain from particles/hair to derived mesh to cloth
modifier to implicit solver data and back. Every step in this chain adds
overhead as well as rounding errors and a possibility for bugs, not to
speak of making the code horribly complicated.
The new subfolder is named "physics" since it should be the start of a
somewhat "unified" physics systems combining all the various solvers in
the same place and managing things like synchronized time steps.
|
|
structure as a texture.
This is mostly a debugging feature that may be removed again later.
|
|
contains a '/'
Added a new BLI_path_utils func, `BLI_filename_make_safe()`, which for now simply
replaces unsafe chars for paths (like '\' or '/') by an underscore...
|
|
|
