Age | Commit message (Collapse) | Author |
|
|
|
The issue was caused by mismatch in how aligned triangles storage was
filled in during BVH construction and how it was used during rendering.
Basically, i was leaving uninitialized storage for triangles when
there was deformation motion blur detected for the mesh. Was likely
some sort of optimization, but in fact it's still possible that regular
triangles would be needed for rendering.
So now we're storing aligned storage for all triangle primitives and
only skipping motion triangles (the deformation motion blur flag from
mesh is now ignored).
|
|
Reporting mesh name is not really useful, since it's name does not
any relation with the original object/mesh names.
|
|
This was a regression caused by attempts to fix T42844 and there were
some red-herrings which lead me to the wrong way to fix it. It's some
deeper issue than just interpolation offset, it's mainly how the node
resolution is being mapped to each other.
It could be actually a part of canvas awareness project..
|
|
|
|
Was using draw-type when drawing BGE collision bounds.
|
|
|
|
Would clamp value ranges in UI when outside hard coded range.
|
|
|
|
Removed all references of deprecated texture shader. Also deleted
several lines of dead code.
Since texture_shader.py no longer does what it was supposed to do,
the file itself was removed.
Patch reviewed by Tamito Kajiyama (kjym3).
|
|
lines in Cycles.
This is a regression introduced by rBd8b00a3bf5c1 (Freestyle: memory
consumption optimization in stroke rendering).
The issue was caused by uninitialized MPoly::mat_nr values. Before the
stroke rendering optimization, individual Freestyle strokes were
represented by distinct mesh objects, and thus MPoly::mat_nr was left
unset (i.e., was always zero). Now that the stroke rendering optimization
has been done and mesh objects may represent multiple strokes of different
materials, MPoly::mat_nr had to be properly set to the material index that
refers to the material of the poly face.
|
|
Relying on user-count of 1 wasn't reliable because of custom-bones.
|
|
|
|
Fix by @randon
|
|
|
|
Make consistent with calc_edge_angle,
take an optional fallback arg for non-manifold edges
otherwise raise an exception.
|
|
related
Only to create and destroy joystick devices for connected joysticks
Reviewers: campbellbarton, sybren, moguri
Reviewed By: sybren
Maniphest Tasks: T43883, T43876
Differential Revision: https://developer.blender.org/D1161
|
|
wrappers.
|
|
|
|
it :| ).
|
|
part...).
Now we have an helper that will generate local/global paths and ensure they are valid.
Note: We currently have no way to 'generate' a valid extension in these cases, so just
using raw (file-safe) ID name.
|
|
|
|
screen.
Apparently the screen on the given file did not have a scene attached.
Not sure how this is possible exactly, but for now just guard against it
at load time by assigning default scene in that case.
|
|
|
|
Assumed the entire scene used the one motherball.
|
|
Basically just made constraints free function aware of possible do_id_users
argument, same as we've got for objects, object data and so on.
|
|
It was only happening on 32bit platforms because of alignment
differences when allocating class.
Now got rid of copy of eigen matricies stored by value in the
residual block which solves aligment issues and should also
give some unmeasurable speedup.
|
|
|
|
This was mis-named, rename to `calc_edge_angle`
and allow a fallback value in the case when the vert doesn't have 2-edges.
|
|
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D1003
|
|
Calling ensure_lookup_table for each face is stupid! :/
(Noted by Sergey - thx)
|
|
Another script that was missing the lookup_table call.
|
|
This reverts commit 04b0a9f4b885e8e3b0b3207f3b3cda74b936df3e.
|
|
|
|
|
|
|
|
|
|
This patch make it possible to export and import shadeless material.
Reviewers: sergey, sauraedron
Subscribers: sergey
Projects: #collada
Differential Revision: https://developer.blender.org/D1094
|
|
Only happening in the debug builds, avoids issues like recent AO one from happening.
|
|
The issue was caused by AO operation reporting it's a color operation
(which means it's expected to output RGBA) but internally it's RGB
only in the render engine, which caused some memory to be uninitialized.
|
|
|
|
The issue was caused by numerical instability whrn having ray origin close to a huge
triangle, which could have aused bad ray distance check.
Watertight Woop intersection isn't really addressing such cases, it's dealing with
small triangles far away from the ray origin instead, so it's a bit tricky yo make
it working reliably.
While we're quite close to the release it's safer to do check in Pleaucker coordinates
if ray close to a huge triangle. Likely this additional check combined with some other
tweaks to the code doesn't cause measurable slowdown in the scenes tested here.
After the release we can play a bit more with this code in order to make it more
stable without Pleucker fallback.
|
|
That's how file is actually called in the upstream.
|
|
|
|
|
|
|