| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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...
|
|
|
|
This fixes obvious overflows when checking bitflags, who knows how much
undiscovered issues exists in the code still..
|
|
This is an old option which wasn't working in over a year without complaint.
|
|
|
|
|
|
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...
|
|
This directory does not exist even.
|
|
This function sets an error message which would be displayed after
rendering is over and info space lost the link to the engine.
|
|
This is useful for addons which intend to write data next to the rendered image/movie,
but not for preview renders.
|
|
|
|
|
|
Use BKE_appdir/tempdir naming prefix for functions extracted from BLI_path_util
|
|
This module is intended for path manipulation functions
but had utility functions added to access various directories.
|
|
|
|
|
|
|
|
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
|
|
Only allow non instanced renderobjects to be baked.
|
|
Move powX functions from particle code into math library and use them.
|
|
Use FSAA settings only if current render engine is BI or GE/
That's for until we'll support FSAA in Cycles or other render engines.
|
|
|
|
The root of the issue comes to the way how we sample the gaussian filter in
RE_filter_value(). We need to scale x to -3*sigma..3*sigma segment in order
to get the whole bell.
The old code tried to do it, but failed dramatically, plus it used some weird
gaussian sampling formula. Replaced it with much more clear one, which gives
proper blur now.
There's no visible different in AA sampling in BI render tho.
Other filters like Mitchell still tends to give wrong square shaped blurs,
but they're much more difficult to resolve because they're just wrong in
the code -- for some reason smaller kernel size means more blur. Let's solve
this later.
|
|
|
|
type is set to "wire"
Added an exception in convertblender.c's is_object_hidden(), so that an object with active
smoke modifier is never considered hidden.
|
|
|
|
Noise function's significant bits are up to 31st bit. This should now
give the same visual result as before, minus the stripes.
Issue pointed out by Anthony Edlin, thanks!
|
|
|
|
* Use pie direction, not draw type for pie item collision
* Strict function definitions.
* Initialize random array with system time
|
|
|
|
Two fixes here (only the second one is strictly needed to fix the issue,
but both make the system better).
First is introduction of a random generator array for use with threaded
systems where each thread needs to access its own number generator.
The random texture now uses this so it should not be influenced by other
random generator reseedings of the main random generator like it did
before.
Second, I reshuffled the texture code to resample the upper bits of the
random number first. According to Numerical Recipes, this is where the
most variance can be found, so by sampling those we avoid correlation
issues. Also, multiplying here is not ideal because if a pair of bits
are zero, then the whole result will also be zero.
Overall this is much more random (tm) than before, however result will
also be brighter, since we now have less black spots. Tweaking the
brightness/contrast should somewhat fix that, generally having the same
result as before is not possible anyway if we are to really fix this.
Also, seems like exposing procedural depth might be nice here since it
influences the precision of the texture lookup.
|
|
or not
If render engine has bl_use_texture_preview set to truth blender wouldn't fallback to
the blender internal rendering for previews.
|
|
|
