OTOY Forums

Anyone else having issues when switch Materials from Diffuse to Mix ?
For me the NGE throws all texture settings away. Need to change it back from RBG Colour to Image and select the texture for fist and second material.

In older Version the Diffuse Material stays as normal as it should.

Here is an example of a V4 Face :

swipswap wrote:

asennov wrote:Ain't girls hands pure white?.

Are the geoshells on the character?

This shot doesn't use geoshells at all.

swipswap wrote: Also keep a look out for missing textures from image nodes.

Well, I know what to do to restore the look of character . I just won't to do it manually for all shots in my project (103 was for Octane 1.2, now 205 for iray, will be at least 624 for the whole thing )

swipswap wrote: I believe locking DAZ is to prevent race conditions between DAZ studio and the plugin.

Making application irresponsible doesn't prevent race conditions - DS is multithreaded by nature and locking GUI thread doesn't prevent others from working. It's just a sign of programmer being too lazy to make special thread for heavy processing and doing it in main GUI thread instead. Well, one may even do that but still let application to process OS message queue.

swipswap wrote: Have you tried hitting reload at bottom of viewport? Also verify the mesh is high resolution and try changing the subdivision to see if it updates the scene correctly.

Reload does the trick but for this particular frame and there are 180 more in this shot It may return to base mesh any time mid-animation.

Hydra wrote: I also noticed that this plug-in is working much harder at interpreting default Daz shaders than before. Nothing acted up yet, and I will continue playing with this. Geografting is working flawlessly near as I can tell. Oh and finally out of core textures are in the plug in.

Yeah and I honestly am not sure I want this yet. In the past when you auto-create materials from the daz source, you got a simple material that was not mixing different types. Now you do, which could be neat for the casual Daz users (which I understand are part of the market) but for me I feel inclined to remove the network and start much cleaner. But it will require more work than in the past.

Geo-grafting has its quirks I have noticed. But they might be fixable with some workarounds or settings. Seams are pretty noticable in some scenarios, and I swear there is some geometry overlap going on where both the original geometry and the geo-graft are both rendering.

Not extensive testing yet so I would need more time to be certain.

However it works way better than in the past, and the quirks I think are manageable. And they may have simply been from my first two quick tests from last night. I plan to dedicate some time for it today to see if I have the same issues with simpler test.

Hubby72 wrote:Anyone else having issues when switch Materials from Diffuse to Mix ?

I never did it this way in the past. I would make a mix material and drag the diffuse to it. Changing a nodes type can be tricky.

asennov wrote: [*] Nasty habit of freesing when loading scene, when building geometry, when preparing for final rendering. Cool devs spit on multithreading, don't they?

Did you look to see if your CPU's were max out? I've seen the same, but the CPU's were at 100%. So freezing would make sense. The plugin switched to multi-threading geometry creation/merging a while back so unless something changed I would expect it still is.

asennov wrote:

swipswap wrote: I believe locking DAZ is to prevent race conditions between DAZ studio and the plugin.

Making application irresponsible doesn't prevent race conditions - DS is multithreaded by nature and locking GUI thread doesn't prevent others from working. It's just a sign of programmer being too lazy to make special thread for heavy processing and doing it in main GUI thread instead. Well, one may even do that but still let application to process OS message queue.

Actually talking to a GPU used by Octane is different, and if you don't block, you'll likely see a catastrophic driver failure, and likely need a full reinstall of the drivers to recover. Octane really does mess with the GPU.

On the other hand I've only seen 'freezing' when loading monster large scenes. The rest of the time, meh... More play time required.

Many thanks, t_3. I, like many others, whilst hoping for the best was mentally preparing myself for bad news, so seeing you active on the forums again and with a new update is very much good news!
I had a small issue with some dynamic clothing on the previous beta and will give this latest a quick check to see if it still happens when I get a moment to try it out.

asennov wrote:Making application irresponsible doesn't prevent race conditions - DS is multithreaded by nature and locking GUI thread doesn't prevent others from working. It's just a sign of programmer being too lazy to make special thread for heavy processing and doing it in main GUI thread instead. Well, one may even do that but still let application to process OS message queue.

ds isn't multithreaded "by nature" - they do a _few_ things in background tasks, like writing ogl textures out to the tmp folder and smoothing, and that's it. they have even skipped to build multithreading around layered image baking. the impression of a smooth moving load progress bar in studio definitely not means there is much MT going on.

apart from that, the studio api is NON THREAD SAFE from A-Z; any attempt to access daz objects from anywhere else but the ui-thread is going to crash, more sooner than later. in addition the node api of octane is _non thread safe_.

the plugin locks the ui at most if _octane_ loads maps from disk (what i can't avoid since i cant read maps from ram, and daz hadn't much to say about such a request from me), and if octane uses all cores @ 100% to super-fast build geometry..

apart from that i have around 2 dozen own different multithreaded tasks - or in other words i do it _were possible_. and were it makes at least some sense.

larsmidnatt wrote: Did you look to see if your CPU's were max out? I've seen the same, but the CPU's were at 100%. So freezing would make sense.

Maybe I'm a bit biased against the freezing - in my world it could cost lives. Well, for the rendering app - it can be tolerated, just annoying. I always have task monitor open and in my opinion there were enough CPU resources to process message queue at that time, thou all cores were under load.

t_3 wrote: ds isn't multithreaded "by nature" - they do a _few_ things in background tasks, like writing ogl textures out to the tmp folder and smoothing, and that's it. they have even skipped to build multithreading around layered image baking. the impression of a smooth moving load progress bar in studio definitely not means there is much MT going on.

But user has impression that everything is under control.

t_3 wrote: the plugin locks the ui at most if _octane_ loads maps from disk

For image loading you have moving progress bar and that's OK, but in cases I mentioned everything is frozen including 'Building geometry...' progressbar in viewport.

t_3 wrote: (what i can't avoid since i cant read maps from ram, and daz hadn't much to say about such a request from me), and if octane uses all cores @ 100% to super-fast build geometry..

...then user has to pray that's just a temporary freeze...

Anyway it's not the worst thing, I've just mentioned it because in previous versions it wasn't as apparent and it caught my attention.

larsmidnatt wrote: Geo-grafting has its quirks I have noticed. But they might be fixable with some workarounds or settings. Seams are pretty noticable in some scenarios, and I swear there is some geometry overlap going on where both the original geometry and the geo-graft are both rendering.

Also noticed some seams but wasn't sure if plugin is responsible or my material setup but overall impression of progress in geograft support is very positive, especially from the geometry side of things. Yet have to test material side

t_3 wrote:the plugin locks the ui at most if _octane_ loads maps from disk (what i can't avoid since i cant read maps from ram, and daz hadn't much to say about such a request from me)

Cannot test it right now but isn't it

dzApp->getImageMgr()->getImage("T:/mytextures/tex.jpg")->getImageData(targetQImage);

or some of findImage methods of DzImageMgr?