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.
vertices. Previously it would hide particles by creating invalid faces, but this
didn't make the vertices actually disappear.
Also found that it could generated corrupt geometry for cases with faces, which
gave wrong subsurf and could crash in edit mode.
The particle system modifier has to ensure tesselation before testing for topology changes. It compares the number of vertices, edges and tesselation faces to the previously stored values.
Note that this test only detects a subset of actual topology changes (where the number of elements differs), but this is a known limitation we have to live with for now.
The direction for these are flipped from other end caps, so add a root
flag to indicate whether the cap polygon's vertex output order should be
reversed.
Fixes bug [#32079] Skin-modifier calculates root's normals wrong
projects.blender.org/tracker/index.php?func=detail&aid=32079&group_id=9&atid=498
