Hi Murray,

The OpenFlight format is pretty crap when it comes to identifying
which objects should be treated as opaque or transparent.  The OSG has
to do a best guess based on an alpha values present in colour or
textures.  It could be that your model is being treated as completely
transparent so all objects are placed in the transparent bin.

Convert your .flt or an .osg or .osgt (if you have svn/trunk or 2.9.x)
and then have look at all the StateSet's in the model to see how they
have been identified.

Robert.

On Wed, Feb 23, 2011 at 7:37 PM, Murray G. Gamble
<mgam...@connect.carleton.ca> wrote:
> Thanks for the suggestion, Chuck.
> I've tried this, and do not observe any appreciable improvement in
> rendering.  I should point out that while the images I provided highlight
> the main rotor disc as the offending geometry, there are numerous other
> geometry elements (e.g., windows) that cause similar issues when viewed from
> various angles.
> I've stepped through the OpenFlight loader in debug mode and have observed
> that the rotors and windows are both being caught by the tests therein for
> translucent images and transparent materials, respectively.  These tests
> result in the state sets being set as you've suggested, so it appears that
> OpenFlight loader is treating these nodes correctly.
> Any other ideas?
> Murray
> On 2011-02-23, at 1:57 PM, Chuck Seberino wrote:
>
> Murray,
>
> Your rotor is being placed in the Opaque render bin, which is causing all of
> the geometry behind it to be culled out.  You need to make sure it is in the
> transparent bin.  You should add these to the stateSet of the rotors:
>
>      stateSet->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
>      stateSet->setMode(GL_BLEND, osg::StateAttribute::ON);
>
> HTH,
> Chuck
>
> On Feb 23, 2011, at 10:53 AM, Murray G. Gamble wrote:
>
> Hi All,
>
> We have an OpenFlight model of a helicopter that exhibits some undesirable
> rendering behaviour in OSG.  Specifically, various parts of the helicopter
> geometry are being culled and/or rendered in the wrong order.  We do not
> observe this behaviour when rendering the same model using Vega Prime.  I've
> attached a couple of screen captures that exemplify the issues.
>
> Can users with similar experiences provide any suggestions as to how to
> avoid these rendering artifacts? Does the model component/geometry hierarchy
> need to be modified and/or are there programmatic things that can be done
> within our OSG application to remedy the situation?
>
> I'm using OSG 2.8.0.
>
> Many thanks,
>
> Murray
>
> <CH149-OSG.jpg><CH149-VP.jpg>
>
>
>
> _______________________________________________
>
> 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
>
> --
> Murray G. Gamble, CMSP
> Director of Modeling & Simulation
> VSIM / Advanced Cognitive Engineering (ACE) Lab
> 2227 V-SIM, Carleton University
> Ottawa, Ontario, K1S 5B6
> off: 613.520.2600 x2475
> cell: 613.298.0997
> fax: 613.520.2539
> e-mail: mgam...@connect.carleton.ca <mailto:mgam...@connect.carleton.ca>
> http://acelab.carleton.ca
>
>
>
>
>
>
>
>
> _______________________________________________
> 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

Reply via email to