Thanks Jonathan. Great info as usual.
Will definitely drop a feature request for some more control over how the
renderer handles the screen bbox.
The only vertices automatically clipped are ones behind the camera, so you
> shouldn't have a problem with verts outside the frustum sides.
>
Ah, I see. I hadn't even tried it, but I misunderstood your previous reply,
where you said "don't worry about clipping to the screen". I interpreted
that the other way around, as if clipping occurred automatically on the
frustum sides. This is clearer now.
Thanks,
Ivan
On Wed, Aug 17, 2011 at 1:22 PM, Jonathan Egstad <jegs...@earthlink.net>
wrote:
>> - As far as I can tell, lensNFunc is acting like a vertex shader,
>> right? As in, I can only push around existing vertices, and then get
>> interpolated values between them. For the cases where the existing
>> geometry isn't dense enough, is there any way to force the primitives
>> to tessellate from within a lensNFunc?
>
> Yes, it's basically like a vertex shader, and Primitive uses the
vertex_shader() method when it tessellates, but the lensNfunc is used during
tessellation when the rPrimitive's 'add_to_render()' method is called to
(possibly) further tesselate the rPrimitive.
>
> The reason this isn't all done in vertex_shader() is that the shaders
remain in non-distorted world-space so that lighting calculations remain
consistent, but the final screen location of the vertex can still get
changed. It probably could have all been rolled together into a single
shading stage but that's not how it evolved...
>
>
>> - If I push some of the vertices around, the screen-space bbox doesn't
>> grow accordingly. Seeing that lensNFunc gets passed a pointer to the
>> scene, I've tried to manually set the Scene's screen_bbox_, but the
>> renderer (scanline render) doesn't seem to care about that. Where does
>> the renderer get the info to set its own bbox?
>
> The renderer is probably just using the Scene's bbox projected through the
matrix so any vertex shader or lens func is likely ignored. This is one of
the reasons why the renderer *didn't* attempt to reduce it's screen-space
bbox and left it at the format maximums...
>
> What's really needed is a user option to specify how the renderer calcs
it's bbox so that you've some control over it... Wanna put in a feature
request...?
>
>
>
>> - Last question. Fortunately, the distortion model I'm using doesn't
>> require this, but if one needed to pull vertices that fall outside the
>> camera frustum (say, a vertex that's outside, but would fall into the
>> screen once it's distorted), would there be a way to do that from
>> within a LensNFunction?
>
> The only vertices automatically clipped are ones behind the camera, so you
shouldn't have a problem with verts outside the frustum sides.
>
>
>
>>
>> Thanks again,
>> Ivan
>>
>> On Wed, Jul 6, 2011 at 9:18 AM, Jonathan Egstad <jegs...@earthlink.net>
wrote:
>>>> But if I try the same with lens_function(), I get no joy. In my case,
it looks like lens_function() is never even called (as in, I don't get its
cout, which is still my lame way of debugging) :)
>>>>
>>>> /*virtual*/ LensFunc* lens_function(int mode) const {
>>>> cout << "custom projection func" << endl;
>>>> return myLensFunc;
>>>> }
>>>>
>>>>
>>>> In any case, I was only interested in implementing my own LensNFunc, so
it's all good. But I'd be interested in knowing whether lens_function() is
meant to work differently, or if it's just not doing what it should be
doing.
>>>
>>>
>>> That's likely correct, especially since there's only a LensNFunc pointer
stored in the Scene. It's probably a case of lens_func being deprecated in
favor of LensNFunc as it's clearly more efficient to use the array method.
>>> To be honest I can't completely recall the sequence of events re. these
functions...
>>>
>>> -jonathan
>>>
>>> _______________________________________________
>>> Nuke-dev mailing list
>>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>
>> _______________________________________________
>> Nuke-dev mailing list
>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
> _______________________________________________
> Nuke-dev mailing list
> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
