Hi Robert,
That sounds interesting. I hope it can solve my problem in a much better way.
I am looking at the camera class and so far assuming that I need to use the
setPreDrawCallback function. Looks to me like RenderStage calls this after
culling has been done.
My day is ending now, will look more into this tomorrow.
This is however an area I am not well known in in OSG yet, so if you have more
information for me then please send a mail :-)
Thanx,
Viggo
> Date: Wed, 23 Jul 2008 15:01:50 +0100> From: [EMAIL PROTECTED]> To:
> osg-users@lists.openscenegraph.org> Subject: Re: [osg-users] Is it possible
> to know when the node-graph is 'dirty'?> > Hi Viggo,> > I think you are on
> totally wrong take w.r.t trying to track changes in> the scene graph, for
> what is effectively just a custom transparent> renderbin setup, and has
> little to do with the scene itself.> > The way you should tackle it is to
> customize the rendering backend so> that the bins you require are built for
> you. One one for instance> would be to post process the RenderStage and its
> contents after the> CullVisitor has filled it in.> > Robert.> > On Wed, Jul
> 23, 2008 at 2:52 PM, Viggo Løvli <[EMAIL PROTECTED]> wrote:> > Hi Peter,> >>
> > This is the problem I am trying to solve:> >
> -------------------------------------------> > Two partly transparent
> polygons intersect each other. Example: A tree> > created from two quads. The
> tree has many pixels that is completely opaque,> > and many pixels that is
> semi visible (transparent) and of course many> > invisible pixels.> >> > If
> you render them without writing to the depth buffer:> > - One will partly
> owerwrite the other.> >> > If you render them with writing to the depth
> buffer:> > - One will partly block the other.> >> > Solution:> > Render them
> twice.> > First render without writing to the depth buffer.> > Second render
> with writing to the depth buffer.> >> > When you have multiple trees then
> trees that are close to each other will> > some times overwrite or block each
> others, so I need to solve this too. It> > can be solved by rendering all
> trees in one pass, then all trees again in a> > second pass. Rendering each
> tree independently in two passes will only solve> > the problem for that tree
> while it can still block or overwrite other trees.> > So I must render all
> trees without writing to depth buffer and then all> > trees again with
> writing to depth buffer.> >> > This solution works greatly.> >> >> > The
> following is a new problem occurring when I am trying to render parts of> >
> the scene-grapth two times:> >
> -------------------------------------------------------------------------------------------------------->
> > I need to reduce the number of polygons I render twice.> > So, all
> completely opaque polygons need to be rendered only once.> > All transparent
> polygons must be rendered twice.> >> > The node tree is quite complex. It
> contains many different nodes which are> > turned on and off at runtime.> >>
> > I need to detect who got transparent polygons. This problem is solved by a>
> > node visitor that checks the node's stateset and sees if it contains the> >
> BLEND state turned on.> > I can also say that render bin 10 is the only bin
> that contain transparent> > objects.> >> > If I want to go for the group node
> solution then I need a group that point> > only to transparent objects, and
> another group that point to the same> > objects. I then need to render both
> in one go. Sounds doable, but would be> > quite messy when you shall fo
> example add LOD nodes that contains both> > transparent and opaque objects. I
> would need to split them apart runtime and> > actually rewrite the whole
> tree. I do not think that is doable.> >> > My solution was to mask the nodes
> so that I could use the cullMask on the> > camera to decide wether I want to
> render opaque objects or transparent> > objects. So I can have 3 cameras.> >
> First one render opaque.> > 2nd renders transparent without depth write.> >
> 3rd renders transparent again with depth write.> >> > The solution works like
> a dream this far.> >> >> > So what is the real problem?> > If someone add
> anything to the node tree, then I need to pre-process the> > nodes and set
> nodeMasks on them.> >> > I can as you suggest write an interface function
> that all of our code must> > use to add nodes to the tree. It would work
> nicely.> > Any future code will then be dependent on my library. Not a high
> price to> > pay.> > Any future 3rd party products we use will also have to
> use my add function.> > This may cost more. If the products create a sub-tree
> which it give back to> > me then I can add it through the function. If the
> product later on through> > OSG callbacks decide to add more nodes then I
> have a huge problem. They> > would not use my function and would proably have
> 0xffffffff as node mask> > which means they would be rendered one time per
> camera I use.> >> > So... I am struggeling to avoid this function. If I can
> somehow know that> > something is added to the tree, then I can simply
> re-format the tree. Any> > future products will therefore work automatically
> and no human errors can> > break the system.> >> > Sorry for writing such a
> large mail, but its hard to explain with letters> > :-) I hope it clearifies
> my problem.> >> > Cheers,> > Viggo> >> > ________________________________> >
> Date: Wed, 23 Jul 2008 15:10:45 +0200> > From: [EMAIL PROTECTED]> > To:
> osg-users@lists.openscenegraph.org> > Subject: Re: [osg-users] Is it possible
> to know when the node-graph is> > 'dirty'?> >> >> > Hi Viggo,> >> > This is
> only a suggestion (you may have other reasons). To avoid the human> > error
> as you called it, meaning that if someone forgets to call the reformat> >
> code...> > then you should have a method that 3rd party code/humans must use
> when> > adding to your scene, for example> >> > void
> CMySceneManagerThingy::AddToScene( osg::Node* pNode )> > {> > // add to
> wherever you want the pNode to be added in the scene> > <code here>> >> > //
> reformat your scene as you want> > <code here>> > }> >> > on the other
> subject about rendering multitimes the same object.. you should> > just
> create a new group and add your objects to that group> > and the group to the
> scene (do this as many times as you want)..> > don't know why you should be
> messing around with the renderbins? unless you> > are trying somekind of
> render pass?> >> > regards,> > Peter> > http://osghelp.com> >> >> > On Wed,
> Jul 23, 2008 at 11:00 AM, Viggo Løvli <[EMAIL PROTECTED]> wrote:> >> > Hi
> Peter,> >> > What you say is true in most cases. The 'simplest' way to do
> this would be> > to tell my system that the node-tree need re-formatting each
> time we call> > OSG to add children. That would require two calls each time,
> and also requre> > humans to remember to implement both calls. This opens for
> human errors,> > which at least I dont want (I am lazy).> > I want to make my
> module (the one that need to format the node-masks)> > independent of the
> rest of the system, and to ensure that the rest of the> > system will not
> need to know about my module.> > I also want to be able to add 3rd party
> libraries to my application without> > re-writing them to do special calls to
> my module when they add nodes to the> > tree.> >> > So, the conclusion I have
> is that I need to automatically know when I need> > to format the
> node-masks.> >> > The osg::Group has a callback function named
> osg::Group::childInserted.> > I can make my root-node into a sub-class og
> osg::Group where I implement the> > childInserted function. This way I will
> get a callback each time someone add> > nodes to my root-node. If a module
> create it's own osg::Group and add> > children to it dymically then I would
> not know anything about that.> >> > I also saw Roberts reply and I agree that
> a dirty system on the node-tree> > would be very expensive. I knew that my
> question was a longshot.> >> > I am now thinking about other solutions to
> achieve my goal. The goal is to> > render the world with 3 slave cameras. One
> shall render all render-bins up> > to bin 9. One shall render bin 10. And the
> 3rd shall render bin 10 and up.> > So bin 10 is rendered twice. This is to
> fix some glitches on transparent> > polygons that intersect each other while
> needing to write to the> > depth-buffer.> >> > Ok, so another solution would
> be to force a camera to only render a certain> > number of bins.> > I have
> not seen any place in the code around camera or cull-settings that> > you can
> specify a camera to stay within a limited range of render-bins, so I> > guess
> this won't be as easy either?> >> > Do you have any suggestions on how to be
> able to render one bin twice in the> > same frame. The first and second
> render of the bin shall have a few> > render-states set differently.> >> >
> Regards,> > Viggo> >> >> >> >> >> > ________________________________> > Date:
> Wed, 23 Jul 2008 07:58:37 +0200> > From: [EMAIL PROTECTED]> > To:
> osg-users@lists.openscenegraph.org> > Subject: Re: [osg-users] Is it possible
> to know when the node-graph is> > 'dirty'?> >> >> > Hi Viggo,> >> > Don't
> know the details of your code, but if you are adding a sub-node then> > you
> have code already that is called for adding the sub-node and> > thereby you
> know when the scene-graph has been modified?> >> > regards,> > Peter> >
> http://osghelp.com> >> >> > On Wed, Jul 23, 2008 at 7:51 AM, Viggo Løvli
> <[EMAIL PROTECTED]> wrote:> >> > Hi,> >> > My code is currently formatting
> the node-masks of the whole scene-graph> > before we start rendering. The
> formatting code is only ran once.> > If a sub-node is added to the node-tree
> afterwards then I want to run my> > formatting code again.> >> > Is there any
> way to know whether or not the scene-graph has been modified?> >> > Regards,>
> > Viggo> >> >> >> >> > ________________________________> > Windows Live
> Hotmail på mobilen. Ha alltid e-posten din tilgjengelig.> >
> _______________________________________________> > osg-users mailing list> >
> osg-users@lists.openscenegraph.org> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >>
> >> >> >> > --> > Regards,> > Peter Wraae Marino> >> > www.osghelp.com -
> OpenSceneGraph support site> > ________________________________> > Få Hotmail
> du også. Windows Live Hotmail nå med 5000 MB gratis> > lagringsplass.> >
> _______________________________________________> > osg-users mailing list> >
> osg-users@lists.openscenegraph.org> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >>
> >> >> >> > --> > Regards,> > Peter Wraae Marino> >> > www.osghelp.com -
> OpenSceneGraph support site> > ________________________________> > Få Hotmail
> du også. Windows Live Hotmail nå med 5000 MB gratis> > lagringsplass.> >
> _______________________________________________> > 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
_________________________________________________________________
Hold kontakten med Windows Live Messenger.
http://clk.atdmt.com/GBL/go/msnnkdre0010000003gbl/direct/01/_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
