Ok, sounds good! On 04/10/11 11:50, "Martin Bürbaum" wrote: >> 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
_______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
