Hi Brian, thanks for posting the file!

Are there any particular steps that I should follow to see the problem?

Over here it seems to work as expected if I select those objects and change the z value, it works like this:




Are you seeing something different than that?

- Michael

Thanks, Michael. That CPlane script works fine.

--Lewis

Hi Lewis,

You wrote:
> But I would also like to see the ability to set new
> construction planes and save them,

This is definitely in the cards, but probably not until after I get the "scene tree browser" type thing working.

I think that browser panel (discussed some in this other thread) will be a kind of "one stop shopping" area for listed / named entities of various sorts, and if it works out how I'm kind of thinking it would probably be best to list things like saved cplanes there rather than trying to make a special UI for managing the list of them.

One other thing that you may be interested in, is that MoI v2 has some functions to be able to draw directly on to any planar surface using it as a temporary construction plane. The nice thing about that is that it kicks in if you just click your points on the surface while in the 3D view, you don't have to do any extra cplane setup/restore/etc... steps. So that may help reduce the need to set a cplane for some common situations. Some examples on that here:

http://moi3d.com/forum/index.php?webtag=MOI&msg=1621.1
http://moi3d.com/forum/index.php?webtag=MOI&msg=1621.21
http://moi3d.com/forum/index.php?webtag=MOI&msg=1621.27

- Michael

Michael

HopeI can explain this.
In the first instance, I did a sellection of all the items.
Then I did the Z make smaller.
That was fine, except, it left a separate, copy (well, actually the original?), unsized, of the wiggly bit,---- where it was originally!

As I said it is not a problem as I can delete this "copy" bit---it was just that the "oddity" seemed worthwhile reporting.

Tis a strange world!

Brian

Hi Brian, I think I understand - the file you posted is the result of _after_ the problem occured?

Unfortunately what really helps me is to see the file _before_ the problem, so that I can try to repeat the steps over here and watch the problem actually happen directly rather than just seeing the aftermath... :)

So if you happen to notice something weird, it can be a big help if you undo, and then save. That way there is more of a chance that the problem can be repeated. Sometimes it is tough to remember that, but if that is possible it is easier for me to debug.

- Michael

Hi Pilou,

> Trivial question :)
> When I name
> Sphere = ob1
> Cube = ob2
> Selection ob1 + ob2 and name it = ob3

Just to clarify - when you select multiple objects and set the name, you are not creating a group, it is doing the same thing as if you selected each object individually and assigned them all the same name.

So on your 3rd step there there are no longer any names of "Sphere" or "Cube" present, they have been overwritten when you entered the new value of "ob3".


> Now when I select the Sphere only, Sphere's name is ob3,
> Cube's name only selected is ob3

Yes - since you set both of their names to ob3 in your 3rd step.



> How clear the group selection? (ungroup)

There was no group made... So nothing to ungroup, if you want to clear the selection click in an empty area or push escape.



> And seems the Undo to the start keeps the all group name ob3!

Yeah, undo is not working right with the properties that needs to be fixed.



> if I select all so ob3, when I clear the the name ob3
> Sphere and cube become Unnamed !!! seems must be ob1 and ob2 ;)

You then assigned them an empty name which is displayed in the UI as "unnamed".


It is an interesting idea to make a group by assigning the same name to a multiple selection, but I think that may cause some problems. I'm generally intending for grouping to work with a different mechanism than that, which will be part of the scene browser tree thing.


The name is just a descriptive tag that you can set on an object, assigning a name does not make it into a group.


> PS there is not yet a list ?...(arborescence)...

Not yet, Styles and colors are going to come first, then the scene tree after that.

There is still a lot of work left to do for this area, as I've mentioned before it will take a few betas before it is all complete.


Does that all make sense? Please let me know if any of that doesn't seem right.

- Michael

Observation: MoI objects 'name' does not transfer to Rhino's 'name', which I'm only pointing out because I thought opennurbs was a structured file format (and therefore 'a' is 'a').

Betas looking good though! :-)

Hi Burr,

> Just so I'm clear. I'm not sure which number is the "actual" size.
> So if I were to create a 1 inch square to machine, Would it be the
> new "size" option or the "custom distance tool".
>
> I guess I just dont understand when this number can be different
> and why.

The size that is reported is the size of the object's bounding box in the world coordinate system (unless you set a custom cplane in which case it is in the cplane coordinate system - setting a custom cplane basically re-orients the grid to a different position and rotation).

But a bounding box around an object can have different sizes depending on the orientation of the object.

Here's an illustration - here I've got a 5 x 5 square, which is aligned with the x and y axes. The x and y axis bounding box around this is the same exact size as the square itself, and you can see that the size readout says 5 x 5:



Now let's say we take that square and rotate it, the bounding information will change, even though we did not scale the square:



That's because a rotated square has a larger bounding box than the axis-aligned square, here I've drawn the bounding box to illustrate:




The sides of that original 5x5 square are still the exact same length as before, but the bounds of it are different.

Which one is most important to you (the length of the square's edge versus its bounding size) may be different for different kinds of purposes, but I would think that when you were machining you would probably consider your stock to be a world aligned piece and you'd be interested in the overall size of the object in that stock rather than the size of the rotated edge? If so then the current size readout should be the right thing for that.

Actually that would help me to know what you expect to see when the 5x5 square rotates - would you always want to see the size as 5x5? Or would you like to see the bounding size which changes as the object has different rotations?

- Michael


EDIT:

Just to try and clarify further, this is where the size is coming from with the rotated square:

Hi Burr,

> Seems "Undo" doesnt work on the object properties.

Yup, I forgot about that part!

It doesn't fall under the umbrella of the regular automatic undo handling because it doesn't actually change any geometry.

But it should not be too difficult to fix that up.


> Object name doesnt persist and desist with multiple group
> namings and changes. more like layers. "Styles" will probably
> acheive what we want here but of course I'm just chatting and
> will wait for Michaels response with you!

Yeah setting the name just sets a label on an object, and if you have multiple objects selected it sets the same label on each of those objects.

There will be more stuff coming for grouping, the current name thing is not really for that.

- Michael

Hi Nick,

> Observation: MoI objects 'name' does not transfer to Rhino's
> 'name', which I'm only pointing out because I thought
> opennurbs was a structured file format (and therefore
> 'a' is 'a').

Yeah I haven't quite gotten to doing the object property data transfer to Rhino yet.

MoI doesn't use the standard Rhino name property for holding the name because Rhino's names can only be applied to top-level objects and not to any sub-objects such as faces or edges.

In MoI sub objects are "first class objects" and can have their own individual properties assigned to them. So to support this MoI stores object properties in a custom chunk of data in the 3dm file, since there is no standard mechanism for it.

I expect to translate properties over to Rhino-visible ones when possible, like I will be setting the regular name property of the top-level object so that Rhino will be able to see the stuff that it supports. But I'll probably be worrying about that more all in one batch after I've got the properties that I want to have set up in MoI all set up first.

- Michael

I understand the bounds description now. Thanks. I guess what I would expect or what I am used to would be that 5x5 is 5x5. So when I'm creating real world objects and using measurments I gather, I would choose to create a "square" and then want to "numerically size and place it". Having those nubers change would be confusing to me. I am not good at drawing something on the screen where it should be....I'm better with "square 5x5x1 size, at 26.6, 20.2, 10.35 coords... So if I typed size 5x5x1 and the actual object was something different because it was set somewhere in space, I would be lost.


Could I learn a diffewrent way??? (Danny should know this answer. ie; could my approach or thinking change and acheive the same results)

Is there a way to have it act like this?

Thanks for the time.

Hi Pilou,

> Suggestion: when object's name is too long line is cut in 2 parts
> Why not make 2 lines : one for the object's name, one for the quality ?

I had wanted to set it up like this originally but I had some difficulty making it work.

But I have a new idea which I'll try.


> so quality can be writed without abbreviation! 8 Closed curves

It's still good to avoid having more than one line if possible, and "Closed curve" just takes up too much space. So even with a better line wrapping I still want to keep that abbreviated to help make for fewer multi-lines with simple names.

- Michael

Sounds like you need to submit your more sophisticated format to the opennurbs project. ;-):-)

Hi Nick

> Sounds like you need to submit your more sophisticated
> format to the opennurbs project. ;-):-)

It'd be tough though - it's sort of more of a program architecture problem rather than a file format problem.

Just having the properties available to sub-objects in the standard 3DM format would not solve the problem of the data structures in Rhino not being set up at run-time to deal with that concept...

Once things get kind of entrenched in a program in a certain kind of expected structure (for example properties only on top level objects) if you've got a lot of other code that assumes that particular structure it is not easy to change it.

- Michael

Hi Burr,

> Could I learn a diffewrent way??? (Danny should know this answer. ie; could my approach or thinking change and acheive the same results)

Thanks for dragging me into this......buddy! ;)

But your right, I would of expected to click on a rectangular solid say 5X5X1 and it didn't matter at what angle it was related to the coordinate system it would always show up as 5X5X1, but as Michael explained your actually changing the bounding box of the object not the object directly like in a cad system.

The way I see it, sizing in the new object properties panel is a numerical version of the object editing frame, where, instead of dragging your object to roughly that size now you can give it a value.

So knowing this, if I need to resize a 'primitive' that was modelled at some sort of angle I would set my cplane to that object, but we have to remember that once that object has a Boolean function applied to it we can't resize that object alone the sizing in the new object properties panel will show the 'Booleaned' bodies as one solid.

I think resizing objects after another operation will be a history enhancement for MoI in the future.

Michael, please correct me on any of these points if misleading.

Cheers

Hi Burr, well the thing is that I am pretty sure that the CAM software that you use will report the same thing that MoI is using (axis aligned bounding box size), when you tell it to give you the dimensions of the shape you are going to cut.

If you'd like to try that, create a box in your CAM software, get a dimensions or size report, then rotate the at something around a 45 degree angle and get a new dimensions report.

Is it possible for you to do that experiment and tell me what the results are? I mean does it report the same bounds size for you in both cases?

- Michael

Hi Danny,

> but we have to remember that once that object has a
> Boolean function applied to it we can't resize that object
> alone the sizing in the new object properties panel will
> show the 'Booleaned' bodies as one solid.

I'm not completely sure if it covers what you are talking about here, but you are not limited to only seeing and editing the size of the full object - you can select sub-objects like an edge or a face to see their length or bounds, and actually edit those sizes, which will scale the whole object to make those sub-objects that size you specified.


> I think resizing objects after another operation will be a history
> enhancement for MoI in the future.

Yes - probably doing a kind of targeted "dimension edit" to adjust something that you drew would be properly done with a history type edit instead of this new object property size tool.


The whole other issue is that this can get moot fairly easily once you are dealing with something other than a rectangle or a box. Like for example what is your expected width and height of this object:




If I tried to track a separate plane for each object, it would be pretty easy for the bounding information to become hard to understand once the object deviated from a simple rectangle... With the current way I think it is actually easier to understand what the bounds mean for any particular shape, you don't have to try and imagine what is the frame of reference for a particular shape and take that into account to understand what the size means, it is always in the world or cplane frame...


I've been thinking about it back and forth a fair bit and I'm currently leaning towards the current way as actually being the least surprising overall, because it has a consistent behavior.

But I can also see that especially for planar curves it could be nice for the bounds to be tracked in that curve's plane...

But if you do want to get a kind of "absolute" value that is also possible currently by selecting a line since that gives you length information and not a bounding box.

- Michael

Hello Michael....

>Yes - probably doing a kind of targeted "dimension edit" to adjust something that you drew
>would be properly done with a history type edit instead of this new object property size tool.

will be interesting in the future...

For the pentagon, how about this :

Hi Anis, that is probably possible for a regular pentagon.

What about this one though:




Another example - here is one 2x4 rectangle and another 4x6 rectangle:




What would you expect to be reported as the overall size when both of them are selected at the same time?

- Michael

Not sure if this is the right place to post this request..


But... it would be super handy to have slightly better hide options. Something like this...


left click "hide button" = hide selected
right click "hide button" = hide unselected

I know i can click it twice and all, or select items and invert the selection. But I think this would be slightly better