Hi artisanicview,

> Maybe because I also have other Wine applications in my system?

It's not supposed to be a problem to have this, but maybe there is some kind of bug related to that.


> P.S. I opened Console and read the logs. Seems that
> WineskinX11 is crashing. If you need the crash logs I
> can sendyou.

Yes, can you please e-mail them to me at moi@moi3d.com so I can take a look.


Thanks,
- Michael

Hi everyone. I have been lurking in this forum for sometime now, but this is my first post here.

Let me just say that i like Moi3D a lot! The user interface is logical, very friendly and in some cases genius. Coming from Rhino, i find a lot of things that frustrated me in that program easily accessible and logical in Moi3D, so congratulations Michael.

I use a Mac exclusively so I am really glad that an OSX version has been released. I am also a software developer, although nowhere near Michaels level.

After playing with the OSX version for a couple of days i think i can offer my honest opinion on the state of the current port.

Michael, as a fellow developer i can easily understand the reasons you decided to use WineskinX11 to do the port. But after examining the application folder for a few hours, trying to figure out the internals of the application, this might have been the wrong decision.
As far as i can tell you are using QTWebkit on windows for the user interface and OpenGL for the views. Also a number of other dlls that provide additional functionality. Using WineskinX11, your are going through a huge number of layers in order to actually do something as simple as receive an event.
The sequence is probably: Cocoa -> X11 -> Wine -> Qt -> Webkit -> Your code.
And all this time Webkit is natively available on OSX! I would imagine the process is similar for OpenGL, which is again natively available. Moi3D is really fast now, but i can't imagine how much smoother it would have been if you could use OSX directly. Even if you would prefer to use Qt for the OSX version to simplify the port, the benefits will still be enormous.

I'm sure that using WineskinX11 seems attractive. "Just compile the same code and you are ready to go". But, as you go deeper into trying to make it look native, it will get complicated. A lot. You will have to address issues at the user experience level, and at a lower lever. Things like keeping all data in Applications Support in order to survive updates, custom plugins that require something other than javascript, UI inconsistencies and a number of other issues i can't begin to imagine. Issues that you will eventually blame on WineskinX11 and you will have no control over them. And it will never be as smooth as a native app, even though the math are running at almost the native speed.
Now, unless some of the external libraries you are using are not available for OSX, your time might be better spent doing a native port. This current version is good enough for a first mac version and its fully usable. I am quite happy to use it over wine or the windows version while i wait. But you application is ideally suited for a full port. Even the html/javascript UI looks mac like!

So i would sudject releasing this version as an intermediate version as planned, and at the same time consider doing a full native port. It will definetly save you a lot of time and frustration in the long run.

Well, there goes the only reason I had for keeping a Windows machine around.

Brilliant!

Thanks Michael.

C.

Hi Michael

Had the same thing happen again yesterday, was working on the attached file, last night, after about 1 1/2 hours working with the same file, I was trying to Boolean Union, the Green and Red solid objects, The objects was created by first making the main "bead" then sweeping the edges (rims).



When I Bool-Union the bead and 1 rim, all OK, 1 new solid, when I union the result and the other rim , ended up with the following defect,







Left them has two separate solids, did some other work , went to bed, this morning open the same file, Bool-union worked fine, first thing I tried.
Went back to through some of the incremental saves, where I first noticed the defect and again it worked fine.

Very strange, last night I did not think to restart MoI and see if that made a difference .

Hi dinos, I'm really glad that you're liking MoI!


> But after examining the application folder for a few
> hours, trying to figure out the internals of the application,
> this might have been the wrong decision.

But why are you basing your judgement on this kind of analysis of the application's internals rather than just basing it on the actual experience of using the program?

It's far more practical to look at how the end result actually functions rather than worrying all about theory...


> The sequence is probably: Cocoa -> X11 -> Wine -> Qt ->
> Webkit -> Your code.

Yeah, it does end up going something like that, although I think that X11 receives its stuff from the lower level internal CG library and not Cocoa directly which is also built on the same kind of low level stuff as well.

But generally these levels are just passing things through with minimal work done.

The couple of extra function calls involved would have been an issue on something like a 486 computer 20 years ago but on any computer made in the past 10 years or so it's not an issue at all.

The main proof of this is just in using the program itself - moving the mouse around and drawing things feels really very snappy and quick, the only exception is resizing windows, and I will be doing some work on improving that.

But the empirical evidence that I've seen and that I've heard universally from users about performance is that it's very responsive, and so the theoretical issue that you don't like the internal architecture just does not amount to an actual problem in real world usage.


> Moi3D is really fast now, but i can't imagine how much smoother
> it would have been if you could use OSX directly.

Maybe something on the order of 1 millisecond smoother (again, with the exception of window resizing) - most likely nothing that you would be able to notice or really be able to measure.


> But, as you go deeper into trying to make it look native, it will
> get complicated. A lot. You will have to address issues at the
> user experience level, and at a lower lever.

This has already been largely addressed in the most recent beta which has support for native file and save dialogs.

I think it's going to be an intentional design goal that other than at a few particular points like those dialogs that the UI for the OSX and the Windows versions will be the same, which in MoI's case works out ok since it was not really ever set up to look or behave like a standard boilerplate Windows program in the first place. So in the same way that I ignored many Windows UI conventions, it doesn't really bother me to ignore some of the OSX strict conventions as well and have something that has its own UI instead of boilerplate.


> Things like keeping all data in Applications Support in
> order to survive updates,

This is already done - as of the most recent beta things that are supposed to survive updates and be separate from a particular installation are stored in ~/Library/Application Support/Moi , like for example the moi.ini file lives there now so any settings that you set in this most recent beta will persist with a new beta.

So that's a solved problem, what's the big remaining issue with it?


> custom plugins that require something other than javascript, UI
> inconsistencies and a number of other issues i can't begin to
> imagine.

In the future if it's possible to make a custom plugin with a C++ dll and the same exact binary plug-in will work on both the Windows and OSX versions with the same binary, how is that a bad thing?


> And it will never be as smooth as a native app, even though the
> math are running at almost the native speed.

That's incorrect - math and pure calculations are absolutely running at 100% native speed - it's loading native x86 machine code and running that code directly on the CPU. That part is not "almost" native speed - it's fully native code execution.


> Now, unless some of the external libraries you are using are
> not available for OSX, your time might be better spent doing
> a native port.

The problem is that what you are asking for would require an enormous investment of time, there is so much stuff that would need to be rewritten, it's simply not something that is feasible for me to tackle.

And I have to balance that against what the actual practical benefit would be once all that work is finished, which would mostly seem to be just some kind of abstract architectural purity and not really any actual measurable improvement.


Anyway, I'm sorry that you're disappointed in some way with the OSX version, I guess I can understand that if you're really into consistency as a really high value thing that you might not like it when an app goes outside of that. There do exist some people that don't like the Windows version for the same kind of reason - that it does not just follow a standard Windows UI approach either. I guess if you're really into a program following a standard boilerplate UI with no deviation from standard controls and the like, that MoI just won't be a good fit - it's just not what MoI is about - right from the beginning I was not afraid to experiment with different kinds of UI with MoI and that's sort of embedded in its design philosophy that differences from a standardized UI are not automatically a bad thing.

I can understand though if this does not agree with your own design philosophy which from what you are describing it seems that it doesn't. And sure, I can understand that you wish that MoI was developed with the same design philosophy you have... But it's not.

I do wish though that you would be more concerned with actual empirical problems with the current OSX version rather than worrying so much about theoretical purity.

There were times when I wondered if it was really worthwhile to even attempt an OSX version because there is a kind of undercurrent of intolerance for things that deviate from the "one true way of Cocoa"... That's kind of what I'm getting from what you're describing here. But it seems that for the majority of people anyway, more practical concerns like "does it perform well", and "is it easy to use without special installation tricks" and things like that seem to trump worrying about architectural purity. And I think the current version is hitting those targets.

I mean like for example right now when I go to draw a circle, the circle redraws on the screen what appears to my eye as instant feedback from when I move the mouse. I don't understand how you think there is going to be any improvement on that? I mean what faster level is there than instant?

Maybe I should not have written all of this since you will probably perceive it as an attack on you. Instead please think of it as more of a disagreement with your conclusions.

- Michael

Hi dinos, so I mean I guess I would say things more clearly like this -

I would certainly understand your concern about the layering of the internal architecture if there was some sluggishness or performance problems and a cause for those performance issues needed to be located.

What I don't understand is why you are worried about it when it should be easy for you to see yourself just with basic direct use of the app that such a systematic performance problem does not exist?

I mean why would I do a ton of work on rearchitecting things to solve a problem that isn't there in the first place?

Is your machine behaving vastly different from the machines I'm using over here? I mean over here basic stuff happens totally instantly - when I move the mouse over the UI the UI is very responsive, buttons highlight instantly. Collapsing or expanding a palette happens instantly, when drawing a circle or a sphere in the viewport for example the viewport display instantly updates in response to movement of my mouse.

Is what you experience so totally different from what I've seen over here?

The one exception is that there is a performance problem on window resizing, I am still planning on doing some work on that. Other than that though, why worry about basic performance with event handling when it seems to be so clear that it's not an issue?

- Michael

Hi Michael.

> Maybe I should not have written all of this since
> you will probably perceive it as an attack on you.
> Instead please think of it as more of a disagreement with your conclusions.

I see nothing in your post that i would consider a personal attack. 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. I really wish more developers where that involved in the discussions about their applications and the community in general.

> There were times when I wondered if it was really
> worthwhile to even attempt an OSX version because there
> is a kind of undercurrent of intolerance for things that
> deviate from the "one true way of Cocoa"...

Reading my post for a second time, i can see how a few of my remarks could make me look as an apple style guide fanatic or a true believer in the "one true way of Cocoa".
Far from it. I have been using professional 3D software, for more than 25 years. I am fully aware of the complexities of their UI design and how thinks can get messy really quick. Not one of the applications that i like uses the standard interface of the underlying OS. It might even be impossible, as 3D modeling is a very complex process and its demands are far greater than the problems the standard style guides where design to solve. The same goes for graphics applications like photoshop, CAD systems, video editors etc.
When i said the UI of Moi3D is genius i failed to mention is that i was also referring to the architecture. Using Webkit and javascript is what makes it customizable, extensible and generally amazing. It will definitely save me hours of tedious modeling! And i would never expect it to look like cocoa or behave like it. I am happy with the way it is.

> Is what you experience so totally different from what I've seen over here?

I've used Moi3D for a couple of days, and i have no major complains about its performance. Yes there is a bit of an issue with resizing the window but i can live with that. The same about the rather long launching time. I also retract my comment about "almost native speed". It IS native code execution as you correctly say.


> > Moi3D is really fast now, but i can't imagine how much smoother
> > it would have been if you could use OSX directly.

> Maybe something on the order of 1 millisecond smoother
> (again, with the exception of window resizing) - most
> likely nothing that you would be able to notice
> or really be able to measure.

I still have my reservations about the UI speed. I run a simple javascript DOM Core Performance benchmark in both safari and Moi3D (http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html) in order to judge to performance of Webkit in both environments.
On my macbook pro the results are:

Safari:
Total elapsed time: 56ms
Breakdown (fraction shows time relative to append time):
Append: 1.00; 13ms
Prepend: 0.92; 12ms
Index: 0.54; 7ms
Insert: 1.23; 16ms
Remove: 0.62; 8ms

Moi3D:
Total elapsed time: 336ms
Breakdown (fraction shows time relative to append time):
Append: 1.00; 74ms
Prepend: 1.07; 79ms
Index: 0.47; 35ms
Insert: 1.19; 88ms
Remove: 0.81; 60ms

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.

To conclude, I am in no way diapointed with the mac port. I absolutly love it. I am really glad you did it as i would be able to use Moi3D instead of rhino for most of my modeling.
I claim to know nothing about the internal architecture of Moi3D, other than what i can judge by looking at the application folder. So, i'm sure that doing a fully native port is a huge undertaking as you say. As a Mac user i am really grateful for the current OSX port of Moi3D and i would definitely buy it as soon as i have the first project that would justify the investment.

My post was mainly about what i thought was a missed opportunity. "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!"
After your reply i understand the oversimplification of this and the amount of work it would require. And maybe my post was based on my personal experience of having to emulate one type of UI using another and the complexity that arises in the long run due to the amound of overwriting it requires.

Hi Dinos,
Do you have the opportunity to run that benchmark with MoI with some other MAC 3d CAD program?? I would like to see that. It may be a better benchmark than with a simple browser.

As far as i know no other 3D CAD software uses Webkit for the ui..

A little question, I've tried to modify the moi.ini file for adding my shortcuts but it just added a couple of them and when I opened the ini file again, it showed a lot of letters instead of my shortcuts. Im using osx lion. Ive tried to locate the ini file and replace it with other but i can't find it manually. Where is it?

Hi ed, which shortcut key were you trying to add which didn't work? It sounds like there is some bug there that needs fixing up.

I just tried for example adding in Cmd+J for Join and it seemed to be working ok, so maybe it has to do with some particular specific keys that you were using, so I'll need to know what those are in order to fix it.

> Ive tried to locate the ini file and replace it with other but
> i can't find it manually. Where is it?

You can find the moi.ini file by going to Options > General and push the "Edit .ini file" button - that will pop up a little dialog that shows the location of the .ini file on it.

As of the most recent beta it will go under
/Users/ [your user name] /Library/Application Support/Moi/moi.ini

- Michael

Hi steve,

> Had the same thing happen again yesterday, was working on
> the attached file, last night, after about 1 1/2 hours working
> with the same file, <...>

Hmm, yeah so loading the file now I can't seem to repeat any problem with it anymore, over here it seems to boolean union into a solid fine now.

In the screenshot you show with the sort of weird wrinkle or hole near the end of a tube - that's the kind of thing that a damaged trimming boundary looks like so at some point during your work something went wrong with one operation and produced an improper trimming boundary there.

So there's definitely a bug in something, but it's really hard for me to figure out where it might have been when I can't repeat the problem in a systematic way over here, it could have been in some previous command that you used before the boolean itself.

If you find some way that you can repeat the problem in a definite series of steps then please let me know about that because being able to repeat the problem goes a long way in helping for debugging it.

- Michael

You are right Michael, it has to be an specific shortcut. The way i did it the first time was just pasting the shortcuts of 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:

B=Booleanunion
C=Copy
Ctrl+A=script:moi.geometryDatabase.selectAll();
Ctrl+C=CopyClipboard
Ctrl+E=Export
Ctrl+I=Import
Ctrl+N=New
Ctrl+O=Open
Ctrl+S=Save
Ctrl+Shift+C=CopyClipboardWithOrigin
Ctrl+Shift+V=PastePart
Ctrl+V=Paste
Ctrl+X=Cut
Ctrl+Y=script:moi.command.redo();
Ctrl+Z=script:moi.command.undo();
D=Curve
Delete=Delete
DownArrow=script:moi.ui.mainWindow.viewpanel.mode = 'Front';
E=Rotate
F=Line
F1=script:moi.drawingAids.gridSnap = !moi.drawingAids.gridSnap;
F2=script:moi.drawingAids.straightSnap = !moi.drawingAids.straightSnap;
F3=script:moi.drawingAids.objectSnap = !moi.drawingAids.objectSnap;
G=Booleandifference
H=script:moi.geometryDatabase.hide();
I=script:moi.ui.createDialog( 'moi://ui/PluginGallery3.htm', 'resizeable,defaultWidth:1000,defaultHeight:600' );
J=Join
K=Separate
L=script:moi.geometryDatabase.lock();
LeftArrow=moi.ui.mainWindow.viewpanel.mode = '3D';
M=Explodemove
N=Assignname
O=script:moi.ui.mainWindow.viewpanel.reverseView( moi.ui.getActiveViewport().name );
P=Point
Q=Offset
R=Scale
RightArrow=script:moi.ui.mainWindow.viewpanel.mode = 'Right';
S=Scale1D
Space=Showpoints
T=Trim
U=script:if ( moi.ui.mainWindow.viewpanel.mode != 'split' ) { moi.ui.mainWindow.viewpanel.mode = 'split' } else { var viewport = moi.ui.getViewportUnderMouse(); if ( viewport ) viewport.viewpanel.mode = viewport.name; }
UpArrow=script:moi.ui.mainWindow.viewpanel.mode = 'Top';
V=Mirror
W=Move
X=Extrude
Y=script:moi.command.redo();
Z=script:moi.command.undo();

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