I did a little test setting the threading at different amounts and testing the rotation controls in the SphericalTransform node on Windows and it appears that the higher I set the threads the slower the performance is, almost increasing exponentially. The default setting on the workstation I'm on at the moment (Win 7, 2x Intel E5-2689, 64gb) is 32 threads. Threads at 1 or 2 performs like butter. Might be worth having the devs investigate why there's a performance hit with this node, must be a threading issue.
Best, John On Thu, Mar 28, 2013 at 2:21 PM, Michael Garrett <[email protected]> wrote: > Hey Gary, > > If I'm understanding yo correctly, one way you could abstract out this > rotation to make it a bit more clear is to project the cubic environment > through a sixpack (cubic camera) setup and then you can just parent the > setup to an Axis to do the master rotation. > > Check this nice tutorial Frank R did a while back for some pointers on a > latlong>cubic>projection workflow. > > http://www.youtube.com/watch?v=Uq0kcUJ_XA8 > > > > > On 26 March 2013 11:03, Gary Jaeger <[email protected]> wrote: > >> Can someone give me a sanity check on what to expect with the >> SphericalTransform node? I'm doing something I *think* should work fine, >> but isn't. >> >> Imagine we want to take projectors and project onto the ceiling, walls >> and floor of a room. Pretend our room is a cube, and we can get the >> projectors into position such that their 90 deg FOV maps perfectly to >> walls, ceiling and floor. >> >> Our approach has been to render a vray 360 cube and crop it 6x (or just >> render individual cameras) , run those through SphericalTransform nodes to >> break out the -x, +x etc and then pipe those into a separated cube mesh to >> "check our work" as it were. We enter values (-90, 180, etc) in the output >> rotation fields to spin the -x to the LEFT etc. All good so far, and things >> look correct. The sides are all in their correct places. The trouble comes >> when we want to rotate that cubic SphericalTransform to spin the content on >> the surface of our cube mesh. >> >> It seems like we should be able to rotate the output rotation values and >> have the imagery spin on the "walls". We expression tied the output >> rotations together (we also tried the input rotations) so we could "spin" >> all 6 together. It "works" in the sense that the imagery spins, but the >> imagery gets all split up. It feels like maybe a rotation order thing, or >> we just doing something fundamentally wrong. >> >> We *should* be able to do this, right? >> >> Gary Jaeger // Core Studio >> 249 Princeton Avenue >> Half Moon Bay, CA 94019 >> 650 728 7060 >> http://corestudio.com >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
