Hi Felix, thanks for reporting these problems.

> It kind of freezes after the first key stroke, some times
> it unfreeze after pressing "esc"

This one sounds odd - do you possibly have any shortcut keys assigned to the characters that you are typing in? Maybe your shortcuts are being launched in addition to your typing or something like that.


> I also notice that some times the dimension shown (under
> style) are different then those shown when I try to edit them.
> The Z value is often the one showing different values.

That's not unusual - the values that are displayed on the top level are approximations that are taken from the render mesh. When you pop open the menu a much more extensive analytic bounding calculation is done to get really accurate information.

That size information is changing all the time every time you do a selection so it would not really be feasible to do the more intensive calculation so frequently, otherwise it could end up slowing down just getting things selected.


> Another little thing I noticed when I want to create an ellipse
> using manual entries. I write the width, then press tab to get
> to height, write the value I want and press enter nothing
> happens until I click twice in the viewport.

That's also normal - an ellipse that you draw can have any orientation and so it takes one click to set its x axis direction and then a second click to set its y axis direction (which could be picked vertically or something like that in one of the other views if you wanted).


> While entering values manually for rectangle and boxes
> for example and pressing enter draw the shape immediatly.

Actually no that's not correct - doing the rectangle "3pt" variation does the same thing because it allows you to specify the orientation of the rectangle in the same way that ellipse allows you to specify the orientation of the ellipse. The other 2 varieties of rectangle commands only make axis-aligned rectangles and so yes those behave differently from ellipse.


> When any edit box is present on the screen is there a key
> to get to the edit box at the bottom? Other then having to
> click on it, when I'd like to enter stuff there like say the
> angle or whatever.

If the current command has edit fields in them, then pushing tab or typing will target those edit fields and in that situation there is not any built in shortcut for putting focus onto the bottom edit fields for the x/y/z , distance, and angle values. I've been thinking of making Ctrl+Tab work for that, would that work ok for that purpose?

- Michael

Hi Felix, thanks for reporting these problems.

> It kind of freezes after the first key stroke, some times
> it unfreeze after pressing "esc"

This one sounds odd - do you possibly have any shortcut keys assigned to the characters that you are typing in? Maybe your shortcuts are being launched in addition to your typing or something like that.

I don't think so, I haven't assign any shortcut using any NUMPAD key including (+-*/.)


> I also notice that some times the dimension shown (under
> style) are different then those shown when I try to edit them.
> The Z value is often the one showing different values.

That's not unusual - the values that are displayed on the top level are approximations that are taken from the render mesh. When you pop open the menu a much more extensive analytic bounding calculation is done to get really accurate information.

I can understand a small difference (3 or 4th decimal place) but some times I have as much as 2 or 3 time the value shown in the top level values. Often it's simply the wrong value, nothing to do with the actual value.

That size information is changing all the time every time you do a selection so it would not really be feasible to do the more intensive calculation so frequently, otherwise it could end up slowing down just getting things selected.

That understandable and probaly the only way it could be done. It's unfortunate I don't have a screen capture program, you would be surprised with what I get sometimes. (Would you happen to know a cheap or even a free one)


> Another little thing I noticed when I want to create an ellipse
> using manual entries. I write the width, then press tab to get
> to height, write the value I want and press enter nothing
> happens until I click twice in the viewport.

That's also normal - an ellipse that you draw can have any orientation and so it takes one click to set its x axis direction and then a second click to set its y axis direction (which could be picked vertically or something like that in one of the other views if you wanted).

I understand but I wonder if it should not be the same behaviour as for a rectangle, that to may need to be rotated sometime. Most of the time I ear you say Moi already have a command to rotate thing around and that it would create a more complex UI or something pretty close to that. I see below is the explanation, the center point option is consistant amougn similar center point command, Ok!


> While entering values manually for rectangle and boxes
> for example and pressing enter draw the shape immediatly.

Actually no that's not correct - doing the rectangle "3pt" variation does the same thing because it allows you to specify the orientation of the rectangle in the same way that ellipse allows you to specify the orientation of the ellipse. The other 2 varieties of rectangle commands only make axis-aligned rectangles and so yes those behave differently from ellipse.


> When any edit box is present on the screen is there a key
> to get to the edit box at the bottom? Other then having to
> click on it, when I'd like to enter stuff there like say the
> angle or whatever.

If the current command has edit fields in them, then pushing tab or typing will target those edit fields and in that situation there is not any built in shortcut for putting focus onto the bottom edit fields for the x/y/z , distance, and angle values. I've been thinking of making Ctrl+Tab work for that, would that work ok for that purpose?

I was thinking of the exact same thing (Ctrl+Tab) and of course it would be fine with me.

Thanks,
Felix

Hi Felix,

> That understandable and probaly the only way it could be
> done. It's unfortunate I don't have a screen capture
> program, you would be surprised with what I get
> sometimes. (Would you happen to know a cheap or
> even a free one)

There's actually one built into Windows - if you push the "Print Screen" key on your keyboard (it may be abbreviated like mine for instance says "Prt Sc") it will take a snapshot of the screen and put it onto the clipboard and then you can paste it into any image processing program, including the built in Windows paint program (pbrush.exe) and then save it to an image file from there.

I think the free program IrfanView (http://www.irfanview.com/) also has some screenshot stuff in it as well, see:
http://www.tombraiderforums.com/showthread.php?t=64487


> I can understand a small difference (3 or 4th decimal place)
> but some times I have as much as 2 or 3 time the value
> shown in the top level values. Often it's simply the wrong
> value, nothing to do with the actual value.

That does sound weird, can you please send me a 3DM file with the object in it that behaves like that so I can test it over here and see if there are any bugs to fix there?


> I understand but I wonder if it should not be the same
> behaviour as for a rectangle, that to may need to be rotated
> sometime.

It's more to maintain consistency with how the ellipse command works with point inputs given rather than width/height given. When you draw an ellipse with the mouse it behaves in this same way where the first point that you pick gives the x axis direction and also the width, and the second point picked gives the y axis direction and also the height.

So if you have entered in width and height separately it basically constrains those values but you still pick points in the same workflow as the regular "draw by points" method to specify orientation in the same way.

Since there is already an orientation mechanism built into ellipse for handling it by clicking points with the mouse, it would maybe be more weird for entering in width and height values to then behave very differently from that.

- Michael

Hi Felix, also for the size field - are you using coordinates that have a lot of decimal places in them, such as values like 0.00002 or things similar to that?

That display is also constrained to need to fit on a single line in the UI and so it will truncate the number of decimal places that it uses for each value, maybe that has something to do with what you are seeing there as well.

Right now it may truncate them more than is really needed, it's on my list of stuff to work on to try and optimize that a little bit more.

- Michael

Hi Felix, so for the ellipse just run it one time and instead of entering in a width and a height just use the mouse instead - that way you'll see the behavior with how the x axis and y axis are specified right in the drawing tool. When you enter in a width and a height basically that just adds constraints but doesn't alter the workflow of the command, it still takes 3 points to be input and uses them for orientation.

- Michael

Michael,

>That does sound weird, can you please send me a 3DM file with the object in it that behaves like that so I can test it over here and see if there are any bugs to fix there?

As soon as I notice it again, probably tomorrow though.

-Felix

Michael,

>are you using coordinates that have a lot of decimal places in them, such as values like 0.00002 or things similar to that?

I use 4 digits after the point and most of the time I can see all of them for each x/y/z values.

-Felix

Hi Michael,

I've tried the 2 point ellipse and it behave just like the 2 point rectangle command for manual entries of course. I also tried the center point rectangle and it work for manual entries just the 2 points rect and ellipse. What can I say, I'm an old bear and I'm always expecting the (center, point, point) ellipse to work the same as related rect command. Just forget I mentioned it for nieth time.

Regards,
Felix

Hi Felix, yup the ellipse corners command (the third one in the ellipse command set) only picks 2 points and makes an axis aligned ellipse.

But the ellipse from center point has 3 picks in it, not 2 picks like the rectangle center command has.

So basically since it has 3 picks in it it behaves similar to the rectangle 3 points command.

If you use either the ellipse from center point, or the rectangle by 3 points command you should see that they both use 3 picks and they both behave similarly where the first pick makes some base point, the second pick makes an x axis direction, and the third pick makes a y axis direction.

So 3 picks for ellipse behaves the same as 3 picks for rectangle, I guess I don't see how that's odd...

The button icons show a little circle point there for how many picks each command are going to take, notice how the ellipse center command has 3 dots in it? That means it uses 3 picks.

If the ellipse command did not use 3 picks then you would instead be picking a kind of corner frame for the ellipse, and that's somewhat slightly odd for an ellipse since there is no portion of the curve that actually goes through the corner. That's why the first 2 ellipse commands are more focused on picking a major and minor axis point since those are actually points that the ellipse goes through.

- Michael

Michael,

here is an example of what I was saying about the dimension not being right and by far.







What's odd for me is when I enter the size manually and press enter, with the rectangle command, it draws it immediatly and when I do the same with the ellipse cmd, I also have to click a couple of times before the ellipse is drawn.

Thanks,
Felix

Hi Felix..

you could use ELLIPSE - CORNERS for a RECT-like workflow.




+ Marco

Marco,

I could do that of course but my point was basically that the behaviour of many "shape" commands is different on pressing the "enter" key using manual entries. Some will draw the shape immediatly and some need extra point(s) entered with the mouse. It's not the end of world of course but I thought it would be more consistent if the behaviour was the same.

Regards,
Felix

Hi Felix,

> here is an example of what I was saying about the dimension
> not being right and by far.

Can you please send me the 3DM model file that was used to get those dimensions?

Then I'd be able to test it over here and see what's going on with that.

If you need to keep the file private, please send it to me through e-mail at moi@moi3d.com .


> What's odd for me is when I enter the size manually and press
> enter, with the rectangle command, it draws it immediatly <...>

It depends on which rectangle command you are using. The rectangle 3pt command, the one here:



does not behave like you are describing - when you enter in a width and height for the rectangle 3 point command it still waits for you to enter click points to define the x and y axis directions for the rectangle.

Out of the rectangle commands, the rectangle 3 point command is the one that is most similar to the ellipse command, since they both take 3 points as inputs and they both deal with drawing an oriented shape instead of only an axis-aligned shape.

If you give both the rectangle 3 pt and the ellipse command a try you should see that they behave very similarly with the same workflow and steps between them.

The key difference between the other 2 rectangle commands (the rectangle from center and by corners commands) is that they only take 2 picks to completely finish the command. Since those commands generate an axis aligned rectangle only, they have enough information to finish when you have entered in 1 point and then a width and a height. Since the ellipse from center point command is not restricted to only make axis-aligned ellipses, it does not yet have enough information to finish when you have entered in only the width and the height.

So yes, those 2 rectangle commands behave differently than the ellipse command - that's expected since those ones take 2 picks to finish and are axis-aligned and the ellipse command takes 3 picks to finish and is not restricted to being axis-aligned. This does not mean that there is no similarity between how rectangles behave and how the ellipse command behaves though, as I mentioned previously the ellipse command behaves exactly the same as the other rectangle 3 point command.


> and when I do the same with the ellipse cmd, I also have
> to click a couple of times before the ellipse is drawn.

Yes - but notice that with each of those clicks you are defining the orientation of the ellipse, so you're handling the placement of it directly in the command. It behaves the same as the rectangle 3 point command.


In general it's part of MoI's overall drawing strategy that you should be able to draw the thing you want directly in the place that you want it - that's why all the various drawing commands allow you to specify all those things like width and height and radius and what-not. For example when you draw a sphere you are able to place the center point and then the radius to create a sphere of the size you want right off the bat instead of doing something like plopping in a "default" sphere into the origin and then doing an extra step to move and also size it, which is how some programs actually work.

Some commands include orientation as part of that, like rectangle 3 point or ellipse.


In the future it could be possible for me to make a plug-in command for you that would make an ellipse from center point that was forced to be axis-aligned and would then behave like you want, but it's not a bug in the current ellipse command that you pick 2 more times to finish the command - you are specifying orientation in those picks and that's an intentional part of how the regular command is set up to work.

- Michael

Hi Felix,

> Some will draw the shape immediatly and some need extra
> point(s) entered with the mouse. It's not the end of world
> of course but I thought it would be more consistent if the
> behaviour was the same.

That's correct, but the source of the inconsistency is that some commands are restricted to either only create an axis-aligned shape, or the alignment is uniform like with a circle (and thus more simplified).

So with those particular commands there can be fewer steps involved in the particular command.

Some other commands though incorporate the orientation of the shape directly into the drawing command itself and those ones can require another pick to define the orientation.

Often times there are a couple of different varieties of commands to have some in each of these flavors - that's the case for both rectangle and ellipse as well.

For rectangle the first 2 commands (by corner and by center point) make axis aligned shapes. If you want an axis aligned shape then those are the most convenient to use. But there's also a 3rd variety of rectangle command rectangle by 3 points which allows you to define the orientation of the rectangle right in the command. If you want to create a rectangle at a specific orientation that one can be more convenient to use since it allows you to create it directly where you want it without doing any extra repositioning steps later.

For ellipses, the first 2 ellipse commands incorporate orientation into the commands, while the 3rd ellipse command (the by corners one) makes an axis-aligned restricted one and so that last one requires fewer picks.

These differences between the drawing commands is an intentional part of the workflow design so that you have an overall more flexible toolbox of drawing commands at your disposal so that you can sometimes use simple axis-aligned tools for more efficiency and lower number of picks for basic stuff but you still have some other tools to do more advanced "in place" drawing available as well.

This kind of flexibility and variety is a good thing, I'd hate to lose that type of functionality just in the name of forcing absolute conformity. It's not bad to have uniform behavior in general but there are times when variety is useful too so it's a balance and it is not a goal to have 100% conformity at all costs or 100% variety either.

Hope this helps explain the overall design rationale better!

- Michael

Basically what it comes down to is that if I were to make the Ellipse command end after you had picked the first point and then entered in a width and height, the only way to do that is to make an axis-aligned ellipse.

If I did that, then the behavior would become inconsistent with the rectangle 3 point workflow.

Right now it's not like the Ellipse command is inconsistent with everything else - it behaves the same way as the rectangle 3 point command that deals with drawing an oriented rectangle.

- Michael

an awesome printscreen program that is free is gadwin http://gadwin.com/download/
Hit the prt sc button drag a box with the mouse and save to file / folder and or printer and or to clip board and to email, you can even change the destination between capture and save.
Save as jpg gif or even as a tiff
Its very good
cheers
shayne