There were several issues involved into triangle ribbons hair:
- Even for the viewport rendering the blender scene camera was
used for orientation. This made hair triangles oriented to
the scene camera, not to the viewport camera.
- Triangle orientation was actually supposing the camera is
perspective. Triangles weren't oriented properly for the
orthographic camera resulting in different hair width across
it's length.
This issues are solved now, but there are some related TODOs:
- Rotating viewport doesn't re-orient the triangles, so after
viewport navigation hair might not look correct. However,
with this fix toggling viewport render (to force hair sync)
makes viewport render correct.
This isn't so much trivial fix, would require making BVH
aware of the dynamic triangle orientation, so they get
properly oriented without full hair re-sync.
- Panorama camera behavior didn't change but looks like it
should, however not really sure atm what's the right thing
to do here.
The issue was caused by the changed defaults from the Cycles side.
Because of those properties being saved as an IDProp and not being
saved to the file, every change to the defaults would ruin someone's
day updating the values.
Added a bpy.app.handler.version_update which is run after the regular
do_versions() are done and could be sued by the scripts to apply
versioning code on their settings.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D761
Issue was caused by the precision issues which made sdivm by 1 under
it's actual value. We can try to do some eps magic, but from the tests
on laptop and desktop doing integer division is not slower than using
floats here.
Thanks for Aldo Zang for the help with the fix for the panorama/fisheye
depth of field calculation and the overall math.
Reviewed By: sergey, dingto
Subscribers: juicyfruit, gregzaal, #cycles, dingto, matray
Differential Revision: https://developer.blender.org/D753
Now we build 2 .cubins per architecture (e.g. kernel_sm_21.cubin, kernel_experimental_sm_21.cubin).
The experimental kernel can be used by switching to the Experimental Feature Set: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Experimental_Features
This enables Subsurface Scattering and Correlated Multi Jitter Sampling on GPU, while keeping the stability and performance of the regular kernel.
Differential Revision: https://developer.blender.org/D762
Patch by Sergey and myself.
Developer / Builder Note:
CUDA Toolkit 6.5 is highly recommended for this, also note that building the experimental kernel requires a lot of system memory (~7-8GB).
It can be helpful in some cases and it works properly, so no need to hide it behind the experimental flag anymore. It's only enabled for the CPU though.
Limitations:
* Smoke/Fire rendering is *not* supported on GPU yet, that is also documented here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume
* Decoupled Ray Marching is also not supported yet, so no Equi-Angular and MIS sampling yet.
Note for Builders and Developers:
* Make sure to use the CUDA Toolkit 6.5 from now on. 6.0 might still work, but can cause slower renders.
This was originally caused by a6ae12a where i didn't foresee unclear distinguishing
between empty and non-synced meshes will give issues for the viewport. They're the
same for final rendering, but for viewport we need to be accurate here.
That was only needed in the beginning, when we did not had support for tangents. It's time to clean some of the defines up, it's getting a bit too much.
* __VOLUME__ is basic volume support with Emission and Absorption.
* __VOLUME_SCATTER__ enables volume Scattering support.
* __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
This problem was introduced in 983cbafd18
Basically the issue is that we were not getting a unique index in the
baking routine for the RNG (random number generator).
Reviewers: sergey
Differential Revision: https://developer.blender.org/D749
Operators' poll func might be called from anywhere in Blender, so they should
not make any assumption about available context. material, lamp and world
are specific to context from Properties space...
It now uses the tile size to split the job. For CPU this may add
overhead, but for GPU this is highly needed.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D690
* Don't compute expf() for every step, instead sum the intermediate values and calculate it every N (8 for now) steps. This helps a few percent (~5% on a cube with wave texture) in my tests here.
Root of the issue goes back to the on-fly normals commit and the
latest fix for it wasn't actually correct. I've mixed two fixes
in there.
So the idea here goes back to storing negative scaled object flag
and flip runtime-calculated normal if this flag is set, which is
pretty much the same as the original fix for the issue from me.
The issue with motion blur wasn't caused by the rumtime normals
patch and it had issues before, because it already did runtime
normals calculation. Now made it so motion triangles takes the
negative scale flag into account.
This actually makes code more clean imo and avoids rather confusing
flipping code in mesh.cpp.
This is rather workaround solution for now, which seems to
work and it's not that huge to maintain (one liner apart from
the comment).
Idea is to make sure PeekMessage peeks the message when window
proc receives WM_MOUSEWHEEL (some touchpad drivers seems to
swallow the messages making it so PeekMessage doesn't get
anything).
