OcDS 1.2.120.34xx - BUG REPORTS Tweet

[sikotik13]

Usually, if your cursor disappears in Daz Studio, right clicking will bring it back (it's a Daz Studio issue, nothing to do with the plugin, although the plugin tends to trigger the Daz Studio issue more frequently).

A scaled mesh light means a light that possesses a scale, doesn't mean you scaled anything in it. If you have a light, that was your error. You ignored it.

And viewport scaling is also a Daz Studio issue, as Daz Studio controls the viewport, unless you are specifically referring to the Octane viewport, which should mirror what the camera display within the viewport shows, unless you locked it to a specific camera.

Never experienced the last one, but the other three are relatively common ones for Daz Studio in general, and highly unlikely to be the fault of the plugin.

[t_3]

@Jazbee & @sikotik13

regarding pt.2 - viewport aspect mismatches; this is an issue (not necessarily a bug) with the plugin.

the plugin needs to alter the daz studio render settings to allow calculating a correct fov for the octane cameras (e.g. the right ar), as daz and octane cams use different axes for the fov angle.

sometimes the setting might be locked or is changed again by the studio load procedure afterwards, so the ar doesn't match. the additional downside of this is, that changing the ar is only possible by adjusting the ds render size (or in other words changing the ar in ds will also change the ds render size) - this is probably unwanted, if one wants to render in 3delight instead of octane. means there is some tricky what/if/when/why/or/not going on to avoid that, e.g. to set it only when really needed - but this decision is not always clear, so it might lead to this effect...

[t_3]

and about the cursor: this is even more a Qt thing (Qt is the ui framework that studio uses), and affects other Qt-based applications as well. usually it happens because a background task starts before the cursor was released to the system (where it would then appear spinning). i try to avoid that whenever i start a background task from the plugin, but it may still interfere with background tasks in studio - which i neither can't control nor even get noticed about...

[Jazbee]

Thanks for clarifying.


The disappearing cursor didn't happen to my with previous versions of the plugin nor during any other DAZ operations so I assumed it was plugin-related.

Going back to the mesh emitter and the "Final" button issue. I thought the "scale" was referring to the scale of a texture emitter etc. within Octane itself, not the scale of the mesh modified in DAZ. The previous plugin did allow "Final" rendering with meshes scaled in DAZ and worked just fine (as long as you didn't change the light distribution rotation), meaning it was still saving time and I couldn't see any change in lighting of the render. Was it previously working in an undesirable way or is it now?

Be as it may, the button greying-out when nothing at all can be done (including saving a render) shouldn't happen in any case.

[t_3]

Thanks for clarifying.
The disappearing cursor didn't happen to my with previous versions of the plugin nor during any other DAZ operations so I assumed it was plugin-related.

thu current version has reduced multitasking for background processes; unfortunately this is the only way to avoid certain instabilities, as the daz api isn't thread safe. i tried to work around that in many ways, but none of them didn't work for all circumstances (in other words i was trying to achieve sthg. that isn't really possible); this means there are more situations where background tasks may block the ui (and the cursor). in particular this happens because the cursor shape is modified in studio, what makes it quite more likely for this to happen. i'll of course see if i can do sthg. against it. what may help already is to alt-tab to another application and back.

Going back to the mesh emitter and the "Final" button issue. I thought the "scale" was referring to the scale of a texture emitter etc. within Octane itself, not the scale of the mesh modified in DAZ. The previous plugin did allow "Final" rendering with meshes scaled in DAZ and worked just fine (as long as you didn't change the light distribution rotation), meaning it was still saving time and I couldn't see any change in lighting of the render. Was it previously working in an undesirable way or is it now?

the problem lies in the way how octane handles mesh lights. if a mesh is scaled this will also affect the light intensity. final mode collapses all meshes, so the scale of a single object is calculated into a mesh with 100% scale and so the light intensity will change. in the previous version i had explicitly removed the scale from the live geometry handling, means every scale change did also rebuild the geometry of this object (so octane internally did always get a mesh with 100% scale, no matter what its actual scale in studio was). about the same was already true for ies lights (which didn't work with final in prev. versions also, because they were affected by the rotation). the changed geometry handling in octane as well as upcoming features like object motion blur needed me to finally bring everything back to common methods; objects are translated/rotated/scaled without rebuilding the geometry for octane, but in order to keep the results identical they can't be collapsed if lights are scaled/rotated (or if instances are present). you can still avoid this by avoiding to scale a mesh emitter.

Be as it may, the button greying-out when nothing at all can be done (including saving a render) shouldn't happen in any case.

that's quite true...

[Jazbee]

Thanks for a thorough explanation, t_3.

I suspected something wasn't exactly right with mesh emitter scaling in previous versions. Now I know why.

[linvanchene]

edited and removed by user

[t_3]

ah, this indeed _is_ a bug, as it should show nbrs past 24 hrs. but you are probably right that an additional "days" nbr would be even more helpful...

[Jazbee]

I've experienced some very erratic behavior from Octane when changing UV sets in a figure. When I change the UV set from Genesis 2 to Victoria 4 (for using V4 textures on G2F) Octane automatically creates a new material for all surfaces and unlinks the old ones. When I try to relink my custom materials, it resets the figure UV back to default, as if the Octane materials had the UV set embedded in them and was forcing it on to the figure.

This happens when I try to relink a mat that was previously used on a figure. When I load a mat from my saved presets, it seems to work, although some mats still loose their links.

[birdovous]

Maybe not a real bug but when I use the Polygon Group Editor tool and create a new Material/Surface from a selection the newly created material does not appear in the Materials selection tab of the plugin and the Create Missing materials button is disabled as well. Reloading the scene using the reload button in the viewport does not make the new material zone to appear either.