Hi Steve. What Michael is suggesting is that anybody can use the Rhino evaluation version to perform tasks such as object checking. Becuase the eval software has the full function of the paid software. It can be used forever, but only limited to 25 saves. So many people (not just MOI community) use it for inspecting their models from other programs...

jonah

Hi Steve,

> For your application to be "Powerful, accurate" do you not
> think such info is required in current release?

Nope, as far as I can tell it is not required - the evidence for this is that it just has not come up before in the beta release which lasted for about a year and half.

It is not difficult to add the script interface that will enable this, but I'm not planning on releasing any updates for version 1.0 for very minor issues, because it takes quite a bit of work to manage update releases.

If there are more major issues reported that force me to issue an update to 1.0, I can include this at that time. But right now there are no major issues that are forcing this at this time.


This would have been an easy thing to add if you mentioned it in the beta period before the final 1.0 release. As it is now, you are asking for it after the 1.0 release has been finalized.


> I look at MOI as a standalone product, I am not putting forward a
> "wish" but what I think is currently missing from such a release.
> (with full respect and IMHO).

Asking for some feature that is not present in the current program is pretty much the exact definition of a "wish"!

There are plenty of useful things that did not make it into version 1.0, if I waited until version 1.0 was perfect and had every conceivable missing thing in it before releasing it, it would be delayed for a long long time.

I can certainly understand if these particular missing features make MoI unsuitable for you - in that case you will need to wait until version 2.0 before it will be more suitable for your purposes.


> I will say, I do like this program. I have attempted many forms
> (from loft / bridge / sweep) that would crash a number of programs,
> yes, on purpose,

I'm glad this part is working well for you - yes stability was a major major focus for version 1.0 - many of the things you are asking for were postponed from version 1.0 so that some other basic foundational stuff could be handled first instead.

I mean, would you prefer to have a "what" type thing functioning, but have unreliable functions and crashing instead?

It just is not feasible from a scheduling perspective to implement all things all at once. I had to be pretty ruthless in a lot of ways in trimming down certain features to make an initial release feasible.

If too much was trimmed down for you, that will get solved in future releases.



> instead, MOI gives me a possible example.(nice co-processor~ is that yours?)

I'm not sure which part you are asking about here?


Anyway, don't get me wrong, I don't take any offense if you decide that MoI is not suitable for you in its current state.

- Michael

Michael.
Just a few thoughts--and not a criticism.

Your developement time/beta of version1 is irrelevant to the user--especially the new users I suggest.
You regularly add things to a Version 2 possible fix/improvement list--really a lot! (Will V2 be in 1 or 2 years?)

Now I am amazed at the quality of MoI but I can not help feeling that there are, at least a handfull, of problems that need an improvement in the very short time. As I have said before, maybe an SR1?

Just to add ideas in the thinking process,

Brian

ps--dont even ask what I think should be at the top of a list---I am just giving an impression I gain from following the posts.

Hi Brian,

> Your developement time/beta of version1 is irrelevant to
> the user--especially the new users I suggest.

Well, it's not so much the previous development time that is a factor here, but rather that putting out updates requires me to do additional work with tracking new versions and possibly making new update installers and stuff like that.

It also takes a significant amount of testing to make sure that any changes do not cause a "regression" and introduce new bugs and problems instead of making things better. If something is released and is functioning in a very stable manner, it can be a very good thing from a development standpoint to not mess around with it.

It is basically not a totally simple process for me, it adds extra stuff to my workload and will actually take time away from new feature development.

So it is not something that really merits the time involved if the issues are not at a somewhat high level of impact, like a persistent problem affecting many people, stuff like that. A special feature for just one person's request just does not fall into this category - I'm sorry but those are just the cold hard facts.

It is a lot easier for me to put in these kinds of things _before_ the release is finalized. If you absolutely need stuff to be included with the full version release, it is more practical to mention it to me before the final release rather than after the final release... That works a lot better!

Please note that I have added in a huge number of such things (for individual people in many cases) during the beta release when it is easier for me to just roll out new versions all the time.

Generally it will be during beta releases that you can expect to get a lot of updates and dynamic changes in response to requests.

Once there is a finalized version, that final version will not generally undergo a bunch more dynamic changes, it will tend to be a lot more nailed down.

I know that may be confusing since it is such an abrupt change from the way the betas go, hopefully with this information you can get a better explanation of what to expect.

Also this kind of approach is only really possible since I shoot for an extremely high level of quality in that final release, so it is not as necessary to roll out all sorts of bug fixes.
That's a little different than what you may be used to with other software.

Would you prefer it if I rolled out a much less stable initial version that crashed all the time so that there would be a lot of updates following it? ;)


> but I can not help feeling that there are, at least a handfull,
> of problems that need an improvement in the very short time.
> As I have said before, maybe an SR1?

So far nothing has been reported that is significant enough to merit a service release.

It will be a lot more efficient for me to incorporate minor tweaks into v2 betas which should get going in not too much longer.

I'm sorry, but I just cannot totally throw out my own time and development efficiency considerations to the wind, I don't have unlimited time and only have 24 hours to work with in a single day... :)


> (Will V2 be in 1 or 2 years?)

V2 release will be about a year away from now probably, but the initial v2 betas will be available a lot sooner than that, hopefully not too much longer.

I appreciate the feedback! But there are a lot of factors at work here that may not be immediately apparent to an observer.

I can understand that from a customer's perspective that it would be cool to buy one version and then get all kinds of updates and new features without ever upgrading to a new version - but that is just not feasible for me to do from a business perspective, sorry!

- Michael

Hi Brian, let me put this another way as well.

You've been using the MoI v1 release for a while now.

Can you let me know how many times it has crashed on you?

- Michael

How can one have a good discussion/argument when you bring that up Michael!----Not fair!

Brian

:)

But seriously, how many crashes have you experienced when using the 1.0 release?


There just isn't an unlimited amount of time to spend on any one particular release.

Right now I focus on spending time before the release, fixing it up so that the final release is really stabilized.

The more standard way is to push out a release at a certain date even if it is not quite perfected yet, and then spend a bunch of time after the release with service packs to fix bugs and crashes and make it work better.


I personally don't like the second method, but if you want me to be focused on releasing service packs, that would be the type of development method that I would be switching over to...

Which one do you really prefer?

- Michael

The joj of MoI is not even a sign of a crash!

And I am no complaining. Though, still, V1 is here and it would seem that maybe a few current working methods--not perhaps new things especially--would be a great boon to users if improved in the short term rather than waiting for V2. My own problem especially is not being able to readily identify were points have not been cleanly connected--a regular problem in mine and seveeral others posts.That these areas could be highlighted visually and or self connect better maybe?

Just a thought.
Brian

Hi Micheal,

Sorry, but I am a little confused with your reply on my initial question.

Post #2 >>>There isn't a way to do it right now, but it will be an easy thing to add for V2.
For MoI v1 you need to copy/paste into Rhino for this checking.

Post #5>>>It is not difficult to add the script interface that will enable this,

(I will say that it is the first 3d application I have used that does not give direct feedback of position/ orientation etc of an object.)

-------------------------------


I would also now need to ask, what do you consider a bug? Would this in fact be a need for moi to crash?

I ask due to your comment
post #7>>>So far nothing has been reported that is significant enough to merit a service release.

Hi Brian. That's the beauty of a public beta system. You will start to see those additional tools in the upcoming betas. You can think of it almost the same way you would think of a SR. And because it is a beta, it can be released without extensive testing and without written doumentation. The updates come much faster. Do you remember how long it took Michael to finish writing the ducumentation for V1?

jonah

you can set up at least a shortcut for selecting closed (poly)surfaces...

script:moi.geometryDatabase.getObjects().getSolids().setProperty( 'selected', true );

Oops! Thanks Petr, that is correct, there is a way to do this after all I had just forgotten that method myself!

To use the script Petr provided above, go to Options / Shortcut keys, and add in a new entry.

Then add whatever key you would like, and paste in the script above as the command.

Then when you hit that key, any closed solid will be selected, that is a method you can use currently to determine if an object is a solid or not.

Sorry I forgot about that method!

- Michael

Hi Brian,

> That these areas could be highlighted visually and or self connect better maybe?

That would be a new feature - definitely something that would be worth exploring when it is time to add new features during the next beta.

A service release would not be focused on adding new features, but instead on correcting bugs.

- Michael

Hi Steve,

you wrote:
> Sorry, but I am a little confused with your reply on my initial question.

I wrote:
>>There isn't a way to do it right now, but it will be an easy thing to add for V2.
For MoI v1 you need to copy/paste into Rhino for this checking.

>>It is not difficult to add the script interface that will enable this,


I'm not quite sure which part is confusing you? Here I am trying to say that it will be an easy thing to incorporate into the next release, which is currently planned to be the v2 beta release.

But it actually turns out that the script interface is already in place in v1 for identifying closed objects, I was just looking for an "isClosed" method that is not present for surfaces, but there is another way that can be used instead as posted above.

Sorry for getting confused myself on this part!


> (I will say that it is the first 3d application I have used that
> does not give direct feedback of position/ orientation etc of an object.)

But I thought you mentioned previously that you had used Rhino since the first Rhino betas? It's no different over there.

In general CAD programs are not so focused on a kind of generic bounding box / pivot point type approach. Actually usually that type of method is used by applications that are not so focused on precision.

In a CAD program you tend to align an object using some kind of command (like in MoI it would be Rotate) that allows you to snap on to specific individual features of the object and use those to perform the orientation, rather than just some generic spot that is in some arbitrary averaged centroid of the object.

Once you have placed an object in its desired orientation, I guess I don't understand why you want a special readout of it after that, what purpose would that serve for you?

I do expect to add more orientation type functions in v2...


> I would also now need to ask, what do you consider a bug?
> Would this in fact be a need for moi to crash?

It's just the typical definition - something that is malfunctioning.

Missing features that are intended to be added in future versions are not bugs.

- Michael

Hi Brian,

> would be a great boon to users if improved in the short
> term rather than waiting for V2.

Don't get me wrong, I certainly agree that it would be useful to users to have new stuff added.

Unfortunately putting out new releases of a finalized version creates a lot of additional work for me, that's what I was trying to explain earlier.

Some logistical things I have to plan around what is efficient and feasible for my own work schedule.

Ultimately being efficient in my work schedule ends up being beneficial in the long run because it means that I can get more new features accomplished overall.

If I had more than 24 hours in a single day, it would be a lot easier for me to do all kinds of extra work all of which would be beneficial to users... But I'm stuck with only 24 hours in a day so there are limits on the amount of work that I am able to produce.

- Michael

Hi Michael,

>>>But I thought you mentioned previously that you had used Rhino since the first Rhino betas? It's no different over there.

From Rhino release 1. That provided a "what" command, it also had a set of analyze tools, such as length / radius / volume etc, even an option to show broken edges.
So I am not sure as to why you would say "its no different"


I will have a look at the options within the scripts.

Steve

Hi Steve, the "What" command for Rhino v1 did not give size or orientation information on solids.

There was no concept of an orientation attached to an object in Rhino v1.

I do expect to add in a set of Analyze commands to MoI to query things like volume, length, etc... These are not present in version 1.0 though.

If you have Rhino I guess I don't quite understand what the fundamental problem is for you, are you having problems transferring data into Rhino to perform these types of queries?

I can understand that it would be good to have these operations inside of MoI, that's why they are going to be added.

Version 1.0 of MoI is focused mostly on making it quick and easy to draw simple objects, that core mission does not require these types of analysis tools, so that's why they have not been a focus so far.

In general development of MoI is a lot different than development of Rhino. I'm not rushing to throw in every single kind of possible tool I can think of which is what I did with Rhino.

Instead with MoI the approach is a lot more careful and calculated, I'm trying to slowly build things up so that the final result can have a carefully balanced interface.

I can understand that you might have some frustration with this approach if you are more used to the "tons of stuff" kind of approach instead.

Over time I expect for this approach to pay off with plenty of functionality but with with an overall easier and more pleasant to use interface.

This approach may mean that the current version of MoI is not suitable for you and you may have to wait for a while before things kind of bubble up to the level of functionality that you need.

However, having said that there are also a lot of things in MoI currently that you may be interested in as well, so a good approach for you currently might be to use MoI in combination with Rhino instead of expecting to use MoI completely on its own.

- Michael

Hi Steve, I guess the disconnect is that MoI is not really intended to be like a completely direct replacement for Rhino, it is focused on somewhat different things than Rhino.

There is certainly overlap, and that overlap will grow larger over time, but it just was not a primary goal of MoI to do all the exact same things as Rhino.

I guess that's why it does not seem strange to me to recommend using MoI and Rhino in combination with one another, if Rhino does things that you need that MoI currently does not do.

- Michael

Hi Michael,

>>>the "What" command for Rhino v1 did not give size or orientation information on solids.

I know, it would give me the info if the object was closed or not. The script posted to select solids now gives me this info, So not a problem.

>>>If you have Rhino I guess I don't quite understand what the fundamental problem is for you, are you having problems transferring data into Rhino to perform these types of queries?

I personally purchased version1 (on its release) for work, after that, all other versions where purchased by the company, so I do not use them at home.

>>>I can understand that you might have some frustration with this approach if you are more used to the "tons of stuff" kind of approach instead.

It is not a case of "tons of stuff", I was just looking for a simple way to give me ref of an objects position etc. Probably more due to habit rather than a real need.


Steve

Hi Steve,

> I personally purchased version1 (on its release) for work, after
> that, all other versions where purchased by the company, so
> I do not use them at home.

I see.... unfortunately the 3DM file toolkit only supports reading Rhino v1 files and not writing out to them.

So it only works to copy from Rhino v1 and then paste into MoI, you can't do copy/paste in the other direction like you can with Rhino v2, v3, or v4.

- Michael