Hi Robert.
In reality I'm not doing anything with the depth buffer since i never used
depth for a 2D projection in pure OpenGL programs.
For a simple OpenGL program I just draw components in sequence. As an
example like this:
void draw( void )
{
......
for( int i = 0; i < number_of_components; ++i )
{
glEnable() // for all necessary capacities of a geometry
glBegin()
//// draw vertexes
glEnd();
glDisable() // for all necessary capacities
}
}
The component[ number_of_componet - 1 ] in this case is always the top-most
visible no matter if it has blending or anything else.
-----------------
Hello Trajce Nikolov, sorry not to have a piece of code here because its
from the company.
But I'll reproduce the same error in a simple example to send you in c++ for
everyone to check as soon as possible.
--------------
Regards
Andre
2009/12/15 Robert Osfield <[email protected]>
> Hi Andre,
>
> Text by default will drop into the transparent bin so this is likely
> the reason why it's ordering is not exactly what you expect it. Text
> has to be in the transparent bin to ensure correct blending.
>
> Also I don't of if you are aware but rendering order only controls
> which item depends upon the current setting of the depth buffer - i.e.
> is depth test on, and what is rejected (normally more distance
> fragements are discarded) and the depth of the object. If you switch
> off depth test or the fragments have the same depth and fragements of
> the same depth pass the depth test will rendering order make a
> difference.
>
> In you case you don't specify what you are doing with the depth test
> or depth buffer, it's also difficult to guess at what level of
> understanding you have about depth buffers and depth test.
>
> Robert.
>
> On Mon, Dec 14, 2009 at 7:48 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
> ...
> > )
> > - 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.
> > Screen shots from my current diagram block configuration and my scene
> > http://yfrog.com/6eosgproblemp
> > http://yfrog.com/catextdefaultp
> > 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
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
