Various problems with CD layers and tesselation, related to modifiers stack #30234

New Issue

Bastien Montagne · 2012-02-17T19:43:21+01:00

Bastien Montagne commented

2012-02-17 19:43:21 +01:00

%%%Hi Andrew, posting here as Campbell advised me you were the guy for this area, and I couldn’t catch you on IRC.

To see the problem, simply open the default scene and switch to Weight Paint mode. Instead of a blue cube, you get a black one.

You can find similar problems in various modifiers setup involving custom data layers (e.g. dynapaint’s demos, weightvg’s demos, an UVProject after a subsurf, etc.).

First part of the problem is that, at the end of the mod stack func (mesh_calc_modifiers), the finaldm is only re-tesselated if it has no tessfaces already.

So I coded a function to only update CD layers, without re-tesselating, to catch that kind of situations. And there I faced another one: quite often, finaldm has tessfaces, but no CD_POLYINDEX layer, which I think is a bug. This happens e.g. because subsurf (i.e. CCGDM) does not generate that layer currently when it does its own tesselation, and also because that layer was not protected during copying of dm in stack evaluation…

The attached patch addresses all the problems I could find out, but I finally wonder if we shouldn’t just unconditionally retesselate at the end of the mod stack? Or else, review all modifiers that actually affect topology, so that they really invalidate tesselated data (or just do it as soon as we have a constructive one in stack)? %%%

**Relates to**: #30234 #30266 #29451 %%%Hi Andrew, posting here as Campbell advised me you were the guy for this area, and I couldn’t catch you on IRC. To see the problem, simply open the default scene and switch to Weight Paint mode. Instead of a blue cube, you get a black one. You can find similar problems in various modifiers setup involving custom data layers (e.g. dynapaint’s demos, weightvg’s demos, an UVProject after a subsurf, etc.). First part of the problem is that, at the end of the mod stack func (mesh_calc_modifiers), the finaldm is only re-tesselated if it has no tessfaces already. So I coded a function to only update CD layers, without re-tesselating, to catch that kind of situations. And there I faced another one: quite often, finaldm has tessfaces, but no CD_POLYINDEX layer, which I think is a bug. This happens e.g. because subsurf (i.e. CCGDM) does not generate that layer currently when it does its own tesselation, and also because that layer was not protected during copying of dm in stack evaluation… The attached patch addresses all the problems I could find out, but I finally wonder if we shouldn’t just unconditionally retesselate at the end of the mod stack? Or else, review all modifiers that actually affect topology, so that they really invalidate tesselated data (or just do it as soon as we have a constructive one in stack)? %%%

Bastien Montagne commented

2012-02-17 19:43:21 +01:00

Changed status to: 'Open'

Bastien Montagne commented

2012-02-17 19:46:06 +01:00

%%%As a side note, it should also fix [#29451].%%%

Bastien Montagne commented

2012-02-20 10:54:50 +01:00

%%%Moved from BMesh Branch 2.6x Bug Trackers to Blender 2.6 Bug Tracker%%%

Bastien Montagne commented

2012-02-20 10:54:50 +01:00

%%%Updated patch against 44275 of trunk, and moving that bug into main tracker!%%%

Bastien Montagne commented

2012-02-26 20:20:58 +01:00

%%%Updating %%%

Campbell Barton commented

2012-03-07 15:24:55 +01:00

%%%Discussed with Bastien

requested that we have a flag in DM so that tessface data can be tagged as out of date so its not recalculated always (would slow down subsurf a lot I would think).
%%%

%%%Discussed with Bastien requested that we have a flag in DM so that tessface data can be tagged as out of date so its not recalculated always (would slow down subsurf a lot I would think). %%%

Bastien Montagne commented

2012-03-09 14:52:28 +01:00

%%%Updated patch to r44744, adding a dirty enum flag to DM (this way, wae can easily add other dirty flags later, if needed).

Side note: I’m not sure it’s related, but we still have problems with particules and subsurf modifier (i.e. dynapaint demo works well and gets nice weight preview, but not particles, as long as subsurf is there)… :/%%%

%%%Updated patch to r44744, adding a dirty enum flag to DM (this way, wae can easily add other dirty flags later, if needed). Side note: I’m not sure it’s related, but we still have problems with particules and subsurf modifier (i.e. dynapaint demo works well and gets nice weight preview, but not particles, as long as subsurf is there)… :/%%%

Miika Hamalainen commented

2012-03-10 14:25:33 +01:00

%%%@Bastien
Yes, hard to say if that is related or not. Particles or hair don't work at all if there is a subsurf modifier and dynamic paint in the stack earlier, weights seem to have nothing to do with it. Also it seems to be very random - just changing the subsurf level randomly works. After short investigation I have no idea why that is happening. :s%%%

%%%@Bastien Yes, hard to say if that is related or not. Particles or hair don't work at all if there is a subsurf modifier and dynamic paint in the stack earlier, weights seem to have nothing to do with it. Also it seems to be very random - just changing the subsurf level randomly works. After short investigation I have no idea why that is happening. :s%%%

Bastien Montagne commented

2012-03-15 21:25:30 +01:00

%%%Updated patch against r44907, and removed customdata changes.%%%

Bastien Montagne commented

2012-03-18 23:15:44 +01:00

%%%Patch committed as r44978, closing.%%%

Bastien Montagne commented

2012-03-18 23:15:44 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2012-03-18 23:15:44 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Various problems with CD layers and tesselation, related to modifiers stack #30234