[Bf-committers] OSL Composite Node
Ton Roosendaal
ton at blender.org
Wed Jan 9 14:47:51 CET 2013
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 ton at blender.org 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 ton at blender.org 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 <
>>> brechtvanlommel at pandora.be> 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
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
More information about the Bf-committers
mailing list