OTOY Forums

t_3 wrote: regarding 2: yes - it is that switch.

Even after turning on that switch, there were a few frames (of the rest) which were unfit.

t_3 wrote: regarding 3: was it one of the earlier frames, or one of the last frames that showed the firefly?

frame 151 and 163 (so in the middle).

t_3 wrote: regarding 1: how long was rendering going on until reaching 332? did you have any animation before, that rendered close to that frame count? a crash of this sort looks a bit like something system or at least memory related. animations cause some stress not only for the gpu, but cpu/system memory also (because of repeated geometry building... can you pls give me some additional specs (cpu/ram/psu, scene size - triangles/vram, render time/frame, ...). also if you still have the log file from this try it might help; any message from the engine that might appear in the message window ("system" tab) will also get written to the studio log file. what might also reveal something is to watch the memory utilization in the taskmanager - if it constantly grows, there might be a memory leak somewhere. btw, did you watch gpu temps?

log file is now out of queue (will look immediately next time).
I rendered this sequence many times - never a gpu issue (i also have temp throttle). [420x540, gtx670+gt640(unchecked) reported 1:40:00 for total sequence, 756mb used of 3622 mb (total 4096) available. 17/144, 9/68, 0/10, 1/10 of textures. daz geo: 4, daz mat: 41, textures used: 53, unique textures: 48, oct mesh: 1, oct mat: 222, oct text used: 58, unique textures: 57. nvidia v320.18

I also noticed that some frames really didn't finish (jacket fit to head instead of body in one frame - really weird visual).

thanks,
jim

jimgale wrote:Even after turning on that switch, there were a few frames (of the rest) which were unfit.

annoying. i'll bring the "interactive on" method back - at least for animations. running out of other options.

jimgale wrote:log file is now out of queue (will look immediately next time).
I rendered this sequence many times - never a gpu issue (i also have temp throttle). [420x540, gtx670+gt640(unchecked) reported 1:40:00 for total sequence, 756mb used of 3622 mb (total 4096) available. 17/144, 9/68, 0/10, 1/10 of textures. daz geo: 4, daz mat: 41, textures used: 53, unique textures: 48, oct mesh: 1, oct mat: 222, oct text used: 58, unique textures: 57. nvidia v320.18

thanks for the info's; i was more thinking about pc memory issues. such a trace-less crash points into a rather hardware specific direction (or something directly in octane). do you by chance know, if it went down in the middle of rendering, or during forward?

jimgale wrote:I also noticed that some frames really didn't finish (jacket fit to head instead of body in one frame - really weird visual).

another point were i'm currently running out of options; i tell studio to finalize all geometries, and at the point this command returns it should be save to do the transfer (regarding daz). someone suggested to add a configurable delay after the forward - that might cure things (or even still not), but it's more like voodoo than programming.

i'm currently validating the possibilities to additionally implement octane as dz renderer; it would be then possible to start renderings and esp. animations from the studio render dialog (and would also allow scripted access) - regarding daz this will force synchronous processing during forwards, and (in theory) should solve all that problems. imo it is possible to take that route but i'll require quite some work, so it isn't to expect in a week or two...

t_3 wrote:thanks for the info's; i was more thinking about pc memory issues. such a trace-less crash points into a rather hardware specific direction (or something directly in octane). do you by chance know, if it went down in the middle of rendering, or during forward?

wasn't watching that render at the time - I did have a simple video playing on the other gt640 however that hasn't presented issues before. This is an i7+16gb memory if that helps at all.

t_3 wrote:voodoo

I agree - eventful programming is much more stable/secure, and always faster.

t_3 wrote:implement octane as dz renderer... require quite some work

I wonder if a hybrid gating function would offer some help while you implement the daz renderer... you still have your plugin, and you start your SHELL daz renderer (even automatically), then your plugin waits for a signal from the shell that a frame is ready - while the shell waits for the plugin to finish. It may not be the ideal-final, but it might solve the event issue without having to port all the plugin work inside.

btw: thanks for the updates - I'm happy to help you debug/provide feedback/etc.

jimgale wrote:wasn't watching that render at the time - I did have a simple video playing on the other gt640 however that hasn't presented issues before. This is an i7+16gb memory if that helps at all.

well, you probably know what i now am about to ask
but seriously... if the player is gpu-enabled this could have been part of the crash. might be even something that would not had happen with older octane versions and/or studio versions. in general rendering out an animation causes lots of expensive work on the gpu (and the cpu); lots of heavy vram transfers, the rendering workload itself of course, in addition there is opengl activity because of studio, render films and 2d viewport needs updates and all that is going on in parallel. even with a dedicated (nvidia) display card, there is a driver level, which needs to track and manage all those things for all cards.

but it should be possible to cut some extra and most probably unneeded work off; it is possible to turn off the ds ogl viewports, and of course to reduce octane viewport updates, both things are rather easy to do and might in return increase stability...

further: (restarted daz, reloaded) reran the sequence - got thru - NO jacket issues. 3 frames still have FF's in one or the other eye (396, 426, 465 of 630).

Is there a way to workaround the file merging with itself issue? I've got a file I thought I could get around the issue by disabling the plugin, opening the file and saving again. I thought this would get rid of the octane data. It used to in the past(but I never had to do it for this issue before). However now when I re enable octane and load the file that should be now clean I still have all the messed up surfaces.

So I can't get rid of the bad octane data and continue forward. I've tried saving as a scene subset too and that doesn't seem to help.

jimgale wrote:further: (restarted daz, reloaded) reran the sequence - got thru - NO jacket issues. 3 frames still have FF's in one or the other eye (396, 426, 465 of 630).

More updates: Have done lots of renders since - only issue is fireflies. I turned up my 420x540 frames from 200 maxsamples to 400. Tighter, and more, fireflies - mostly on the edges of the eyes (for whatever reason).

jimgale wrote:

jimgale wrote:further: (restarted daz, reloaded) reran the sequence - got thru - NO jacket issues. 3 frames still have FF's in one or the other eye (396, 426, 465 of 630).

More updates: Have done lots of renders since - only issue is fireflies. I turned up my 420x540 frames from 200 maxsamples to 400. Tighter, and more, fireflies - mostly on the edges of the eyes (for whatever reason).

sounds good! while doing some own tests, i alos randomly had very isolated fireflies in the eyes (and if at all mostly only one single pixel) - a hotpixel_removal value of 0.75 took them away, without notable other smoothing (btw, you can apply that even if the rendering is done)...

I was wondering if you had looked at the user made material preset's?

At this time it messes up material/object assignments in the plugin.

This prevents us using texture atlas uv's set up previously to reduce texture counts and/sizes.

Isotemod wrote:I was wondering if you had looked at the user made material preset's?

At this time it messes up material/object assignments in the plugin.

This prevents us using texture atlas uv's set up previously to reduce texture counts and/sizes.

i'll take a look; if it is a quick fix i'll include it in the next update - scheduled for tomorrow...