OTOY Forums

I have re-installed the plugin, the error is still there
But I allready have save the new custom characters

I had to "Save all Material for this Prop/Figure as Poser Material" again and save it as new custom figure.
This way it doesn't use the old v1.20 nodes from the material room.
There was only one figure with the texture scaling by now.

I had to "Save all Material for this Prop/Figure as Poser Material" again and save it as new custom figure.
This way it doesn't use the old v1.20 nodes from the material room.
There was only one figure with the texture scaling by now.

Potentially there is an issue reloading the Octane 1.2 node layout from the nodes saved to the Poser material. If you would like me to investigate this further, if you have a Poser Material with the 1.2 nodes saved to it - save as a MAT pose, and then send it to me.

Paul

Finally upgraded to this latest version from 1.20 due to that old 'stable' version having an utterly broken hotpixel removal tool (and plus I was mid-project). I imported a scene I've been working on and started making it version 1.5 compatible, meaning I started rescaling my tiling diffuse and bump maps to match Poser's scaling, which is what plugin 1.5 is now doing. Also, changing all previous transmapped objects using the default 'floatimage' node type to 'alpha', as the 1.5 plugin defaulted them all to 'greyscale'. When I initially loaded this scene, all of the tree leaves were semi-transparent. But after changing JUST ONE of them from 'greyscale' to 'alpha', suddenly all of the tree leaves began rendering correctly. It was very weird. Regardless, I'm still going to change all opacity pin node types from 'greyscale' to 'alpha' which is going to be a nightmare... This scene has over 450 pieces of foliage.

Anyway, I am curious if anyone else is experiencing huge delays when changing the node type in the pins? I click on 'Alpha' from 'Greyscale', and it appears nothing is happening. Then, my Windows 7 blue 'thinking' wheel starts spinning. Literally ten seconds later (I counted), the node type finally changes.

This seems horribly optimized. I can't imagine others would be having this problem regularly, or there's no way Paul would have released this. Does anyone know why this is happening? It's brought my workflow to a screeching halt. I cannot convert all of the foliage in this scene at this speed.

And I don't know what others are experiencing as far as render times go, but this scene would render out with the daylight environment to 2000 s/p in only 20 minutes on my rig with a GTX Titan and GTX 680. Now it is telling me it will take 50 minutes to complete since the plugin upgrade. Octane 1.5 got slower? What the hell?

Oh, below is what the trees looked like when I imported my scene. This is before I started adjusting the scaling. You can see the ocean tiling texture and distant mountain tiling texture were working in reverse. Also, this is how the trees rendered with the opacity pin using the 'greyscale' node type instead of 'alpha'.



Here is what it looks like after changing JUST ONE node type for ONE of the trees from 'greyscale' to 'alpha'. Suddenly, the plugin rendered everything differently. Makes absolutely no sense.

Also, the trees and mountains have corrected scaling in this test render.



EDIT: I reset up the materials for one of the trees, exported a .poc, then tried to reimport that .poc for another identical tree. It took OVER ONE MINUTE to copy in. What is with this optimization? Why am I having this problem? Is it because of the size of the scene? I need help!

Also, changing all previous transmapped objects using the default 'floatimage' node type to 'alpha', as the 1.5 plugin defaulted them all to 'greyscale'. When I initially loaded this scene, all of the tree leaves were semi-transparent. But after changing JUST ONE of them from 'greyscale' to 'alpha', suddenly all of the tree leaves began rendering correctly. It was very weird. Regardless, I'm still going to change all opacity pin node types from 'greyscale' to 'alpha' which is going to be a nightmare... This scene has over 450 pieces of foliage.

Hi Aaron. Are you able to tell me why you are needing to change all the 'floatimage' nodes to Alphaimage? 1.5 renamed the 'floatimage' nodes to 'Grayscale Image'.

Paul

So I've changed all the alpha nodes back to greyscale. My problem was hardware. After working with Paul directly, it turns out that my 16 GB of RAM and my SSD with only 3 free GB of space were causing serious problems with Octane since I was topping out my physical memory use at 97% and Octane wasn't able to do much. The scene is simply too big for my PC.

However, I've upgraded to 32 GB of RAM and went from an 80 GB SSD to a 240 GB SSD, so now I have plenty of RAM and drive space. The problem has been resolved. So lesson here I guess is that keep an eye on your scene size and make sure your hardware can support it!

Thanks to Paul for the help. Onward!

Hi Paul,
there's an error when I switch Auto Refresh from OFF to ON while the viewport is open:

Traceback (most recent call last):
File "D:\Programme\CGI\Poser\Poser Pro 2014\Runtime\Python\lib\site-packages\wx-2.9.1-msw\wx\_core.py", line 16291, in <lambda>
lambda event: event.callable(*event.args, **event.kw) )
File "C:\Program Files\Smith Micro\Poser Pro 2014\Runtime\Python\addons\OctaneRender for Poser\SetupForm.py", line 581, in callAfterRefreshVertices
File "C:\Program Files\Smith Micro\Poser Pro 2014\Runtime\Python\addons\OctaneRender for Poser\UiManager.py", line 3561, in refreshVertices
File "C:\Program Files\Smith Micro\Poser Pro 2014\Runtime\Python\addons\OctaneRender for Poser\UiManager.py", line 1303, in updateMesh
AttributeError: PropMeshNode instance has no attribute 'polyTextureMismatch'

there's an error when I switch Auto Refresh from OFF to ON while the viewport is open:

Hi Uwe - I've seen that error before - but never been able to reproduce it again. I think it is related to changing the visibility of a prop. If you find a way to re-produce the error, pls let me know.

Paul

The visibility was a good hint!
Yes, it's reproducible: take an empty scene, put a cube in and switch it invisible.
Then the error happens. It doesn't when the cube is visible.

Uwe

Yes, it's reproducible: take an empty scene, put a cube in and switch it invisible.
Then the error happens. It doesn't when the cube is visible.

Uwe - are you able to provide more specific instructions for reproducing this pls - I sit can't get the error playing with visibility.

Paul

I can try
I have a default scene that is empty except for the ground plane and a (invisible) cube from the Poser primitives. That cube is for scaling reference and it's visibility is switched off because I only need it temporarily. It seems to me, that this causes the problem. If I load up Poser with my default scene and turn the visibility of the cube on, then everything works fine in the plugin. The error occurs when the cube is invisible.
Hope, that helps, if you need more info, just ask.

Uwe