| Message |
 |
- Date: 2010-11-28 14:06
- Sender: Ton Roosendaal
- Please follow bug reporting guidelines. No recipies here, just add a .blend to prevent misunderstandings.
ALWAYS test with our releases too, mention version and OS you tested, and check if this worked before with older versions.
|
- Date: 2010-11-28 16:13
- Sender: Konstantins Visnevskis
- Sorry,
the problem seems to be in the .blend file itself and my startup file (or in my head), because files saved in blender 2.4 then opened in 2.54/2.55 work ok and allow to create new cloths that work ok too.
The cloth parameters and recepie are identical to ones in opened 2.4 files yet I cannot create working pinned cloth.
Vista64, blender 2.54, 2.55.
|
- Date: 2010-11-29 00:50
- Sender: Rob Waite
- Confirmed on OSX for the attached .blend.
I noticed a lot of actions with fake users and (although I don't have sufficient knowledge to explain why) by selecting the plane in object mode, selecting an action (any action it seems) then unlinking the action allows the cloth sim to behave as normal.
If this is helpful - great, otherwise I shall quietly depart ;)
R.
|
- Date: 2010-11-29 04:01
- Sender: Henk van der Laak
- Confirmed with attached file on Ubuntu 10.04 64 bit. Blender svn 33344.
Setting the Physics -> Cloth -> Pre-roll to positive number is sort of a work-around.
Playback runs from frame 0 (and could even run from negative values), but cloth simulation cache can only start from frame 1. Maybe this will point to the problem?
|
- Date: 2010-11-29 09:34
- Sender: Janne Karhu
- Assigned to self for investigation.
|
- Date: 2010-11-29 12:40
- Sender: Janne Karhu
- This basically works just fine in the modifier code, but there's something going wrong in the derivedmesh update that is done from the drawing code. I've been looking over the modifier calculations code in mesh_calc_modifiers(..) and at least for me it seems to be a giant mess with hacks upon hacks, so I really don't know how deep the underlying problem is.
It's a big mystery to me why the derivedmesh is calculated 3 times for frame 1 for example! Once from object_handle_update (this is correct), and twice from drawing code (once with the correct datamask and once with a wrong one).. This last derivedmesh update with the wrong data mask is what causes cloth pinning not to work, as the cloth dm isn't given the vertex weight layer.
I have a feeling that recalculating the derivedmesh from the drawing code is a bad idea in any case as it's the main reason for thread crashes when rendering/baking. So if this could be avoided it could solve quite many problems with thread safety.
Campbell: I really don't know where to go from here, but it seems you has been quite active in the derivedmesh/modifier code recently, so would you have any words of wisdom on this whole thing?
|
- Date: 2010-12-01 07:01
- Sender: Campbell Barton
- Janne, looked into this and while there is a problem with double updates which needs fixing, I think the bug is in the cloth modifier.
The copy of the derived mesh:
cloth.c:439, result = CDDM_copy(dm);
...is not copying the deform-verts because the modifier system sets the layers to copy with DM_set_only_copy().
mesh_calc_modifiers() ensures that cloth gets a 'dm' with deformverts but knows thay are not needed after so its assumed the cloth modifier will use the dm's data and the copy wont need the deform verts.
applied quick fix to copy the deform verts if they are not copied, but would be better to use the original deform verts, or even make this modifier into a deform modifier and only edit a float array?, left a note in the code about this problem.
committed workaround r33406.
Assigning back to Janne to change how the modifier uses the derived mesh.
|
- Date: 2010-12-01 08:36
- Sender: Henk van der Laak
- Workaround does not work around :-(
On attache file, pinning has no effect until frame #24. From that frame on it pins correctly.
Tested on Ubuntu 10.4 64bit, SVN33408
|
- Date: 2010-12-01 13:25
- Sender: Janne Karhu
- Campbell: Ahh, thanks for looking into this, now my thoughts are much clearer too. I reverted your workaround and switched it so that cloth uses the original dm for simulation and only writes the result into the copy.
Henk van der Laak: To see the correct simulation you have to first clear the cache that was calculated wrong in the past by going to frame 1 and changing some cloth setting.
This should now be fixed, closing the report!
|
