Hi arekm,

> Will it be using more crossplatform stuff (is it switching to qt5?), so maybe sometime in
> future Linux version will be a real possibility?

Yes, I am moving it to use Qt5 for a cross-platform code base. So it does open up the possibility for a Linux version in the future. But it will still involve a lot of work to support each additional platform so it's not likely to happen right away, maybe the next version after. Just targeting 2 platforms is pretty difficult enough for the time being.

One of the things that concerns me a lot about trying to support a native Linux version is dealing with bad video drivers which seem to be prevalent.

- Michael

Since discussion is about V4...just side note about good old fillet.

Any plans also for moi3d V4 to make fillets more robust, faster to calculate and lass prone to failure?

Hi keyi,

> Any plans also for moi3d V4 to make fillets more robust, faster to
> calculate and lass prone to failure?

Later on in v4 I'll be doing some experiments with using different geometry libraries and see if it will be feasible to get filleting done by some other library.

- Michael

I would say - rely on qt5 rendering and don't go lowlevel into drivers. If driver is buggy then mention that (or better bugreport into mesa.org/freedesktop.org bugtracker) and do not workaround. intel, nouveau, radeon drivers on linux are maintained, so should get bugfixes after that.

Doesn't qt5 give enough crossplatform to do not care (much) whether we are on windows/mac or linux? Some crossplatform build system (cmake.org prehaps)

Hi arekm,

> I would say - rely on qt5 rendering and don't go lowlevel into drivers.

That's fine for the GUI - but not for MoI's 3D viewport window - the 3D viewport needs to use hardware accelerated 3D graphics and that is dependent on your video driver.


> If driver is buggy then mention that (or better bugreport into mesa.org/freedesktop.org
> bugtracker) and do not workaround.

This is precisely the type of extra additional work burden that I'm worried about.


> Doesn't qt5 give enough crossplatform to do not care (much) whether we are on windows/mac or linux?

For a fair amount yes, but there are enough quirks on each platform that supporting a new one does not happen "for free". Much of the code is more cross platform C++ code rather than Qt specific stuff. Even just the workload of doing builds on another platform adds to the amount of work that I need to do. It takes time to learn all the quirks and toolset behaviors on each platform.


> Some crossplatform build system (cmake.org prehaps)

That's another issue - right now I don't have the build itself to be cross platform, I'm more comfortable using an IDE so I'm using Visual Studio on Windows, and XCode on Mac, and I would need to do some more work to make the Linux build happen.

So there are various things each of which require more time spent on them, which is difficult to do when time is in short supply...

Then the problem is after spending that additional effort, what is the overall benefit as far as how many users are actually served by that work. If it's a very small number then it's not cost effective.

It's a possibility for the future but probably not for the v4 time frame. It's already a huge undertaking just to get a native Mac build as it is.

- Michael

>> I would say - rely on qt5 rendering and don't go lowlevel into drivers.

>> That's fine for the GUI - but not for MoI's 3D viewport window - the 3D viewport needs to use hardware accelerated 3D graphics and that is dependent on your video driver.

You mean you need to do viewport hangling directly by avoiding qt5? I was hoping that things can be made crossplatform by only using qt5 and relying on qt5 ability to use underlying 3d acceleration in the system (opengl on linux, whatever is available on windows/macos).

http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
http://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration

(if that would work then in theory moi3d would even run on software based opengl (which is available on Linux by default) ... not really usable for normal work but it would run)

Hi arekm,

> You mean you need to do viewport hangling directly by avoiding qt5?

Pretty much - certainly on Windows I'll continue to use Direct3D same as it currently does. Then for other operating systems I need to make an OpenGL port which will make OpenGL calls instead of Direct3D calls.


> I was hoping that things can be made crossplatform by only using qt5 and relying on qt5 ability to
> use underlying 3d acceleration in the system (opengl on linux, whatever is available on windows/macos).

The more of a packaged up abstraction that is used, the harder it can be to get the particular specific behavior you want.


> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html

Even though this one is based on OpenGL, it's more about doing 2D GUI handling using OpenGL for displaying animated controls and things like that, not for heavy 3D model content.


> http://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration

I will probably be using some of this stuff - but this stuff is basically a fairly thin wrapper around OpenGL - if your video driver does not work properly it won't save things from that.


> (if that would work then in theory moi3d would even run on software based opengl (which
> is available on Linux by default) ... not really usable for normal work but it would run)

I can't really target software only 3D graphics, it's just too slow.

- Michael

Thats fantastic news Michael, If you don't mind me asking I would like to hear your thoughts on Apple's Metal API.

The question is (considering you going for a major rewrite) Wouldn't it be a better investment for the long term to adapt Metal instead of OpenGL?

Hi adamio, I have not really looked into the Apple Metal API.

> The question is (considering you going for a major rewrite) Wouldn't it be a better
> investment for the long term to adapt Metal instead of OpenGL?

Well, it would not be good for future additional cross platform considerations - the Metal API is proprietary to Apple and is unlikely to be supported on other operating systems like Linux for example.

Also I would not be surprised if they will only make it available on pretty new versions of OSX, it's unlikely to be back ported to old versions. So that would make it a bad choice for compatibility even with OSX since it would prevent MoI from running on many versions of OSX currently in use...

So those are some big compatibility limiting problems that I would see with that strategy. Those are big enough problems that my first impression is that it would not make sense to target it instead of OpenGL for current considerations.

- Michael

Hi Michael, Correct Metal It's not OS independent, Apple FINNALLY taking control of the their low-level 3D API on their platform putting Nvidia and others where Apple wants them… as just another potential chip vendor. Something that Microsoft has been doing successfully for year with Direct3d…

By now we all know that "open standards" is an UTOPIA (at list in this case). For example Nvidia’s OpenGL is complete and functional, everybody else’s is crippled and inconsistent in random ways, that’s hardly a standard.

Also note that The khronos Group is ditching OpenGL in favour of VULKAN which I guess will have the same destiny as openGL IMO.

Anyway for year end users & developer been putting pressure on Apple for better drivers support etc.
Their answer is Metal and it look very attractive.

Now the ball is now in the developer court :)

Some examples from early adapters.

The Foundry demoing Metal in MODO at approx. 11:00
https://developer.apple.com/videos/wwdc/2015/?id=603

Adobe, demoing Metal in Illustrator and AfterEffects at approx. 1:32
https://developer.apple.com/videos/wwdc/2015/?id=102

Michael just to be clear I not asking you to go the extra mile and support Metal ( which I think would be great :) I am just thinking out loud.

Hi adamio, it's still early yet to know what will happen with Vulkan - that's another additional factor that makes it kind of unwise for me to jump in with Metal support right now.

But definitely the biggest barrier for me is actually OS X support - meaning all the already released versions of OS X. From what I have seen so far, Metal will only be supported on 10.11, probably not on any previous version. So if I were to only target that for the graphics API to use, MoI would not be usable on earlier OS X versions at all. That's an extremely significant disadvantage compared to targeting OpenGL, which does work on all versions of OS X.

If you can find out if Metal will be supported on earlier versions of OS X, that could make it a lot more interesting for me to look into.

re:
> Some examples from early adapters. <...>

Well, I hope you're aware that the Foundry and Adobe have considerably more developers working for them than I do. That makes it feasible for them to work on Metal as a side engine instead of their only supported one. Please keep in mind that I'm only one single person doing all the development work for MoI and that makes it difficult for me to do exploratory side work, I need to focus my efforts on the main line work that will be used by the most people.

- Michael

>If you can find out if Metal will be supported on earlier versions of OS X, that could make it a lot more interesting for me to look into.

According to Apple OS X adoption rate is very high, 55% of all mac are running the latest OS X. I thing you shouldn’t worry about that, after all upgrading OS X does cost $0.

Also Rav Dhiraj from the GPU software division states at 8'40"
Metal is supported by all Macs introduced since 2012. (Nvidia, AMD and Intel)
https://developer.apple.com/videos/wwdc/2015/?id=603


>Well, I hope you're aware that the Foundry and Adobe have considerably more developers working for them than I do. That makes it feasible for them to work on Metal as a side engine instead of their only supported one. Please keep in mind that I'm only one single person doing all the development work for MoI and that makes it difficult for me to do exploratory side work, I need to focus my efforts on the main line work that will be used by the most people.

Michael I am well aware of that and thats one of the reasons of me proposing Metal, (once the initial transition and teething pains are past) will actually be easier to maintain, with less time worrying about various driver and hardware compatibility issues.

Hi adamio,

> According to Apple OS X adoption rate is very high, 55% of all mac are running the
> latest OS X. I thing you shouldn’t worry about that, after all upgrading OS X
> does cost $0.

That's not enough for me not to worry about it - that leaves 45% of the Mac user base unable to run the software. That's a lot.

I currently have some MoI users running on 10.6 right now. I'm still hoping to support that on v4 but I'm not entirely sure if that will happen or not, it's possible I may need to require 10.7 minimum. But certainly jumping to require 10.11 is a very long way off from what I'm shooting for.


> Also Rav Dhiraj from the GPU software division states at 8'40"
> Metal is supported by all Macs introduced since 2012. (Nvidia, AMD and Intel)
> https://developer.apple.com/videos/wwdc/2015/?id=603

But only when it's running 10.11, is that correct? No support on any currently released version of OS X, even 10.10 ?

- Michael

But only when it's running 10.11, is that correct? No support on any currently released version of OS X, even 10.10 ?

> Correct is an El Crappy situation for users running old OS...

OS X v10.11 Developer Beta supports the following Macs:

iMac (Mid 2007 or newer)
MacBook Air (Late 2008 or newer)
MacBook (Late 2008 Aluminum, or Early 2009 or newer)
Mac mini (Early 2009 or newer)
MacBook Pro (Mid/Late 2007 or newer)
Mac Pro (Early 2008 or newer)
Xserve (Early 2009)

Well that makes it an easy choice not to worry about targeting it for the time being. I need an API that will be supported by 10.7 at a minimum.

Requiring 10.11 just to run MoI is a no-go.

- Michael

As a Linux user, obviously a native version would be ideal, but I'm happy as long as I can at least continue to run it with Wine.

Too bad that 64 bit wine is only able to run 64 bit windows binaries (here on my Linux there are no 32bit libraries at all, so unable to run moi3d). Hopefully v4 will be 64bit binary, too.

I think most distros include Wine compiled with both 32 bit and 64 bit enabled. I know that's true on Ubuntu and its derivatives (Mint, Elementary, etc.). I read that CentOS and RHEL only include 64 bit Wine, which I don't think is considered stable anyway, so that seems kind of silly to me.

Ohh, a 64bit version , that would make my day :).

Thanks for update Michael.

Hi Michael,

I was wondering if you are using Visual Studio 2012, or 2013, or 2015? As C++ compiler with Qt5...

I would guess that the commercial version of Qt5 cost $ ?


- Brian