Full Version: New Mac OSX public beta Jan-31-2012 available now

Show messages:  1-20  21-40  41-60  61-80  81-100  101-103

Hi olio,

> Michael... You are unbelievable! Moi looks amazing on OSX,
> It feels like you developed a native OSX app!.

I'm glad it is not feeling too out of place for you!

I think having the native file open and save dialogs helps quite a bit.


> Everything is very snappy, viewports are smooth and fast,

Great! Yes, that's one of the best advantages of this porting method - MoI's own program code runs directly and so it runs at full native speed when doing its own calculations.


> there are occasional display glitches when e.g. turn on
> the browser or switch viewports, but that is not even
> annoying:)

Yup, this hiccup happens when a 3D viewport gets resized - I'm going to be looking into it to see if I can fix it up, but at least it's only a cosmetic problem and not something that really gets in the way of actually doing stuff.

- Michael

---

thank you Michael.

spent about 2 hours with it last night, touching up some models I thought I had completed :)

worked fine for the simple stuff I'm doing.

Cheers, Steve

---

Don't work for me.

Wineskin Error.
"ERROR! Launching wineserver failed! No new wineserver PID found!"

I enabled and disabled "Wineskin Winery" in firewall from System settings. I don't know what to do more. Please help.

---

Michael,

I spent some time with this last night. The basic functions seenm to be working well for me. I will try some more complex work later.

Thanks a lot for this...

J. Tucker

---

Hi artisanicview,

> Don't work for me.
>
> Wineskin Error.
> "ERROR! Launching wineserver failed! No new wineserver PID found!"


Do you possibly have some kind of restricted permissions set on your system, especially on your temp folder?

If so then that could cause problems like this - this probably means there was some problem setting things up in /tmp

You also might try doing a system reboot which will clean out your /tmp folder and maybe that will help.

But if you have done some kind of lockdown process on your machine's tmp folder you may need to set that back to its original permissions in order to get MoI to run.

- Michael

---

Thanks Micheal!!

Works great on my mac pro running 10.6.8

---

I rebooted, and no change. I'm getting the same error.

> But if you have done some kind of lockdown process on your machine's tmp folder you may need to set that back to its original permissions in order to get MoI to run.

Please, can you be a little more explicit? I can't find any tmp folder in my system. I have a MacBookAir 13" from 2010 with OSX 10.7.1

---

Hi artisanicview,

> Please, can you be a little more explicit? I can't find any
> tmp folder in my system. I have a MacBookAir 13" from
> 2010 with OSX 10.7.1

There should normally be a directory named /tmp at the root of your filesystem.

Why was it that you set up the firewall initially, were you following some instructions on how to lock down your system? If so, can you point me to those instructions? They might have involved changing some default setting in your filesystem in such a way that MoI won't run on your system after that.

Or are you possibly running any kind of system-wide utility programs like a virus checker or anything else similar to that?

- Michael

---

was looking forward to trying this but i'm getting these errors related to wineskin when i try the Mol v2.5 beta jan-31-2012. i'm using OS10.5.8.

Image Attachments:
error moi.jpg 

---

Hi Ronaldo,

> was looking forward to trying this but i'm getting these
> errors related to wineskin when i try
>
> i'm using OS10.5.8

The MoI OSX version requires OSX version 10.6 (Snow Leopard) or 10.7 (Lion).

It will not run on OS 10.5.x , so that's the problem that you're running into.

This is because Apple's current development tools will only produce programs that work on 10.6 or higher.

- Michael

---

i see, that explains it. another reason to go to snow lion. am looking forward to trying it. will be back. thanks very much.

---

Hi Michael

I had been using the OSX public beta for about 2 hours working with the same file (but I do use incrementalSaves) then all of a sudden and boolean functions like merge and diff, started working very weirdly , shut down MoI loaded up the same file than boolean functions started working correctly .

I've almost finished for tonight, if I get the same problems again, I'll let you know

Cheers, Steve

---

Hi Steve - if the objects that you were working with became open surfaces instead of a closed volume, that will make the booleans behave differently since they're mostly oriented towards working on closed volume objects.

So if you run into this again, look at the object type indicator when your objects are selected - that's in the upper right corner of the properties panel that shows the properties of the current selected objects. If that indicator says "Surface" or "Joined Srf" that means that the object is not a closed volume, it will read "Solid" if it is closed.

Anyway, that's one thing to check on if booleans start to behave differently.

- Michael

---

I tried all sorts of thing. I changed permissions on /tmp directory, I activated and deactivated the firewall and nothing. I'm getting the same error message. Maybe because I also have other Wine applications in my system? I have WinOnX and also some Windows games wrapped as executables around Wine to make them work under OSX.

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

---

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 .

Attachments:
test14.3dm

Image Attachments:
Screen Shot 2012-02-11 at 8.38.29 AM.png  Screen Shot 2012-02-11 at 9.03.04 AM.png 

---

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

---

Show messages:  1-20  21-40  41-60  61-80  81-100  101-103