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 b1191e5caf.
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.
OpenCL doesn't let you to get address of vector components, which
is kinda annoying. On the other hand, maybe now compiler will have
more chances to optimize something out.
New Lock Z velocity parameter was added. This parameter avoid the micro-jumping.
By default it is actived except when you load an old file that it is deactived to keep former behaviour.
Additionally it was solved another issue related with the acceleration: That is the acceleration value was not taked into account and we had always the maximum linear velocity from the beginning of movement. Now the acceleration is taken into account until we reach the maximum velocity.
When you load an old file, the acceleration value is set to the maximum range (1000.f). This way we simulate a maximum velocity constant from the beginning of movement (former behaviour).
{F142195}
Reviewers: moguri, dfelinto, campbellbarton
Reviewed By: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D1074
We don't like when NULL is send to MEM_freeN(), but there was some
differences between lockfree and guarded allocators:
- Lockfree would have silently crash, in both release and debug modes
- Guarded allocator would have printed error message, abort in debug
but keep working in release build.
This commit makes lockfree allocator behavior to match guarded one.
Title pretty says it all actually. Can only briefly mention that we're
indeed entering that state when after applying some WIP patches having
much fuller statistics about memory usage would help giving exact memory
benefit.
Null check to verify that parent has a character controller. Otherwise (i.e empty) it will crash.
Reviewers: moguri, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1115
Move physicsid type to unsigned long long to avoid crashes on Windows 8.1 64bits.
Other systems also modified to put them inline with this solution.
Reviewers: dfelinto, brita_, moguri, juicyfruit, campbellbarton
Reviewed By: juicyfruit, campbellbarton
Subscribers: juicyfruit
Differential Revision: https://developer.blender.org/D1122
bounds indices of vertices.
Issue here is that if we copy edge customdata the MEdge data that were
previously written get overwritten, solution is to write indices and
flags last (probably writing flags is superfluous here).
This flag is global for all the sessions and never changes. so it doesn't
really make sense to pass it around to all sessions and synchronization
routines.
Switched to a static member of BlenderSession now, but it's probably more
logical to introduce some sort of BlenderGlobals. Doesn't currently worth
a hassle for a single boolean flag tho.
