feedback

32 views
Skip to first unread message

Shawn Neely

unread,
Mar 15, 2017, 6:06:15 PM3/15/17
to OpenDCX Forum
We have the latest 2.2.2-2 build working now along with the Nuke plugins and it looks very promising!

How do you want to receive feedback?  Just informally on this forum for now?  Here are a couple of early observations regarding the Nuke plugins:

1. It's pretty easy to accidentally crash Nuke if you're just creating DCX nodes and hooking them up in random sequence.  For example, starting with an empty Nuke script, add a DeepSurfaceType node, then connect a DeepSubpixelMask node to the output.  Without valid deep data, Nuke will crash in the deepEngine() routines, so you probably want to add some deep_in_plane.channels.empty() checking.

2. We haven't explored all the various knobs for DeepTransform yet, but setting supersampling to 16 on a deep read and transform of the dcx_reyes_both_geo.exr example causes the data to completely disappear, even with an identity transform.

We've got a few Pixar TDs eager to jump in with testing so I'm sure we'll have more feedback coming soon.  :)

thanks,
shawn.

Jonathan Egstad

unread,
Mar 15, 2017, 6:25:55 PM3/15/17
to OpenDCX Forum
How do you want to receive feedback?  Just informally on this forum for now?  Here are a couple of early observations regarding the Nuke plugins:

Sure, unless you have a recommendation? This is all new to me...

 
1. It's pretty easy to accidentally crash Nuke if you're just creating DCX nodes and hooking them up in random sequence.  For example, starting with an empty Nuke script, add a DeepSurfaceType node, then connect a DeepSubpixelMask node to the output.  Without valid deep data, Nuke will crash in the deepEngine() routines, so you probably want to add some deep_in_plane.channels.empty() checking.

Good to know, I've fixed several of those since the 2.2.1 release. Usually it's exactly what you describe - missing input channels not handled well.


2. We haven't explored all the various knobs for DeepTransform yet, but setting supersampling to 16 on a deep read and transform of the dcx_reyes_both_geo.exr example causes the data to completely disappear, even with an identity transform.

I saw that too and had not tracked it down completely.  In practice anything past 8 is very expensive due the number of additional samples that are created, but the base algorithm should at least work at higher rates (and obviously support stochastic jitter.).

btw DeepTransform needs to detect identity and turn itself off so that it's not expensive or creating add'l channels when it's not doing any work.

Thanks for the feedback!

Jonathan Egstad

unread,
Mar 16, 2017, 4:47:44 PM3/16/17
to OpenDCX Forum
Hi Shawn,

There's bug fixes in the latest 2.2.2 code which is now available on github as well as the web site tar balls.


1. It's pretty easy to accidentally crash Nuke if you're just creating DCX nodes and hooking them up in random sequence.  For example, starting with an empty Nuke script, add a DeepSurfaceType node, then connect a DeepSubpixelMask node to the output.  Without valid deep data, Nuke will crash in the deepEngine() routines, so you probably want to add some deep_in_plane.channels.empty() checking.

Fixed.
 
2. We haven't explored all the various knobs for DeepTransform yet, but setting supersampling to 16 on a deep read and transform of the dcx_reyes_both_geo.exr example causes the data to completely disappear, even with an identity transform.

This turned out to be a stupid bug in DcxDeepTransform which had a max bin accumulation limit of 255 since only a byte was being used to store the value. Made it an int and that fixed supersampling 16+.

Cheers,
-jonathan

Reply all
Reply to author
Forward
0 new messages