| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
Currently only summed number of traversal steps and intersections used by the
camera ray intersection pass is implemented, but in the future we will support
more debug passes which would help checking what things makes the scene slow.
Example of such extra passes could be number of bounces, time spent on the
shader tree evaluation and so.
Implementation from the Cycles side is pretty much straightforward, could only
mention here that it's a build-time option disabled by default.
From the blender side it's implemented as a PASS_DEBUG with several subtypes
possible. This way we don't need to create an extra DNA pass type for each of
the debug passes, saving us a bits.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D813
|
|
|
|
This is better to be backported to the 2.72.
|
|
|
|
Rotated coordinate of the ray start was used when calculating
the ray direction, ending up with wrong direction.
|
|
was rendered too.
Pretty straightforward, issue probably goes back to (pre)history!
|
|
|
|
|
|
|
|
A DAG_id_tag_update here is enough to fix the problem.
|
|
incorrect.
|
|
invisible layers
|
|
Node was simply ignored by occ shading (noted as TODO), though it's a mere matter
of a very few lines of code, nowadays... Just copied from similar task in bake code.
|
|
|
|
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D561
|
|
We had complete/cancel, but no matching init for rendering,
render_pre/post callbacks aren't always usable.
|
|
|
|
|
