On Tue, 2012-09-04 at 19:15 -0400, Jean-Sébastien Guay wrote:
> Hi Jeremy,
>
> In the past I've done similar low-level 2-pass rendering in a Drawable,
> by doing as Robert suggests. Apply one stateset, draw, apply another,
> draw again (same or different geometry).
>
> A Program is just state, so you need to draw something in between
> setting different Programs. Otherwise setting the first Program has no
> (visible) effect. I know it sounds obvious but I thought I'd just throw
> that out there so there's no ambiguity :-)
>
> Hope this helps,
Hey Paul. :)
It's not simply an issue of setting two similar state attributes in
sequence; the NV_path_rendering API is different enough in that for the
stroke you may want to use a shader and for the fill you may want to
reset the state and use whatever fixed state was available previously,
which is why I've had the issues. HOWEVER, I could just implement
everything as shaders anyways.
What I really seem to need is like a State::save(), State::restore()
kind of thing...
> J-S
>
>
> On 04/09/2012 1:23 PM, Jeremy Moles wrote:
> > On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
> >> Doesn't a Drawable's state get applied prior to the call to
> >> Drawable::drawImplementation()? If so, you could just put the _program in
> >> your
> >> Drawable's StateSet?
> > I'm working on a nodekit for NV_path_rendering, which takes an "as of
> > yet unseen" approach to rendering; new go OpenGL, at any rate. :)
> >
> > They call it the "Stencil then Cover" approach, and like most 2D vector
> > drawing libraries, there is a notion of both STROKING _and_ FILLING. In
> > order to support arbitrary shading on both the affected stroke fragments
> > and affected fill fragments, I need to be able to potentially set two
> > different shaders during a single drawable drawImplementation.
> >
> > Now, having said that--which I potentially should have mentioned in the
> > first email--does that change any advice you might have? :)
> >
> > (Thanks for the response, btw... good info.)
> >
> >> It's easy to verify that things are happening in the right order using a
> >> debugger with breakpoints set at your drawImplementation() and also at
> >> Program::apply().
> >>
> >> If it doesn't happen as I describe above, then I believe what you're doing
> >> below
> >> is the most robust, as that code would work with all other rendering in the
> >> scene graph, both shader and non-shader rendering.
> >>
> >> Honestly it's been too long since I played at this level. But I seem to
> >> recall
> >> that the difference between:
> >> _program->apply( state );
> >> and
> >> state->apply( _program.get() );
> >> is that the latter tracks the currently bound program, doesn't bother to
> >> apply
> >> it if it's already in use, and would probably allow you to remove the call
> >> to
> >> setLastAppliedProgramObject(0).
> >> -Paul
> >>
> >>
> >> On 9/4/2012 9:58 AM, Jeremy Moles wrote:
> >>> I am creating a custom Drawable that needs to push a Fragment Shader
> >>> into the current rendering state and then, after a single extension
> >>> call, subsequently remove this shader from the state.
> >>>
> >>> I have some code I noodled through to make this work, but I feel like
> >>> there is probably a better way. It goes something like this:
> >>>
> >>> ----------------------------------------
> >>>
> >>> drawImplementaion(RenderInfo& ri) {
> >>> State* state = ri.getState();
> >>> unsigned int contextID = state->getContextID();
> >>>
> >>> _program.apply(state);
> >>>
> >>> myExtensions->doMycall();
> >>>
> >>> GL2Extensions::Get(contextID, true)->glUseProgram(0);
> >>>
> >>> state->setLastAppliedProgramObject(0);
> >>> }
> >>>
> >>> ----------------------------------------
> >>>
> >>> Like I said above, this "works", but I feel like there is probably a
> >>> cleaner way to achieve what I want. Note that _program is a ref_ptr to a
> >>> properly create osg::Program object, since I certainly do NOT want to
> >>> recreate all the goodness it provides. :)
> >>>
> >>> Any API advice?
> >>>
> >>> _______________________________________________
> >>> osg-users mailing list
> >>> osg-users@lists.openscenegraph.org
> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >>>
> >>>
> >> _______________________________________________
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
