OctaneRender 2 for Modo [OBSOLETE]

[cuffi]

I am using exact the same plugins and tried alle the steps you described above, deleting the MODO config included (more than once)...finally I figured out that it was the Substance plugin. It is not uodated to 801 actually and seems to cause the error...When switching off the substance plugin (for MODO 701) I can activate all other plugins and all run fine...thx god!

René, how did you get "Substance for Modo 701" to run in Modo801? I have it installed and it shows up in 701, but not 801.

Paul

I simply tweaked the config... all ran well so far...until now.

René

[face_off]

I simply tweaked the config... all ran well so far...until now.

René

René, whilst I'm glad it's solved, I now have a very difficult email to write to the Modo support people

Paul

[v1adut]

Hi Paul,
Small annoying bug , selected modo material in from octane viewport does mot apply the color changes to the modo materiL. It is necessary to click on the modo color filed to proper adjust the color.

Thumb up for proportional preview window.

[cuffi]

I simply tweaked the config... all ran well so far...until now.

René

René, whilst I'm glad it's solved, I now have a very difficult email to write to the Modo support people

Paul

Yes, I am responsible for that irritation. I was talking about the modification of the substance cfg with Wes McDermott from Allegorithmic in the forum: http://community.thefoundry.co.uk/discu ... 731#794731 and got a "thank you" not an "No, don't do that!" answer from him. So as bad as this was going in terms of the mail you wrote to the MODO support, no one (Wes included) was able to forseen this is affecting the Octane plugin in SOME cases (depends on what other plugins are enabled). There is a new function in the substance plugin since version 1.1.0 where you can use the GPU for calculating 4K Textures:
https://www.youtube.com/watch?v=n2qdy3WSuVs
There is a good chance this function has caused the error and there is a good chance the upcoming version of the substance plugin for MODO 801 will interfere with the Octane plugin in some odd ways too, because both plugins are using the GPU.

For me there is no reason to get a guilty conscience about my posts because I did not asked you to eskalate the error to the MODO support. It was your decision to do that with that amount of information. To be honest, how difficult can it be to say them, the problem is solved and it turned out, the reason for the error was another one? This must be daily support practice... I don't understand why you wrote this statement above...sorry.

Anyways, I will post my further findings...please handle with care

René

[face_off]

Small annoying bug , selected modo material in from octane viewport does mot apply the color changes to the modo materiL. It is necessary to click on the modo color filed to proper adjust the color.

I never even thought about implementing this, but it's a good idea. I will look into it.

Yes, I am responsible for that irritation. I was talking about the modification of the substance cfg with Wes McDermott from Allegorithmic in the forum: http://community.thefoundry.co.uk/discu ... 731#794731 and got a "thank you" not an "No, don't do that!" answer from him. So as bad as this was going in terms of the mail you wrote to the MODO support, no one (Wes included) was able to forseen this is affecting the Octane plugin in SOME cases (depends on what other plugins are enabled). There is a new function in the substance plugin since version 1.1.0 where you can use the GPU for calculating 4K Textures:
https://www.youtube.com/watch?v=n2qdy3WSuVs
There is a good chance this function has caused the error and there is a good chance the upcoming version of the substance plugin for MODO 801 will interfere with the Octane plugin in some odd ways too, because both plugins are using the GPU.

Modo 801 brings some big changes in the internal API event system, and it took some re-working of the Octane plugin to get working correctly. So whilst just changing the release number in the cfg will get the plugin to load, if it is listening to Modo events, there is a good chance it will be causing problems internally to Modo.

Paul

[face_off]

I have refreshed the installer at the top of this thread with:

2.01.0.19
- Compiled against Octane 2.01
- Fixed issue where Triangle Wave node had no properties
- Fixed issue where Sine Wave was being interpreted as Saw Wave
- Added "Lock Aspect Ratio" to lock the Viewport aspect ratio to the Modo render aspect ratio
- Refreshed all LiveDb presets on the FTP server so they now include Octane 2.0 pins/channels (see the manual for links)

The priority TODO at the moment is to get animated texturemaps (image sequences) working. This is proving so be quite challenging to implement, so will take some time.

Paul

[funk]

- Added "Lock Aspect Ratio" to lock the Viewport aspect ratio to the Modo render aspect ratio

This isnt working correctly. The height is incorrect. It looks like you are using the window size for your math (which includes the border and header). You need to be doing the math on the internal viewport dimensions.

UPDATE: Try this:
1. In a default modo scene width = 720 and height = 480
2. If I resize the octane viewport to width of 360 and save the image, the dimensions show w=360 x h=211. The height should be 240, not 211

[Obizzz]

I've finally had some time for Octane again and did some testing over the last few days.

Sometimes objects don't load in the renderer even though they are fully visible in Modo. I tried hiding something else and it turned up. I was not at the memory limit as the scene was using approx 800MB and I have a 6GB Titan. If I encounter this again I'll try to isolate it a bit more. It's been in rather complex scenes so far so I need to narrow it down.

Sometimes changing values in the imager / post processing that should not reset the renderer do. This is a serious error as it makes it impossible to tweak hotpixel values and anything of the sort. Again I'll try to narrow this down for you. Has anyone else experienced this?

In 1.5 exporting a scene to .ocs exported all objects with a connected placement node. Although very cluttery it could be really helpful if you needed to fine tune positions inside the standalone. Could it be possible to have this type of export as an option as opposed to the "Non-Live Items mesh" we have now? I can see why this was done but for some situations the old system was perfect. (easy to swap objects etc)

[riggles]

Sometimes objects don't load in the renderer even though they are fully visible in Modo. I tried hiding something else and it turned up. I was not at the memory limit as the scene was using approx 800MB and I have a 6GB Titan. If I encounter this again I'll try to isolate it a bit more. It's been in rather complex scenes so far so I need to narrow it down.

Sometimes changing values in the imager / post processing that should not reset the renderer do. This is a serious error as it makes it impossible to tweak hotpixel values and anything of the sort. Again I'll try to narrow this down for you. Has anyone else experienced this?

Both of these issues have happened to me. I need to get Paul another scene, but so far the first issue (incomplete scene loading) seems to only happen on existing 1.5x scenes that are now being rendered in 2.0. Not sure about post-processing yet. Haven't noticed a pattern.

[Rafael-Vallaperde]

Hello everyone!

I'm back!
and got 2.0 running into production here.

Lots of bugs but i think it's quite stable atm.

here are two quick finds:

1-If you have a material grouped under a group matereal doesn't update like it's outside form it.check the image of a grouped octane material.

2-while rendering if you change mesh visibility inside modo(toggle the eye on/of) nothing changes in octane.HOWEVER, if you have meshes nested into a folder they do!

so, that means that meshes inside a group are being loaded into octane even if they're toggled of.

Cheers, will be coming back here more often now
wish you guys a great week!