I like the first one because it looks like a stack of cards, one on top of the other.

In the second one the unopened cards seem a bit in mid air.

Maybe the "Yellow cross" when you pass over with the mouse should be "dark blue"?

Either one for me is fine, I see what Thomas and Marc were getting at, they do follow the overall MoI theme better.

Cheers

Hi Pilou,

> Maybe the "Yellow cross" when you pass over with
> the mouse should be "dark blue"?

It's kind of good to have a lot of contrast and a kind of "lighting up" feel for the mouse-over state, a dark color like that would not quite feel the same.

But if you'd like to change it on your local installation, you can edit this image in the \ui subfolder: TreePlusMinusBackground_highlighted.png

Replace the yellow areas of that image with dark blue instead, and then your installation will have dark blue when you mouse over the +/- controls in the scene browser.

- Michael

Thx

I like the first one personally. One refinement I would like to see here is when a tab is open to havew the tab "Blend with the data area. So the red line would become the line on the open tabs and the yellow would disappear.

After revisiting this post I just made I'm not sure how it would work like that. I suppose I would have to experiment with a "Fade", but with my original post I wasnt paying attention to the difference in colors of the tab and the data area.

Anyway.....I'm not proud.

Hi Burr, yeah that probably won't work since like you noticed the header has a different color background already.

But the idea to have a red outline is pretty interesting! Here is a version where I used your image as a source:



Definitely a unique look! ;) ;)

- Michael

Hi Michael, I kind of prefer the first one, seems more ordered and systematic.

I'm slowly beginning to assimilate all these new features, it's a whole new ball game now!
I done a 'globe valve' project and it was very handy to have this flexibility.

As mentioned previously by Danny, filleted and Boolean created faces should preserve original style of the objects.

Marc

What is exactly the finality of the Object system?
Just a great "selector" for easy use of complex objects or also something for manage them ("Copy" / "Move" / "Delete" etc...) inside the arborescence?

Hi Pilou,

> What is exactly the finality of the Object system?

The main goal is to make it easier to work on a more complex project that has many different pieces in it, by allowing certain basic functions like hide/show/isolate/select/deselect work on a predefined batch of objects.

But you still use it in combination with the regular tools, for example it is not meant to replace every single tool such as Move/Copy/Fillet, etc...

You can use it to more easily select objects that are used in those tools though, and really its overall main purpose is to make it easy to manage visibility so you can turn off different sets of objects quickly to make it easier to work one smaller area of a complex model at a time.

- Michael

Hi Michael,

sorry for getting back to you so late.

I think the new look fits MoIs overall style better.
I'm not sure about the divider line though. I think BurrMan is basically right: Normally if you use tabs, the opened tab has no dividerline towards the open area of the tab.
But I tried it out in Photoshop, and without the line the heading is pretty weak...

And somehow I am still missing consistency with the rest of the GUI (which I like a lot).
I'm not sure if you need to introduce new elements at all.

So I went to explore the existing elements some more in Photoshop...

First I created a header for the Scene Browser (without a + sign) that would be collapsible like the other toolboxes to be consistent there.
In this form it doesn't take much space when collapsed (see the top of the image below) and I think that one line doesn't take away too much screen estate while it helps the overall consistency. Also, you can collapse the Browser with one click, equal how many of the sub-tabs are open.

Then I took the existing idea that you use in the headers of all other toolboxes and played with them. They aren't exactly "tabs", but work very well for me as headers for the toolboxes.
Putting them completely inside the existing frame of the scene browser would create a doubleframe which would be a bit overdone, so I tried using the rounded corners "connected" to the outer frame directly and well - works for me and fits in pretty well with the rest of the GUI IMHO ;-)



No new elements needed, the headers are clearly visible and divide the groups very well while being light on the eye and no problems with the tab-divider-line.
I also wasn't too hot on the light blue header color (again more a consistency thing).

What do you think?

Best Regards!

Thomas

P.S. I think Pilou brings up an interesting point. Being able to create hierachies of named objects (move the parent and it will move the child as well) like it works in many other 3D tools could be helpful. Also having some basic "file-like operations" in the right mouse menu would be interesting (copy, paste, delete...).

Hi Thomas, thanks for the feedback!

> I'm not sure if you need to introduce new elements at all.

Well, those are some new controls that have some different behavior than previous elements. So having a look that is in the same general theme but slightly different is actually something I consider to be a positive thing - things that work a little differently but look exactly identical tends to cause problems. A lot of people will assume that things that look identical should behave in an identical fashion as well.

The main issue is when the browser is in "inside" mode, where the browser is another palette located inside the side pane with the other tools such as Construct, Draw curve, etc... In this mode, the browser sections are child elements inside of the "Scene browser" palette, and clicking on the "Scene browser" palette header hides or shows the entire browser palette, while clicking on one of those child sections only expands that sub-section.

If there was no "inside" mode, and only an "adjacent" mode, then I would have very likely have done it right along the lines of what you are showing.

But there is an "inside" mode to consider as well.


> First I created a header for the Scene Browser (without a + sign)
> that would be collapsible like the other toolboxes to be consistent
> there.

It looks like you are talking about a collapsible title for the "adjacent" mode there?

But what purpose would be served by collapsing that?

When collapsed you would then have a panel that was nothing but empty space inside of it, I don't really see what would be the gain from having that... If there is no purpose for something, it can be nice to just not have it - and there are actually benefits to having less UI, for example having that header means that there is not as much space for the actual browser items, there would be something like one less item able to be shown before getting a scroll bar.

In the future at some point I may be able to have some purpose to have a title section there, like 2 different panel options to switch between (like Browser / History), so it is something that may be good to add in the future, but only when it actually serves a useful purpose.

When in "inside" mode, there is a title there because it may be useful to collapse the browser there since it is sharing space in the side pane with other palettes in that mode.


> <..> works for me and fits in pretty well with the rest of the GUI IMHO ;-)

It does work well for the "adjacent" mode like you are showing - I'm pretty sure that if that was the only way, that I would like to set it up like that.

But with "inside" mode, having the child sections look the same as the parent one is not good - they look too much like they are siblings on some kind of equivalent level rather than the palette being the parent and the sections being children and distinct from the palette header.


> I also wasn't too hot on the light blue header color (again more
> a consistency thing).

Yup - again too much identical consistency between the parent header and the child sections in "inside" mode is a bad thing - that's the reason for the intentional difference there.


> Also having some basic "file-like operations" in the right
> mouse menu would be interesting (copy, paste, delete...).

Actually, right-click actions are already filled up - right-click on an eye will do an "isolate" where it shows only that item and hides others, right-click on a style swatch will set it as the active style, and right-click on an item's text will do an "isolate selection" which will select just that item and deselect others.

So making right-click put up a menu would mean sacrificing some of this other existing functionality.

But in the future I do want to make a drop-down menu, probably with a drop-down box that appears on the right-hand side of the item, which you would left-click to pop out.

That will probably be fine to put in a few frequently used operations on that menu, but I don't think that will be happen for v2 though, probably that one will have to wait for a bit longer.


Thanks very much for the ideas and the image tests!

- Michael

Hi Michael,

I didn't do this testing for a specific one of the two modes, since it should be the same for both IMO. I only used the adjacent mode to see the two designs side by side and to not have such a long screenshot. So yes, collapsing the title is actually only useful for inside mode (or if the panel would vanish and only leave the title when it's collapsed...).

I don't agree with you on the titles being too similar but thats just fine when talking abut design ideas ;-)
"they look too much like they are siblings on some kind of equivalent level" - that is what they are for me - "Scene Browser" just kinda groups them, but each section is independent and does something else. I would have the same feeling if you would group all the current "tools palettes" into one collapsible parent group.

I'm looking forward to what you come up with in the end!

Cheers,

Thomas

Hi Thomas,

> I didn't do this testing for a specific one of the two modes,
> since it should be the same for both IMO.

The actual browser control itself (which is made up of the sections: Groups, Objects, Types, Styles) should certainly be the same, and it is...

But the container that owns the control is a different issue - that is a separate thing from the control and does not necessarily need to be identical.

In the side pane where there are other palettes that work as containers, then the browser control should be nested inside of a palette container. For the "adjacent" mode where currently the whole panel is dedicated only to hold the browser and not any other palettes, there is no need to add in a "lone" palette container there, it would just not serve any useful purpose (not yet, anyway).

I mean really the whole reason to have more than one mode for the browser ("inside" versus "adjacent") is actually to have different container methods for it.


> "they look too much like they are siblings on some kind of
> equivalent level" - that is what they are for me

They literally are not siblings - when in "inside" mode, the palette header is at a higher level of the UI hierarchy and the scene browser control is nested within the palette body as a contained child element. Then clicking the palette header causes the entire browser control to be hidden or displayed - that's pretty clearly a parent/child relationship rather than a sibling relationship...


Anyway, I hope that explains some of the reasoning behind the design, and why some of the alternates that have been shown do not quite fit.


Also, if you end up not liking some of the particular colors for some reason, you will actually be able to edit the PNG files to suit your own personal taste if you want.


At any rate, for the next beta I've eliminated that "tail" part of the header UI that is in the current beta which seemed to be what was bothering you the most.


- Michael

Hi Michael, is it me or I can no longer use Object Snap if the object is covered by another object? Is there a way around it?

Hi Val -

> Hi Michael, is it me or I can no longer use Object Snap
> if the object is covered by another object? Is there a
> way around it?

Do you have the hidden line display enabled or disabled? In v2 check under the View tab here:



It is one of the new features in v2 that when hidden lines are disabled, hidden object snaps are also suppressed. Some details on that here:
http://moi3d.com/forum/display.php?webtag=MOI&msg=1621.35

But if you have hidden-lines enabled, then osnaps should be working on them - if you do have it enabled, make sure that Object Snap is not disabled itself (it should be highlighted in orange in the bottom toolbar when it is on), and you might want to check the object snap menu (the arrow that pops up when you move your mouse over the object snap button) to make sure that you haven't turned off all the individual types of snaps.

Otherwise, if you are having a problem with a particular model, could you please post it or e-mail it to me at moi@moi3d.com ?

- Michael

Sweet, thanks Michael!

I finally cought the bug I talked about before, but it happened a little differently than I described. It was a union between the two cylinders on the sides and the one that has holes.

Working on this project I found it difficult to readjust the angles on the device. It would be nice to have some simple rigging tools. Like one parts rotates the other moves with it but is kept with respect to x direction, etc..

Hi Val, thanks for reporting the problem!

It does look like it is probably a bug, but I'm not sure if there is much possibility to get a good result from that exact situation.

If you hide these 2 pieces here:



You can see that the center part is not a solid, it is an open surface:



If you actually select that open surface and run Construct / Planar to cap it off to be a solid, then you can get a proper union between it and the other piece like this:



When it is an open solid, the union is basically creating a sort of "squished together" slit in the objects rather than being able to separate them into different volumes.

In general the booleans are oriented mostly around working with volumes, so you may get some slightly unpredictable behavior similar to this when doing volume operations on non-closed objects that do not define a full volume.

If you solidify that open object first, you can avoid this problem.


> It would be nice to have some simple rigging tools. Like one parts rotates the
> other moves with it but is kept with respect to x direction, etc..

Unfortunately a rigging system is pretty difficult to add, even a simple one would require a substantial amount of UI - it is really something that is normally part of an animation system. The amount of work involved will probably make it prohibitively expensive to get that into MoI anytime soon I'm afraid...

- Michael

While it's obviously no easier, the ability to add constraints would probably work for what most people are looking for there, given the nature of parts designed in MoI. That said, with all of the new geometric intercepts, you're most of the way there. Possible, you could leverage the new style and group system -- pull up an object in there, get a list of all of its existing geometric relationships, and tell the system to enforce some of them. If you added a way to have construction planes, lines, and points stick around more, that would get you most of the rest; you could even do distance bounding constraints as being between two points on a cline. There'd still be some things that wouldn't cover, of course -- relative size constraints, for instance, although most of those cases could probably be handled by showing a list of the other constraints the current constraint could establish a relationship with.

That said, yes, big, big chunk of work, and probably a v4+ thing, I'm sure, but I'm another person who would love it, especially coupled with API additions aimed at making generative shape creation easier.