Solidify with fill 'only rim' results in wrong face loop cycle for certain topology #43643

New Issue

Jukka Martama · 2015-02-12T20:27:25+01:00

Jukka Martama commented

2015-02-12 20:27:25 +01:00

System Information
Windows 8.1, NVIDIA GeForce GTX 645

Blender Version
Broken: 2.73a

When I use Rip on plane with Solidify and Bever modifiers applied, Blender crashes.

Exact steps for others to reproduce the error
Create plane and subdivide once. Add Bevel and Solidify modifiers (Solidify on top). Check Only Rim from Solidify modifier. Select middle verticle and rip (V). Use Rip again and Blender will crash.

Just open attachment rip_crash.blend and press V.rip_crash.blend

**System Information** Windows 8.1, NVIDIA GeForce GTX 645 **Blender Version** Broken: 2.73a When I use *Rip* on plane with *Solidify* and *Bever* modifiers applied, Blender crashes. **Exact steps for others to reproduce the error** Create plane and subdivide once. Add *Bevel* and *Solidify* modifiers (Solidify on top). Check *Only Rim* from Solidify modifier. Select middle verticle and rip (V). Use Rip again and Blender will crash. Just open attachment *rip_crash.blend* and press V.[rip_crash.blend](https://archive.blender.org/developer/F142814/rip_crash.blend)

Jukka Martama commented

2015-02-12 20:27:25 +01:00

Changed status to: 'Open'

Jukka Martama commented

2015-02-12 20:27:25 +01:00

Added subscriber: @JukkaMartama

blender-admin commented

2015-02-12 20:27:25 +01:00

#42860 was marked as duplicate of this issue

NikoLeopold self-assigned this 2015-02-13 01:19:14 +01:00

NikoLeopold commented

2015-02-13 01:19:14 +01:00

can confirm crash in Blender 2.73 on Ubuntu 14.04.1.

very interesting, will try to investigate.

can confirm crash in Blender 2.73 on Ubuntu 14.04.1. very interesting, will try to investigate.

NikoLeopold commented

2015-02-21 15:44:44 +01:00

it is obiously not a problem of the rip tool per se, but more generally of the mesh structure.
i tried to simplify the mesh as much as possible to leave only the essential topology (see image below).

when applying solidify with fill 'only rim' to the simplified mesh, obviously one face gets a wrong loop edge assignment in its loop cycle.

bmesh_elem_check then fails with error codes
2^20 (loop base vertex or next loop base vert are not the vertices of their edge.), and
2^21 (bmesh_radial_validate failed, loop base vertex of some loop in the radial cycle
— i.e. among the loops around the same shared edge — doesnt belong to the edge.)

and when the bevel modifier is being drawn, blender crashes from segmentation fault due to nullpointer after some geometry could not be found in the generation of the beveled faces.

so the real issue seems to lie in the solidify modifier, since when modelling the mesh manually, all bmesh assertions pass and everything works fine.
so will try to investigate into what happens on solify application.

it is obiously not a problem of the rip tool per se, but more generally of the mesh structure. i tried to simplify the mesh as much as possible to leave only the essential topology (see image below). ![Screenshot_from_2015-02-21_15:16:30.png](https://archive.blender.org/developer/F145118/Screenshot_from_2015-02-21_15_16_30.png) when applying solidify with fill 'only rim' to the simplified mesh, obviously one face gets a wrong loop edge assignment in its loop cycle. bmesh_elem_check then fails with error codes 2^20 (loop base vertex or next loop base vert are not the vertices of their edge.), and 2^21 (bmesh_radial_validate failed, loop base vertex of some loop in the radial cycle — i.e. among the loops around the same shared edge — doesnt belong to the edge.) and when the bevel modifier is being drawn, blender crashes from segmentation fault due to nullpointer after some geometry could not be found in the generation of the beveled faces. so the real issue seems to lie in the solidify modifier, since when modelling the mesh manually, all bmesh assertions pass and everything works fine. so will try to investigate into what happens on solify application.

NikoLeopold changed title from ~~Rip crashes with solidify and bever modifiers~~ to Solidify with fill 'only rim' results in wrong face loop cycle for certain topology

2015-02-21 15:47:28 +01:00

NikoLeopold commented

2015-02-21 17:48:13 +01:00

note that as a workaround you can select the mesh and run C.active_object.data.validate() in the python interpreter to fix the mesh. if it returns True it actually changed something.

note that as a workaround you can select the mesh and run `C.active_object.data.validate()` in the python interpreter to fix the mesh. if it returns `True` it actually changed something.

NikoLeopold commented

2015-02-23 15:54:30 +01:00

Added subscriber: @ideasman42

NikoLeopold commented

2015-02-23 15:54:30 +01:00

ok so from the comments in MOD_solidify.c /* 3+ faces using an edge, we can't handle this usefully */
and from the report cited below it seems that this is a more general and known issue (just try any edge with more than 2 faces attached, using fill only rim, it will be the same issue).

In #38636#202882, @ideasman42 wrote:
Solidify modifier just doesnt work well when 3+ faces use an edge, this is a known limit with the method used.

Its designed not to fail outright, but not really supported either.
[...] its possible though difficult to integrate with the current modifier.

so at this point unfortunately i must say that i dont have sufficient studied topology and dont really have the time to try a rewrite of the modifier.

but it would be nice to at least be able to assert the above statement 'Its designed not to fail outright', since when we use a bevel modifier on it (and likely in other cases), it rather segfaults outright due to the invalid mesh structure.

a dirty hack would be to just run mesh_validate after the modifier is applied with the only rim option, where the issue is known to occur. but thats not really beautiful.
guess we might ask @ideasman42 at this point.

ok so from the comments in MOD_solidify.c `/* 3+ faces using an edge, we can't handle this usefully */` and from the report cited below it seems that this is a more general and known issue (just try any edge with more than 2 faces attached, using fill only rim, it will be the same issue). > In #38636#202882, @ideasman42 wrote: > Solidify modifier just doesnt work well when 3+ faces use an edge, this is a known limit with the method used. > > Its designed not to fail outright, but not really supported either. > [...] its possible though difficult to integrate with the current modifier. so at this point unfortunately i must say that i dont have sufficient studied topology and dont really have the time to try a rewrite of the modifier. but it would be nice to at least be able to assert the above statement 'Its designed not to fail outright', since when we use a bevel modifier on it (and likely in other cases), it rather segfaults outright due to the invalid mesh structure. a dirty hack would be to just run mesh_validate after the modifier is applied with the only rim option, where the issue is known to occur. but thats not really beautiful. guess we might ask @ideasman42 at this point.

NikoLeopold removed their assignment 2015-02-23 21:35:45 +01:00

NikoLeopold commented

2015-02-23 21:35:45 +01:00

Added subscriber: @NikoLeopold

Campbell Barton commented

2015-02-24 23:17:47 +01:00

This is caused by D737, the problem is that the number of newVerts is being confused with the newEdges.

When each vertex is on the boundary of only one face island. These values are the same. but when vertices are shared you get this:

   +----+
   |    |
   |    |
   +----+----+
        |    |
        |    |
        +----+
  
   there should be: 7 verts, 8 edges.

... currently in this case it only allocates 7 edges. when it should be 8.

This is caused by [D737](https://archive.blender.org/developer/D737), the problem is that the number of `newVerts` is being confused with the `newEdges`. When each vertex is on the boundary of only one face island. These values are the same. but when vertices are shared you get this: ``` +----+ | | | | +----+----+ | | | | +----+ there should be: 7 verts, 8 edges. ``` ... currently in this case it only allocates 7 edges. when it should be 8.

NikoLeopold commented

2015-02-25 17:34:23 +01:00

ok so i see that the number of edges to use in CDDM_from_template is

(int)((numEdges * stride) + newEdges + newVerts)

in case of do_shell stride is 2 and newVerts is 0, since it just takes a translated copy of the original mesh and adds the newEdges of the rim.

in the case of no shell (only rim) the stride is 1 and newVerts is assigned the value of newEdges, as if assuming that for each vertex at the end of the new extruded edges there is one edge on the rim.
and as you pointed out, this assumption is wrong.

hm.. i wonder about the we can't handle this usefully */ comment. i guess a lot has been tried before, but if it can't be handled without a extensive rewrite of the modifier, maybe still the crash can be avoided?
im just wondering if maybe the code from the do_shell could be used and then just cut out the shell, or maybe even use some of the code from mesh_validate.c (maybe count the islands and find a pattern to get the edge count if there is one, but well probably its not just about the number of edges), but i fear that my oversimplifications leave out a lot of the variables involved...

ok so i see that the number of edges to use in `CDDM_from_template` is ``` (int)((numEdges * stride) + newEdges + newVerts) ``` in case of `do_shell` stride is 2 and newVerts is 0, since it just takes a translated copy of the original mesh and adds the newEdges of the rim. in the case of no shell (only rim) the stride is 1 and newVerts is assigned the value of newEdges, as if assuming that for each vertex at the end of the new extruded edges there is one edge on the rim. and as you pointed out, this assumption is wrong. hm.. i wonder about the `we can't handle this usefully */` comment. i guess a lot has been tried before, but if it can't be handled without a extensive rewrite of the modifier, maybe still the crash can be avoided? im just wondering if maybe the code from the do_shell could be used and then just cut out the shell, or maybe even use some of the code from mesh_validate.c (maybe count the islands and find a pattern to get the edge count if there is one, but well probably its not just about the number of edges), but i fear that my oversimplifications leave out a lot of the variables involved...

NikoLeopold commented

2015-02-25 17:36:52 +01:00

btw. sorry for thinking out loud, i guess thats rather unappropriate...
though this issue seems too involved for me atm. im learning a lot in all this process, but i shouldnt go into such detail i feel.

btw. sorry for thinking out loud, i guess thats rather unappropriate... though this issue seems too involved for me atm. im learning a lot in all this process, but i shouldnt go into such detail i feel.

Martin Felke was assigned by Campbell Barton

2015-02-26 04:37:56 +01:00

Campbell Barton commented

2015-02-26 04:37:57 +01:00

Added subscriber: @scorpion81

Campbell Barton commented

2015-02-26 04:37:57 +01:00

@scorpion81 is going to check on the bug.

@NikoLeopold, its fine to show results of investigation, this is rather hard to follow in areas.
However the comment ... we can't handle this usefully */ isn't relevant. Thats related to normal calculation and not even executing in this crash.

@scorpion81 is going to check on the bug. @NikoLeopold, its fine to show results of investigation, this is rather hard to follow in areas. However the comment `... we can't handle this usefully */` isn't relevant. Thats related to normal calculation and not even executing in this crash.

blender-admin commented

2015-02-26 08:48:22 +01:00

This issue was referenced by 31f6e621b8

This issue was referenced by 31f6e621b8cf005ff2b02fd7f0c6f4f9bfc5a8d4

Campbell Barton commented

2015-02-26 08:50:27 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2015-02-26 08:50:27 +01:00

Campbell Barton commented

2015-02-26 08:50:27 +01:00

Closed by commit 31f6e621b8.