Based on usages so far:
- Split callback worker func in two, 'basic' and 'extended' versions. The former goes back
to the simplest verion, while the later keeps the 'userdata_chunk', and gets the thread_id too.
- Add use_threading to simple BLI_task_parallel_range(), turns out we need this pretty much systematically,
and allows to get rid of most usages of BLI_task_parallel_range_ex().
- Now BLI_task_parallel_range() expects 'basic' version of callback, while BLI_task_parallel_range_ex()
expectes 'extended' version of the callback.
All in all, this should make common usage of BLI_task_parallel_range simpler (less verbose), and add
access to advanced callback to thread id, which is mandatory in some (future) cases.
Would be true in most cases (and in particular with own generated geometry),
but in case one would be using original geometry this could have crashed badly.
Note that I tried to parallelize the loops porting result of the simulation to the
DM data itself, but that ended up being 20% slower than non-threaded code!
Compared to previous revision, this gives 20% speedup on the whole modifier evaluation!
Wondering a bit how improvement can be so impressive here, would have expected very
small increases given how simple is the code here... Maybe it's the fact we get rid
of many additional OMP threads (tests are done with ten Ocean mod evaluated in parallel)?
Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
Caused by my recent normal calculation changes, added dependsOnNormals callback which was missing for ocean modifier (it assumed input normals were set).
many modifiers were calculating normals, when those normals were ignored by the next modifier.
now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback.
Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
A previous bugfix disabled the dynamic paint modifier for orco texture
coordinate evaluation of the modifier stack. However the MOD_APPLY_USECACHE
flag is not a good way to check if the modifier is evaluated for orcos.
Instead I've added a MOD_APPLY_ORCO flag. Also removed a bunch of
applyModifierEM callbacks, none of them served a purpose except for the
subsurf modifier.
there were 2 bugs here.
- int buttons scaling values on input but not on display.
- pixel distances were using PROP_DISTANCE subtype - which isn't correct.
added assert incase PROP_INT values have PROP_DISTANCE subtype applied in future.
Caused by my assumption that alpha wasn't used for vertex colors.
Infact it is used by blender-internal rendering, but typically only for blending strand particles.
Updated comments to note this.
Also:
* Fixes a (op prop) bug which prevented, once you had baked and freed ocean once, to bake again.
* Fixed infinite values of acumulated foam when baking with foam_fade values above 1.0, now simply clipping accumulated foam value to 1.0, as already done for the "instantaneaous" foam value returned by BKE_ocean_jminus_to_foam().
* Added missing RNA descriptions.
* Made foam_fade unanimatable!
* Added in UI some missing properties that are imho useful: random seed, size (kindof 'surface scaling'), and foam_fade (baking only).
* Removed custom lerp() func from bke's ocean.c, BLI's interpf does exactly the same thing (the first two args are just in reversed order). Note: this could most certainly be done in other parts of the code, bpy's mathutils for e.g. has its own linear interpolation code for vectors and matrices :/).
* Did some general code cleanup (mostly line length and no C++ -> C comments)...
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
We need both a new MLOOPUV and MTEXPOLY layers with generated geometry! For some reason, the loopuv alone seemed to work in 3D view, but definitively not in render.
- UV's were not being calculated if there were too many VColor layers.
- precalc (omd->size * omd->spatial_size) was being called in a loop.
- use vector functions to avoid pointer indrections on each access which the compiler wont optimize - eg: och->ibufs_disp[f]->rect_float[4*(res_x*j + i) + 1]
- dont call abs() on ints (converts to double and back to int in this case).
also unrelated render buttons change. move saving options directly under the file path since these were easy to confuse with image format options like zbuf, ycc, preview.. etc.
The real reason for this crash is that ocean modifier (in generative setting) does not properly set the derived mesh face ORIGINDEX data to ORIGINDEX_NONE. With this the previous fixes are not necessary.
