Age | Commit message (Collapse) | Author |
|
|
|
|
|
Own stupid off-by-one regression in rB019ce363b01bba0afe1 and later...
|
|
The purpose of the patch is to replace deprecated glShadeModel.
To decrease glShadeModel calls I've set GL_SMOOTH by default
Reviewers: merwin, brecht
Reviewed By: brecht
Subscribers: blueprintrandom, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1958
|
|
|
|
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.
|
|
|
|
Caused problem w/ basic-shader
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Makes behavior of proxy_from backlink working similar to the old dependency graph.
it's nasty, but needed here in the studio to get proxies fixes ASAP.
|
|
|
|
FCurve evaluation depended on FCurve.curval, which isn't threadsafe.
Now only use this value for debug display,
and pass the value instead of storing in the FCurve for all but debug-display.
|
|
Enabling auto-run, then excluding a path but leaving it set to a blank value would ignore all paths.
|
|
|
|
Using double pixel size prevented 1px brushes
D2044 by @jeske
|
|
That was a nice and funny hunt, albeit rather time consumming!
To summarize, so far code was using a static global gpu_buffer for pbvh vbo drawing
of 'grid' types (multires mostly?).
There were two issues here:
1) Global gpu buffer was assigned to GPU_PBVH_Buffers->index_buf, but then nearly no
check was done when freeing that buffer, to ensure we were not freeing the global one
(not totally sure this one was actually causing any issue, but was bad and unsafe anyway).
Was solved by adding a flag to GPU_PBVH_Buffers to indicate when we are using some
'common' buffer here, which freeing is handled separately.
2) Main issue: if several multires objects in sculpt mode with different grid size
were present simultaneously, the global gpu buffer had to be resized for each object draw
(i.e., freed and re-allocated), but then the pbvh nodes from other objects storing freed reference
to that global buffer had no way to know that it had been freed, which was causing the segfault & crash.
Was solved by getting rid of that global buffer, and instead allocating one 'grid_commmon_gpu_buffer' per pbvh.
Told ya baby, globals are *PURE EVIL*!
|
|
This seems to be illegal and not productive anyway. Do it ahead of
a time now, which solves shading issues in edit mode and prevents
assert from happening.
|
|
saved in Edit mode.
In that case, surface modifier won't run (until surface object goes back to Object mode),
and its bvhtree remains NULL.
|
|
|
|
init_render_nodetree
|
|
|
|
A bit tricky, need to pass additional information about what the attribute
is and how to deal with it.
BI path stays unchanged, just to make things simplier for now.
Fixes T48555: Cycles GLSL- Incorrect Vertex Color results from Attribute node
|
|
Error in 0b5a0d84
|
|
Gives little to no speedup (a few percents at best).
|
|
Not replacing with some BLI_task_stuff here, tests show this is pointless
(in absolute best case - i.e. single huge mesh in scene - parallelizing here switches
from 0.8ms to 0.5ms for that piece of code - with something like 750ms per frame update...).
|
|
Gives over 50% faster scope update (from 4.5ms to 2.2ms here with SD shot)!
Probably mostly due to more clever usage of thread-local data (which avoids any lock,
when OMP code had a rather stupid critical section for minmax)...
|
|
|
|
viewport
|
|
This changes the bezier handles b-bones to fit to a circle more closely.
|
|
The title says it all actually.
Added special custom data type, because we don't know in advance
whether we're referencing UV or Color layer. Also made it so vertex
attributes are normalized.
TODO: Border render in viewport ignores the normalization of the
attribute array for some reason, will be looked into still.
Reviewers: mont29, brecht, campbellbarton
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D2022
|
|
|
|
Nothing was shown in UI during pre-bake step, while it can take several minutes
to complete with heavy geometry.
|
|
other optimizations.
This commit makes Dynamicpaint modifier evaluation (during playback) a few percents quicker.
However, it makes dynapaint's 'image sequence' baking about 33% quicker (from 119 to 77 seconds
in own heavy test), partly due to switch to BLI_task itself (about 20%), and partly due to
optimizations (remaining ~13%).
As usual, did a lot of tests here to ensure nothing is broken, but a lot more users' testing would definitively
be welcome too! ;)
Note that some quite meaningless omp forloops have been removed (parallelizing thousands of vec copy does
make it two or three times quicker, but the few hundreds of microseconds gained do not make any difference
in a hundreds millisecond process).
Also, this code could still use a lot more cleanup (naming etc.), the way it (tries to) handle malloc faults
is also totally flacky and makes the code horribly verbose and convoluted in some places - without actually
catching all possible faults (memarena could make it more easy to handle here), etc.
|
|
|
|
|
|
(mostly).
Gives 3-4% speedup in pre-bake step (from 112 to 108 seconds with own heavy test file).
Note that here we have a huge potential performance boost if we replace the flat
`Bounds2D *faceBB` array of UV tris bounding boxes by a real 2D AABB tree (right now,
we can loop over all UV triangles times the number of pixels of the surface times 5...).
|
|
bone deleted
In addition to the original bug report, I've gone through cleaning up a range of
related bugs which only became clear when hunting around the code...
* Custom Handle References weren't getting cleared when the bones they used got
deleted. But, neither was the custom bone shape location/transform reference.
* Various places where posebone settings are copied around were also missing code
to handle the new Bendy Bone properties.
(WHY DO WE HAVE SO MANY VARIATIONS OF COPYING POSE DATA!?!?)
* If duplicating a Bendy Bone with custom references, and the custom references
are also selected/duplicated, the new Bendy Bones will use the corresponding
duplicated bones
|
|
This commit adds Peak Memory to the stamp options, the value is the same one that is already shown in the image viewer.
Requested by @nutel.
Reviewers: campbellbarton
Subscribers: campbellbarton, nutel
Differential Revision: https://developer.blender.org/D1989
|
|
|
|
Was not so far, because this effect is not modifying its 'own' PaintPoint, which means
it's not threadsafe. Since a global lock (mutex or spinlock) would not be much efficient
(we need to lock a given point pretty much all the computaion cycle), and since locking
a same PaintPOint from different threads at the same time is *very* unlikely,
solution here is to use an 'array of locks', one for each PaintPoint (same thing as BLI_bitmap,
using atomic ops to set/clear bits).
Here in own test (complex dynapaint over a huge sphere combining all dynapaint types), it gives
20% speedup of the whole dynapaint simulation!
Note: maybe we'd want to move that kind of bitlock into BLI lib some day - not totally sure how,
so let's keep it local for now...
|
|
Vertex's normal is always normalized - and its conversion from short to float should not change that!
On the other hand, linear interpolation of three normals **does not give a normalized vector**
(unless all three inputs are exactly the same).
Also, minor optimization, avoid recomputing that interpolated normal twice for each PaintUVPoint.
|