Hi Michael,

I encountered a problem while shelling quite simple(?) object. Particular objects are in the attached file along with relevant information.

It seems that the edges in one of the object's corner are being messed up. I also separated the surfaces and tried to re-trimed them manually - but I couldn't make it clean at all.



Of course, there is another way how to get desired object, but I'd like to grasp the issue of failure of shelling.

Petr

Hi Petr, I've been looking at this and it is a little bit difficult to figure out.

But to start with I can give you a different way to diagnose what is happening.

There are 2 different styles of shelling - one is when you do it to a solid, and one is when you do it to something that is not closed. For the solid one the shell is the equivalent to an offset plus a boolean operation. The non-closed case is an offset combined with lofted/ruled surfaces between the open edges.

So sometimes you can look at just using offset as a way to diagnose what is going wrong. In this case, select everything except for the bottom face (invert after selecting the bottom), and do offset distance 5, and check "flip" (The default for shell is to go inward, for offset outward).



You can see the problem corner there. Also it is pretty subtle but if you look closely at the edges that I marked with red dots next to them, they look a little heavier than a normal edge, this is because they are naked edges not joined between the surfaces there.

Anyway the thing is that I'm not quite sure yet what the problem is. At first I thought it might be a bad intersection calculation between the 2 top surfaces because they are relatively close to being tangent, sometimes tangent intersections are difficult to calculate. But after going in there and trimming one to the other and looking at the result, that doesn't seem to be wrong.

So what I'm thinking now is that the proper result should actually look like the surfaces that are existing there - but the problem is that there are 2 vertex junctures in that area instead of only one. It seems like the offset mechanism thinks that there should only be a single common vertex point. So this might be an area that causes failure, single vertex branching into multiple vertices in the offset result.

After fussing around with extracting trim edges, trimming some of the ends off and untrimming and retrimming surfaces, I got this (model attached):




Which appears to be the correct result. So yeah I think the problem is the offseter getting confused and assuming the original vertex offsets to another common vertex which is not the case here, one portion diverges to another vertex in this location. I think...

Anyway, hopefully doing the offset method might give you some way to diagnose and repair shelling failures like this in the future.

- Michael

Oh yeah, and looking at the other versions that you had for instance after filleting, the error was still in that same location.

- Michael

I have fileted your last
Are these gaps normal due the different inclined surfaces?

> Are these gaps normal due the different inclined surfaces?

Yes, I believe so. But there should not be actual empty gaps, those areas should be filled in with smaller fillet surfaces.

This is because the top 2 surfaces are not tangent to one another, so that prevents the fillet from being able to run in one single smooth piece along those edges.

- Michael

Thanks for explanation and "repairation" ! -Petr

...one point of order :)

How do you feel about command that could remove unnecessary control points from underlying surfaces like Rhino's _ShrinkTrimmedSrf command? Sometimes it is hard to keep "neat" surfaces using all boolean powerful commands.

For example the button's upper part is composed of 325 control points in comparison with 160 points after shrinking surface in Rhino.



Petr

Hi Petr,

Re: ShrinkTrimmedSrf

Well, the difficult thing with stuff like this is not the command itself, but rather how to integrate it into the UI.

I don't have a particularly good spot to add sort of less frequently used things such as this right now.

So what I did is I added a new ShrinkTrimmedSrf command for the next beta, but there isn't any UI to activate it by default, to use it you'll have to set up a keyboard shortcut or put it on one of your custom menus.

- Michael

>>Well, the difficult thing with stuff like this is not the command itself,
>>but rather how to integrate it into the UI.

Yep, it is necessary for you to hold your respect as a carpenter... :) Something what we discussed in the past... measure twice, cut once...

On the other hand, it is very cheering that there are still commands which can be extended... for example Extend itself... hehe..

:) In the meantime I don't have any problem with adding "hidden" commands for stuff like this.

- Michael

>> After fussing around with extracting trim edges, trimming some of the ends off and untrimming and retrimming surfaces, I got this (model attached):

Hi Michael,

This reminds me of another post where you were talking about untrimming but I can't find it... Could you explain (again ?) what's "untrimming" and "retrimming". What is it useful for and how do you do that ? A bit confused as there's no "Untrim" command in MoI, right ?
Looks interesting as it seems it's a technique to detect or repair problematic surfaces.

Thanks

Schbeurd

Hi Bernard,

> This reminds me of another post where you were talking about untrimming but I can't find it...

Probably this object repair tutorial: http://moi3d.com/forum/index.php?webtag=MOI&msg=446.17
Or also this: http://moi3d.com/forum/index.php?webtag=MOI&msg=444.4


> Could you explain (again ?) what's "untrimming" and "retrimming".

Untrimming means removing the trim curves from a surface. Once trim curves are removed, the original surface (which is still there "underneath" all the trim curves) will be restored.

Then "retrimming" means just to trim (Edit/Trim) that large restored surface to a new set of fixed up curves.


> What is it useful for

It is useful for a couple of situations - sometimes you may want to kind of "erase" cuts that have been made on a surface because they weren't really in the desired place, as with that first tutorial above.

Another use is to clean up the messed-up results from operations that didn't do a proper job of things due to calculation bugs, like in the shell example in this thread. When you look at the corner there, the edges on the object are all a mess, pieces are sticking out where they shouldn't be, etc... To make a good quality object, messed up edges like that need to be repaired. This usually means to extract the existing trims as independent curves by Copy/Paste, then edit those curves (trim them with each other or whatever), and then erase trim curves on the surface and trim the surface with the fixed up curves.


> and how do you do that ? A bit confused as there's no "Untrim" command in MoI, right ?

It is built in to the "Delete" command - you can select trim edges and then hit Delete to remove them.

But there are a couple of restrictions - the edges to remove cannot be joined to other surfaces, select the object and do Edit/Separate if necessary.

Also to make it work you must select all the edges for an entire boundary loop. Surfaces can have one outside trimming boundary that trims away the exterior of the surface, and multiple interior boundaries that cut interior holes. Each boundary can be made up of multiple edges and to remove them you have to select all the edges for a boundary. For surfaces closed in one direction like a cylinder this also means the seam edge, it is part of the outer boundary loop.

If you just want to untrim everything on a surface, select one edge and do Ctrl+A / Select All, and then hit delete.

- Michael

<<Re: ShrinkTrimmedSrf

Well, the difficult thing with stuff like this is not the command itself, but rather how to integrate it into the UI.>>


Hi Michael,

First, I'd like to reiterate that I highly value and appreciate your primary goal
to keep MoI's UI, simple but highly effective and user-friendly.
It's one of the things that I find so innovative and appealing about MoI.

Having said that, I think that as designers new to NURBS gain
experience and see the potential for more sophisticated surfacing techniques,
and as more and more Rhino users finding themselves preferring to be in the MoI modeling
environment, we can anticipate a need for some of the less frequently used surface editing
tools that we're familiar with from Rhino such as ShrinkTrimmedSrf, " surface matching for tangency"
and probably several other features that you've invented or will invent, :-)

So what I'm trying to say is, the problem of where to put them, will call for a solution.
I use a few keyboard shortcuts in Rhino, but they're for tools that I use regularly...
I don't know about anyone else, but unless I see or frequently use a tool, I can forget it's there...
so if it doesn't have some kind of presence on the interface to remind me once in a while, I forget to use it.,
I find myself not even using aliases and tools that are exclusively keyboard activated..
If you want to keep MoI as an entry level CAD program and also have it be useful to more experienced users,
perhaps you can have a "basic" mode with the default workspace that looks and functions as the MoI we
are now familiar with, but then as new tools are developed and implemented you could add in the option
to turn on an "advanced mode" with tabs that would stay folded
up when not being used...or flyout menus for a 2nd tier of advanced tools, or like in Rhino, a pop-up middle
mouse button that you can customize with an assortment of tools on a floating toolbar that will
dock in place or else just stay open on a temporary basis.

Maybe even implement the option to turn on a very thin and unobtrusive top menu bar like Rhino has, for the advanced mode which
can be accessed with the mouse or by the keyboard? ex. (alt +F, then another letter for a particular function)
I don't know really.... everyone has their preferences and I'm just kind of thinking out loud, here. :-) The thing is, I really like the simplicity
of MoI's "look and feel" !

-Jesse

Hi Jesse,

> <....> .or flyout menus for a 2nd tier of advanced tools,

I'm thinking it will probably end up with something like this eventually, some kind of "Tools" popup menu where I can stick a bunch of less commonly used stuff without it making a big impact on the top level UI.

I've thought a little bit about having a "More..." button inside of some palettes that could be used for this.

It's a little clumsy but for tools that you don't need to access very frequently it is ok for them to be in a more clumsy location. It's the frequently used tools that have to remain more uncluttered and available at the very top level.

I'm not really leaning so much towards an Advanced UI / Basic UI switch, because even if you need to do some "Advanced" things it doesn't mean that you don't need to do a lot of more basic things more frequently anyway. So having less clutter is still really valuable even for "Advanced"...

But it will take a while to experiment with different ideas to come up with a good one. Usually I will have to make prototypes and try a few different ways before settling in on a good method. It is always surprising how much work it takes to make a "simple" UI for things.

- Michael

Hi Michael and Jesse,

Well, I am accustomed to having quite austere interface in Rhino and using aliases solely, but in MoI I have got used to calling commands by the big-big buttons and it seems very natural to me. ( I'd still be interested to get a way of defining more than one-letter shortcuts, though. )

I guess the size of button is the reason for natural workflow with UI since I can start moving a mouse cursor exactly towards the particular button/tab and click it with only cursory glance at the side pane. On the other hand, I have adapted Help menu for me by adding new command/script items like ScaleArray and so forth. But it appears to be too clumsy and I often chase after specific item for a while before picking the one. So menu ( without big-big icons :) is somehow uncomfortable to me...

•
I think the command palette - with proper header name - which would be collapsed on default and would collapse itself after clicking on a button inside it, could be reasonable for less commonly used commands. If there wasn't space enough in the side pane, other palletes would collapse/expand appropriatelly so layout of the side pane would look identically before/after using those commands.
•

Btw, from my point of view the File menu come under a group of less commonly used commands, but there is a list of recently used files so I guess it would be difficult to handle it in a different manner...

Petr

Hi Petr,

> I guess the size of button is the reason for natural workflow with UI since I
> can start moving a mouse cursor exactly towards the particular button/tab
> and click it with only cursory glance at the side pane.

Yup, the big button size is a key factor. They're not just big to make them easier to look at for beginners, but also for everyone, experts and beginners alike, to be able to more quickly utilize them.

This is described by Fitts' law: http://en.wikipedia.org/wiki/Fitts'_law

Originally I made those buttons big to help make it easier to click on them with a pen tablet, which is sort of a bit more shaky than a mouse since it is harder to hold perfectly still. But this is one of those areas where tuning something for better targeting with the tablet also helps out for targeting with the mouse as well. I've been lucky that pretty much all of the tablet-oriented design stuff has turned out to be mouse beneficial as well.

Teeny tiny buttons in UI is kind of a pet peeve of mine. Especially on some laptops that have high density screens, it is amazing how tiny many buttons on other applications are.


> I think the command palette - with proper header name - which would be collapsed
> on default and would collapse itself after clicking on a button inside it, could be
> reasonable for less commonly used commands.

That's definitely the plan for the future addition of entire groups of new functionality. Like dimensions and annotations will have a "Dim" palette that is collapsed by default.

But there is still a problem that stuff that is added to a palette has to be in some kind of a group that contains more than one thing in it. If there are a bunch of palettes that only have one or two things in it, then the palette headers aren't providing any real savings over having the buttons somewhere up at the top level.

Sometimes the biggest difficulty is finding a good grouping for stuff - for example ShrinkTrimmedSrf is difficult to place right now.


> If there wasn't space enough in the side pane, other palletes would
> collapse/expand appropriatelly so layout of the side pane would look
> identically before/after using those commands.

The collapsing part of this is implemented right now - you can see this if you shrink the window down (BTW I just found and fixed a bug where the mouse cursor doesn't switch to a sizing cursor when you are on the edge of a non-maximized window. But it still will still size right now if you grab there anyway despite what the cursor looks like) so that there isn't as much vertical room. Now when you activate a palette, other ones will collapse to try and make space and prevent the scroll bar from appearing.


I had thought a few times about making File be a tab on the side pane instead of a pop-up menu type thing, but yes the recent file list on it makes it pretty natural to have as a pop-up menu. It also just seems somehow natural to have as a menu because of similarity to "old fashioned" UI systems that have a menu bar.

- Michael

I haven't tried it. I would probably get a sore throat from talking all day long...

- Michael

Hi Michael,

>>This is described by Fitts' law: http://en.wikipedia.org/wiki/Fitts'_law

:)

>>The collapsing part of this is implemented right now - you can see [...] when you activate
>>a palette, other ones will collapse to try and make space and prevent the scroll bar from appearing.

Surely, I knew about it. But other part of described palette handling after clicking on button lying in the palette "marked as rarely used" is important part as well. It was a crucial thought of my previous reasoning. Now, palette handling can be characterized as self-expanding/other-collapsing. What I meant it was to make a things upside down (for less commonly used tabs/buttons) - i.e. self-collapsing/other-expanding_to_previous_state to restore it.

I really hope the scroll bar never appears to me... hehe... It would imply there is something wrong with UI - too many commands, palletes or something like this...



...see http://www.3designjewel.com/flash/discover/parametric/parametric_court.html


Petr