Hi, We can do both. But it's a bit of storage waste, with a matrix you get same quality world coordinates, and you can use it for different Z values and of course all kinds of other fun effects (like use of motion vectors).
-Ton- ------------------------------------------------------------------------ Ton Roosendaal Blender Foundation [email protected] www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 9 Jan, 2013, at 14:34, Jeroen Bakker wrote: > Hi > > or we can add a World position render layer inside blender (other > renders have these) > I added one for cycles in a private branch as the worldposition is > already known in cycles and give better quality of the position. > > Jeroen. > > On 01/09/2013 11:19 AM, Ton Roosendaal wrote: >> Hi, >> >> I would also sugges to first stick to pixel operations. >> >> A good use case would be to allow relighting, based on getting inverse view >> transforms from RenderLayers, so you can map (x,y + z) pixel coordinate to >> 3d. Add to that UV and Normal and you can go! >> >> I always wanted to add this transform matrix to renderlayers and openEXR >> files... or was this done already? >> >> -Ton- >> >> ------------------------------------------------------------------------ >> Ton Roosendaal Blender Foundation [email protected] www.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands >> >> On 9 Jan, 2013, at 1:32, Dan Eicher wrote: >> >>> On Tue, Jan 8, 2013 at 4:32 PM, Brecht Van Lommel < >>> [email protected]> wrote: >>> >>>> As I understand it, libjit doesn't actually come with any language >>>> compiler, it's just a way to generate instructions manually. So I'm >>>> not sure how using that would be trivial, LLVM gives you the same >>>> functionality as libjit, but the actual implementation of OSL on top >>>> of LLVM is still a lot of code? >>>> >>>> >>> Yeah, one would have write a parser to use libjit, not too terribly hard >>> but... >>> >>> What I really meant was a way to call the compiled functions which it seems >>> is basically what OSL::ShadingContext is, a wrapper around the llvm >>> function calling mechanism with extra stuff tacked on for OSL globals and >>> whatnot. >>> >>> >>>> If you're going to allow only basic pixel processors, i.e. just >>>> reading and writing to pixels in the same location then it fits quite >>>> well already. You can have basic input/output parameters of shaders >>>> and it could run for each pixel. >>>> >>>> If you want to do things like blurring it gets more complicated >>>> because there is no concept of image buffers to read/write to, so some >>>> sort of mechanism for that would need to be implemented. >>>> >>>> From the IRC discussion it was decided not to do any complex things like >>> blurs since there's no guarantee that the pixels you want to look up >>> actually exist due to the way the compositor works with multi-threading and >>> tiles. So just simple single pixel stuff like relighting a scene (Ton's >>> example), technicolor, film-grain (I guess would work?) &etc. >>> >>> Dan >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
