Hi Michael,

Would it make any sense to adapt the various fillet radius mechanism to the chamfer command ?
'use 2 distances' option will probably be not possible anymore in that scenario.

It's kinda easy to do it 'by hand' for the moment by replacing the fillet surface by a loft, but it will make the process as step faster (especially when side surfaces need to be re-trimmed or rebuild, like the cyan one in my example).

I'm doing lots of low-res assets in MoI for the moment, and I'm trying to avoid fillets as much a possible to keep polycount very low at export. So I rely mostly on chamfers, and various chamfer radius gives often interesting shape result.

It's an ultra low importance feature request of course ;)

Hi Pascal - yes it was the "use 2 distances" mode that made me a bit unsure of how to integrate the variable radius into chamfering.

What would you think should happen if you for example start out and set up 2 chamfer distances and then go to add new distance values at spots along the edges, should it just switch out of 2-distance mode back into single distance mode and turn the 2-distance UI off ?

- Michael

Hi Michael,

// What would you think should happen if you for example start out and set up 2 chamfer distances and then go to add new distance values at spots along the edges, should it just switch out of 2-distance mode back into single distance mode and turn the 2-distance UI off ?

Yes something like that.

Activate 'use 2 distance' will disable any chamfer point set.
Desactivate 'use 2 distances' will remove the 2nd distance option and activate the chamfer point set.

Would also be great if while the command is active, input data are preserve, so you can switch between a variable distance set or 2 distances without loosing any input data. So it prevent loosing set by miss clicking on 'use 2 distance'.

For the moment it's not working that way. If I 'use 2 distances', the second value will be reset if I disable and reactivate the option.
(but they are probably reason for that).

I have to say I don't like that much when options in the ui vanish, especially when the ui is dynamically resized.
For example if you switch 'use 2 distances' on and off, the toggle button is moving up and down.
Have you ever considering to use a 'gray out' mechanism, when all the options are in place in the UI, but only available under certain condition ?

Here for example a quick test of how the input command will look like :



I'm pretty sure you do already think about it, and you probably want to reduce ui flooding.

Hi Pascal,

> Would also be great if while the command is active, input data are preserve, so
> you can switch between a variable distance set or 2 distances without loosing
> any input data. So it prevent loosing set by miss clicking on 'use 2 distance'.

Things like this tend to add to the complexity of implementing it... Once things get interdependent modes that are switched on or off with remembered states it tends to add up to a fair amount of code to make that all happen. Then the real problem is that it is often a place where there can be bugs because of it being a bit difficult to test every single mode switch combination. So that's one reason why I have a tendency to shy away from things like that.


> For the moment it's not working that way. If I 'use 2 distances', the second value
> will be reset if I disable and reactivate the option.
> (but they are probably reason for that).

The only reason is that it would take extra work and therefore extra code in order to make that happen. Extra code = more possibility for bugs.


> I have to say I don't like that much when options in the ui vanish, especially when the ui is
> dynamically resized.
> For example if you switch 'use 2 distances' on and off, the toggle button is moving up and down.
> Have you ever considering to use a 'gray out' mechanism, when all the options are in place in the
> UI, but only available under certain condition ?

There isn't much space in the UI to hold command options, so I tend to lean towards hiding things when there is something like a checkbox that is clicked to enable or disable the condition where it's used.

But I do use 'gray out' in some other situations, like in the View > Image command buttons for Remove/Align/Hide/Properties are grayed out until you add in an image.

So that's possible, but I tend to try to use hiding instead when it is feasible.


> Here for example a quick test of how the input command will look like :

The negative aspect of that is that now someone who never uses the 2 distances option is now presented with more stuff on the screen that doesn't have any relevance to what they're trying to do at that moment. You might think "ok, so what?" :) but it all adds up. More stuff on screen = more clutter, more clutter = more visual overload, more visual overload = more difficult to find what they need right then.

This focus on trying to reduce screen clutter is kind of a general overall philosophy with MoI - I'm always looking for opportunities to reduce what's showing on screen and one big general strategy for that is to try and hide stuff by default and only show it when it's relevant or activated for some special and not often used situation...

- Michael

couldn't there be a chamfer set for the 2 distances also? just like single, but 2 now. Or even choosing which of the 2 values to "add a chamfer set" to, with a little + sign....

Hi Burr,

> couldn't there be a chamfer set for the 2 distances also?

Unfortunately no it would not be possible currently - the geometry library only has a fillet rail generator for variable radius fillets for one changing radius value, not for having a separate changing value for each of the 2 adjacent surfaces like the "Use 2 distances" chamfer needs to use.

- Michael