LuxCoreRender Forums

robbrown wrote: ↑Sun Sep 09, 2018 7:48 pm What versions of OS X do we want to support? I don't recommend we go back to 10.6 as was before due to updates of libraries like boost. Seems like 10.10 is maybe the oldest we should go since that's the oldest TravisCI has unless there's a solid reason for something older.

I have sincerely no idea of the current status of OS X versions, etc. It is up to you (at the end of the day, in open source projects, who writes the code, takes the decisions).

robbrown wrote: ↑Sun Sep 09, 2018 7:48 pm It looks like the Linux and Windows Deps uses two repos, I made a single one for Mac because that's what the bitbucket version had. I opted to use the build scripts and tar.gz artifacts method the LinuxCompileDeps did for Travis builds, is there a specific need for two Deps repos in the new Lux Core builds? Also how best to handle a pull request of a whole new repo?

I used a separated LinuxCompileDeps repository because LinuxCompile script just download a .tar.gz from LinuxCompileDeps releases. The repository is only for developers (you don't need a clone of LinuxCompileDeps to run LinuxCompile building scripts). Storing (large) binaries on GitHub is also a bit tricky (i.e. Git LFS). I did about the same for Windows.

I guess you can follow the same pattern for MacOs but it is up to you.

If you are interested in maintaining the MacOS version, I can create the new empty repositories for MacOS on GitHUB and give you access (if you give me your GitHUB name).

robbrown wrote: ↑Sun Sep 09, 2018 7:48 pm As far as output artifacts, currently it's just building the binaries and libraries in the build directory. I see the BitBucket one made Mac OS Applications, and Mac OS Install Packages. I'm assuming we want those, the bigger question is how and where. Maintainer builds Mac OS version on a local server and puts them in GitHub release?

The platform binary maintainers usually build a release on their PC and post the packed binaries under the release of LuxCore repository for stand alone executables and BlendLuxCore for the Blender version.

robbrown wrote: ↑Sun Sep 09, 2018 7:48 pm Travis dumps to an S3 somewhere (probably costly for a free project) for Artifacts to be globed, opt to move towards App Store delivery and see if it's possible to wrap that into Travis CI on Release process?

It may be possible but TravisCI VMs have a long list of limitations, it is practically impossible to build a complete OpenCL version in the time limit available. So we are just handling the releases by hands (at the end of the day is just 1-2 stable releases and 6-7 alpha/beta per year).

Sounds good. PM sent with some deets.

I'm currently building on 10.12 so I'll see what's easiest for backward Mac OS Compatibility probably 10.11 or 10.10 and start with that. If anyone has a need for an older Mac OS version speak up and let's see what we can do.

Rob, you should have received an GitHUB invite. I have also created two empty repositories: MacOSCompile and MacOSCompileDeps.

Sounds good, I initialized MacOSCompileDeps with a README and did the usual fork PR process. I'm thinking after the PR cut a release of the MacOSCompileDeps so the PRs for MacOSCompile and LuxCore are functional using a release of MacOSCompileDeps.

As far as after basic LuxCore builds I'm thinking:

1. Vagrant VM Builds of older Mac OS versions (Currently working on)
2. Get LuxBlend building for MacOS
3. Construct Application Bundling and Apple Code Signing

Rob, thanks for your effort.

May I suggest to defer the first step to the end. Chances are good that many users would be fine with just the latest macOS version.

Hi mick, I'd agree so I took the suggestion and figured out some issues using LuxBlend for OS X pointing back to compiled but not working pyluxcore

First being a nasty boost build pointing to python2.7 only issue. I figured out how to fix that one based on what Homebrew does: Brew Build Method

The second issue I haven't completely resolved yet but am digging into is that Qt 4.8 was deprecated in Mac OS X 10.12 in favor of Qt 5 which wasn't an issue until trying to load pyluxcoretools.zip and python looking for PySide. Unfortunately for Qt 5 & Python 3.7 users, PySide2 is the only option. Thus dependency hell begins...

Seems to me there are two approaches/options:

1. Try and compile on an older version of Mac OS (Blender seems to support 10.9 most likely why they don't have Qt 5 woes)
2. Support PySide & PySide2: Porting PySide Pratices

Option 1 could be faster to result but not sure if that's punting an issue to the near future or reasonable distant future. Option 2 not entirely sure what the implications potential gotchas are on that yet.

Rob, Qt is required only to compile LuxMark and PySide is only used for some specific tool like network rendering. So, in my opinion, you can ignore the Qt 4 and not having PySide is a problem but somewhat limited (I'm you have still 99% features working).

More progress today. Figured out PySide2 business and have a proof of concept working there:
Need to validate network rendering still.

LuxBall seems to be rendering nicely with and without OpenCL.
It looks like all the .blend files don't preserve or generate the node information for Lux when they're loaded and show a bunch of missing material and node warnings so will need to dig into that. Current hypothesis is it has to do with what OS the blend files were made in because if I save it everything I did shows up.

Test files in BlendLuxCore tend to crash when loaded in blender and using the test runner yields a pass but with errors. Should they be less than a second long test? I'll get this stuff pushed into branches but not 100% sure how you'd like to see those. Feels kind of weird making a PR to master knowing there's issues but also don't want to push one massive blob of code to be reviewed. I prefer to do smaller concise PRs that can have meaningful reviews.

What version of Blender are you using ?

robbrown wrote: ↑Tue Sep 18, 2018 3:29 am It looks like all the .blend files don't preserve or generate the node information for Lux when they're loaded and show a bunch of missing material and node warnings so will need to dig into that. Current hypothesis is it has to do with what OS the blend files were made in because if I save it everything I did shows up.

Sounds weird. .blend files should be OS independent, and all our nodes and other settings are saved by Blender, we have no custom code in this area.
Make sure you are exactly using Blender 2.79b (the b is important).

robbrown wrote: ↑Tue Sep 18, 2018 3:29 am Test files in BlendLuxCore tend to crash when loaded in blender and using the test runner yields a pass but with errors. Should they be less than a second long test?

Code: Select all

Error: Not freed memory blocks: 1, total unfreed memory 0.000244 MB

The tests run pretty quickly.
The error is something from Blender, not from us, so you can ignore it.