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) {
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
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.
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
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
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
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
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
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 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
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
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.
Hi Art,
The support for SceneGraphOrderRenderBin is only in svn/trunk.
Robert.
On Tue, Oct 20, 2009 at 5:41 PM, Art Tevs arti_t...@yahoo.de 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
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
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
|
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;
__
-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,
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
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
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.
20 matches
Mail list logo
