OctaneRender® for Poser beta - build 1.13u [STABLE] Tweet

[face_off]

I dont understand what standalone goes with the 113 poser plugin?

You don't need any version of Standalone to run the plugin - the plugin contains a separate copy of the Octane engine from Standalone. The only part of Standalone that you need is the license.

Paul

[gold]

I dont understand what standalone goes with the 113 poser plugin?

You don't need any version of Standalone to run the plugin - the plugin contains a separate copy of the Octane engine from Standalone. The only part of Standalone that you need is the license.

Paul

Thanks Paul! .. My Bad. Been a while since I worked with it.

BTW - if anyones wondering, Paul { face_off} gives excellent, fast, support on this Poser plugin. A real
winner in my book!

[face_off]

Another small patch to the 1.13u version has been uploaded....

1.13u-3
--------
- Rolled-back Octane API version to fix the opacity bug with image, alphaimage, and floatimage nodes.

So if your transmapped hair is not rendering correctly (bug introduced in 1.13u-2) - this patch should fix it.

Download via the link in the first msg in this thread.

Paul

[KleanZlate]

There is a problem with DSON Genesis and it's male genitalia. The genital figure doesn't subdivide in Octane when conformed to Genesis. If the figure is just parented, the subdivision works. Any idea what could be wrong?

Note: This problem exists in earlier versions of the plugin as well.

[face_off]

There is a problem with DSON Genesis and it's male genitalia. The genital figure doesn't subdivide in Octane when conformed to Genesis. If the figure is just parented, the subdivision works. Any idea what could be wrong?

Yes, I would expect this to happen. "Genesis" is a figure, and the only way to tell if a figure is a genesis figure is the presence of an actor in the figure called "__SUBD". When a genesis figure is detected, all props attached to that figure as assumed to also be genesis figures, so the cages of these prop are not rendered by the plugin - only the "__SUBD" mesh is rendered.

In the situation where you have a genesis prop NOT parented to a genesis figure, the plugin will not pickup that it is a genesis prop, so will render both the cage and subd mesh, and the cage will most likely be outside the subd mesh, so give the impression the subd mesh is not being rendered.

So in summary, rendering of non-parent genesis prop is not currently supported by the plugin, but it might be possible to implement this is the future if it was required.

Paul

[KleanZlate]

Ok. thank you for clearing that up. It would be nice to have this fixed sometime but it's not a priority in my opinion.

[face_off]

Hi

Thought I would start posting some details on the "re-vamped" (1.13v) Poser plugin - hopefully ready in a few days.....

The biggest change is that it doesn't load the scene into Octane when the plugin starts. Instead, the Octane load happens when you open the viewport. That means you don't need to wait for the scene load prior to editing materials, etc.

There are a heap of minor "tree" editing changes, but the biggest one is that the Settings and Materials trees are not generated from the Octane scene. Instead, they are generated from the Poser scene, and then the Octane nodes are created from the "tree"s. That means small things like the Transmission pin will no longer have an "floattexture" node attached - it will be "unplugged" instead and you can assign a node to that pin if needed. This will also happen with the "emission" pin.

The above changes should be pretty much invisible to - however in the event that something goes wrong (graphics card failure, etc), then the plugin will handle that in a much more robust fashion.

Other changes include a migration away from the OctaneDefaults.py file. Instead, the majority of settings will be in an xml file, which is maintained by the plugin. There is a new Configuration window to edit these settings. Also, things like Setup and Viewport positions and sizes are retained between sessions via this file.

Moving away from the OctaneDefaults.py file also means I can build an installer for the plugin, which will improve the reliability of my builds, and lower the potential for people to install in the wrong place.

Other changes include: Resolution Lock button now on the Setup window, so you don't need to open the Viewport to change the resolution lock, you can now load/save entire rendertarget settings (and set a rendertarget as the "default" for all new scenes). Setup and LiveDb windows can now be resized and remember their size between sessions (see image below).

A test version will hopefully be available in a few days.

Paul

[RGUS]

Cool Paul... this is starting to sound like I think you dreamt it could be.

[KleanZlate]

Really nice and good changes for a stronger build.

[mlru]

Other changes include a migration away from the OctaneDefaults.py file. Instead, the majority of settings will be in an xml file, which is maintained by the plugin. There is a new Configuration window to edit these settings. Also, things like Setup and Viewport positions and sizes are retained between sessions via this file.

Moving away from the OctaneDefaults.py file also means I can build an installer for the plugin, which will improve the reliability of my builds, and lower the potential for people to install in the wrong place.

so no more editing of the .py files to keep my settings? Nice!

Other changes include: Resolution Lock button now on the Setup window, so you don't need to open the Viewport to change the resolution lock, you can now load/save entire rendertarget settings (and set a rendertarget as the "default" for all new scenes). Setup and LiveDb windows can now be resized and remember their size between sessions (see image below).

That's nice, too!

Do you think, there's a chance to implement a resizing of the image in the viewport, so that when you render in a high resolution, you still can zoom out to the whole picture (like the standalone does)? I tend to render bigger than my screen resolution...

What do the numbers behind the nodes mean (e.g.: diffuse:50/50/50)? RGB values? Wouldn't it be cool to display the actual color, too?

I know, I'm demanding....
Uwe