| Age | Commit message (Collapse) | Author |
|---|
|
also minor warning cleanup
|
|
Visual representation of fire was generated before simulation step took place. This caused fire to essentially lag one simulation step behind, even though all emission areas were up to date.
|
|
|
|
|
|
Runtime costs were horrible. On gooseberry in some sequencer edits using
proxies of small size, a cache with about 2000 elements would slow to
about 6 fps once cache was full and system tried to find smallest
element available.
There are still improvements to be done here, like requesting a number
of good candidates to avoid rerunnung through the list, or even using
some heap or ring buffer scheme to sort data, but nothing suits all
needs so for now that should bring the cache back to usable state (25fps
here at the studio)
|
|
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 way how we shoot the ray to see which rays we're
inside which might start bouncing back-n-forth between two close to parallel
intersecting faces.
Real solution would be to record all the intersections when shooting the ray,
but it's kinda tricky on GPU because of needed sorting and uncertainty of
how huge intersection array should be.
For now we'll just limit number of steps in the check so in worst case we'll
have some samples not being correct which will be compensated with further
sampling. Shouldn't be an issue since probability of such a lock is quite
small actually.
|
|
Issue was in fact only visible in certain circumstances:
- OSL was compiled with Boost Wave
- or system's cpp didn't handle space between -I and path
Now made it so both wave and cpp code paths are always happy.
Original patch from Shane Ambler with own modifications to
mimic what variable holds on more verbose.
|
|
This gives small speedup (around 2% in quick tests) for ray scattering.
|
|
|
|
This is a bit of a mess because of the header dependency hell, but
since the tweak is small enough it's gonna be fine.
|
|
|
|
IN theory object might depend on camera location (spatial adaptive subdivisions
for example) which became not possible to achieve after camera in volume support.
Should be no functional changes for artists.
|
|
This warning provided too much false-positive issues in release version of the
kernel, making it really easy to miss actual warnings.
|
|
Was rather harmless since compiler will optimize it out, but nice to get
rid of this anyway.
|
|
Slowdown was caused by watertight intersection commit and follow-up workaorund
for compiler crash which uninlined utility function which rotates the ray.
Now it's only uninlined for sm_50 and sm_52 experimental kernels which are the
only ones which failed to compile.
Rendering still might be a bit slower but at least shouldn't be that dramatic.
|
|
Basically build-time compiled kernels were using --fast-math (which is correct)
but run-time compiled did not.
|
|
|
|
Basically title says it all. Could be not totally optimized but the code is there now.
|
|
This is for development and test environment setup only, not for
regular users usage hence no mentioning in the man page needed.
|
|
The issue was caused bu the optimization in surface attributes for cases when
there's only a volume shader used. Some attributes doesn't make sense in that
case and were skipped from calculation.
However, it is possible that kernel would still try to access them (because of
the shader setup etc). Prevented an infinite loop in the kernel now, which
should not have much affect on regular renders.
|
|
It is possible that ray distance will be zero which would make intersection
refinement return NaN as the refined position which would later lead to all
sort of mathematical issues.
Don't think there are ways to improve intersection accuracy for such rays
so just return original intersection coordinate.
This should fix T43475.
TODO: Need to look into possible issues in Ashikhmin BSDF which might return
zero-length reflected/transmitted ray?
|
|
This way we save 3 bytes per BVH node while building BVH, which overall
gives 100Mb memory save when preparing Frank for render.
It's not really much comparing to overall memory usage (which is 11Gb
during scene preparation here) but still doesn't harm to have solved.
|
|
Precision of the fast functions seems to be enough in there and
since the code was heavily using inverse trigonometric functions
this change gives few percent speedup on Victor's hair.
From the tests files from ctests storage doesn't have any meaningful
difference, hair on Victor is all below 4% absolute error and only
few pixels are exceeding 1% absolute difference.
In any case, let it be as it is currently so it allows us to have
fast math file in sources for it's further evaluation and possible
usage in other areas as well.
|
|
It is based on fmath.h from OIIO and could be used to give some speedup
in areas where absolute accuracy is not so critical.
|
|
BSDF sampler function shouldn't give labels it's not intended to do.
That said reflection shouldn't give transmission ray and transmission
give reflection ray.
Added an assert in the transmission sampling but reflection still
needs some investigation because even after recent fixes the check
for projection onto the reflected ray could give both positive and
negative values.
It shouldn't have any affect on renders just makes internal logic
consistent and unleashes an issue to be investigate further.
|
|
Hair BSDF did not have proper behavior because of non-normalized
tangent direction (which it expected to be normalized).This lead
to wrong labels being returned by the hair BSDF samplers.
|
|
This was intended to be in the original patch of texco copy from object.
|
|
also remove empty class parenthesis
|
|
(Jorge Bernal)
|
|
* create() and destroy() are deprecated since OSL 1.5, use regular constructors / destructors.
|
|
Reported and nailed down by Michale (MeshLogic).
The code that fixes this was commented out, but Brecht gave the go ahead to use it even if it is not the real solution
|
|
The issue was caused by the whole viewplane used for mapping calculation
which would for sure lead to differences between final camera render and
viewport render from the camera view.
This commit makes it so window texture mapping is the same as final render
when viewing from the camera in viewport render.
It's not totally clear what's the right thing to do when viewport is not
in the camera view mode and that part is left unchanged.
|
|
Looks like with some versions of Xlib (at least the 1.6.2 currently used on Debian testing)
and/or evdev generic driver (2.9.0 currently on Debian testing), you have to also 'select'
DeviceButton1Motion with the extended tablet's motion event, otherwise you won't get any
tablet motion event once pen is pressed, leading to no pressure (each stroke keeping its
init pressure until the end). Crap!
|
|
This is the same as blender internal's texture mapping from another object,
so this way it's possible to control texture space of one object by another.
Quite straightforward change apart from the workaround for the stupidness of
the dependency graph. Now shader has flag telling that it depends on object
transform. This is the simplest way to know which shaders needs to be tagged
for update when object changes. This might give some false-positive tags now
but reducing them should not be priority for Cycles and rather be a priority
to bring new dependency graph.
Also GLSL preview does not support using other object for mapping.
This is actually correct for BI shading as well and to be addressed as
a part of general GLSL viewport improvements since it's not really clear
how to support this in GLSL.
Reviewers: brecht, juicyfruit
Subscribers: eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1021
|
|
This commit makes it so blackbody and beckmann lookup tables are stored on CPU
after being generated and then only being copied to the device if needed.
This solves lag of viewport update when tweaking shader tree by using 266KB of
CPU memory.
|
|
Not sure why this was not visible previously, but the change is
logical anyway.
|
|
When doing BVH leaf node split we can't rely on leaf size limit from
BVH parameters in case there's spatial split enabled.
This commit basically reverts previous optimization change here which
used stack-allocated memory and uses heap-allocated vector now.
It's possible to boost this code up again by using own allocator.
|
|
Handy for troubleshooting.
|
|
Root of the issue goes to the fact that since the very beginning Cycles was
using ZYX euler rotation for mapping shader node but blender was always
using XYZ euler rotation.
This commit switches Cycles to use XYZ euler order and adds versioning code
to preserve backward compatibility.
There was no really nice solution here because either we're ending up with
versioning code or we'll need to deal with all sort of exceptions from blender
side in order to support ZYX order for the mapping node. The latest one is
also creepy from the other render engines points of view -- that might break
compatibility with existing bindings or introduce some extra headache for them
in the future.
This could also become a PITA for us with need of supporting all sort of weird
and wonderful exceptions in the refactored viewport project.
NOTE: This commit breaks forward compatibility, meaning opening new files in
older blender might not give proper result if Mapping node was used.
Also, libraries are to be re-saved separately from the scene file, otherwise
versioning code for them wouldn't run if scene file was re-saved with new
version of blender.
Reviewers: brecht, juicyfruit, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D973
|
|
Differential Revision: https://developer.blender.org/D1018
|
|
|
|
This way Cycles finally becomes feature-full on image projections
compared to Blender Internal and Gooseberry Project Team could
finally finish the movie.
|
|
|
|
* If a Background node is set to a black color or zero strength,
it now gets removed from the shader graph.
* In case the graph is empty (no background node), the kernel will skip
evaluating it and save some rendertime. This can help quite a bit in scenes,
where the majority of the image consists of a black background.
Example: http://www.pasteall.org/pic/show.php?id=82650
In this case the render is ~16% faster.
Differential Revision: https://developer.blender.org/D972
|
|
Please note that opennl is already modified (for double precision)
so re-integration is not really easy. Also, we'll eventually switch
to Eigen.
For until that let's just solve the condition in our bundled opennl.
|
|
|
|
Issue seems to be caused by not totally proper pdf and eval values for this
closure. Changed it so they reflect to ggx/beckmann reflection with roughness
set to 0, which is effectively the same as the sharp reflection.
|
|
Issue was, when requesting (building) lnors for a mesh that has
autosmooth disabled, one would expect to simply get vnors as lnors.
Until now, it wasn't the case, which was bad e.g. for normal projections
of loops in recent remap code (projecting along split loop normals
when you would expect projection along vertex normals...).
Also, removed the 'angle' parameter from RNA's `mesh.calc_normals_split`.
This should *always* use mesh settings (both autosmooth and smoothresh),
otherwise once again we'd get inconsistencies in some cases.
Will update fbx and obj addons too.
|
|
The check should also become aware of the fact were using clipping plane
instead of clipping sphere now.
|
