Fix for T43768
This way it works consistent with cloth, softbodys, etc.
Reviewers: lukastoenne
Differential Revision: https://developer.blender.org/D1134
Strokes containing only a single point are now drawn so that they respect the
pressure values too. Previously, they were getting drawn at a fixed size based
on the thickness of strokes. Thanks to @kekeljevic for posting a screenshot which
made the problem here easy to identify!
(On a side note: Perhaps it's a combination of the drivers I'm using, or the
multisampling goodness at work, but after applying this change, the dots are
now appearing as round circles as originally intended, and can also be scaled
up quite a bit too. And that's for 3D points which couldn't be affected like
this earlier! I'm not sure what's going on here, but whatever it is, I like it ;)
This attribute missed derivatives calculation.
Not totally sure what's the proper approach for algebraic derivative
calculation, so calculating them by definition. This isn't fastest
way to do it in this case and could be replaced with some smarter magic
in the wireframe calculation loop.
At least currently implemented approach is better than nothing.
It was complaining about explicit __constant to __private memory conversion,
which is now worked around using implicit conversion.
It's not a real fix i'm afraid and i'm still failing to build OpenCL kernel
with latest Linux drivers, but maybe it'll let someone else to investigate
what causes compiler to run out of memory?
Deleting an object was deleting all rigidbody constraints in the scene.
Bug was introduced with D701.
Reviewers: agoose77, sergof, moguri, lordloki, sybren
Reviewed By: lordloki, sybren
Subscribers: sybren, hbar, blueprintrandom, sergof, agoose77
Differential Revision: https://developer.blender.org/D1007
Issue was caused by the changes in 7b16fda which changed the initial
state for rng. This commit makes it so the same initial hash is used
(which solves the regression without distorting AA-looking image.
It also makes it so OpenCL compiler is happy about this code (before
this change it'll complain about trying to cast private variable to
global one).
We are now guarding against some divisions by small values.
There are still issues here but they are not on boundary faces
anymore so they must be related to some other issue such as
the triangle intersection test.
Previous text could make think this func was checking whether a point was
inside and on the face, while it actually checks whether the projection
of that point onto the face is inside its boundary...
There are more flags that trigger this assertion, so I want to discuss
an appropriate way to fix it before changing them all.
This reverts commit b1191e5caf1a888bfad2185ed41db2e91fbf46e2.
rna_RenderSettings_use_game_engine_get() in rna_scene.c would return 0 or 2,
whereas the assertion in rna_access.c:1843 indicates that boolean values
should only be 0 or 1.
problematic (still!)
It seems due to floating point precision issues we have to account for
even more cases.
Added colinear check for one more triangle edge-vertex and assumed that
if no collision test is found then triangle is completely inside box.
Such cases are mostly from float precision not catching triangle just
outside bucket. Now tests are much better for simple tests (paint/flood
fill cube from ortho view, paint sphere), however there are still some
rare cases of stray pixels.
Ideally we should get rid of those temporary vectors anyway, but
it's not so trivial because of the alignment. For untl then we'll
just have a bit worse solution. This part of code is not the root
of the issue of memory spikes for now anyway.
But since we're getting rid of temporary memory earlier actual spike
is a bit smaller as now. For example in franck_sheep file it's now
5489.69MB vs. previously 5599.90MB.
Simple change: just get rid of intermediate data a bit earlier, before
final pixels array is being allocated. This gives around 30% of memory
save during light update (this is about 60meg in the frank sheep file
i'm using here).
This isn't really visible by artists a lot, because actual spike happens
on BVH construction. But it doesn't mean we shouldn't be accurate with
memory usage in other areas.
