OctaneRender for Modo (OS X) 2.24.2 [STABLE]

[face_off]

I have Windows installed on a separate partition, so the older OSX plugin doesn't see any newer plugin files. I created the file in Windows, copied it to Dropbox, restarted in OSX, downloaded the file, and hit render.

I can't think what would be causing this issue other than the 2.06 windows plugin adding channel that is being misinterpreted by the 2.03 OSX plugin. I wouldn't have thought that not possible - but regardless, I will do a 206 build of the OSX plugin today an post it in this thread.

Paul

[face_off]

I will do a 206 build of the OSX plugin today an post it in this thread.

Sorry John - this turned out to be more complex than expected due to the need to roll-out some "next-version" changes. I will get it to you tomorrow.

Paul

[riggles]

I will do a 206 build of the OSX plugin today an post it in this thread.

Sorry John - this turned out to be more complex than expected due to the need to roll-out some "next-version" changes. I will get it to you tomorrow.

Paul

No worries Paul.

[riggles]

Not sure if it helps, but here's what's going on in the thread that crashed, from the OSX crash report:

Code: Select all

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dynamics.lx                   	0x000000011a13a5c7 CLxIfc_CmdSysListener<CBulletListener>::ExecutePre(void*, void*, int, int, int) + 87
1   libvalet8.dylib               	0x000000010de48221 PortNotifyClient + 273
2   libfront8.dylib               	0x000000010db8ebc3 WCmd_Execute_PreExec + 2131
3   libfront8.dylib               	0x000000010db768e4 WCmd_Execute + 20
4   libfront8.dylib               	0x000000010db7aecd SCmd_ExecuteArgString + 557
5   OctaneRenderForModoOSX.lx     	0x0000000118b8630a CLxLoc_CommandService::ExecuteArgString(unsigned int, unsigned short, char const*) + 74
6   OctaneRenderForModoOSX.lx     	0x0000000118cde985 UiManager::SaveViewportSize() + 437
7   OctaneRenderForModoOSX.lx     	0x0000000118b4b485 NT_ViewportClosing + 21
8   OctaneRenderForModoOSX.lx     	0x0000000118b4d319 ViewportManager::CloseViewport() + 9
9   OctaneRenderForModoOSX.lx     	0x0000000118cde7c9 UiManager::CloseViewport() + 9
10  OctaneRenderForModoOSX.lx     	0x0000000118b0b85e cleanup() + 14
11  OctaneRenderForModoOSX.lx     	0x0000000118d0778d CLxThisModule::FreeObj(void*) + 29
12  OctaneRenderForModoOSX.lx     	0x0000000118d077df non-virtual thunk to CLxThisModule::FreeObj(void*) + 47
13  OctaneRenderForModoOSX.lx     	0x0000000118d0ae47 CLxGenericPolymorph::Release(void*) + 263
14  libvalet8.dylib               	0x000000010de77dfe HostFastShutdown + 62
15  libnexus8.dylib               	0x000000010d4f4aba AppSvc_Run + 3322
16  com.luxology.modo             	0x000000010cf9d98f CLxLoc_ApplicationService::Run() + 31
17  com.luxology.modo             	0x000000010cf9d8c2 mainW + 34
18  com.luxology.modo             	0x000000010cfa6374 main + 84
19  com.luxology.modo             	0x000000010cf9d844 start + 52

[face_off]

Not sure if it helps, but here's what's going on in the thread that crashed, from the OSX crash report:

Ah OK. That's the same one as on Linux. When closing Modo with the Viewport open, Modo is shutting down the user.values system prior to the Viewport trying to save the Viewport position/size. I will try to sort this out.

Pul

[face_off]

The next (draft) version of the Modo OSX plugin can be downloaded from http://render.otoy.com/customerdownload ... MacOSX.pkg. There is an outstanding issue where you may find your GPU's UNselected in the Cuda tab of the plugin. If so, re-enable them. The release notes for this version are:

2.6.0.25
- Compiled gainst Octane 2.06
- Added GI Clamp in the Kernel settings
- If the Modo environment map has been mirrored (ie. the texture locator Horizontal Wrap = -1), the Octane envirnment will also be mirrored
- Fixed performance issue when exporting an amination to ABC ORBX/OCS
- IMPORTANT: when using "octane.command exportAlembic", export to OCS format if possible, since that uses much less disk space (because the ABC file does not need to be stored inside the ORBX container)
- "octane.command exportAlembic" now only exports the following animated Octane camera node pins: pos, target, up, fov, focalDepth. So aperture is not animated (let me know if you need it animated)
- "octane.command exportAlembic" now no longer stores the camera animation in the ABC file - it instead stores it in the Octane Camera node of th ORBX/OCS file
- Added potential fix for the minor lag issue when navigation the Modo preview window when the plugin Setup window is open
* KNOWN ISSUE: Running out of disk space during the "octane.command exportAlembic" process will crash Modo. This has been reported to Otoy.

Paul

[riggles]

This has probably been discussed before, but I've been on 701 until just recently, so I might have skipped over it.

801 added OpenColorIO support which automatically degammas texture maps. So, instead of having to manually set the image gamma to .4546, you can leave it at 1.0. This is a great time saver. However, when an Octane override is created, it doesn't look at the image maps native gamma, it just sees a MODO gamma value of 1.0 and leaves it at that, which gives an incorrect result.

In standalone, when an RGB image is loaded, Octane detects the correct gamma and sets it accordingly. With the plugin, is it possible to detect the gamma of image maps upon override creation? Or perhaps some other method works along with MODOs color management?

[riggles]

I'm seeing an odd issue. I just added a plane and a sphere (positioned just above the plane) to a blank scene. You'll notice both the black circle underneath the sphere and also the lighter gray surface of the sphere thats getting clipped or something. Not sure what's causing it, all other kits are disabled.

[face_off]

801 added OpenColorIO support which automatically degammas texture maps. So, instead of having to manually set the image gamma to .4546, you can leave it at 1.0. This is a great time saver. However, when an Octane override is created, it doesn't look at the image maps native gamma, it just sees a MODO gamma value of 1.0 and leaves it at that, which gives an incorrect result.

In standalone, when an RGB image is loaded, Octane detects the correct gamma and sets it accordingly. With the plugin, is it possible to detect the gamma of image maps upon override creation? Or perhaps some other method works along with MODOs color management?

A png/jpg does not store it's gamma (the 'native gamma' in the file) - so I don't believe it is possible to read an image files intended gamma. My guess is the Standalone assume 2.2 for png/jpg and 1.0 for hdr/exr.

Funk can provide the details - however I believe the instructions at http://render.otoy.com/manuals/Modo/?page_id=959 (Color Management) provides the solution. There are some additional Modo API functions in 801 for color management, so there more be more that the plugin can do in this area - however the it will not be compatible with Modo701 (since the Modo 801 API does not work on 701 - so the current version of the plugin is compiled against the 701 API).

I'm seeing an odd issue. I just added a plane and a sphere (positioned just above the plane) to a blank scene. You'll notice both the black circle underneath the sphere and also the lighter gray surface of the sphere thats getting clipped or something.

This look like a 'ray epsilon' issue. Adjusting that slider should rectify the problem.

Paul

[riggles]

A png/jpg does not store it's gamma (the 'native gamma' in the file) - so I don't believe it is possible to read an image files intended gamma. My guess is the Standalone assume 2.2 for png/jpg and 1.0 for hdr/exr.

Funk can provide the details - however I believe the instructions at http://render.otoy.com/manuals/Modo/?page_id=959 (Color Management) provides the solution. There are some additional Modo API functions in 801 for color management, so there more be more that the plugin can do in this area - however the it will not be compatible with Modo701 (since the Modo 801 API does not work on 701 - so the current version of the plugin is compiled against the 701 API).

Ok. So basically, don't use 801's color management.

This look like a 'ray epsilon' issue. Adjusting that slider should rectify the problem.

Ah yes. I've never knowingly changed this, but somehow it got set to .1, don't know what the default is, but .001 seems to work.