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.
- when an edge exists across a quad, dont attempt to triangulate it. (such a case isn't so common anyway)
- silly mistake when checking if anything needed to be done in the modifier, percent was being checked for 1.0 even when not used.
- use unsigned ints only (where mixing signed/unsigned)
- turn heap_swap into an inline function, add SWAP_TVAL macro to swap values using a temp value as storage.
- added type checking SHIFT3/4 macros
also style cleanup for CTR_Map
- update face normals when triangulating.
- avoid divide by zero when interpolating customdata on a zero length edge.
- replace zero float comparisons with fabsf() < FLT_EPSILON to avoid numeric error.
also renamed BLI_heap_empty() --> BLI_heap_is_empty() so its obviously readonly function.
The issue here is that the particle instance modifier (pimd) accesses data from the linked particle system modifier (psmd). This data is only correctly generated when the psmd is enabled; here the design violates the modifier principle of providing valid object data (or rather DM) even when disabled.
The solution in this case is to make a custom isDisabled check for the pimd to see if the psmd is enabled. This means the pimd won't work for disabled psmd, but doesn't crash.
Caused by modifier updates during dupli-list generation. The dupli-list generation temporarily changes the ob->obmat matrix, which in turn leads to wrong particle states if used for reset. Skip the particle update if no timestep is performed or initialization required.
Proper solution for this problem would be to avoid changing the object data (= particles) state altogether in modifiers, which are usually only writing to DM data and not touching the object or base mesh. This would require a well designed physics framework and integrating it into current particles is close to impossible.
Documentation & Test blend files:
------------------
http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements
Credits:
------------------
Miika Hamalainen (MiikaH): Student / Main programmer
Daniel Genrich (Genscher): Mentor / Programmer of merged patches from Smoke2 branch
Google: For Google Summer of Code 2012
Issue was caused by cycles being duplicated curve objects before converting
them to mesh. This duplication will loose pointcache which resulted in object
not being properly deformed.
