More than just layers (mockup), 2004-01-30

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Wed Feb 18, 2004 8:34 pm

But removing the limitation with stacking scenes and other changes would impact backwards compatibility no less than a completely new system, or wouldn't it?

If scenes would be the new layers, what would current layers be?

What implications might that have on interaction/interface?


And I'm still waiting especialy on feedback on my proposed handling of visibility and other states, like illustrated with the diagram. If the basic concept and logic is not right, everything else is not of much use.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Wed Feb 18, 2004 9:20 pm

If scenes turned into layers, we would not have scenes anymore! I like the current system where layers are under scenes.

I like the look of Thorwils mockup, although I doubt the usefulness of the Flash-like timeline. In Flash, you can only have one keyframed symble per layer, Blender is alot different, you could choose to have everything in one layer if you want. Being able to change layer names, having an unlimited number of them, being able to set their render status on/off, and their UI visibility on/off are all very useful things that will boost productivity, but the timeline won't, as far as I can see, improve anything. Better improve the NLA Editor (so you can also mix and blend IPO's, making it work for objects, not only armature actions.)

With the raytracing capabilities we also need an ability to set an objects render visibility off, but raytracing visibility on so that you can have objects that exist in reflections but not directly. However, I think this would best go to the Material buttons.

You display layers and hirearchy in the same view. To be honest I think I prefer splitting it up so that the hirearchy and layers are two different things. What happens, for example, when an objects child is on a different layer? Anyway, I think most of the time you will be working with hirearchies and layers seperately.

I think what XSI has is suficcient enough. It is very simple to use and it works extremely well:

Image
(the green layer is the active layer. New objects get added here.)

I think this could be added to the 3D window as a floating panel, Transform Properties style. It could be View>Layers

One thing that hasn't been discussed is how to add or remove layers. How about a 'New' and 'Delete' button in the bottom of the panel?

For the hirearchy, I think it would be nice to have small icons (we could use the same ones as the Oops Schematic.) I prefer your arrows to my Windows-style [+][-] thing (did this some time ago), so just imagine Thorwils arrow where there are pluses and minuses.

Image
Last edited by Monkeyboi on Wed Feb 18, 2004 10:09 pm, edited 1 time in total.

loos
Posts: 0
Joined: Mon Jun 09, 2003 3:43 pm
Location: South Jordan, UT

Post by loos » Wed Feb 18, 2004 10:09 pm

Monkeyboi, from what I understood I don't think he was trying to put both the layers and the hierarchy of objects into one pane. What I think he was trying to do is make it so you could have a hierarchy of layers. Sort of a way of grouping the layers. What do you think about that?

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Wed Feb 18, 2004 10:11 pm

Aha, loos! I suppose that is quite useful! Good idea! Must have misunderstood.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Wed Feb 18, 2004 10:15 pm

About the Flash like timeline: I brought Flash up, because it's a source of inspiration and well known. But similarities might be rather limited in the end. Please note that the concept "layer" is not existant in my current proposal. There are objects and groups.
About the usefulness:
- Using different setups, stages whatever in a single scene, accessible by just navigating through frames (made possible by limiting lifespans accordingly). I think this is more "natural" than anything else one could use to organize scenes/stages/shots in a movie.
- It's also a place for audio/video strips. Unification cuts on learning and makes the app more elegant and pleasant to use.
- Time dependant parameters of particle systems could be visualized.
- Events coul be placed in the timeline to switch every kind of setting, like active camera. Events could call scripts.

Not to forget, that the timeline is hideable. One doesn't have to use it.
Monkeyboi wrote:You display layers and hirearchy in the same view. To be honest I think I prefer splitting it up so that the hirearchy and layers are two different things
Besides that I don't use the term layers, because I want to differentiate from other implementations and the current system: Tell me, what would one have, after removing what you refer to as layers from what you think is the hierarchy part?
What happens, for example, when an objects child is on a different layer?
That is not possible in the context of the proposal, so you obviously got something wrong. Maybe I did not do the best job in explaining, but I tried hard ...

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth » Wed Feb 18, 2004 11:50 pm

thorwil wrote:But removing the limitation with stacking scenes and other changes would impact backwards compatibility no less than a completely new system, or wouldn't it?
It wouldn't affect backward compatibility. Basicly, what we could be adding is a new Scene ("layer") manager where you could manage scenes groups. In each group, you could set scene visibility, rendering, lock, ...
By default, a newly created scene would be part of its own group, this way, it would act exactly like it does right now (scenes independant from one another).
if scenes would be the new layers, what would current layers be?
The current layers are better understood when you look at how they work internally. Layers a bit masks that you can compare to see visibility. Objects can be on more then one layer. In that effect, it is rather different than pretty much all the other implementation of layers that I have scene (whether in the 2D program like GIMP or in a 3D program). To that effect, the current layer system is more like a large grouping method.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Thu Feb 19, 2004 10:48 am

loos and Monkeyboi: your posts came while I was typing ... a hierarchy of layers is quite close. Actualy each 3d object is represented by at least one entry. You can think of it as layer containing only one object. These entries can be organized in groups. An this is where it gets interesting, because every entry or group has visibility, rendering and editability status.
But it's all in the text on the page, and I don't know how to formulate it shorter/easier anyway. It might seem too complex, but with an acual implementation, where you could click and see what happens, things would be different.

But since some people seem to think it's complicated, and I should rather keep it simple:
It's only as complicated as the user wants to have it. Lots of possibilities that are there if you want/need them, but must not hinder simple usage.
- If you just add objects to the scene, they will show up as entries in the hierarchy. Giving you access to per object visibility, rendering, editability (for now on: VRE).
- You can create groups to organize the entries. Now the proposed logic allows to handle VRE on two levels: single objects or groups. If you don't care about object VRE, then this groups are much like the current Layers.
- Query groups allow you to change the VRE of all objects of a kind at once. For example: Hiding or showing all armatures. But if you're not interested in that, they will not get in your way.

Now please ask, if something is still unclear about the basic concept! Advice on improving my explanations or the diagram is also welcome.


teeth:
Well, sounds interesting. We went allready through "what layers realy are" on the BF-Funboard list. Still I wonder, would what you propose result in having 2 different concepts for VRE management (extended Scenes and old Layers)?
The fact that current Layers act rather like groups led to the concept ouf groups in my proposal.

But what's wrong with my proposal, and is better with changed Scenes? (Remember, I assume my proposal is for Blender 3, because of the complete replacement of what is called Layers now).

jd-multi
Posts: 0
Joined: Thu Mar 13, 2003 11:29 pm

Post by jd-multi » Thu Feb 19, 2004 5:46 pm

Well it looks great work guys, keep it going like that. Another idea is, you all know the real layers in Blender, using little buttons to use layers. Why not make an option you can add layers by yourself like Photoshop does and Illustrator from Adobe. Just like, when you start with 1 layer in a scene, you can select a button layers, Add layer, and then a new layer is added to the drop down menu. and when to move something to another layer, select objects, press M, and window apears with drop down menu, select layer, press ok, and it's moved. That would be geart, because blender now has got a few layers, and you can't use more then there are added now. For huge animations layers are a great idea, and really usefull. When you computer can't handle a huge scene anymore, just add some objects to a layer, disable layer, and it saves a huge amount of vertices or faces rendering while modeling. :D

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Thu Feb 19, 2004 6:29 pm

jd-multi, what you talk about is in the scope of my proposal. It's just that details are missing (like how to actualy add groups).
What your refer to as Layers are Groups here, and their number is not limited.


Sorry If I'm wrong, but I have the feeling that many people only look at the nice pictures (and maybe skim over the text). I don't know why I invested all the time, if nobody takes a closer look and actualy evaluates the stuff. The 'wow' 'good work' or 'looks good' comments are nice, but that doesn't tell me if just the pictures are nice to look at, or if people are in favor of the concept, or where there might be problems.

I would realy appreciate, if somebody would try to explain my proposal in his own words, so I can see if I brought home the message or what aspects need clarification.

Or going through every aspect of it, and telling me what's good or bad, which implications are to be thought of and so on.

And everybody who feels like proposing a different system should explain where the advantages/disadvantages might be.
Right now this thread looks like everybody just drops his stuff. After all the work I invested, don't you think it would be better to build up on it (at least as long as no fundamental problems can be pointed out)?

loos
Posts: 0
Joined: Mon Jun 09, 2003 3:43 pm
Location: South Jordan, UT

Post by loos » Thu Feb 19, 2004 8:23 pm

Thorwil, I really do like your idea. So here's what I understand from what you've written:

You have a list of objects that can be grouped, or left on their own. Every time an object is created it gets an entry in this list (at which point you can group it with others). Each object/group can be made visible/hidden in the opengl window, visible/hidden in the render, but I can't figure out the third icon (the one that looks like a transaltion widget, two crossing lines). Besides this basic functionality there is what you call inheritance. You can assign materials (or translations, or whatever) to a "group" and every object in that groups gets that material (or translation, etc...). That also helps that guy who asked about being able to make all particles with one material, he could just group all the particles and give that group one material.

I don't understand the timeline as well. You say it helps with object lifespans. Is that with when it shows up in animation? If that's true, then maybe you could just make the visible/hidden render button key-frameable. If not, you'll have to explain a little bit better about the lifespan of an object. Though the layering of the bars in the timeline makes sense.

If I understood it correctly the only thing I would change (except the timelines) is that not every object gets inserted into it's own layer. Make it more like layers in other programs. Whatever layer you're currently on is the layer that the object is inserted in. You can change it later if you want. That way you can make a new layer, and start adding objects to it. It makes it more like a layer manager, instead of a hierarchy manager.

Hopefully this helps a bit. I'm starting to code a bit for blender, but it's slightly daunting. But I think it might be fun to try and implement this. No promises though. It just looks neat. :)

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Thu Feb 19, 2004 9:00 pm

Glad you like it, thank you very much for going through it:D!

Everything correct. Seems my explanation are indeed understandable.
...
loos wrote:... but I can't figure out the third icon (the one that looks like a transaltion widget, two crossing lines).
Editability. Not editable also means not selectable in 3d space, so it's halve the job of ghosting. Year, the icon is not obvious, but it's hard to create a good on for such abstract things ...
Besides this basic functionality there is what you call inheritance. You can assign materials (or translations, or whatever) to a "group" and every object in that groups gets that material (or translation, etc...). That also helps that guy who asked about being able to make all particles with one material, he could just group all the particles and give that group one material.
Don't know about translations, but otherwise correct. Only it's an additional thing, not core.
I don't understand the timeline as well. You say it helps with object lifespans. Is that with when it shows up in animation?
If the lifespan covers a given frame, then the object exists at that frame, otherwise not. You can think of it as combined visibility/rendering setting tied to frames. Maybe the term lifspan is misleading, since it can start and end as often as necessary. Maybe call it strips?
If that's true, then maybe you could just make the visible/hidden render button key-frameable.
It's quite importing to visualize it as durations. With just events (show/hide) things would be much harder to 'read'. Technicaly it's of course like keyframing with booleans.
If I understood it correctly the only thing I would change (except the timelines) is that not every object gets inserted into it's own layer. Make it more like layers in other programs. Whatever layer you're currently on is the layer that the object is inserted in. You can change it later if you want. That way you can make a new layer, and start adding objects to it. It makes it more like a layer manager, instead of a hierarchy manager.
I often put single objects into Blender's Layers, especialy early in a project. So I think it's good and well to initialy insert entries for new objects on the top level of the hierarchy.
It already came to my mind that directly inserting new objects in a group would be a good thing. It's only I don't know how to handle it selection wise. For the single object entries you have the same selected and active states like in 3d views. I think it should be possible to right-click everyything in the hierarchy for context menus (assuming always LMB for selection, another topic that might have to wait until Blender 3). Ther could be an independent active state, always on the last selected group, where new objects will be added.

It sure helps, thanks again!

jd-multi
Posts: 0
Joined: Thu Mar 13, 2003 11:29 pm

Post by jd-multi » Fri Feb 20, 2004 6:00 pm

thorwil: Well I can only post, great, awesome and so on, because I really tryed myself to learn c++ and how to code on blender, but I really don't understand what C++ does, how to code or anything else. If there where people that had online classes for this, I would join. At this moment I'm trying to learn python for making games in Blender. Well I know html, but that's all, I really tryed to learn, but sorry, I wish I could help guys. But I really could help, I also had joined one of the projects here to code on blender, because it's cool to see your ideas in blender, and so on. :)

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Fri Feb 20, 2004 6:30 pm

Well, jd-multi:
Allthough I have some basic understanding of object oriented programming, I'm only able to hack some simple scripting stuff, if you give me the time, since I'm not in training.

But why do you think you would need to be able to code for giving detailed feedback on the proposal, or for providing own ideas? Maybe some of the language I use sounds like programming, but it's all on the design, not the implementation side (and there is no implementation of this, all text and mockup, if that's still not clear).

I think one only needs a basic understanding of computing to work on such proposals, for not asking for things that would require pure magic ... but any additional knowledge sure helps.

Post Reply