Warning ! VERY Dangerous operation with Modifiers !

Tale of a bad venture :

Hi ! I have lost two days of work because of an error I did using Shrinkwrap Modifiers, and before I understood what was the matter, I had to redo many things from scratch !

I wanted to tell you this venture, because an apparently simple error can have heavy consequences and leads to a blend file that seems to work perfectly well but can’t be opened once saved !

I was building a setup with several mesh objects using Shrinkwrap modifiers to match the surface of the terrain, in the desert scene I’m working on for a while. If you know my “Tracks Creator” creating an animated texture to be used in a second pass for displacement mapping, the last method I’m working on allows to generate detailed and realistic tires tracks in relief in only one pass, directly visible in the 3D viewport.

For that, I used several objects with shrinkwrap modifiers applied in cascade. By error, the last object of the chain pointed to the first one. So it made a loop.

When using constraints, loops are not a problem, and sometimes they can even be an advantage, allowing very interesting things like the self tracking constraint that I use for the rear wheels of cars and trucks in my cars setups.

So I have not suspected this at first glance, and before I found out what happened, I came with a serie of unusable blend files ! When working, I save often my work, but as the problem occurs only once the file is closed, all saved files have been corrupted.

Once closed, the blend file containing a Modifier loop can’t be opened. If you look at the ressources usage in Windows task manager, you will see that memory amount used increases up to the level where the whole memory (8GB in my case) is used and the computer becomes unresponsive and has to be hard-rebooted !

Before, when (rarely) I encountered a file refusing to open, I had created a new file and imported the whole content of the locked file or opened the last working file and imported the recently added objects of the locked file, and this solved the problem.

With Modifiers, before I understood the nature of the trouble, I tried to import the last added objects (included in a group), but as soon I imported the litigious objects, the computer entered in a loop !

It happens as well with Blender 2.49b and 2.55.

So, be careful when working with Modifiers ! I haven’t searched if some other Modifiers may give such surprise, but the Shrinkwrap Modifier must be used with caution ! This said, it is a marvelous tool allowing many interesting effects !

Happy Blending !

Did you file a bug report?

Well, It is not really a bug. I agree that something could probably be done to avoid a computer crash in such situation, but it is an error in using the Modifier.

Do you think that it should be reported as a bug ?

It’s a bug for sure, that should not be allowed to happen.

Blender consuming 100% of your computer’s resources during an endless loop while trying to open a saved .blend could probably safely be considered a bug.

Just sayin’…

i did report last year a loop of this sort in some old 2.49 file which was also in 2.5
ad had something to do with the constraint .parent and it was corrected!

so report it has a bug cause it should not allow to do a loop like that and damage files!
so id’ say this is a bad bug!
nothing to loose in reporting it and see what devs say about it !

it should be corrected or at least give a warning so you don’t loose your file!

also you should never loose a file because of an operation or a modifier i think!
cause that’s very bad PR!

salutations happy 2.5

This is most not only a bug, but a very high priority bug. Any thing that corrupts user data is an extremely serious issue and needs to be corrected.

OK ! Thank you for the advice. I have just reported it as Bug report 25271 in Blender 2.4x section and 25272 in Blender 2.5x section.

…and Brecht fixed it. :slight_smile:

http://cia.vc/stats/project/Blender/.message/3644aa3

There’s a lesson here: Be a good Blendizen, report your bugs kids. The developers are very friendly and helpful and fix things fast (Especially high priority ones like this), so don’t be afraid to report.

Holy crap, that was fast O_O

ok nice response from dev’s and thanks to them

any idea when it will be updated - which built ?
and will this affect latest 2.5 built too ?

happy 2.5

See the link in the post above, rev33756

Great news ! Thank you Brecht ! Wow,really fast !

I have a rule from my old Maya days. Save your milestones like “work0001.blend” and next milestone “work0002.blend” and so on.

Yes! Absolutely amazing!
Great job!

Since ever, it’s a cool reflex with any file in any app… Can (and does often) save hours of hard job!

As I said, I save very frequently, with incremental file name, but in this case it has no effect because the bug is saved with the files and appears only if you try to re-open the file. In a continuous work, you don’t come back each time to verify if the last saved file opens, specially on a big scene whene the file requires around one minute to load !

Hi Roubal
Thanks for your posts. I was planning to shift to 255 from 249b, I think I should wait a while more ?

Actually this problem seams to be existent in 2.49 too… But, if you shift, you’re not obliged to throw away your 2.49 version(s) anyway. :slight_smile:

For my own, I have not yet switched to 2.5x. I have encountered the bug with 2.49b, and just verified that my files behave the same way in 2.55.

I have not yet switched only because I have not enough time to learn 2.55 currently, not because of bugs. I 'd like a lot switching to 2.55, because some old bugs in 2.49b will never be fixed, specialy some texture refresh things acting on particles and real time mesh displacement.

This said, I don’t know if all my setups for cars animation will work in 2.5x. I have tried to open some and they were broken ! I hope that the kind of constraints loops that I use in 2.49b will not be forbidden in 2.5x, because it’s really useful.