I would vote for something similar to the very first post (and similar to the scene tree in C4d).
I also like the idea of a "scene tree" button to collapse the panel if you don't need it.

This would be quite clear to use for anyone coming from many Cad or 3d soft. backgrounds, but also for novices.


Please don't do cryptic buttons à la Lightwave, one of Moi's strengths so far has been its clarity.


One thing related to the scene management: it would be important to be able to export each group as a seperate group or object,
and to be able to read imported 3dm objects correctly grouped, per material or per layers.


Also it would be good to have a command to lock a layer, to make it visible but not selectable,
and an option to turn on\off snapping to locked layers.

C4d would be interesting to look at in my opinion.
To me it has by far the best scene management concept.

It has a scene tree and a distinct layer manager. It may be worth looking into.

Also, a nice feature it has in the scene tree, is that it allows you to 'paint' layer information from one object to any other object near it in the scene tree.
Very quick way to change attributes (hard to describe).

Hi Okapi,

I don't really understand what you mean by 'cryptic', that's said I never said to replace MoI interface by an lightwave one ...

>> Also it would be good to have a command to lock a layer, to make it visible but not selectable,
and an option to turn on\off snapping to locked layers

Well that's the point I'm talking about, but I would love to be able to lock/unlock/hide layers without having to scroll into a tree that takes half part of my screen. That's why I showed the tiny lightwave layer system.

Hi PaQ,

> Here's the horrible lw interface :P ... on the upper right corner you have the layer system ... it's really small, but it allows all what I'm talking about.

Just wondering in that layer system how do you know what part is under what little square ?

.

Here is a little more to throw on the fire. I see both sides of the lightwave layer scheme. It's very accessible but it's also not obvious what is in their just by looking at it.



I use C4D and tags can quickly add up and C4D has a ton of them. If you limit you're scope of tags maybe this would be good otherwise you can end up with ten tags for and object quickly.

Hi Danny,

As Grendel said, you don't really know what's behind a layer until you click on it.
In practice it's not a huge problem, as you remind the structure automatically in fact, as far as you don't play with more than 10 layers of course.

Now the more I think about it, the more this system looks probably a little bit 'old school'. As I'm so used to it, I probably don't have a good overview of the weakness ... the main one is that you limit yourself to a couple of layers.

The simon example is quite cool, the tree looks good and you have a good overview of the structure because every part are correctly named.
The problem, for unorganized people like me, is that most of the time I finish with a tree like the cinema 4D image, where only one or 2 objects are correctly renamed, and all the other layers are 'untitled'. So if I still have to pick layers one by one until I find the one I want to lock, hide, or show :(

I did not that that you implied it should be replaced.

By cryptic, I mean that you have no clue what those small buttons do intuitively.
Also, a classic shader tree has the advantage that you can nest objects in one another to create hierarchies.
True the LW layer system has the advantage of being very compact.
Modo's is nice in that it offers both systems, depending on how small you make the shader tree, it transforms automatically into a system that is close to the LW one, or something in between.

Yeah, I like the system Grendel mentions it's close to most CAD packages assembly tree layout, but then I like PaQ's idea about the quick access on/off/hide system.

So that last graphic you have there Grendel is the best of both worlds, which is cool, but, the size of that tree is a bit big, I thought anyway.

So I stared at MoI for a while and had this in mind, so I thought I'd throw it out here for discussion.
It was quick so I might of missed something.

It functions like the OSnap except it has 3 clicks for the tick, which are ✓ for normal operation X for Non Selectable and blank for hide and the rest is self explanatory.



~Danny~

Here a couple of screenshots of the C4d system.
What is nice are the amount of options, since you can switch between the normal,
hierarchical tree, to a tree organized by layer, or an alphabetical list, to name a few.

The search option is also really good, as it filters out automatically as you are typing.

Dantas I like the look of yours as well, but I think it looks good now because you have a small amount of objects where you may not need a tree anyway. If you have an scene with 80 different components it is then the same size as what I had. I do like that it looks simple and in keeping with tht UI overall but when it pops up it will be in the middle of the workspace I think instead of off to the side so it may obstruct viewing.

Hi Danny...

I like you idea that keep moi in simple ui. But for the position of this new stuff I prefer the idea by Grendel, so put on the right, not bottom. Just my opinion. Lets wait also for Michael idea and wish he can post some image someday.

Edit : As I know, Michael also want to put "object editing" inside the object organization. So when pick a circle, we can resize by type new value for the radius or diameter. Michael, please tell us if my explanation not correct.


-Cheers

Dany's idea to have a System Object (orange button bottom)can be cool
Only visible objects in the view will be display

But why not make the same for all views? So put here the tree icon ;)

But manage all that is not a task of programming? (only visible objects)

I did'nt know if he was intending on placing object history in the tree or leaving it under the little clock icon.

Hi Anis, you wrote:

> Edit : As I know, Michael also want to put "object editing" inside
> the object organization. So when pick a circle, we can resize by
> type new value for the radius or diameter.


And Grendel wrote:
> I did'nt know if he was intending on placing object history in the
> tree or leaving it under the little clock icon.

Actually, I would like to remove that little clock icon from the Edit palette and instead have history options for an object be part of the object properties panel.

The object properties panel would be something that would show up in this area:



It would be active when you are in selection mode - I mean in the mode before you have starting to run any command.

The idea is that the properties for the currently selected object or objects would be displayed there, probably by default it will show only a small amount of info like the type of object, its name, and color, and then have some way to expand it into different sections, like shape properties (endpoints of a line, center and radius of a circle), bounding box size (see and/or edit an object's size by its bounding box dimensions), and probably a bunch of "advanced" properties...

This panel would be something that was always available even when the browser tree thing was closed, it would show up in that currently empty area.

- Michael

I like that Michael, it would keep the tree functions to a minimum and that space is empty during selection anyway so two birds with one stone.

Hi Grendel,

> that space is empty during selection anyway so two birds with one stone.

Yeah, it will be good way to reuse that space I think. The main problem is that there is not a whole lot of room there, so it has to be kind of sparse by default but have ways to optionally expand to get at more stuff...

- Michael

Definitely a lot of great ideas in here, keep on posting stuff!

Just a note - I think that probably the initial focus for this will need to be for handling a larger quantity of items.

I'd definitely like to have an optional way for it to be used in a smaller panel, there are many options for this like a pop-up or entry on the bottom toolbar as shown above, also another idea is to have it as an item on a tab on the side pane similar to "Construct", "Transform", etc...

But I think that lightweight option will have to come later, once a more comprehensive mechanism is available first.

- Michael

My 2 cents would be to utilize the most minimal layer/object manager within MoI's CommandProc, and have it read and write a "seperate" xml data file linked to objects. This could have a "Customizeable" tag/hierarchy system managed by the user. I could keep it simple or make it as robust as I want. I suppose the downfall would be that it's not compatable with "Other" higher end packages and these Moi Tags would be proprietary to MoI (At first, Down the road third party can easily manipulate the xml data)



Kind of a "Seperate" script with access to the objects and linking capabilities through the layer manager implemented in MoI.

Hi Burr - interesting idea... If you wanted to send a file to another person, would that mean that you would have to send both an .xml and a .3dm file to them in order for them to get layer data?

Data transfer to other machines tends to be the problem area with this kind of scheme...

- Michael

>>interesting idea... If you wanted to send a file to another person, would that mean that you would have to send both an .xml and a .3dm file to them in order for them to get layer data?


I suppose. It does get bloated when you bring all the stuff in. The MoI "Assembly Exporter" could automatically "zipp" the required stuff if needing to share all the "added features" with others. The zip file could have a proprietary extension that then needs never be unzipped, MoI's "Assembly Importer" unzips the 2 files uses them, anytime an assembly is closed, it's just zipped up again. Something only utilized by those that require it. A "Moi.assm" file if you will.

It could get bloated when considering all the possibilities. I would think this could also be a third party tool if later MoI could expose the "Objects" through some kind of SDK. This could open the door (down the road) to incorporate database feature based modeling and have MoI be "third partied" into a full featured high end assembly package.

Seems for the common man, and probably your main target, alot of this kind of stuff is not considered or desired, but you have such a great product, your attracting Solidworks/nx users who want/can utilize the heavy stuff.

It could just be understood that if this is used in the process, there are some steps that have to be adhered to. (the whole reason opposite of your vision of MoI! :) but satisfying your high end clients.)

Again, it's just 2 cents from the peanut gallery!

Burr