Was hooked up last year for testing purposes, as we already had some code for it, but the closure itself is not really good nor really useful, so let's remove it.
This way there's much less cross-references between objects and meshes
device update functions.
The only thing remained s the object bounds calculation which is needed
by bvh update. This could also be decoupled, but it's not that crucial
yet because its's how it used to be for ages now.
This adds an AABB collision check for objects with volumes and if there's a
collision detected then the object will have SD_OBJECT_INTERSECTS_VOLUME flag.
This solves a speed regression introduced by the fix for T39823 by skipping
volume stack update in cases no volumes intersects the current SSS object.
This means it's no longer needed to enable experimental feature set in order to
have proper camera in volume support. And this also means if there's something
wrong going on, or if there's speed regression for cases when camera is obviously
not in the volume -- this issues are to be reported and handled in the regular
matter.
Happy blending!
The idea is to only count intersections with objects which has volumetric shader
and ignore all other objects.
This is probably as fast as we can go without involving some forth level magic.
Now we do much better preliminary check for panoramic camera is inside the
volume object boundings.
Also we're now cacheing the has_volume in the mesh, which makes it unneeded
iterations for each object's shaders.
Should be no functional changes, just faster sync and panoramic-in-volume
rendering.
Using matcap with a displist is not really good thing to try
and it's actually a regression since we've enabled matcaps
for all objects instead of just an active one.
The issue was caused by the fact that we never used to store the
generated image color in DNA, so image reload will loose this
information.
Now we store the color in DNA, making ti so re-loading the image
will preserve it's generated color.
It is now also possible to change generated image color using the
color swatch in image properties after the image was created.
The view map is mostly treated as a read-only data structure by line stylization
operations (i.e., selection, chaining, splitting, sorting and stroke creation). The
only exception is the chaining operation in some cases where insertion of extra
FEdge objects is necessary to ensure the continuity of underlying FEdges from
which a chain is constructed.
The present revision addresses the removal of extra FEdges so to keep the view
map clean and suitable for reuse in subsequent render frames.
New render layer option named "View map cache" is added to reuse a
previously computed view map for subsequent rendering. The cache is
automatically updated when the mesh geometry of the input 3D scene has
been changed.
This functionality offers a major performance boost for Freestyle
animation rendering when camera-space mesh geometry is static, as well
as for repeated still renders with updates of line stylization options.
Although the "View map cache" toggle is a render layer option, the cache
memory is shared by all render layers and scenes. This means that if
Freestyle is used for two or more render layers (possibly in different
scenes through the compositor), then the cached view map for one render
layer is replaced by a new view map for another render layer and hence
no performance gain is expected.
We on'don't really support 10.5 anymore for my knowledge and in any case
the defined symbol was never checked in the sources, so this workaround
was basically doing nothing for quite some time now.
This makes headers a bit less clean (with the anonymous structs
mainly and headers inclusion from another header.
Makes compilation with clang a bit less noisy.
