OTOY Forums

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

1.52.0.28
- Mouse dragging the Octane Viewport whilst Resolution Lock is enabled now scrolls the Viewport
- Changed default "Video Card" from 500 series to 600 series
- Fixed issue where changing the material type of an input to a Material Mix could leave to a python exception
- When exporting to OCS, the mesh and material names are assigned to the Octane nodes

Paul

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

1.52.0.29
- Fixed python exception introduced in 1.52.0.28 when changing node types

Paul

Any way of saving a OSC file out of poser _without_ having the viewport open?
When rendering in background with Octane Standalone I hit not only texture limits but also Vram limits when trying to export a OSC file.

Any way of saving a OSC file out of poser _without_ having the viewport open?
When rendering in background with Octane Standalone I hit not only texture limits but also Vram limits when trying to export a OSC file.

Zay - the complete scene need to be in your graphics card in order to save as OCS, so it means the Viewport needs to be open.

Paul

face_off wrote:Zay - the complete scene need to be in your graphics card in order to save as OCS, so it means the Viewport needs to be open.

Yeah, was afraid of that. Can only hope when Octane 2.xx in the future get access to system memory we are out of those limitation problems.

Hi Paul,
I've noticed that changing a texture node to "multiply" looses the texture. Is there a way to keep it? Also, the default multiply 2nd value is currently a number - wouldn't it better if it were an RGBColor instead? I usually multiply by a color. ^^

Keep up the great job!

I've noticed that changing a texture node to "multiply" looses the texture. Is there a way to keep it? Also, the default multiply 2nd value is currently a number - wouldn't it better if it were an RGBColor instead? I usually multiply by a color. ^^

Yes - the current functionality matches Octane Standalone, and whenever possible I am trying to align the plugin and Standalone (so the plugin takes the default nodes for pin from the API). So my preference would be to retain the current functionality. You can copy the texture prior to changing it to a multiply, and then paste to the texture1 or texture2 inputs to get around this.

Paul

face_off wrote:Yes - the current functionality matches Octane Standalone, and whenever possible I am trying to align the plugin and Standalone (so the plugin takes the default nodes for pin from the API). So my preference would be to retain the current functionality. You can copy the texture prior to changing it to a multiply, and then paste to the texture1 or texture2 inputs to get around this.
Paul

Oh what a pity. I can't help but be left with a sense of loss. That's the kind of thing that was there because it made sense, and then it's removed so that we comply with something else. Aw well...

About the prop subDivs, what is the chance SMS will release another SR for P10/PP2014? Have they said something about it?

About the prop subDivs, what is the chance SMS will release another SR for P10/PP2014? Have they said something about it?

I'm unsure if prop subd will be in a Poser SR or not. Myself and others have prodded SM about it recently, but these things get resolved according to their priority, so not sure on the outcome. Also, I think the Octane 2 subd solution gets around the non-availability of subd vertices from Poser props.

Paul

face_off wrote:I think the Octane 2 subd solution gets around the non-availability of subd vertices from Poser props.

Yes, I am counting on Octane2 to help with this, but I think that will only come later this year, and that's why I wanted to see the options for what we will have until then. Sounds like prop subDs are out of the question.