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.
- use NULL rather then 0 for pointers
- use static functions where possible
- add own includes to ensure func's and their declarations don't get out of sync.
