Also refactor:
- Material property UI related to shadows
- Preparation of OR-ed mode flags (ma->mode_l) of render materials
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D313
This actually had nothing specific to new split normals, it was an internal limitation
of BI raytracer, which would check against neighbor face shadowing only when they shared
a common vertex, now it also performs checks when both faces have a vertex with a common
"ancestor" (org index).
Note this allows to also fix same issue when using SplitEdges modifier (and potentially
others?), but only when AutoSmooth is enabled (due to some compute/mem overhead, we
do not want to enable this code systematically).
Thanks to Brecht for advices and review!
We really should not have Object.imat_ren, that's the wrong place to put render
data. But just update it now on rotation rather than doing a bigger refactor to
remove it.
Note that this commit completely replaces old behavior of the auto_smooth feature in BI.
Also note that split normals are only handled when no "advanced geometry post-processing" is used
(something like Displace will obviously break it, since it has to re-compute normals after displacement...).
Reviewers: brecht
Reviewed By: brecht
CC: campbellbarton
Differential Revision: https://developer.blender.org/D368
We need to salt temp exr filenames with pid, else several instances of Blender rendering
the same scene on same machine and using "Save Buffers" option would use the same files!
There is not much sense to have a whole BLI file just to check SSE2 on CPUs...
So idea is to rename it to more generic "BLI_system", and add to it more system-related
utils, like e.g. an include helper for getpid(), which allows to hide unix/windows
internals from rest of the code...
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D439
The issue was caused by assumption object matricies can be modified
by DupliObject->obmat outside of the duplilist iteration cycle.
This isn't really true. The thing is, old code used to modify object
matrix based on the duplicated matrix to make it so modifier evaluation
kind of works (it'll use proper matrix in most cases, but think there
might be some cases when this assumption also breaks).
Even when matrix is copied from dupliobject to object in advance
(to mimic old behavior or dupli system) you're still to use matrix
from dupliobject inside a cycle body. This is because the same object
might be modified multiple times by different dupliobject. For example,
in case of duplifaces loads of faces will modify object's matrix and
before this change matrix from the last face would have been used.
The fix is simple one-liner which makes it so render instance will
use proper matrix from dupliobject.
All the rest bits here (pre-loading matrices and restoring them in
the reverse order) totally matches old behavior of duplilist.
This is a regression and to be ported to 2.70 tag!
The previous fix 162d6c73e3 has been cancelled because it caused a
problem that mesh deform cages and so on mess up the preview. To avoid
the problem, viewport doesn't show mesh object if its draw type is
bounding box or wireframe.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D375
in threaded depgraph updates and effector list construction.
Gathering effectors during depgraph updates will call the
psys_check_enabled function. This in turn contained a DNA alloc call
for the psys->frand RNG arrays, which is really bad because data must be
immutable during these effector constructions.
To avoid such allocs the frand array is now global for all particle
systems. To avoid correlation of pseudo-random numbers the psys->seed
value is complemented with random offset and multiplier for the actual
float array. This is not ideal, but work sufficiently well (given that
random numbers were already really limited and show repetition quite
easily for particle counts > PSYS_FRAND_COUNT).
to wrong obmats of nested dupli objects.
Restoring obmats after BI nested dupli object rendering has to happen
in reverse order, so higher level omats are applied last.
Commit 162d6c73e3 changed the behavior of rendered viewport to use
viewport visibility, but that can cause some problems. For example,
mesh deform cage is drawn as a solid/textured mesh (not a wireframe
mesh) and its unnecessary surfaces and shadows mess up the preview.
renders were broken.
This was caused by rB1a79abdad2443ff9f12e7efd95ee78a264a9d60a which
makes a copy of the render layer list for thread safety. The single
layer passed to this function is still in the original list though, so
to get the correct index it has to be looked up there. Otherwise no
active index is set and all layers are rendered every time.
It would include/exclude shadow depending on the pass being disabled/enabled,
but that should have no influence on the combined render result. Now it always
includes shadow.
The render operator invoke checks render layers, which can force the
render layer to be activated. This requires a notifier, which has to be
done in the operator itself (can't do this inside pipeline code).
in Blender Internal renderer.
The BI renderer applies modifiers //after// changing the obmat of the
respective object (for the first instance it encounters). Before
rB6940bf0 the original obmat (omat) was stored inside dupli object data,
which was removed in favor of local omat variables due to hackishness
and redundancy. Problem with BI is that all the obmats have to be
overridden in relation to each other to produce the correct modifier
results (here: offset object for the array modifier).
The patch restores the old (messy) behavior for BI by first overriding
**all** the obmats at once from duplis, then creating render instances,
then cleaning up.
A better solution would be to avoid these modifier hacks in BI
altogether and properly evaluate them in the original object space, but
that requires far greater changes to the old code base, and is out of
scope for bugfixing.
The "Cast Shadows" worked as expected, but it can cause problem in some cases.
For example, when using strand render, we need disabling only buffer shadows,
but the previous changes made that impossible. "Cast Shadows" should be added
as a newly created option.
This allows us to make materials that don't cast ray shadows.
Turning off this property can reduce the rendering time slightly.
Note: RNA path is changed to "use_cast_shadows" as well. The older
path "use_cast_buffer_shadows" still can be used as its alias, but
it will be removed after updating some addons.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D272
