Nuke has been my go to application for testing WDP functionality since day one. The only downside if I had to pick one is that it often requires me to create Python bindings for the code being tested well before I’d like to. It isn’t Nukes fault though. The bindings would need to be generated regardless of which application I decided to perform my tests in. It’s just that Python bindings from scratch are tedious and boring. Not something a developer necessarily wants to do when progressing forward. Chores ewww! 🙁
Complaining aside I’ll take the minutiae of generating Python bindings vs shell output any day. Nuke allows me to easily create setups which not only can be visually manipulated but also visually display results. The ability to hookup nodes and expressions makes prototyping and verification tests a breeze.
I’ve dug through my archives and have chosen a few tests I created for the WDP which utilized Nuke in the process.
View Frustums
Nuke is perfect for testing Camera, Plane, and ViewFrustum related classes. One of my early scripts was for testing code that determines if a 3d coordinate is inside/outside a cameras view frustum.
The setup consisted of a single camera and 3d sphere, pretty basic. My idea was to set the spheres texture based on whether it was inside/outside the view frustum. I would utilize an Axis node to move the sphere around and watch the viewport to see which texture was displayed.
I configured the spheres material color so that it would switch between green when inside and red when outside. A no brainer of a test but as I recall the first time I moved the sphere around the material flickered wildly between both colors. Something was broken. 🙁
Once the bugs were ironed out though the test worked flawlessly. The sphere turned green when inside and then red when outside. I love tests like these because I often have trouble visualizing things with text alone. I’m more of a visual person and if I had to guess I’d say it plays a large part of why I excelled in the compositing realm. It’s just so damn visual!
The expression used in the materials Switch node is pretty basic. It converts the camera into a ViewFrustum and then tests the 3d location of the sphere.
def isInside(): from FSeq import FsCore node = nuke.toNode('Sphere1') cam = nuke.toNode('Camera1') knob = node.knob('translate') view_mat = cam.knob('transform').value() frustum = FsCore.ViewFrustum(cam_to_planes(node)) pos = view_mat.inverse().transform( nuke.math.Vector3( knob.value(0), knob.value(1), knob.value(2) ) ) return frustum.isInside(xyz.x, xyz.y, xyz.z) ret = isInside()
Later on in development the same setup was modified for testing bounding box and plane intersections.
Color library testing
The color library provides the ability to register many different data types. During development of the ColorPrimary and Illuminate classes a custom Nuke node was created for testing purposes.
The builtin Colorspace node in Nuke doesn’t see much use these days with the advent of OCIO. But its a great node to compare functionality and with just a few tweaks could still be viable in a color management world.
Looking at the builtin node one of the most obvious drawbacks is that its colorspaces, illuminates, and primaries are all hard coded. The only method to include additional entries is with a recompile. Booooo!
The color library with its registerable datatypes allows for a more robust node that can adapt without the need for recompilation. The custom ColorSpace node also provides the ability to manually enter illuminant and primary values. It’s a bit sad the builtin node doesn’t at least provide manual illuminant/primary entry.
Another draw back of the builtin node is that some colorspaces do not include information as to which primaries they use. During development I encountered numerous third party applications and command line tools which did not use the same color primaries. It was not an uncommon scenario to discover one application using Rec.609 and another using Rec.709. YCbCr and YPbPr were the most common colorspaces third party source code had varying values for.
Due to the minefield encountered with color primaries and illuminates additional default entries were added to the color library that may not have been included otherwise. Some entries may not even be valid but were added so exact color matching of externally generated material would be possible.
The nodes available options update on the fly when registering new primaries and illuminates with Python. It was pretty neat the first time I tested data registration.
|
|
|