of threads to the number of cores when the fluid is created. Rather it is now
set to 0 which means "use the number of threads specified for the scene".
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.
Dynamic Paint was also being calculated during "orco" mesh generation, causing image sequence baking to use orco derived mesh instead. This likely affected vertex type surfaces too in some cases.
The previous fix limited overlap, but is sometimes
too conservative, and artists want way to turn off
the limiting, so added 'Allow Overlap' option to
modifier.
generator with a local one. It's not thread safe and will not give repeatable
results, so in most cases it should not be used.
Also fixes#34992 where the noise texture of a displacement modifier was not
properly random in opengl animation render, because the seed got reset to a
fixed value by an unrelated function while for final render it changed each
frame.
this matches closer to convention from existing functions - angle_v3v3() angle_normalized_v3v3().
also added assert to ensure argument given to axis_angle_normalized_to_mat3() is in fact normalized.
This is a quick fix that perhaps overestimates the point
of first geometry collision, but at least for now it should
allow models that used the old modifier and a too-big
bevel amount to not look awful.
The correct solution to this problem is much more involved
and I'll get to it later.
Now modifier takes a segments parameter.
Bevel edge weights will multiply the overall amount.
For vertex-only, you can give a vertex group name,
and the weights in that will multiply the overall amount.
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.
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
This means the deformation on the input to the modifier can be re-applied ontop of the mesh cache.
In practice this is most useful for using corrective shape-keys with mesh-cache.
