Hi Andre, Block diagrams won't help as that most likely not at issue. What are you doing with the depth buffer/depth test? What you are doing the with the depth of each of the objects?
Robert. On Mon, Dec 14, 2009 at 6:17 PM, Andre Simoes <[email protected]> wrote: > Hello Robert. > Sorry about the bad explanation of my problem. > I think is better to start from scratch and just explain the problem to you. > I'm making a widget system, on Ortho2D, that separates levels of parents > from childs by osg::Groups ( osg::PositionAttitudeTransform, osg::Switch ... > ) > There are two png files attached (a block diagram and its osg scene ) that > gives a better idea of this groups.... > - The children position is always related to the bottom top vertex of the > parent ( i.e, a text inside a box ). > --------------------- > | | > | | > |text (at 0,0) | > ---------------------- > box at (20,20) > - Children have to be drawn on top of the parent ( the parent area can be > hidden by the child but the child cannot be hidden by the parent drawing ). > ( i.e white child text on a black box ) > |----------------------- | > |------------------------| > |------------------------| > |---WHITE TEXT--| > |------------------------| > ------------------------ > My problem is to always make all kinds of Geometries that are on the leafs > of my tree as the top most visible. > For example: If i have a tree in the following sequence > root -> Rectangle1 > child -> Rectangle2 > child -> Triangle3 > OpenGL should draw Rectangle1 than Rectangle2 and on the end Triangle3 to > the FrameBuffer. > On the monitor: Triangle2 will be above Triangle1 and Triangle3 will be > above Triangle2 (in case those are being drawn at the same place ). > --------------------------------- > | -------------------- | > | | / \ | | > | | / \ | | > | | / \ | | > | | --------- | | > | | Triangle3 | | > | --------------------- | > | Rectangle2 | > | (below triangle3) | > -------------------------------- > Rectangle1 ( goes below everyone ) > I've made some separate tests and noticed that if my geometries have just > the same StateSet configuration ( i.e all geometries with > StateSet::setGlobalDefault ) I can make this result on the frame buffer. > But when i add a osgText::Text element for example as: > root -> Rectangle1 > child -> Rectangle2 > child-> osgText::Text > ----------------------------------------- > | -------------------------------- | > | | "no osgText::Text" | | > | | inside | | > | |_________________ | | > | | > |_______________________| > The text will only appear if i make > _child_text->getOrCreateStateSet()->setGlobalDefaults(); that makes me to > loose transparency and other configurations for the osgText::Text component. > I've already tried to use "setRenderBinDetails" ( version 2.9.5 ) and > worked... But if I simply use setRenderBinDetails i will have to rebuild > all the binNum for every visual on my graph after a simply insertChild > because they will be not in the right draw order. > For our system this is not good. Because the number of components that my > co-workers generally draw are very large and it would take very long to > rebuild the number for the graphs just because of a removal or an insertion > of component. > Is there anything that i could use to ensure that they will always be > processed in the order that they are being added as child bypassing the > state set configuration ? > Regards > Andre > 2009/12/14 Robert Osfield <[email protected]> >> >> Hi Andre, >> >> I'm finding it difficult to guess what your after/what problems your >> seeing. The best I can do is say as a general note, one would >> typically use control the rendering order via >> StateSet::setRenderingDetails(..) from within the scene graph rather >> attempting to set globals. >> >> Robert. >> >> On Mon, Dec 14, 2009 at 2:06 PM, Andre Simoes <[email protected]> >> wrote: >> > Hello There. >> > >> > I've been reading alot of e-mails regarding drawing of objects in >> > sequence, >> > like a simple OpenGL program that draws each Geometry independently of >> > its >> > complexibility and cost to the GPU. >> > >> > And for now I'm working in an OSG scenario in which I'm doing a toolkit >> > that >> > generates widgets in 2D Orthographic mode. Almost all of the components >> > are >> > being drawn with LIGHTING disabled because they are unecessary for the >> > case. >> > And with or without RenderBin::TRAVERSAL_ORDER option enabled I can add >> > a >> > widget as a child of other widget without problems by using >> > osg::Group::insertChild( 0, child ). >> > >> > The problem is when I try to draw osgText::Texts inside components as >> > children. They simply not appear on the screen. >> > - if i create them and set their StateSet as setGlobalDefaults the text >> > appears as a Child of other widgets ( But in this case i loose color and >> > background transparency control of the text and is something i would not >> > like to loose ). >> > - If i draw them without a widget on the screen the Text appears. >> > >> > After that I thought that TRAVERSAL_ORDER could solve the problem. But >> > TRAVERSAL_ORDER is not solving the problem. >> > >> > I'm doing on the initial part of my code before creating any X Window >> > with >> > osgViewer::View... : >> > >> > int main( void ) >> > { >> > using namespace osgUtil; >> > RenderBin::setDefaultRenderBinSortMode( >> > RenderBin::TRAVERSAL_ORDER >> > ); >> > RenderBin::SortMode s = >> > RenderBin::getDefaultRenderBinSortMode(); >> > >> > /// window init >> > /// widget init >> > >> > return viewer.run(); >> > } >> > >> > My questions are: >> > - Am I looking to the right option (RenderBin::TRAVERSAL_ORDER ) ? >> > - Am I setting TRAVERSAL_ORDER in the right way ? >> > >> > Sorry to ask but i already lost one week searching for documentation >> > about >> > this problem and no good results. >> > >> > Kind Regards >> > Andre >> > >> > >> > _______________________________________________ >> > osg-users mailing list >> > [email protected] >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> > >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
