More than just layers (mockup), 2004-01-30
Moderators: jesterKing, stiv
More than just layers (mockup), 2004-01-30
Edit: last updated 2004-01-30
Update to my grouping/visibility (previously layers) page:
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
Work in progress, but there's more than enough to comment on, any feedback is appreciated!
You might be also interested in some screenshots and explanation how layers work in 3ds max:
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
Update to my grouping/visibility (previously layers) page:
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
Work in progress, but there's more than enough to comment on, any feedback is appreciated!
You might be also interested in some screenshots and explanation how layers work in 3ds max:
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
Last edited by thorwil on Fri Jan 30, 2004 6:29 pm, edited 3 times in total.
-
- Posts: 0
- Joined: Sun Jan 19, 2003 8:30 pm
wow! this is one of the most extensive and complete proposals i have seen! good job!
about the layer feature to have different layer 'modes' is a cool feature i also saw in lw a while back. i thought itd be nice to have in blender and now with blender opensource it is more than possible!
great proposal!
about the layer feature to have different layer 'modes' is a cool feature i also saw in lw a while back. i thought itd be nice to have in blender and now with blender opensource it is more than possible!

great proposal!
Guys great, There is one big thing we should add to blender. Ok here it comes: When you make a game, model, or scene and add textures, sounds, materials, actions or whatever you can delete it sometimes totally out of blender. So we should make a feature in blender, that shows you a page with categories like, materials, textures, sounds, ipo's, actions and so on, then hit a arrow like on the idea of that manager, and you can choose a several options for that file in that category by right click on it, and choose, detele, update (like when you added a texture with the same name, to reload it, or save to map (when you do this it makes a map in what catehory the files is, example make map: textures> ground.jpeg) and maybe a feature to export materials as little files, that would be great. So sharing materials would be easy then 

Another update.
Duplicating all stuff from buttons window is problematic, so I changed direction on that.
http://wrstud.urz.uni-wuppertal.de/~ka0 ... ml#manager
Please help me with giving feedback!
I'm thinking of solo functionality. Like in audio sequencer software, were all channels have mute and solo buttons. Activating solo on any channel mutes all other channels, but you can set several channels to solo.
No I would like to set a single object, or a small group of them to solo often enough.
Every entry in the entry could have solo and mute buttons instead of a single visibility. Alternatively there could be one big solo button, setting the currently selected (or maybe only the active?) object(s) to solo (hiding oll other objects).
What do you think about that?
Duplicating all stuff from buttons window is problematic, so I changed direction on that.
http://wrstud.urz.uni-wuppertal.de/~ka0 ... ml#manager
Please help me with giving feedback!
I'm thinking of solo functionality. Like in audio sequencer software, were all channels have mute and solo buttons. Activating solo on any channel mutes all other channels, but you can set several channels to solo.
No I would like to set a single object, or a small group of them to solo often enough.
Every entry in the entry could have solo and mute buttons instead of a single visibility. Alternatively there could be one big solo button, setting the currently selected (or maybe only the active?) object(s) to solo (hiding oll other objects).
What do you think about that?
Another update, now the timeline has content.
Changed locking to editability, because it fits better into the logic.
Added an diagram to help explain, edited and added text.
I will stop with this, if I don't hear from coders there's interest and a chance of implementation.
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
Changed locking to editability, because it fits better into the logic.
Added an diagram to help explain, edited and added text.
I will stop with this, if I don't hear from coders there's interest and a chance of implementation.
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html
I will stop with this, if I don't hear from coders there's interest and a chance of implementation.
thorwil is this just a screen shot or you already started to implement this as a project? i like to give you more ideas - i don't like blender to folow
the same path as others with layers, we have better ideas than maya, max & co.
thorwil is this just a screen shot or you already started to implement this as a project? i like to give you more ideas - i don't like blender to folow
the same path as others with layers, we have better ideas than maya, max & co.
io,
why do you think I asked about coder's interest and chance of implementation? I'm not capable of coding stuff for Blender (I'm sure I could learn it, but I think it's better to make use of my existing skills for now).
It's just a mockup (like stated in the subject).
Implementation would require quite some changes, and would be problematic for compatibility with older versions. That's why I'm waiting to hear if the general direction is ok, or where there are problems.
Nonetheless, any input is welcome.
It should be clear that my ideas don't follow any of the big players, as far as I know their handling of these things. On the other hand, being different is not a design goal. I want an elegant and powerfull basic concept, unification and no unnecessary restrictions.
I don't like the "must have" from your earlier post. Please only use "must" for features that realy must be present in a given context! Everything else is "should have", whereby things should be sorted by priority. Maybe mark some items as optional.
And such lists are ok to start with, but don't forget the "why" in less obvious cases, and the "how" in general.
why do you think I asked about coder's interest and chance of implementation? I'm not capable of coding stuff for Blender (I'm sure I could learn it, but I think it's better to make use of my existing skills for now).
It's just a mockup (like stated in the subject).
Implementation would require quite some changes, and would be problematic for compatibility with older versions. That's why I'm waiting to hear if the general direction is ok, or where there are problems.
Nonetheless, any input is welcome.
It should be clear that my ideas don't follow any of the big players, as far as I know their handling of these things. On the other hand, being different is not a design goal. I want an elegant and powerfull basic concept, unification and no unnecessary restrictions.
I don't like the "must have" from your earlier post. Please only use "must" for features that realy must be present in a given context! Everything else is "should have", whereby things should be sorted by priority. Maybe mark some items as optional.
And such lists are ok to start with, but don't forget the "why" in less obvious cases, and the "how" in general.
sorry, "must have" is for real. otherwise blender is going to be very limited on large projects - or not usable for that at all. what kind of productivity you'll have if you're not able to do these "basic" operations? "name the layers", "lock/unlock", "renderable/not", "snapable/not", "group them" and apply a single operation to a group, "copy by layer","ghost/ungost", etc. i don't see anything that should be put on hold here. if we develop "real layers"let's do it, and thik different than others.
i red the posts in speed and i did not realize that you are not coding too the stuff that you're placing. sorry i'm busy discussing other issues on different forums and i did not realize that. apologize if my tone was not appropriate. _a_
i red the posts in speed and i did not realize that you are not coding too the stuff that you're placing. sorry i'm busy discussing other issues on different forums and i did not realize that. apologize if my tone was not appropriate. _a_
io,
snapable is rather debateable and even ghosting is no way as important as visible or render.
If we would realize all you listed in collums just like in the mockup with visibility, render and editability, that would take quite some space and would not make fo a clear sight.
See, it's obvious you rushed by, and this is no way to design something like this, not even to talk about it. Have you read all what I wrote on my page?
snapable is rather debateable and even ghosting is no way as important as visible or render.
If we would realize all you listed in collums just like in the mockup with visibility, render and editability, that would take quite some space and would not make fo a clear sight.
See, it's obvious you rushed by, and this is no way to design something like this, not even to talk about it. Have you read all what I wrote on my page?
If I remember correctly, it was discuss at some point that this kind of layer functionnality could probably be done by adding functionality to Scenes.
Scenes can already be named, put on top of one another (albeit limited to two) and locked (when used as sets).
I'm not sure how hard it would be to reworked how scenes work to transform them in "layer", but it certainly seems the best approach to me.
Martin
Scenes can already be named, put on top of one another (albeit limited to two) and locked (when used as sets).
I'm not sure how hard it would be to reworked how scenes work to transform them in "layer", but it certainly seems the best approach to me.
Martin
Life is what happens to you when you're busy making other plans.
- John Lennon
- John Lennon