NOTE: this is only the first of many patches towards completing the subdivison
and displacement system in Cycles. These patches will be reviewed and committed
one by one over the coming weeks.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D1909
There are couple of reasons:
- Volume shader on hair does behave really weird anyway and it's
not something considered a bug really.
- Volume BVH traversal were only used by camera-in-volume check,
which doesn't really make sense to take hair into account since
it'll be rendered wrong anyway.
Such a removal makes both code easier to extend further (as in,
no need to worry about those traversal for hair bvh) and also
reduces stress on GPU compilers.
This prevents twisted quads from self-intersecting.
This change makes the duplicate surface match the first vertex in the face,
so the diagonal indices match in the face copy.
Previously the logic manager was used as a global variable for SCA_ILogicBrick::m_sCurrentLogicManager,
this request to always update it before run any python script and allow call function like
ConvertPythonTo[GameObject/Mesh]. The bug showed in T48071 is that as exepted the global
m_sCurrentLogicManager is not updated with the proper scene logic manager.
Instead of trying to fix it by updating the logic manager everywhere and wait next bug report to add
a similar line. The following patch propose a different way:
- Every logic brick now contain its logic manager to SCA_ILogicBrick::m_logicManager, this value is
set and get by SCA_ILogicBrick::[Set/Get]LogicManager, It's initialized from blender conversion and
scene merging.
- Function ConvertPythonTo[GameObject/mesh] now take as first argument the logic manager to find name
coresponding object or mesh. Only ConvertPythonToCamera doesn't do that because it uses the
KX_Scene::FindCamera function.
Reviewers: moguri
Differential Revision: https://developer.blender.org/D1913
When the Moon is full it was possible to have a dead-lock in task
scheduler's exit() method.
Similar problem was fixed in Blender's task scheduler 3 years ago
in bae2a2c.
Previous fix made another issue even more visible, leading to +1 particle on first vert
and none on last one. This commit should fix both original and new issues.
The patch contains an implementation of the wide lines and the line stipple that is necessary for OpenGL upgrade.
For the implementation I have chosen the geometry shader because it required minimum changes for the wrapper calls and such implementation is the best for the "basic shader" architecture.
There are few shortcomings that can be corrected in future. They all are related to the fact that the lines in one strip are not connected with each other. So the stipple pattern is not continuous on the common vertex of two lines. There is also no continuity of form (each line is an independent rectangular).
But the advantage is that even outdated glBegin, glVertex work! Though with the above restrictions.
Continuity of form and stipple can be implemented with additional attributes, and it will require more changes in calls.
At the moment, the patch replaces calls for some "gestures". It works satisfactorily for "cross" or "rectangular" and not so good for "lasso" and "circle" due to the above-mentioned shortcomings.
Don't forget to set USE_GLSL to true for testing.
Alexander Romanov (Blend4Web Team)
Reviewers: merwin, brecht
Reviewed By: merwin, brecht
Subscribers: aligorith, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1880
This patch depends on D1747, which upgrades the Recast version. It exposes the new Recast partitioning methods in the navmesh generation.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1748
The version of Recast that Blender ships with is from 2009. This patch updates the Recast version to the latest version, 1.5.0. The Detour version remains untouched.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1747
The addressed issue is a regression from Blender 2.75, after the internal
switch from double to single precision floating-point numbers in the
Freestyle code base. Face normal calculations require the higher
precision during the computations, even though the results can be stored
as single precision numbers.
Support for driver variables that don't resolve to numbers, eg:
objects, bones, curves... etc.
Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`,
however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
This fixes reported issue, but there could be more of those hidden in Freestyle code,
it did not handle user refcount at all (and the fact it by-passes BKE in some places
for efficiency does not help here).
Note that this should be relatively harmless, since freestyle uses own Main during
render, so everything is cleaned up in the end in any case... But better try to
handle IDs correctly here too. :)
The title actually covers it all, This commit exploits all the work
being done in previous changes to make it possible to build spatial
splits in threads.
Works quite nicely, but has a downside of some extra memory usage.
In practice it doesn't seem to be a huge problem and that we can
always look into later if it becomes a real showstopper.
In practice it shows some nice speedup:
- BMW27 scene takes 3 now (used to be 4)
- Agent shot takes 5 sec (used to be 80)
Such non-linear speedup is most likely coming from much less amount
of heap re-allocations. A a downside, there's a bit of extra memory
used by BVH arrays. From the tests amount of extra memory is below
0.001% so far, so it's not that bad at all.
Reviewers: brecht, juicyfruit, dingto, lukasstockner97
Differential Revision: https://developer.blender.org/D1820
Policy here is a bit more complicated, if tree becomes too deep we're
forced to create a leaf node and size of that leaf wouldn't be so well
predicted, which means it's quite tricky to use single stack array for
that.
Made it more official feature that StackAllocator will fall-back to
heap when running out of stack memory.
It's still much better than always using heap allocator.
We had per-tree statistics already, but it's a bit tricky to see overall
time because trees could be building in parallel.
In fact, we can now print statistics for any TaskPool.
Currently they're staying at 1 (actual size over capacity), but we
will be changing it quite soon in order to avoid having too much
memory re-allocation happening at a BVH build time and will be
playing with different policies for that.
Note that we may want to review that some day, we have quite a bit of ID types here that are
'blend file' view only, might be worth splitting the check based on this.
In some files stack memory was overruning the pre-allocated stack.
Perhaps we should fall-back to a hep-allocated stack so release builds
don't crash in works case but just becoming slower.
That might consider a bit more objects to be considered deform modified,
but it covers common case of using taper object without require of doing
recursive checks.
In worst case it'll be just some extra synchronization time, no render
time difference will happen for false-positive because of extra checks
happening in Cycles.
