YeeeHaaawwww! An old friend has come to MoI.

Just to be sure, where you answered:

>>But this new system is for setting the size of the entire object, it will not do "constraint" based type operations that may extend and alter interior regions of a shape differently than the shape as a whole.

It WONT do a single edge? Are points included? Position is next :) !



MoI is SO gui it sticks all over you!

Hi Burr,

> It WONT do a single edge?

Sort of... You can set the length of a particular edge, but it sizes the whole object to get that edge to the size you asked for.


> Are points included?

Not currently but I think I can make that work.


- Michael

Well, Michael, I take my eye off the forum for a little while and what do I find? Editable size and viewable directly at the top of the interface!!

Great stuff - just what I was hoping for. Hats off to you, sir!

Hi Michael,
I believe we're on the same page. Though persistent relationships would be great (like that afforded by a constraint middle-ware engine like D-Cubed); that's not what I was asking about or hoping for now.

Indeed at this point the suggestion, or if you will request, is that whatever object you're editing it would be possible to establish a relationship, albeit temporarily, using the very same variables that originally allowed defining that object. For instance, in the box example you'd be able to make the length equal twice the height (x=2*Z). Or similarly for a cylinder, relating radius or diameter and height.

Cheers,

- Diego -

Hi Diego, I was able to set that up pretty easily:



There are "x", "y", and "z" variables that you can use in an expression.

So for example there I entered "y" in for the X: value, to make x and y values equal to "squarify" the box (make sure to turn "Maintain proportions" off if you want to change dimensions independently instead of doing a uniform scale), and then "x/2" for the Z: value to make the height 1/2 of that starting y extent value.


But it is not quite the full package that you were asking for - this just handles the bounding box around an object, regardless of how it was constructed. So something like a cylinder is not treated any differently than a box.

I will be doing some custom editors for certain entities, but probably those will start out just with a line segment length and a circle radius. But actually since a cylinder has edge sub-objects which are lines and circles, just the line and circle editor should actually work pretty well for editing a cylinder as well.

Being able to edit any combination of the original values that an object was created with is going to be something that goes into a "history" editor which will be a different thing than this size editor thing.

Thanks for the feedback, that was a good idea!

- Michael

Useful :)

And this feature ? (just new in the 7.0 G Sketchup)
Dynamic component
http://au.youtube.com/watch?v=4aVW5X-tb8s&feature=PlayList&p=B62D27FCCF0C34C7&index=2

Hi Pilou,

> And this feature ? (just new in the 7.0 G Sketchup)

That is also something else entirely.... Certainly useful in the right situations, but in a very different category of work than what I am doing right now.

That would be like making a special "stairs" command in MoI that knew how to take various parameters and make a staircase automatically. That's possible in the future at some point but currently things in MoI are more focused on general purpose geometry building and not so much on making specialized commands that are for just one very specific kind of resulting model.

Basically it takes some specialized code behind such objects to take those parameters in (and alterations to placement and scale, etc...) and generate a structured specific shape output.

The problem with such things is that you are often stuck with a kind of fixed output in several ways, like for example what if you want stairs that have a rounded end, or have a groove cut down the middle, etc.... ?

With a special "stairs" command it makes it really easy to make a certain kind of stairs that the command was set up to produce, but that does not help you if you want something different than that. But it is helpful for things that use a common set of structures.


This can get added to MoI eventually, but currently the focus in MoI is sort of on a more creative drawing type process and not so much on assembling a set of "standard auto generated components" together.

I mean don't get me wrong, it is useful in many ways to be able to easily assemble many standard things together and I would like to make that easier in MoI in the future. It's just more the concept and energy behind MoI is more in the area of doing creative dynamic stuff more than that currently.


If your model is more of an assembly of totally standardized shapes, then probably MoI is not really the best tool for that, a different program that has put more emphasis on templating and instancing, etc... (like the kind of stuff shown in that video) would be a better fit for efficiency.

- Michael

Yes this sort of thing ask input some different constrains at the start of creation of the component!

Hi Michael,

You wrote

"I mean don't get me wrong, it is useful in many ways to be able to easily assemble many standard things together and I would like to make that easier in MoI in the future. It's just more the concept and energy behind MoI is more in the area of doing creative dynamic stuff more than that currently."

My poor opinion is that this is the way to go.

Regards,



George

Hi Michael....

>> This new system will also allow you edit the size of a sub-object like an edge or a face
Nice, I want to see the effect if "Maintain Proportions" is unchecked.

I know your idea behind MoI is not for replacing some constraint base software.
Here I just want to give you some feedback to improve MoI, I dont want to push your original idea into a wrong place....

Attached is another video ( I dont know how to embed swf file directly to this forum )

Hi Michael ...

Please don't get diverted from your original 'moment of inspiration' ...

I greatly appreciate your willingness to be flexible and to try to include users' wishes but no program suits all potential users.

SketchUp is a personal example ... I actually purchased it few years ago and was initially very impressed with what it would do. And it does what it does pretty well most of the time. Some of my architectural friends rave about it. However, I stopped using it rather quickly and though I still download the latest versions I find it still does not work well for me. It is really not very flexible.

I use Rhino for almost everything, from architectural design to presentation and final drafting ... but I am really excited by MoI ... both because of the more intuitive approach you have taken, to the simplicity of use by comparison to Rhino and numerous other programs. MoI may not replace Rhino for me but I will be using it more and more frequently as a more 'friendly' and flexible companion.

Thanks for all your work and your patience.

eric

Hi Anis,

> Nice, I want to see the effect if "Maintain Proportions" is unchecked.

It will be the same as using the Transform / Scale / Scale1D command - the full object will stretch in that one direction, like this:




> I know your idea behind MoI is not for replacing some constraint
> base software. Here I just want to give you some feedback to
> improve MoI, I dont want to push your original idea into a
> wrong place....

I appreciate the examples! Sometimes it may be possible to see an element of something in there that I could incorporate into MoI. Like the new "Distance from edge" option in the MoI v2 Move command basically happened like that.

But your last examples are not really like that, those are more like things that I would probably need to work on for several years before they would work in MoI (on something other than just a box), either that or I would have to license some expensive components and move the price of MoI up more in line with the price of SolidWorks.

So I just want to make sure that your expectations are in line with what is possible for me to do.

When I see an example of something that is working well in other software and would be difficult for me to add into MoI (difficult either from the amount of work involved, or possibly just not a good fit with MoI's UI), it actually tends to make me think sort of the reverse actually. I mean that I tend to think that I don't really need to worry so much about adding that function into MoI because it is already being handled well by something else. So if you need to do that kind of task you are already covered by using that other software.

- Michael

Thanks George & Eric!

Since it is going to take a while longer to finish up the "styles" part of object properties, what I think I'm going to do is polish up this size editing part now (with a couple more pieces like some special UI for lines and circles) and then release a new beta without the styles part in it yet and keep working on that after.

- Michael

Hi Michael.....

Thanks for your clear explanations...
I wish the best for next release of MoI ;)

Btw, I am waiting for the next beta ( that will be launch this week, maybe... )

-Anis

Hi Michael,

Just got myself up to date with this thread and everything so far looks great and releasing the next beta is exciting news also :)

As I got the grips on what you have done so far, how I understand it is, that with the new scene management we can name an entity, be it a curve, solid or surface does that go for edges as well ? Can we name each edge of, say a rectangular solid ?
The reason I ask is that going off Diego's idea, which I agree was a good one, could we name an edge of one entity and then use that in an expression to get a proportion relationship of a separate entity ? e.g. 'wall/2', 'wall' being the name I gave to an edge, to get a door half the height of that wall.

BTW persistent expressions would be nice, but I guess you would have to store a lot of info with the file.

---------
~Danny~

Hi Danny, yes you can name an edge or a face sub-object... But mostly the idea behind the naming is to set up labels that will show up in the scene tree / scene browser thing.

Currently there is no restriction that the names have to be unique - you can have objects that have the same name and it is actually hard to avoid this since it is otherwise hard to figure out what to do when you split an object into multiple pieces.

It is an interesting idea to be able to use the names in expressions, but one problem right off the bat is I don't know what to do when there are multiple instances of the same name...


> e.g. 'wall/2', 'wall' being the name I gave to an edge, to get a
> door half the height of that wall.

It is possible to use construction lines now to get that kind of measurement... But I can see that if you are going to be using the same value many times it is better to be able to refer to it with a simple tag or name.

I'm not really sure that using object names would be sort of the best fit for that though, it seems like a kind of "variable manager" type UI would be the thing - like you would go somewhere and push a button for "define variable", and you could pick from different functions like get the distance between 2 picked points, take the length of a selected edge, radius value, etc... and then you enter a name and then that variable would be defined for use in expressions.

That could definitely be useful, but it is kind of going down a fairly specialized and "advanced use" type road, it will probably be a bit difficult for me to raise it in priority very soon.


> BTW persistent expressions would be nice, but I guess you would have
> to store a lot of info with the file.

It's not so much the storage - the main problem is I just don't have a constraint-based solver mechanism that has all the stuff worked out for how to alter interior regions of a shape (like by extensions etc...) separate from the whole shape.


- Michael

It looks like I will be able to get some custom readouts for spheres, cylinders, and cones.

Like when you select a sphere (either a whole sphere on its own or a sphere face sub-object out of a larger solid) instead of showing the Size: label, it will show Radius:

The way the readout works, is that for a general object or multi-object selection, it shows Size: which is the bounding box size.

If you have a single object selected, it can show information about these types:

Line - the length of the line.
Circle or Arc - the radius
Sphere - radius
Cylinder or cone - radius + height

- Michael

Hi Michael,

> I'm not really sure that using object names would be sort of the best fit for that though,
> it seems like a kind of "variable manager" type UI would be the thing -
> like you would go somewhere and push a button for "define variable",
> and you could pick from different functions like get the distance between 2 picked points,
> take the length of a selected edge, radius value, etc... and then you enter a name and
> then that variable would be defined for use in expressions.

Yeah that would work, but I was thinking even with the idea I gave there are too many steps and typing involved, something with less steps, like if you had that 'define variable' or 'reference' button beside each input box (x, y, z) as a small button and once pressed you can pick that edge mentioned previously and the length value would be placed in the input box.
But then as you implied, how many times would we use it, just thinking out loud.

Keep up the good work