very cool! Putting on my non foundry user hat on here. Even though it is inefficient, it would be good to have a T based cube map option just because this is what many game engines and gpus support by default. wink wink :)
-- Deke Kincaid Creative Specialist The Foundry Skype: dekekincaid Tel: (310) 399 4555 - Mobile: (310) 883 4313 Web: www.thefoundry.co.uk Email: d...@thefoundry.co.uk On Wed, Aug 27, 2014 at 6:55 PM, Haarm-Pieter Duiker < l...@duikerresearch.com> wrote: > Hey, > > Following up on this thread. There's a Blink implementation of the > panorama to panorama mapping up on Nukepedia now. > http://www.nukepedia.com/blink/transform/environmenttransform > > Hope that helps, > HP > > > > > > On Mon, Aug 25, 2014 at 3:11 PM, Michael Garrett <michaeld...@gmail.com> > wrote: > >> In fact I took maths for the angular map transform (latlong to angular, I >> think) from an old Debevec Siggraph paper or something, or maybe the book >> he wrote....so maybe that was yours too! Since I know you worked with him >> on all that interesting stuff. >> >> >> On 25 August 2014 03:17, Haarm-Pieter Duiker <l...@duikerresearch.com> >> wrote: >> >>> Hey, >>> >>> That environment blur script has the start of what you need for a >>> panorama transform node. That script defines the function >>> 'spherical_tex2dir' that maps UV coordinates to directions. Define the >>> inverse of that, mapping a direction back to UV coordinates and you have >>> what you need for the spherical mapping. Do the same for angular, chrome >>> ball and whatever other mapping you need and you have the pieces you need >>> to write the full transform. >>> >>> The basic algorithm that I've used in the past was, for each output >>> pixel: >>> - map output pixel coordinate to UV >>> - map UV coordinate to direction using the output panorama format >>> - map direction to UV coordinate using the input panorama format >>> - map UV coordinate to pixel coordinate and sample input image >>> >>> Oversampling, rotations and handling chrome balls vs. pan-and-tile panos >>> (reflections vs. direct view) should be pretty easy to add on top of that. >>> >>> If I get some time this week, I can take a look at putting that >>> together. The formats I used to have supported were Spherical, Angular, >>> Fisheye (180 degree), Chrome Ball and Cubic (but that was a little funky). >>> What other pano formats are needed? >>> >>> HP >>> >>> >>> >>> >>> >>> On Sun, Aug 24, 2014 at 7:07 PM, Michael Garrett <michaeld...@gmail.com> >>> wrote: >>> >>>> I put it together before I knew about that 0.5 pixel offset trick, I >>>> would say it needs updating but then Haarm-Pieter Duiker's blink >>>> EnvironmentBlur node looks like the real deal. >>>> >>>> http://www.nukepedia.com/blink/filter/environmentblur >>>> >>>> >>>> On 24 August 2014 19:02, Patrick Heinen <mailingli...@patrickheinen.com >>>> > wrote: >>>> >>>>> Yeah I picked your EnvConvolve apart the other day to have a uv mapped >>>>> spherical transform ;) (by the way, don't forget your +0.5's for pixel >>>>> center) >>>>> I think a blink spherical transform would be worth it, seeing that >>>>> nuke's spherical transform is pretty slow. >>>>> I might give it some more thought tonight. >>>>> >>>>> cheers, >>>>> Patrick >>>>> >>>>> On 24.08.2014, at 15:51, Michael Garrett <michaeld...@gmail.com> >>>>> wrote: >>>>> >>>>> Definitely possible. I've seen a couple of UV map Blink things already >>>>> but haven't actually done anything myself yet. For example: >>>>> http://nickdeboar.wordpress.com/2014/01/02/nuke-8-blink-script/ >>>>> >>>>> I have the UV map math for some of the transforms and it could be >>>>> applied to Blink for sure. Have a look at the innards of my somewhat out >>>>> of >>>>> date EnvConvolve gizmo (which may need fixing...): >>>>> >>>>> http://www.nukepedia.com/gizmos/filter/envconvolve >>>>> >>>>> >>>>> On 24 August 2014 18:31, Frank Rueter|OHUfx <fr...@ohufx.com> wrote: >>>>> >>>>>> Possible? Worth it? Anybody up for it? :) >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> <ohufxLogo_50x50.png> <http://www.ohufx.com/> *vfx compositing >>>>>> <http://ohufx.com/index.php/vfx-compositing> | workflow customisation and >>>>>> consulting <http://ohufx.com/index.php/vfx-customising> * >>>>>> >>>>>> _______________________________________________ >>>>>> Nuke-users mailing list >>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
