CCFLAGS are used for both C and C++ compilers and one is better not to pass
C-related flags to C++ compiler. C-compiler flags are to be passed via CFLAGS
variable.
In this case we can calculate an offset without worrying about
perspective correction. Unfortunately if looking from a camera we still
have depth issues here. There's no really general case that can fix this
so I'm leaving this as is.
The reported crash case seems to be caused by freeing compiled Python
objects in a thread. Now this issue is avoided by allocating a buffer to
store a Python script and using BPY_string_exec() to run the script. This
makes it unnecessary to repeatedly create and destroy Text data blocks.
Many thanks to Campbell Barton for his help on the bug fix.
Issue is zfighting with wire of mesh when parts of the mesh are close
together. We can make this slightly better by reducing the offset,
however this offset is calculated pre-perspective division and can vary
greatly with distance. Correct approach would be using polygon offset,
however we draw mesh wireframes as lines, (not polygons with polygon
mode line) so this approach will not work.
Alternatively, we could set an offset in a shader, however we don't have
code for that either.
would fail on coplanar faces (or smooth verts).
Loop remapping is really a tricky topic... For now, we enhance a bit more
our Frankenfunc by using distance between dest and source polygons as
fallback in case we have too much similar normals...
Probably not a perfect solution, but should be robust enough I hope.
One core question remains open though: do we want to stick to 'use only seams
to detect UV islands'? This makes things much simpler, but will obviously fail
in case of actual islands without matching seams. :/
Was changed to draw after meshes without depth mask to make grid not
contribute to compositing effects. Now only draw it like this when we do
compositing (unfortunately can't have both).
Caused by own commit that changed island detection code. In the case of
modifiers we don't want to take winding information into account, but
left the code since there are use cases (like painting) which could use
this.
This patch adds support for light portals: objects that help sampling the
environment light, therefore improving convergence. Using them tor other
lights in a unidirectional pathtracer is virtually useless.
The sampling is done with the area-preserving code already used for area lamps.
MIS is used both for combination of different portals and for combining portal-
and envmap-sampling.
The direction of portals is considered, they aren't used if the sampling point
is behind them.
Reviewers: sergey, dingto, #cycles
Reviewed By: dingto, #cycles
Subscribers: Lapineige, nutel, jtheninja, dsisco11, januz, vitorbalbio, candreacchio, TARDISMaker, lichtwerk, ace_dragon, marcog, mib2berlin, Tunge, lopataasdf, lordodin, sergey, dingto
Differential Revision: https://developer.blender.org/D1133
This more a workaround for CUDA optimizer which can't optimize clamp(x, 0, 1)
into a single instruction and uses 4 instructions instead.
Original patch by @lockal with own modification:
Don't make changes outside of the kernel. They don't make any difference
anyway and term saturate() has a bit different meaning outside of kernel.
This gives around 2% of speedup in Barcelona file, but in more complex shader
setups with lots of math nodes with clamping speedup could be much nicer.
Subscribers: dingto
Projects: #cycles
Differential Revision: https://developer.blender.org/D1224
I finally put the time into understanding what was going on here.
Basically RE_AcquireResultImage() produces RenderResults without
RenderViews. That will be fine for now since I'm planning to refactor
RenderResult soon.
This is a kind of sloppy-focus,
resolving long standing bug with loop-cut/knife/ruler /w quad-view.
Where activating a tool would lock onto one of quad-views,
especially problematic when activating from the toolbar or menus.
