I think my custom RenderStage is the only approach for what you
describe, because the number of passes can't be known until draw time.
In your case, you could override RenderStage::draw and iteratively call
uniform::apply and RenderBin::draw. See my post in this thread, in which
I include basic
Hi,
can I add something here?
What about a simple multipass (unknown until the draw stage), with rendering
done by a glsl shader, and shader variable update in function of the pass, like:
void render() {
setGlslProg(prog); //which uses uniform_x
for(i(0); i != num_of_passes; ++i) {
Art Tevs wrote:
Hi J.P., Paul
yes, exactly like Paul said, I know the number of iterations at cull time.
Chaning the number of iterations at rendering time would be either to write a
special RenderStage, as Paul propose, or to write a draw callback which will
iterate the whole execution. Howev
Hi J.P., Paul
yes, exactly like Paul said, I know the number of iterations at cull time.
Chaning the number of iterations at rendering time would be either to write a
special RenderStage, as Paul propose, or to write a draw callback which will
iterate the whole execution. However, this seems to
Hi J.P.
No, before the execution the number of iteration is not known. However the
iteration number is known just right before rendering the subgraph. So in
programming language paradigm it is the same as for-loop with known number of
iterations.
In the future one can think on iterating until
Art Tevs wrote:
- then I have specified some kind of extra pre-draw callback for this special
repeatable group node (by placing empty drawable under that group), which is
active only on iteration >= 2. In this callback I reset textures to the shaders
accordingly to the output of the very last
J.P. Delport wrote:
Art Tevs wrote:
- then as soon as I reach a group node, which's subgraph should be
repeated, I retraverse the subgraph as often as there are iterations
Is the number of iterations known before execution?
In Art's case, the number of iterations would have to be known at cu
Hi Art,
just a question...
Art Tevs wrote:
- then as soon as I reach a group node, which's subgraph should be
repeated, I retraverse the subgraph as often as there are iterations
Is the number of iterations known before execution?
jp
Cheers, art
Paul Martz wrote:
Hi Art -- I'm wond
Hi Paul,
I am not that familar with customizing RenderStage, but it seems it would be
the way to go. However, I am not sure if using own RenderStages is that easy in
osg.
I solved my problem in a different way. So, this is how I do with osgPPU in a
new module called UnitBypassRepeat:
- use t
Hi Art -- I'm wondering if there's a slick way to tap into RenderStage
to do what we want here. Assuming you have a Camera with a scene graph
attached, and want to render it multiple times, then ideally the draw
iteration could just happen atomically in some kind of custom
RenderStage associate
I am using svn/trunk.
Ok, I found it, it calls "TraversalOrderBin", not "SceneGraphOrderRenderBin",
hence was not able to see it quickly.
Perfect, setting up the sort mode of the renderbin to "TRAVERSAL_ORDER" helps
to solve my problem. Very usefull thing, thanks!
art
robertosfield wrote:
>
Hi Art,
The support for SceneGraphOrderRenderBin is only in svn/trunk.
Robert.
On Tue, Oct 20, 2009 at 5:41 PM, Art Tevs wrote:
> Hi folks,
>
> J.P: thanks, but it seems that this is a little bit different problem.
>
> Hmm, it seems that state sorting prevents me of repeated rendering of severa
Hi folks,
J.P: thanks, but it seems that this is a little bit different problem.
Hmm, it seems that state sorting prevents me of repeated rendering of several
things at the same time. For example: two nodes are being gathered by the
CullVisitor and placed into the stategraph for rendering. Howe
Hi all,
see also this thread for maybe a different idea. We also need multiple
(but variable) passes for an image processing algorithm.
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/49423
regards
jp
Paul Martz wrote:
Art Tevs wrote:
P.S. The solution is practicaly for impl
Art Tevs wrote:
P.S. The solution is practicaly for implementing iterative image processing
algorithms with osgPPU for example.
I've been thinking about the same issue, rendering a subgraph repeatedly
with different texture input and FBO setup output, for purposes of depth
peeling. Overridin
Hi guys,
thanks for the tipps. I also was thinking about overriding the traverse method
as JS said. So in deed this is what I need. A simpler thing would be also,
what Robert proposed, just to write own traverser.
However, in my case I will also have a circular dependency in the graph. So
so
Hi Art,
The suggestions from JS and Gordon are both pretty reasonable ways to
tackle this problem. The only thing I'd add is that a variation of
JS's solution would be to use a cull callback attached to a Group node
that does the repeated traverse for you without the need to subclass
from osg::Gr
__
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org [
mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Art Tevs
Sent: Monday, October 19, 2009 11:20 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Repeatable rendering of subgraphs, ideas?
Hi
Hi Art,
Of course the amount of repeats should be changeable during run time, hence simple multiple "copy" of group A will not work.
Make a subclass of osg::Group which has an overridden traverse() method,
which is like this:
void traverse(osg::NodeVisitor& nv)
{
for (unsigned int i = 0
Hi folks,
I need to render a subgraph multiple times per frame. So, not the way how
osg::Sequence work, where it renders a subgraph for specified amount of frames,
but I want to render the same subgraph several times during one frame.
The graph will look for example like this one:
root
|
grou
20 matches
Mail list logo