| Age | Commit message (Collapse) | Author |
|---|
|
Could give barely measurable speedup on a complex rigs.
|
|
Became obsolete after recent changes.
|
|
bones
Avoid annoying checks form inside operations loop, gives few percent speedup in
files like army_of_blenrigs.
|
|
After some talking with Campbell, this is now accessible through BMesh's CustomData system:
- clnor data is now exposed in BMesh (same way as for UVs etc.).
- You can now get/set **raw** values (pair of factors) of each loop independently.
This is not so useful in itself (though it allows nice 'relative' normal edition, given what
those two factors represent), getting/setting 'real' normals there is for later.
- You can now set all custom normals at once using the new 'from_array' method of BMLayerItem.
This is supposed to be generic setter, but for now it's only implemented for clnor data.
Some notes/reflections, also for future developments:
- About from_array:
* Do we accept that rather 'flexible' way of handling given array of data? think we do not have much choice
if we want to keep generic BMLayerItem (else we'll have to define sub-classes of this for every type of data :/ ).
* Currently clnor's from_array returns values actually set as a new array, not sure we want to keep this, or instead
add another 'to_array' method (in this case, how do we control type of returned data?).
- About clnors in BMesh in general:
* Think ultimately we'll want to have own struct of clnors in BMesh,
caching clnor spaces, encoded normal, real normal, etc.
* We'll then need to add lots of stuff to handle edition, in particular a system to rebuild clnor spaces
of affected loops each time we add/remove/modify geometry...
Latest point is important, since it means current BMesh py API will **not** be stable for now, and will
most certainly break when full support of custom normals is added to BMesh.
|
|
|
|
It's still not completely working - there are still some glitches - but far better than before.
To make buttons of the uiList work, you have to add a 'check' callback to the operator that invokes the menu. Only if it returns True, the uiList gets refreshed. To avoid this we have to make the region refresh tagging in the entire button handling a bit smarter.
Changes I had to do:
* Call uiList handling from menu/popup handling if needed.
* Make uiList handling use special popup refresh tag if placed in menu.
* Allow popups invoked from py operator to tag for refresh by using operator 'check' callback.
* Tag popup for refresh when resizing uiList.
Mostly fixes T48612.
|
|
|
|
|
|
|
|
Caused problem w/ basic-shader
|
|
|
|
|
|
|
|
|
|
|
|
Don't store maximum length of text per undo step,
or attempt to pack all data in a single array.
Was storing 32766 characters per undo step, irrespective of actual text length.
|
|
|
|
|
|
The way cloth is coded, structural springs are only effective when stretched, while bending springs act only when shrunk. However, when cloth is exactly in its rest shape, neither have any effect, and effectively don't exist for the implicit solver.
This creates a stability problem in the initial frames of the simulation, especially considering that gravity seems to act so precisely that it doesn't disturb the strict equality of lengths, so in parts of the cloth this springless state can continue for quite a while.
Here is an example of things going haywire because of this and some suspicious logic in collision code acting together: {F314558}
Changing the condition so that structural springs are active even at exactly rest length fixes this test case. The use of >= is also supported by the original paper that the cloth implementation in blender is based on.
Reviewers: lukastoenne
Reviewed By: lukastoenne
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D2028
|
|
|
|
|
|
All text was displaying black.
BLF uses alpha-only textures which aren't supported by the basic-shader,
Workaround this by using texture swizzle so the RGB components of the texture are set to 1.
|
|
This hopefully fixes T48383 by avoiding two numerical problems that I found in the volume code.
Reviewers: sergey, dingto, brecht
Reviewed By: sergey, dingto, brecht
Maniphest Tasks: T48383
Differential Revision: https://developer.blender.org/D2051
|
|
It's not obvious that they use the mouse coordinate of the initial key-press event (behavior since rBf1f33ba7be2d), so added comment.
Also corrected other comments.
|
|
Looks like a line was forgotten in the 'BOTH' case in code...
|
|
API call too.
Seems to be working OK from quick tests...
Some notes:
- This is mimicking BKE_mesh_evaluate code. While this is OK for some cases,
we'll likely want some more integrated and fine-grained ways to set/edit those
normals in Edit mode once we create real editing tools for those (most likely based
on some BMesh operators).
This implies some kind of dynamic caching/update of clnors spaces though, which
is not trivial. So kept for later, for now you have to set all custom normals at once.
- Not sure where/how to expose this in py API, for now just added a func in bmesh.utils.
|
|
|
|
Needed to add GL_TEXTURE_RECTANGLE support to basic-shader.
|
|
way as cuda 6.0 does allow, disabling cuda kernels on buildbot for now
|
|
way as cuda 6.0 does allow, disabling cuda kernels on buildbot for now
|
|
The basic shader needs to be temporarily disabled in this case.
Add macros for temp store/restoring the state.
|
|
This allows for it to be more easily tested.
|
|
|
|
OpenCL seems to work fine here, and for some reason that comparison was
giving compilation error on OpenCL here.
Better to compile OpenCL kernel than to be fully robust to weird corner
cases.
|
|
A few places still needed to be updated to use the new Mesh::num_triangles()
method; wrong number from triangles.size() was causing crashes.
|
|
Newly computed custom normals were forgotten during poly flipping, leading
to wrong custom normals being assigned to wrong loop...
Dead simple, but was tough to track down this one!
|
|
|
|
At the moment light shading in Blender is produced in viewspace. Apparently, that's why
shader nodes work with normals in camera space. But it is not convenient for artists.
The more convenient approach is implemented in Cycles where normals are represented in world space.
Blend4Web Team designed the engine keeping in mind shader parameters readability,
so normals are interpreted in world space as well. And now our users have to use some tweaks, like
empty node group with the name "Replace", which is replacing one input by another on the engine side
(replacing working configuration in Blender Viewport by the configuration that has the same behavior in the engine).
This patch adds the ability to switch to world space for normals and lamp vector in BI and Viewport.
This patch is very important to us and we crave to see this patch in Blender 2.7 because
it will significantly simplify Blend4Web material creation workflow.
{F315547}
{F315548}
Reviewers: campbellbarton, brecht
Reviewed By: brecht
Subscribers: homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D2046
|
|
Was using O(n^2) lookup on ID's with undo.
This caused undo to hang with 1000's of data-blocks
(especially with heavy scenes & outliner-space, which doesn't even need to be visible to cause a slow-down).
Internally this uses a ghash per id-type, which is lazy-initialized.
Each key uses the name and library since there may be name collisions between libraries.
Developer Notes:
- Adds small `BKE_main_idmap_*` API.
- Needed to change linking order for this to build.
|
|
This lets us use MAX_LIBARRAY to loop over id-codes in Main.
|
|
Instead index libraries, makes minor speedup when using many libraries.
|
|
|
|
The original quad intersection test works by just testing against the two triangles that define the quad.
However, in this case it's actually faster to use the same test that's also used for portals: Determining
the distance to the plane in which the quad lies, calculating the hitpoint and checking whether it's in the
quad by projecting onto the sides.
Reviewers: brecht, sergey, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D2045
|
|
Allows to avoid generating flipped faces when using extreme normal modifications.
Related to T48576.
|
|
The Shift key can be held while adjusting profile to make finer changes
to the profile (just as it already does when adjusting offset).
|
|
|
|
|
|
Was some accumulated precision error happening.
|
|
Being granular means we need to re-build depsgraph a bit more often..
The issue was caused by rigidbody requiring some special nodes to
handle physics which were not created with just tagging object for
update.
|
|
|
