Hi Michael,

thank you for the infos and the suggestion for the shortcuts.

"And actually the total cost of v1 + v2 upgrade I think will be the same as the cost of v2 standalone - the v2 standalone will be going up in price a bit I think."

That sounds like an userfriendly upgrade price policy. I afraid buying the license now cause to pay much more than the v2 price only. Can you say, when v2 will be released - in days, weeks or months?

A question to the Rhino workflow. I remember me, that the reimported meshes was turned to the side allways - is it still so? Could it be possible that the imported mesh is placed at the original NURBS layer?

I understand that it is much work to write a plugin for Rhino and it's better for MOI3D, that you focus your work on it. An other idea: could it be possible that you open MOI3D for plugin developer, so that a plugin could be written by a Rhino plugin developer? The MOI3D interface could be used by other CAD user to write a plugin too. So, you would not need to think about the plugin codeing, the people would buy MOI3D and the plugin could be an open source project or could be bought additional. I think on that the moi3D can be used per command line like "moi3d.exe -parameters original.3dm mesh.obj". Sounds quite easy for me, but I don't much about programing. ;)
It could be great, if at Rhino all rendermeshes would be created by the MOI3D mesher.

Doe's the current mesher support the option "max distance/error NURBS to mesh"? If not, is it planed?

Regards,
Micha

EVERYBODY want Michaels new mesher!!!! Seems it may be a highly sought after licensing pack!!! :)

Hi Micha,

> Can you say, when v2 will be released - in days, weeks or months?

There isn't an exact fixed date yet, but it is probably something like 2 months from now.


> I remember me, that the reimported meshes was turned
> to the side allways - is it still so?

For OBJ files you mean? It may still be like this by default, but there is an option to choose the orientation for OBJ exports from MoI under Options > Import/Export > OBJ options / Orientation - you can choose between Z-Up and Y-Up.

If it is turned in the wrong direction for you, just flip that setting and it should be solved.


> Could it be possible that the imported mesh is placed
> at the original NURBS layer?

It doesn't do this currently, but this area of layer management is one of the main areas that I have left to work on to complete v2. However, I'm not quite sure if there is a way for Rhino to create layers from an OBJ file so this may not be very easy to resolve right away.


> An other idea: could it be possible that you open MOI3D
> for plugin developer, so that a plugin could be written
> by a Rhino plugin developer?

Yup, I am planning on doing this eventually. Unfortunately both documenting a plug-in system and also supporting other programmers who are using it tends to be a very time consuming area of work, so it is not easy for me to add this in currently while I still have a lot of other more basic areas that I am also working on. So it will probably be a while yet before I am able to focus much effort in this area.

I tend to have to be careful right now about entering areas of work that will consume a large amount of support time.


> I think on that the moi3D can be used per command line
> like "moi3d.exe -parameters original.3dm mesh.obj". Sounds
> quite easy for me, but I don't much about programing. ;)

Actually this type of automated command-line meshing is already possible, you can give MoI the name of a .js script file on the command line and the script file can call various functions to produce the meshed output also passing parameters such as angle, etc...

Some details on that here:
http://kyticka.webzdarma.cz/3d/moi/#Batch

Also another discussion here on how to use this mechanism to batch convert all files that can be found in a particular folder:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2100.1

So I guess that actually already provides the basic stuff that you would need to make a Rhino plugin that would call moi.exe to do the meshing... The plugin would basically need to create a temporary .3dm file, and a temporary .js file with some calls in it to control what MoI does - it would call some script functions to load that .3dm file and then do a SaveAs to a polygon file (details on this are in the links above), this can either allow the UI to show or it can decide to have the UI hidden and pass specific parameters in. Then the plugin would wait until that moi.exe program ended and it would then be able to load in the generated mesh file.


> Doe's the current mesher support the option
> "max distance/error NURBS to mesh"? If not, is it planed?

There is not currently a "maximum chord height" type option, but I have been planning on adding one.

- Michael

Hi Michael. Why not just create a method to export the mesh objects to a 3DM file. then we import 3DM to Rhino and all layer names, groupings, etc can be preserved?

jonah

"Better to just buy MOI as is, and use only what you need!
(The GUI will probably have you avoiding the use Rhino more and more anyway LOL!) -Will"

But as Micha said, he's using Rhino as his rendering platform. Not really modeling in it. So MoI would not be much help to him for that purpose... For someone like me, I can understand his perspective. I use Rhino for nearly everything I do. I can imagine the advantage (especially for the real-time display mesh) of having a MoI plugin to Rhino. Having a multi-threaded, clean mesher directly in Rhino would be something I would pay for. And I think working together with McNeel (they offer assistance to all plugin developers) it should not be that difficult to implement. For example, Tsplines 2.0 WIP now disengages Rhino's mesher and uses their own mesher for all TSplines objects. Also TSplines mesh can support n-gons. So all this can be possible for a MoI plugin as well... But I won't argue Michael's point that he doesn't have time to handle the support for it.

jonah

3dm files would be great for layers and other attributes, but there is one downside of 3dm for meshes - they don't support n-gons, only tris and quads. I think this may change for Rhino V5 or V6, but if n-gons is a big selling point of MoI's mesher, 3dm is not the ideal format.

Then again, if you're importing back into Rhino for rendering, the obj would be converted back to quads and tris anyway, so it would probably work for Micha's workflow.

Our T-Meshes are sort of an overlay onto Rhino's meshes, adding support for n-gons, T-Points, and knot vectors. But if you render a T-Mesh, or load one of our T-Meshes in Rhino without the T-Splines plugin, it'll just be quads and tris.

I think it's the right moment at the right place :

!!!! We need T-spline for MoI !!!!




:)

As a MoI user Ill say that all the focus should go to MoI's development. One of the reasons I chose MoI over Rhino is that MoI is "CLEAN".
Dont give me wrong I like McNeel's "Democratic" approach to support every single format, every single Rendering app. etc. BUT from what I have experience there is not many formats supported that you can say "Yes It Works".
On the other hand MoI supports few formats BUT they are all do the job. (also one of the main reasons why I choose MoI).So yes MoI is not just a pretty face.
I also think is very very early for SDK or Plugins, that could lead to the same problems Rhino or Others have. After all as we all know MoI have one of the best meshers, there for you can export to any app you wish for UV, Paint, Rendering etc.(is not always perfect but the best you can get).

That's just my personal thoughts and I think MoI should develop to a Hard Core Modeling Tool. I have also asked in the past for a rendering plugin but happily I could trade my wish for more modeling tools...hehe.

Paq, Don't be afraid to ask for what you want... ;)

Hi PaQ I think what Jonah suggesting it really makes seance, what are you thought on a that? Do you think a plugin for MoI will be better? I will like you opinion on that before I contact the
Tspline guys.

 

Hi jonah,

> I would think the best hope for non-Rhino users is
> for ts to build a stand-alone conversion app which
> eats OBJ and spits out 3DM...

That's a really good product idea for the T-splines guys, I forwarded that to one of their developers who I was talking to recently.

That would work well with MoI but there are also all kinds of other scenarios where a stand-alone simple conversion app could be helpful, like someone who wanted to use Modo and SolidWorks in combination with each other, etc....

It would possibly not take too much effort for them to set up a product like that, it would be able to have a very minimal UI, just something like a viewer window to view the imported mesh.

- Michael

Yannada - To replace Rhino's mesher, MoI won't need an SDK of it's own. The plug would have to run inside of Rhino, using Rhino's SDK. I'm sure Michael is already quite a master of Rhino's architecture. So how difficult would it be to port the code? That's something I have no idea. I'm just a dumb software user... :P

jonah

>> Hi PaQ I think what Jonah suggesting it really makes seance, what are you thought on a that? Do you think a plugin for MoI will be better? I will like you opinion on that before I contact the
Tspline guys.

Hi Yannada,

Sorry, I was not talking about the meshing plugin question for Rhino, I just take the opportunity that Tom Finnigan was there to say 'hello, I wan't T-spline for MoI' =)
I know it was allready discussed, and I understand the 100 reasons it will not happend soon, I just didn't resist :P

Hello Micheal,


>the v2 standalone will be going up in price a bit I think.<

With full respect of your ability, please be cautious of the pricing. I would agree that V1 was sold under -priced but that gave the base price based on its functions. I know you have worked hard and many many hours on the update, but would not like to see maajor increase in price which may put off new users/ or owners of V1

Many will look at what functions are in V1 and compare to V2 and then associate the pricing.

Please dont jump up and down on me for this comment, it is just my thoughts.

Regards and respect,

- Steve

Ooops I missed this one (yes sir we want it too)

Hi Jonah,

> Why not just create a method to export the mesh objects
> to a 3DM file. then we import 3DM to Rhino and all layer
> names, groupings, etc can be preserved?

That would solve that particular problem, but possibly cause some other confusion about exporting in 2 possible different ways to the same format.

MoI is able to determine which file format to use based on the file extension - for example if do a "SaveAs" you can just type in c:\test.obj without altering the file type dropdown in the filename dialog, and MoI sees that you are using an .obj extension and therefore knows to export an .obj file.

But if you have 2 different formats using the same extension.... That mechanism will not work to differentiate between them.

Another difficulty is that MoI will not read polygon mesh objects out of a 3DM file, so writing polygon mesh data from MoI could pretty easily lead to confusion as to why some 3DM files that you save cannot be loaded back into MoI. This could be particularly bad since 3DM is the primary file format for MoI.

Note that Rhino does not itself have a method to do a "SaveAs" to a Polygon-only 3DM file (with the mesh conversion done during the save process as per other poly file formats) for these same kinds of reasons.

I suppose it is something that could be added that was only available for scripts and not as a normal part of the UI. But that would probably only be of use just to a Rhino plugin and not really for other general purpose use, that means it will probably be difficult for me to make that work a priority anytime soon, compared to other functions that are more widely used - same as how making a Rhino plugin myself is hard for me to make a high priority.

- Michael

Hi jonah,

> So how difficult would it be to port the code?

Not horribly difficult... But not like a drop-dead easy thing neither, it would certainly need an investment of time, probably about as much as the overhaul for sweep that I want to do in MoI.

The big problem is that is just the tip of the iceberg - forking a codebase tends to create additional work over the long term for maintenance, like applying bug fixes in multiple places rather than in a single place.

Similarly adding new products adds additional support overhead for me as well.

I don't really like to do things that will add to my future work load, so that's basically why it is not too likely that I will be able to invest time in this.

The payoff would seem to be fairly minimal for me as well, since MoI has such a very low price currently and already works very easily in combination with Rhino already. The current version is already working well for a lot of people who would benefit from this function. I have been contacted by a few Rhino users who are looking for a plugin version since they want it to be lower cost than the current cost of MoI. But this is a pretty small number of people, I pretty much figure that if $195 is too much for someone, I'm not really very sure that they would really be able or willing to buy a plugin neither.

- Michael

Hi Steve,

> I know you have worked hard and many many hours on
> the update, but would not like to see maajor increase in
> price which may put off new users/ or owners of V1

Currently my plan is to increase the price of v2 by US $100 to a total of $295 for a full license, or $100 for a v1 to v2 upgrade license.

Then probably after about another year's worth of work for v3, I think the same thing will happen for it, that it will go to $395. By that point in time quite a lot of the things that were missing in v1 will be filled in pretty well.

One idea that I have had is that in the future I could still offer version 1.0 at its same current price as a kind of "lite" version for someone who was looking for just an essential modeling tool that is easy for them to use. I'm not completely sure about that yet, but that is one idea.

Basically I did end up pricing version 1.0 too low. I mean there were some reasons I did this, I wanted to make it easy for people to get MoI and also having a low price tends to make it easier to justify missing functions. As time goes on and functionality increases, that basically removes one of those reasons. Then that leaves me with accessibility as being the main reason to have a low price. Unfortunately it seems that this only works very well from a business standpoint if you also invest a large amount of effort in marketing to reach people. That's not really something I enjoy doing a whole bunch, so that basically leads me more towards focusing on more professional level users who can more easily afford anything in the $500 range if it helps them get their work done.


> Please dont jump up and down on me for this comment, it is just my thoughts.

No, no problem - I'm sure there will be plenty of people who will be upset at any price increase at all. Then at the same time there will be plenty of people who won't care at all! I would kind of go a bit crazy if I worried about the first group all the time though. I mean there have been a bunch of people who have told me that I should make MoI open source and available for free and that I could pay my bills with the good karma that this would generate! :)

- Michael

At one point Hexagon was $1.99.
Double CAD XT--free
XSI Mod Tool--free
ViaCAD $99
Blender--with Nurbs(big Nurbs update coming)---free
3DCoat---update from V2 to V3 will be $80 (HUGE difference in what is in V3)

Jusat food for thought

Brian

Hi Brian, that's great if those cheap/free apps do what you need!

MoI is more of a "finely crafted" type product, it especially takes a long time to do a very high quality UI design.

If you don't place a lot of value on the highest quality UI and workflow, then probably MoI is not going to be the right choice for you, you should use one of those free programs instead if price is your overriding concern.

Just more food for thought! :)

- Michael

Insane!!! I will be able to purchase MoI V2 for $100.00???? This is unprecedented for the type of application we're using here.