Dear Michael,

I also had a quick test of Moi in a WinXP Pro 64 VM under VMware Player 3.1.4 on my Ubuntu 11.04 laptop today. There I got a strange effect in the Split view: The 4 views always showed identical content like all 4 were Top view or all 4 were 3D view and so on... flipping over on mouse moves, see attached screen-shot.
I don't know if that is of any help, just meant to share it with you in case...

Kind greetings,
Chyman

Hi Chyman - that's almost certainly a bug in VMWare Player's Direct3D system.

In order to conserve video memory MoI normally only actually uses a single swapchain for the split view and redirects it as needed to the current viewport that's being drawn at that moment. That's totally supported by the real Direct3D system but it seems that Wine's Direct3D layer doesn't like to render a swapchain to different windows like that and sort of wants to lock each swapchain down to only being displayed in a single window.

I've been doing some work recently to make an option to use a separate swapchain for each individual viewport window instead of only using a single one which should help to avoid this bug.

- Michael

Hi Michael,

thank you for giving a detailed explanation. The VMWare Player was just a quick side test, I would rather prefer a Wine solution than a VM one.

I have posted my Wine problem also on the WineHQ forum since it behaves the same with a simple OpenGL test (qtgears.exe):
http://forum.winehq.org/viewtopic.php?t=12426&start=0&postdays=0&postorder=asc&highlight=

Perhaps we are lucky and there are enhancements for how Wine's OpenGL and XQuartz interact...
Chyman

Hi Chyman,

> I have posted my Wine problem also on the WineHQ forum
> since it behaves the same with a simple OpenGL test
> (qtgears.exe):

Do you know if that program renders its OpenGL content into a child window instead of directly into a top level window?

Because it's that "render to child window" code path in Wine that seems to not function properly on OSX - it seems to need some particular kind of OpenGL extension that Apple does not happen to implement.


> Perhaps we are lucky and there are enhancements for
> how Wine's OpenGL and XQuartz interact...

For MoI's case I don't think any enhancements will be needed, because it looks like I'm going to be able to make a few pretty small modifications to how MoI's viewports are structured so that they will get a regular X window associated with each one and will then avoid the bad render-to-child-window code path that does not work under OSX.

That also combined with another slight modification to have a separate swapchain for each window instead of trying to share a single one seems to pretty much avoid the Direct3D/OpenGL problems entirely.

There only seem to be a few little remaining glitches in some of the UI to still clear up.

- Michael

Hi Michael,

the qtgears.exe is available from http://lab.bachem-it.com/opengl/qtgears
It is based on mesa's glxgears and also provides the source code there. Unfortunately I am not fluent enough in C++ to tell, sorry...

If you happen to know a simple Wine Direct3D/OpenGL application that renders into a regular X window I could probably make a test from the "other side"...

Which versions of Wine and XQuartz/X11 have you been testing with? What type of Mac and OS X version are you running on, if I may ask?

Thank you for all those efforts!
Chyman

Hi Chyman - I took a look at qtgears.exe using a window examination utility and the render window is indeed a child window - the menu bar, render area and bottom status bar are all separate child windows.

So most likely it is that whole issue with OpenGL rendering into child windows not working correctly with Wine under OSX that is causing qtgears.exe from not working right.


> If you happen to know a simple Wine Direct3D/OpenGL
> application that renders into a regular X window I could
> probably make a test from the "other side"...

I've attached a sample program from the Direct3D9 SDK - because it renders directly to a top level window and not into a child window you will probably find that it works ok, unless you have an old version of Wine maybe.


> Which versions of Wine and XQuartz/X11 have you been
> testing with?

Wine version is 1.3.32. XQuartz version is whatever version comes with Wineskin, I think it's a slightly older and slightly modified version of XQuartz.

The part that's good about using Wineskin is that it puts all of Wine, XQuartz and the app itself all together into one self-contained application bundle that can be run directly like a regular OSX app, so it avoids any need to set up Wine or XQuartz separately. Being based off of this should help for stability quite a bit because I won't have to deal with variations in Wine or XQuartz.


> What type of Mac and OS X version are you running on, if I may ask?

I'm on a current generation Mac Mini using OSX 10.7 Lion. This stuff should work on OSX 10.6 as well but I don't think it is going to work on 10.5 or earlier.

- Michael

Hi Michael,

thank you for examining the qtgears.exe, so that explains why it behaves very similar to MoI although it's GUI is so much simpler.

Thank you also for providing a sample program from the Direct3D9 SDK, I tried to run it but got a "Could not find any compatible Direct3D devices." message shortly after all pixel formats have been queried. Not sure what is going wrong this time... I am using Wine version 1.3.32 too... perhaps the Intel GMA X3100 hardware is a problem...

Your description of Wineskin sounds a bit like Winebottler you mentioned previously, that bundling is indeed of advantage for creating a defined environment, I will have a closer look at it.

Many thanks,
Chyman

Hi Chyman,

> Not sure what is going wrong this time... I am using
> Wine version 1.3.32 too... perhaps the Intel GMA X3100
> hardware is a problem..

Hmm, I hope that doesn't mean that MoI won't work on the GMA X3100 as well - the mac mini I'm testing with has a Radeon HD 6630M which seems to be working well.

Could you try the attached sample program and see if that one has the same problem too?


> Your description of Wineskin sounds a bit like Winebottler you
> mentioned previously, that bundling is indeed of advantage for
> creating a defined environment, I will have a closer look at it.

Yeah, it's the same kind of thing as Winebottler, but it seems like Winebottler has not had much activity around it for the past year or so, while Wineskin is quite active with the developer supporting it with a forum and updating it frequently.

- Michael

Hi Michael,

thanks for the Text3D sample, that seems to get further than the previous one and now states: "Could not find required media. Ensure that the DirectX SDK is correctly installed." Perhaps it is just missing a Font...

Maybe I try to install the complete SDK fom MS, though that is 227 MB...

So we don't give up on the GMA X3100 too quickly... ;)
Chyman

Hi Chyman, yeah that sounds like some kind of supporting materials missing, so maybe not too bad.

It doesn't look like it will take too much longer before I can have a MoI version for you to test with, maybe something like a few more days or possibly a week.

- Michael

Wow, that would be super kind to have a MoI demo for Wine to test with!

I went ahead and installed the Microsoft DirectX 9.0 SDK (Summer 2004) in Wine and continued some testing. Starting the Text3D.exe now results in a backtrace:

wine: Unhandled page fault on read access to 0x00c66c7c at address 0x430ddf2b (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00c66c7c in 32-bit code (0x430ddf2b).
...
Backtrace:
=>0 0x430ddf2b _xrenderdrv_ExtTextOut+0x95b() in winex11 (0x0032f708)
1 0x4282ef38 _ExtTextOutW+0xeb7() in gdi32 (0x0032f958)
2 0x0102ff13 in text3d (+0x2ff12) (0x0032f9bc)
3 0x01030980 in text3d (+0x3097f) (0x0032fa84)
4 0x01031de8 in text3d (+0x31de7) (0x0032faac)
5 0x0101f4e8 in text3d (+0x1f4e7) (0x0032fc30)
6 0x0107e657 in text3d (+0x7e656) (0x0032fd44)
7 0x0107fbc3 in text3d (+0x7fbc2) (0x0032fd78)
8 0x0101fe65 in text3d (+0x1fe64) (0x0032feb0)
9 0x7b84ebbc _call_process_entry+0xb() in kernel32 (0x0032fec8)
10 0x7b851a77 _start_process+0x66() in kernel32 (0x0032ff08)
11 0x7bc65d8c _call_thread_func_wrapper+0xb() in ntdll (0x0032ff28)
12 0x7bc66e8a _call_thread_func+0x89() in ntdll (0x0032ffa8)
13 0x7bc65d52 _call_thread_entry_point+0x11() in ntdll (0x0032ffc8)
14 0x7bc3f39e _start_process+0x1d() in ntdll (0x0032ffe8)
…

But I also tried the SkinnedMesh.exe and the StateManager.exe and both ran fine! I think they are much closer to MoI's needs with displaying meshes. So I think basic 3D functionality via Wine/DX9 is supported on the GMA X3100 hardware. The rest I hope is just tuning registry and dlls…

Will have a closer look at Wineskin today.

Looking forward happily,
Chyman

I'm not too keen on 11.10. Would MoI also work on an earlier version, say, 10.10 or 10.04? Just use the latest Wine. What about Mint and Puppy? Or even Kubuntu? Would they work?

Hi Sebastian,

> Would MoI also work on an earlier version, say, 10.10 or
> 10.04? Just use the latest Wine.

Yes, that should work fine, just as long as you can get a good video driver installed.

Getting a reliable and non-buggy video driver running seems to be the biggest barrier to getting things working on Linux.


> What about Mint and Puppy? Or even Kubuntu? Would they work?

I've tested with Mint over here and got it to work.

Again though the major obstacle is getting a good video driver set up.

- Michael

Michael, thank you!

First, thank you making v3 usable in Linux! I have missed MoI a lot after leaving Windows-world.

Also, thanks for important information about video drivers. I updated my Ubuntu nVidia drivers from (default) 270.x to 290.10, and v3 beta worked!

I understand that you can't possibly support every computer architecture or operating system, but this is wonderful! Many have asked for this.

--MarkkuM

Finally got round to trying this out for myself. Works beautifully. A huge bonus for Linux.

Running Mint 12.

Well...finally I changed the graphic card and now MoI runs very fine!
I had a Nvidia 6200 and it was a poor performance, actually.

¡A 10 for MoI again! :-)

Hi David, that's great news!

Yes, on Linux getting a good video driver seems to be tricky, it seems that some particular cards (specific cards I mean, not necessarily just entire brands) are supported better than others.

- Michael

This is sounding good news for me. I have been using Rhino since its early days and it's the one app that keeps tied to windows. I have a couple of questions though ...

1. New Ubuntu and Mint flavours of linux have a kernel mod that enables 32bit platforms to take advantage of systems with more than 4gb RAM, does moi see this and use it, or is that something done at kernel level ?

2. Has anyone tried rendering with blender/yafaray combination with an exported mesh from Moi, is it reliable and stable ?

I much prefer Linux to windows, and Linux's ability to address >4gb with 32bit platform is fantastic, this could be the solution i have been searching for for the last 5 years. If it works, then I will definitely spend - I am a landscape garden designer and i love the speed and accuracy i get with NURBs but i also need stability with large models. I would prefer a native linux app with no translation layers at all, but wine will do as long as it can handle the strain. My Rhino3d v4 and Vray cant hack the pressure on a 64bit windows environment which i need with windows to get all my RAM.

As a footnote, as far as i am aware AMD/ATI are now doing their very own Linux drivers for all their recent graphics cards and ATI has a better pedigree with OpenGL if i remember from the old days 3DSmax and Autodesk were supplied drivers with ATI cards, hopefully we will be going back to those days ... NVidia = Games ... ATI = Design

Martin Spencer-Ford
(TpwUK)

Hi Martin,

> 1. New Ubuntu and Mint flavours of linux have a kernel mod
> that enables 32bit platforms to take advantage of systems
> with more than 4gb RAM, does moi see this and use it, or is
> that something done at kernel level ?

I don't know the specifics of this mod, but most likely it's something at the kernel level, probably allowing the kernel itself to use more than 4GB to divide between all available processes. But any one individual 32-bit process will still be limited itself to a 4GB address space, that's just how much memory can be addressed by a 32-bit number so that per-process limit is fundamental to a 32-bit program.

If you are working with large models, one thing you can do in MoI to help is to adjust the display settings to make a coarser display mesh. By default the settings are fairly high to make for a nice smooth looking surface display but on large models higher density display meshes can consume quite a bit of memory. See here for some information about how to adjust the settings to make a coarser (and a bit more jaggedy appearing) but lower memory consuming display mesh:
http://moi3d.com/forum/index.php?webtag=MOI&msg=4196.2


> 2. Has anyone tried rendering with blender/yafaray combination
> with an exported mesh from Moi, is it reliable and stable ?

Yes, some others have used that combination ok before, here are some gallery images done with that method:
http://moi3d.com/gallery/viewitem.php?id=142
http://moi3d.com/gallery/viewitem.php?id=141

But Blender has some problems with importing meshes exported from CAD programs since it does not have the ability to read vertex normals in from the mesh file, which can result in a lower quality shading than with other rendering and modeling programs that are able to read that vertex normal shading data in and use it. As far as I know every other rendering program other than Blender is able to use that information, it seems to be a problem unique to Blender.

See here for some more information on this Blender problem:
http://moi3d.com/forum/index.php?webtag=MOI&msg=4515.3
http://moi3d.com/forum/index.php?webtag=MOI&msg=4272.1

It will still work to import the mesh into Blender but Blender will ignore the vertex normals stored in the mesh file and instead create its own vertex normals for shading just by averaging the normals of the polygonal data. That will tend to make polygonal artifacts appear in the shading.

It can help if you dice your mesh data up into smaller more evenly sized pieces using the "Divide larger than" setting like this:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2833.5

Basically because it does not import vertex normals Blender is set up to only work with sub-d type mesh structures which are all made up of small evenly shaped quads and not things like big polygons next to small polygons (and polygons at sharp angles to one another) like you will typically get with CAD generated meshes. Other rendering programs can deal with the CAD-generated data much better because they use the vertex normals from the file which come from the original NURBS data instead of being approximated from the polygon structure. When those vertex normals are used it helps to make the shading look exactly the same as the original NURBS CAD structure.

So because of this Blender is not really the best renderer to use for MoI data (or any kind of CAD-generated data), and unfortunately so far the developers have shown no interest in fixing it.

- Michael

I can speak of that to the Blender gurus, because I know some of ones ;)

Done!
So wait and see :)