Hi ed,

> The way i did it the first time was just pasting the shortcuts
> on my old ini file on windows, that way it doesn't work, but
> it worked when I just added one like L=Line. Here is the list
> of shortcuts I entered the first time:

So when you say "pasting the shortcuts" do you mean pasting them directly into the moi.ini file using some text editor application? If so which text editor are you using?

Or do you mean pasting them in one at a time using the Shortcut Keys UI in the Options dialog?

Because I'd like to try and repeat the problem over here.

If you're using a text editor program to edit the moi.ini file directly, make sure you save it as "plain text", and not as something like .rtf format which won't work properly.

- Michael

Well I opened the windows-moi-ini on notepad and then from mac-moi the ini launched on textedit.

I tried again and from what i saw i think what you said is right, the two text editors are using different formats of text, or maybe copying text from windows notepad on parallels to text edit is the problem.

That was the problem! I opened both .ini on text edit and everything passed right from one file to another!

Hi dinos,

> In fact i find it amazing that you took all this time to answer
> my post, point by point, even though i'm not even a customer
> of yours.

Well, I kind of have to because it could otherwise cause FUD about performance when that seems to be an area that is actually handled particularly well by this porting method...


> Yes there is a bit of an issue with resizing the window but i can
> live with that.

I do expect to work on improving this.


> The same about the rather long launching time.

That's actually caused by this anti-cracking obfuscation and encryption mechanism called Themida/WinLicense which moi_lib.dll is processed with. That's only on totally public releases that I ship out, it's not on the actual full version releases that use a license key. So on the full version this particular slow startup issue will not be present.


> Still thats just a benchmark which is largely irrelevant
> in this case as i agreed with you that the UI is more than
> fast enough as it is, and the viewports run at native speed.

I don't really know exactly what is going on with that particular HTML benchmark (for others wondering what this is about, it's about the performance of the HTML used for the GUI elements like the buttons and menus and such, not the 3D display area and not geometry processing) - it could just be a difference that the WebKit that MoI uses is about a year old and maybe they've made some tune ups to DOM handling since then.

I'm not at all concerned about it, since that benchmark measures a particular area of large quantities of DOM manipulation which does not crop up inside of MoI. So since that area is not currently a bottleneck, an improvement in it would not have any noticeable practical effect, other than just making the numbers of that benchmark look pretty.

Again, the key thing if you want to judge UI speed is to simply use the UI in the application itself, why worry about what is even labeled in the URL as an "artifical" benchmark ?

If the UI is already behaving in a fully responsive and seemingly instantaneous manner, then you are not going to see any noticeable improvement in things that only end up saving a millisecond or two here and there in the way that things are actually used.

And if the UI is performing smoothly in regular operation, it just does not make sense to worry about a theory that you think it ought to perform poorly - I mean you have direct "real world, not artificial benchmark" evidence to the contrary.

Are you trying to do some kind of unusual thing with some custom UI where large scale DOM manipulation performance is a particular issue for you?


> "There you have an excellent program, that uses Webkit for
> the UI, OpenGL for the viewports and even the html is very
> OSX like. And its going through all these layers!"

Yeah but it also uses stuff like COM for the object model and interprocess communication, and all sorts of various Windows API calls for things like multi threading, synchronization, top level window management, timers, etc...

So there's just a wide variety of all kinds of stuff that would need rewriting in order to do the kind of approach that you were describing. It adds up to a whole lot of work and it's pretty hard to even judge the volume involved, which tends to be a sign that it would drag on and on for a really long time. It could even be such a long time involved that it could be in the areas of an endless huge time sink that would never actually be completed. Things of that nature can actually be a project ending type strategy because of all the potential negative side effects like burnout and stagnation.

Meanwhile Wine has implemented all that various Win API stuff already using a unix back end, with generally excellent performance...

This information should shed more light about the reasoning behind this particular approach. ;)

I was not really sure at the start that this method was actually going to work, but I thought that it was worth a try since the potential payoff was significant and I don't think other approaches would have been feasible. I'm pretty sure at this point that it's going to work though, at least for the vast majority of users who care more about how it actually runs rather than if it's "100% pure Cocoa" ...


I do actually have some native cocoa elements for particular targeted areas like the file dialogs.


The other really good thing about this current approach is that it gives parity between the Windows and OSX version. I generally expect for the OSX version to have the entire same feature set as the Windows version and after just a little bit more refinement and tweaking I expect for new features that are implemented to come in directly on the OSX version with no extra effort needed on my part, unless there is some kind of external library dependency involved.

That parity is quite frequently not the case when there is a stronger bifurcation between the different versions of the software. When there's more effort and too much different behavior involved for one of the versions it is easy for one of them to lag behind the "main version", sometimes quite substantially.

So a "full low level port" type approach can easily have its own set of drawbacks too.

- Michael

I'll try and repeat the problem, so far , all I can say is it starts to happen when I've been using MOI for over 1hr, when I work, I do a lot of Undo's and I'll take an object I'm working on make a few copies and try different things on, so my files can grow quite large to I delete all temp objects.

I'm also have MoI set to mm, and tend to work on objects under 200mm

Some of the other things that start to happen, I might try to union 2 solids and , in stead of 1 single solid, it ends up removing 1 solid.

But I can't 100% rule out user error, has I'm been using MoI less then a month with no back ground in modelling software :)

Hi Steve,

> I'll try and repeat the problem, so far , all I can say is it
> starts to happen when I've been using MOI for over 1hr,
> when I work, I do a lot of Undo's and I'll take an object
> I'm working on make a few copies and try different things
> on, so my files can grow quite large to I delete all temp
> objects.

So unfortunately these are not really well defined concrete steps that I can repeat myself over here - over here I also use MoI for over 1 hour at a time and don't run into that. So I don't know if it's possibly related to some kind of difficult geometry situation (like booleaning objects that are barely grazing each other at a shared edge or doing booleans between surfaces that have self-intersections like they fold back over top of themselves or things like that) which I tend to avoid but which you're doing somewhat frequently or something like that.

I appreciate the bug report, but right now there isn't much for me to go on to attempt to do anything about it. In order to fix a bug I need to narrow down where in the program code it's actually happening and it really helps for me to be able to repeat the problem over here so I can examine what is actually going on in the debugger.

If you run into it again, I guess try to save the file off so that I can take a look at it and see if I can repeat the problem with it, or maybe offer some suggestions about some particular type of situation that can cause model integrity problems and should be avoided.

Thanks,
- Michael

Hi Steve,

> Some of the other things that start to happen, I might try
> to union 2 solids and , in stead of 1 single solid, it ends
> up removing 1 solid.

Just in general that kind of thing can happen if one of the objects is not actually a solid anymore and has ended up with an opening in it, or if the solid has become ill formed and does not have a uniform inside and outside region to it anymore - that can happen if pieces of your solid are made up of surfaces that intersect themselves, like they bunch up in some awkward way and push through some other portion of themselves. Or the equivalent thing can happen if the trimming boundary of a surface intersects itself, that kind of messed up trimming boundary will usually have some weird shaded display in that area as well.

So anyway I don't know if that helps but that's the type of stuff to look for when you run into that.

You can tell if your object has become an open surface by looking at the type indicator in the upper-right corner of the screen, if it says "Joined srf" or "surface" instead of solid then it means it has an opening in it somewhere.

- Michael

Hi Michael.

Thanks for taking all this time to explain the technical reasons for your choices on the mac port.
Given all the reasons you mention in your post, it is quite clear to me that this is the right choice and the main reason that i can have Moi3D running on my mac :-)

It is very usable and fast as it is, and i will definitely purchase a license as soon as i can justify the investment.

Is there possible to open two MoI windows at once?

Yes, in the menu bar choose MoI > New Window.
Note that it takes several seconds to open the second window.

Didn't noticed, thanks!

I don't know if someone had this problem before but I can't open a file from the MoI window, I have to double clic the file from the finder.

Hi ed - can you please describe in a bit more detail exactly what you mean by "open a file from the MoI window" - do you mean using the "Open" button on the File menu in the lower-left corner of the MoI window does not work to open a file for you?

- Michael

Hi Ed,

Don't know if this is related, but I cannot open MoI files when I am online with Mozilla Firefox. But this is on a Windows Vista PC, not a Mac OS.

Michael T

Hi Michael T - hmm that's kind of odd that Firefox interferes with opening MoI files.

What happens when you go to the File > Open menu in MoI, does the file dialog just not come up, or does it come up but not let you pick a file, or does it let you pick a file but then not load it, or something else?

- Michael

Weird, seems to work fine today. I may have spoken too soon. Possibly my Vista OS or user error :-)

Michael T.

I don't know if this is the problem but I can't open or save files to a folder that is inside a lot of subfolders, but I can open and save to the desktop.

Hi ed,

> I don't know if this is the problem but I can't open or
> save files to a folder that is inside a lot of subfolders,
> but I can open and save to the desktop.

Could you please post an example sub-folder path that does not work for you?

Maybe there is some bug with handling a path with certain kinds of characters in it.

I have tested over here with opening and saving files to and from nested sub-folders and I don't seem to have any problem with that, so it may be something about the particular path that you're using.

- Michael

It opens files on the "7mo. S" folder but it doesn't on the "Diseño 6"

/Users/edwinescobar/Documents/Works/U/7mo. S/Diseño 6