> The appeal of modelling in blender is that it's just so much more > immediate than other tools. > Having the object locked to only its initial creation parameters when > entering edit mode sounds very cumbersome. > How will you make it not so?
I _mostly_ agree when it comes to primitives. But that still doesn't mean that the option of non-destructive behaviour is not useful :-) Any idea to make this as transparent as possible is welcome. The first idea I have would be to make the conversion completely transparent. I.e. as soon as you change the content in edit mode you get an indicator that the object can now be modified, but parameters can not be tweaked anymore. (A simple undo would revert this of course.) Another way would be to make the "locked" creation an optional/separate process. > Also, how will your system work if I add an object whilst in edit mode? Nothing changes here. Adding stuff in edit mode (i.e you already have the object unlocked) would behave like it does now. You can redo operators, but you can obviously not change the parameters in the long run. > There was a python solution a while back that would allow you to do > transforms etc and then go back and change the creation parameters as > long as you hadn't edited the created mesh. > (entering edit mode was the key there I believe) :-D That was what I referred to in my original mail - that is/was my code. It was canned because of various issues. The main problem was basically that the framework I'm proposing right now does not exist yet. And no, there was no locking involved in the scripts (or "smart behaviour" like recognizing if edit mode was entered). It was more of a workaround than solution. This proposal aims for the latter. > IIRC it only worked on primitives created in python rather than the > native ones, but if that worked for all primitives It strikes me that > is a much more "blender" solution... Please keep in mind that internally there is no difference if the object was created by Blender directly or from python. So having a framework that _supports_ this new way of creating objects will then enable us to use it to do useful stuff with it. IMO it's not supposed to be a replacement, other may have a different view on it though. Worst case: I'm all for keeping the existing way of adding object if we can't find a decent way of making this transparent. > Seriously though, in "real world" use rather than theoretical tests > does anyone use a primitive /without /editing it? for me that's so > rare i'd class it as almost never. The proposal is not focused on primitives-only, it's a general view on object creation. As you mentioned already there are a lot of more complex mesh scripts that could benefit from the integration of a system like this. I personally don't do it often with _primitives_. But IF I do it's a bit of a pain checking the geometry to see how the mesh looks and the re-create with exactly the same geometry but one parameter tweaked :-/ Workflow of users differ heavily, so I assume other people use it even more than me and not at all. Discuss! Cheers, Martin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
