OcDS: High Priority Issues and Request - State 2.23

[rajib]

Hi Paul,

Issue with 'Render Settings' export / import. Some of the values change to default even though exported with modified values.

Below are the screen shots and the step by step instruction to create the issue.

1. Open New DAZ scene.
2. Go to OctaneRender->Rendersettings
3. Click New button and select Path Tracing as Type and click Accept

New Settings

RenderSettings-DefaultRenderSettubg-PT-New Settings.png (6.54 KiB) Viewed 5698 times

You will see the following default settings:

Default values

4. Modify all the values - Changes slider / values. Turn option on/off and export it.

Values changed and saved via export

5. Click New button and select Path Tracing as Type and click Accept as in step 3 to get the default values.
6. Click Import to import the exported settings.

Imported Settings.

As you can see the values are different. I have marked as X the settings that did not have the exported value.

Wrong values

Similarly some of the values will reset for the PMC settings export/import. If you need screen shots for that let me know.

I think this should be a fairly simple bug to resolve. It either the export is not exporting some of the values / exporting wrong (default) values or the import is not reading those values correctly or reading it and then some initialization routine within the code is overwriting the values.

One other note. After importing even though the Kernel Settings -> Max Samples was showing 1000 after the import, on the render window, it actually showed the exported value of 256000. Changing the max samples in the render settings would not change this value shown in the render window.

Max Samples

The only way to get the max samples to work again is to select another Kernel Type and then change it back. After that changing the Max samples reflects in the render window. Other settings like Coherent ratio also get stuck until you change the Kernel Type to something else and back. The other settings might be stuck too after the import. Did not try all.

I think the values are being imported back, but somehow not being displayed properly and that in turn leading to the values getting stuck and changing them having no effect to the actual render.

Best regards,
Rajib

[rajib]

Hi Paul,

Another issue. With Opacity Maps. I have my base model wearing a pant that has a transparency map to convert the pant into shorts.

Original pant without Opacity map :

Original Pant without Opacity Map

Pant with Opacity map applied :

Pant with Opacity Map

As you can see even though the Opacity map does it's job, there is a 'dark' layer wherever the actual pant covered her legs. Marked with the red arrows. Anything the original pant did not cover is normal, but between the bottom edge of the shorts and the red arrows, the skin looks darker. The alpha shadows appear properly based on the Opacity map.

Opacity settings are :

Opacity settings

The transparent part is black (0,0,0) and the power and gamma is correctly set. So that 'darker' layer should not be there.

At first I simply could not figure out what was causing it. Finally found that if you have multiple Specular Material node in the skin material (I am using Tonysculptor's skin material) , what values you have in the Medium in each of the node results in that. If they have the same value, then the issue does not appear. But if the Medium node entries are different, with the the opacity map present, the darker layer appear wherever the transparency map was pure black.

With All Medium node of the Specular Material set to the same value it appears ok:

Transparency OK

Not sure if this is an Octane issue instead of the DAZ Octane Plugin. If there is an Opacity mask present and the transparent parts are pure black (0,0,0) shouldn't it be fully transparent and not have any effect irrespective of whether the material used is specular or glossy or diffuse ?

Best regards,
Rajib

[linvanchene]

- - -

- I added links to each of the issues on the first page so it is easier to track down the source

- For most issues I added a link to the post in the "last beta" thread in which the issue was first mentioned.
That way it should be possible to PM the person who posted the issue or requests for follow ups.

- If I knew about a separate thread in which the issues are described in detail I added that.

- - -

[TRRazor]

With All Medium node of the Specular Material set to the same value it appears ok:

This is definitely not an OCDS plug-in-issue.
It's like that in every version of Octane, since you control light / transmission absorption with those medium nodes.
Setting these to individual values, on a character consisting out of more than 20 materials (Genesis2) is bound to give these errors.

Not a bug, hence doesn't need to be fixed.

[face_off]

01 Unwanted UI interactions between DAZ Studio and the OctaneRender plugin

There are a few factors at play....

It's rather easy to run into the issue. Click on any box that allows text entry, and move the mouse (without clicking) out of the window. This occurs in any element of the Daz Studio UI that one can enter text into. More often than not, it will cancel text entry. It is also supposed to focus whichever window the mouse is over while not entering text, but may or may not do so, so it's not that any steps specifically cause this behavior, it is just how the UI behaves in general, and per some discussion with t_3 about it months ago, it shouldn't. This specific behavior does not occur when running Daz Studio without OcDS, for me, and is unique to the version 2.* pre-release betas.

I was not able to reproduce any issues using the above steps. I also compared DAZStudio with and without the Octane plugin installed, and the behavior seemed to be the same. I current progress a fix for the above without a step of steps which reproduces it - sorry.

It is worth noting that Daz Studio occasionally has issues with "click-through." I have no idea what else to call it. I use floating panels for everything on separate monitors, and Daz Studio occasionally reads me clicking a parameter slider as clicking the viewport as though it was behind said slider (It isn't, but if you extended it, it acts as though I clicked in the non-existent extension). This behavior occurs whether using the OcDS plugin or not, but is so sporadic, I think it's just a Quicktime UI issue, and unrelated (again, I think) to the problem above.

This is a separate issue, and due to the Viewport "stealing" the keyboard presses.

Example 1:

- start DS
- place sphere in the scene
- open OcDS viewport
- click on the focal lenght entry field to activate it
- try to enter "50" manually by using number keys on your keyboard

Result:
the entry of 5 and 0 is not accepted

I was able to reproduce this issue. Again - it is the Viewport "stealing" the keyboard presses. I can look to fixing this (but it will be tricky). Placing the camera GUI widgets over the Viewport is always going to be a problem.

Paul

[face_off]

It's rather easy to run into the issue. Click on any box that allows text entry, and move the mouse (without clicking) out of the window. This occurs in any element of the Daz Studio UI that one can enter text into. More often than not, it will cancel text entry. It is also supposed to focus whichever window the mouse is over while not entering text, but may or may not do so, so it's not that any steps specifically cause this behavior, it is just how the UI behaves in general, and per some discussion with t_3 about it months ago, it shouldn't. This specific behavior does not occur when running Daz Studio without OcDS, for me, and is unique to the version 2.* pre-release betas.

I have now been able to reproduce this error. It's like all the text edit boxes (from the plugin or the normal DAZStudio panels) get locked and you cannot edit them. I will investigate.

Paul

[face_off]

Can someone pls tell me if the "Here" button was ever working? If I click it it returns lat/long = 0.

Thanks

Paul

[sikotik13]

No, it never worked (at least not since 1.2). The behavior has always been as it currently is, I just don't think anyone bothered to mention it, since it is generally considered low priority. At least, I never saw anyone else mention it anywhere, so I assume no one cared.

[face_off]

No, it never worked (at least not since 1.2). The behavior has always been as it currently is, I just don't think anyone bothered to mention it, since it is generally considered low priority. At least, I never saw anyone else mention it anywhere, so I assume no one cared.

Thanks. I will remove the button.

Paul

[face_off]

05 Final Render Button
you let a render run not realizing the save button was disabled

I have been unable to reproduce the issue where the Save button is disabled.

Paul