Hi Ed,

> Are the Object Names and Styles functions locked down
> such that assignments made today will still function in
> future releases?

That's the current plan... I am intending to preserve those assignments in future releases.

But I am still gathering feedback on how all this stuff works, so I can't quite say that it is guaranteed 100% locked down quite yet.


> Also, will OBJ export get modified to recognize Styles first?
> Or will all the grouping functions need to be implemented
> before export is tackled?

Not quite sure of the exact sequence yet, but I'm actually hoping to get both of these things running for the next beta.

- Michael

Thanks Michael,

Looking forward to the export handling of "styles".

I have a project to be rendered in Hypershot and I'm trying to avoid assigning materials individually in HS to over 100 tiny surfaces (export from MoI using separateobj.exe). So even a partial implementation of obj export would be welcomed :)

Ed

Hi Thomas and Marc - I've finally got a chance to tweak the section headers a bit more, this is what I currently have:






That's removing the "tail" part and using a dividing line like Marc was showing previously.

Do you think that is a better way to do it?


Another possibility is to only have the divider line on open sections, it kind of keeps collapsed ones slightly less busy, which looks like this:




- Michael

NYCE!

I like the 2nd one - the divider lines only on the open section.

-Will

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?