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.
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..
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.
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.
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.
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...
Safe for 2.73...
This revert rB9b0ab890676790bb1e8e77797629b889ea66f69e - needed to set that threshold to a small
negative value to remove the last artefacts reported in T39735, but now I could not reproduce
any with the previous 0.0f value, so restoring it for the time being.
If this 'shadowed neighbor face' case re-appears, we can always choose a value in-between, like -1e-18f...
Murmur2a is a very fast hashing function generation int32 hashes.
It also features a very good distribution of generated hashes.
However, it is not endianness-agnostic, meaning it will usually generate
different hashes for a same key on big- and little-endian architectures.
Consequently, **it shall not be used to generate persistent hashes**
(never store them in .blend file e.g.).
This implementation supports incremental hashing, and is a direct
adaptation of reference implementation (in c++):
https://smhasher.googlecode.com/svn-history/r130/trunk/MurmurHash2.cpp
That cpp code was also used to generate reference values in gtests file.
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D892
