[osg-users] Simple moving map using CADRG data
Hello, I posted this earlier but it may have gotten lost in the shuffle... I'm interested in adding a moving map display to a simulation. (Something like an instructor operator station.) I understand GDAL can import CADRG data but I haven't found an easy way to use that data to create a moving map display. Have others implemented anything like this ? If so, any tips or suggestions appreciated. Is this something others in the community would find useful? Thanks, Joe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and GDAL
Hello All, I might be missing something obvious here... Is there any easy way to use gdal's ability to import CADRG map data to create a basic moving map window in an osg application? Thanks much - best regards to the osg user community! -Joe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error: 'Debug Assertion Failure!'
This might be helpful under the general topic of loop structures for deleting
elements from STL containers while avoiding invalidating iterators...
http://blog.codedread.com/archives/2007/11/30/c-stl-safely-removing-items-from-a-container
Happy New Year!
-Joe
From: [EMAIL PROTECTED] on behalf of Gordon Tomlinson
Sent: Thu 1/3/2008 8:43 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Error: 'Debug Assertion Failure!'
You might also want to see if the parent has any children first, as we know
has a getChildIndex slight bug in that it returns zero even if there are no
children which is a valid index ..
osg::Group* root = (*ponto_itr)->getParent(0);
if( root && root->getNumChildren() > 0 ) {
root->removeChild(root->getChildIndex((*ponto_itr)), 1);
}
or you could also do something like as remove child with a node as does the
right thing and the getChildIndex bug does not come into play the way it is
written
osg::Group* root = (*ponto_itr)->getParent(0);
if( root ) {
osg::Node* node = *ponto_itr;
if( node )
root->removeChild(node);
}
the you would need to erase the ponto_itr, your logic for your loop will need
to change as the interators will be invalidated when you use erase so you will
need to update them your self
__
Gordon Tomlinson
Email : [EMAIL PROTECTED]
Website : www.vis-sim.com www.gordontomlinson.com
__
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
-Master Tambo Tetsura
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson
Sent: 03 January 2008 16:08
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Error: 'Debug Assertion Failure!'
I think you need to set your (*ponto_itr) to NULL or remove it from the vector
after you have done the remove child, other wise the pointer still has the
address of the child you previously removed so you for loop above (ponto_limp)
will never do any thing
__
Gordon Tomlinson
Email : [EMAIL PROTECTED]
Website : www.vis-sim.com www.gordontomlinson.com
__
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
-Master Tambo Tetsura
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renan Mendes
Sent: 03 January 2008 14:43
To: OpenSceneGraph Users
Subject: [Norton AntiSpam] Re: [osg-users] Error: 'Debug Assertion Failure!'
Hi, Rafa,
I've tried doing something like what you've said before: every time
before I checked for selections with verifySelection(), I searched for a NULL
member and erased it, like it's done below. Can you tell me why it still isn't
working? Is there a logical flaw in my code?
Thanks,
Renan M Z Mendes
case(osgGA::GUIEventAdapter::KEYDOWN):
{
if(!ponto.empty())
{
for(ponto_limp = ponto.begin(); ponto_limp != ponto.end();
ponto_limp++)
{
if(*ponto_limp == NULL)
{
ponto.erase(ponto_limp);
}
}
for(ponto_itr = ponto.begin(); ponto_itr != ponto.end();
ponto_itr++)
{
if((*ponto_itr)->verifySelection())
{
switch(ea.getKey())
{
case(ea.KEY_Delete):
{
osg::Group* root =
(*ponto_itr)->getParent(0);
root->removeChild(root->getChildIndex((*ponto_itr)), 1);
}
}
}
}
}
}
<>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Instrument Panel rendering - interest? ideas?
Zach, There actually is no border... there is a clearnode to clear the entire screen. The 'border' is just render surface with only the clear node (no cameras with a view to the scene) rendering to it. -Joe > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Zach Deedler > Sent: Monday, September 17, 2007 1:20 PM > To: 'OpenSceneGraph Users' > Subject: Re: [osg-users] Instrument Panel rendering - interest? ideas? > > Hi Joseph, > > Tinyxml is an alternative to xerces which usually suffices (it always has > for me). The code is small enough just to embed it into the library that > uses it. > > Also, I was wondering how you implemented the border around the graph in > your screenshot? I'd like to see the ability to add borders to views in > the > osg libraries. I have submitted code that decorates a CameraNode with a > border, but that was OSG 1.2. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sullivan, > Joseph (CDR) > Sent: Monday, September 17, 2007 4:03 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Instrument Panel rendering - interest? ideas? > > Robert, Zach, Paul, Serge, Gerrick, and the rest of the OSG gang, > Thanks for the replies - good to know that this may be generally useful > code. > Things may have changed a bit, but the basic starting idea was to make it > easier to build reconfigurable instrument panels out of a set of gauges. > Rather than 3D models, we use geometric primitives as the scene graph > level. Each gauge in an instrument panel is made up of layers. Layers > would > have a position and textured quad associated with them. The indicators on > the gauge are textured quads that can be articulated: rotated, translated, > etc. So an RPM gauge would have a layer representing the background and > an > articulated layer representing the needle. Details for how to articulate > parts are read from an XML file. For updating the gauges we use a list of > control points and interpolate between these points. (The control points > are real world value - offset pairs. If RPM is linear this could just be > a > list of [ [0,0] [8000,270]] zero RPM would be zero rotation, 8000 RPM > would > be 270 degrees.) The parent application updates the gauge using real- > world > parameters. Interpolation happens auto-magically. > The attached screen shot is a somewhat generic helicopter instrument > panel. > The airspeed indicator and compass are straightforward and would work fine > for the RPM and compass. The altimeter is a bit trickier - there is one > articulated layer for the needle and one for the thousands of feet drum. > The drum is updated by translating the UV coords. > We'll work on packaging this up. The smart folks on the Delta3D team can > provide a better explanation of the current code. Right now the code > relies > on XML parsing (tiny XML or Xerces depending on version). I doubt osg > would > welcome another external dependency so we may want to look at that as > well. > Thanks! > Joe > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Zach > Deedler > Sent: Friday, September 14, 2007 12:57 PM > To: 'OpenSceneGraph Users' > Subject: Re: [osg-users] Instrument Panel rendering - interest? ideas? > > Hello Joseph, > > I have been putting off doing this myself. I need speedometer, RPM, and > compass gauges to display onscreen. My plan was to make them just another > 3D model that sit in their own HUD. How does the Delta3D one work? > > I know it would be difficult to encapsulate this sort of thing because > each > instrument panel has different properties. So how do you define the > interface to the instrument panel node? > > Thanks. > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sullivan, > Joseph (CDR) > Sent: Friday, September 14, 2007 10:42 AM > To: osg-users@lists.openscenegraph.org > Subject: [osg-users] Instrument Panel rendering - interest? ideas? > > Greetings, > Over the last couple years we've worked on a few OSG/Delta3D projects that > have included a rendered instrument panel. We have a pretty decent > solution > that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly > OSG code we're wondering if it wouldn't make more sense to make this an > osg > thing. > So the questions are: > Would this sort of application be useful for others? > Is there enough interest and ability to support as part of OSG?
[osg-users] Instrument Panel rendering - interest? ideas?
Greetings, Over the last couple years we've worked on a few OSG/Delta3D projects that have included a rendered instrument panel. We have a pretty decent solution that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly OSG code we're wondering if it wouldn't make more sense to make this an osg thing. So the questions are: Would this sort of application be useful for others? Is there enough interest and ability to support as part of OSG? What would be the right way to go - build as a plugin? Thanks! Joe S. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
That's awesome! Many thanks, -Joe From: [EMAIL PROTECTED] on behalf of Smeenk, R.J.M. (Roland) Sent: Fri 8/24/2007 12:59 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Tutorials I just copied all NPS tutorials into the Wiki. There's a number of things that still need editing: -Conversion to OSG2.0 -Addition of source zip files -Addition of screenshots -Addition of links to related stuff (Api reference, examples and User guides) Robert, I read in the Wiki that it is possible to automatically add syntax coloring if GNU Enscript or SilverCity (preferred) are installed. I would like to see this installed? Furthermore CamelCasing in the Trac Wiki has bitten me more than it helped me, because I had to disable all Wiki linking on StateSets, MatrixTransforms etc. Could this be turned off? Kind regards, Roland Smeenk > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Sullivan, Joseph (CDR) > Sent: donderdag 23 augustus 2007 0:39 > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Tutorials > > Hey All, > Congrats and big thanks to those that have been adding documentation! > I've been largely away from OSG for a while, but the work > looks mighty impressive. > I think Robert's question about different users is the key. > The examples are absolutely fantastic and work great for > some, not so great for others. Tutorials seem to be a > helpful bridge. (The original goal of the NPS tutorial set > was to get students w/out engineering background comfortable > enough to dive into the examples.) Soo... > What does it take to move the tutorials currently on the NPS > web site over to the osg wiki site? > Is there anybody that can spare some resources to help the effort? > Thanks, > Joe S. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:osg-users- > > [EMAIL PROTECTED] On Behalf Of Robert Osfield > > Sent: Wednesday, August 22, 2007 11:55 AM > > To: osg-users@lists.openscenegraph.org > > Subject: Re: [osg-users] Tutorials > > > > On 8/22/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: > > > > Are the examples of no use to any one??? Shall I just do a > > > > > > > > svn rm examples > > > > > > > > ? > > > > > > No, they very much are. :) It's just that those of us that DO use > the > > > examples don't post here saying so... > > > > Its O.K. I'm not serious about to remove them, just frustrating my > > frustration at big chunks of work that is dedicated to helping new > > users being ignored. > > > > > As far as example usefulness is concerned, "no news is good news." > > > Honestly, in contrast to the entire discussion at hand, I _rarely_ > use > > > documentation. I always just look at the code. Documentation in a > formal > > > sense makes me want to take a nap... > > > > In other projects I do occasionally look for documentation, > but rarely > > does it help me more than a succinct code example. If you are > > experienced programmer than its the code that tells you everything. > > > > It would be interesting to do a profile of different users > to see what > > types of assistance to get their programs written they find most > > effective. When I say assistance I mean documentation, > mailing list > > archives, examples, code comments, code itself, class > naming, method > > naming. > > > > I do wonder if too many developers these days are expecting > to put in > > too little real effort for the amount of results they are wanting. > > Programming is hard. Real-time graphics is a BIG topic. To master > > them you have lavish lots of time. > > > > When I first started programming as a kid there was just > practically > > nothing available relative to today, I didn't know any better, I > > enjoyed in a perverse way learning by myself how to code Z80 > > assembler. Yes it took weeks just to get a few coloured sprites > > animating across the screen, but I didn't go ranting at anyone for > > lack of guidance and docs, I just enjoyed figuring it out > and getting > > the final result. Fast forward to today and the with 10 > lines of code > > in the OSG you can create and load a terabyte sized 3D world and > > interact with it at a solid 60Hz. But yet some people seem > to expect > > more much more. > > > > Robert. > >
Re: [osg-users] Tutorials
Hey All, Congrats and big thanks to those that have been adding documentation! I've been largely away from OSG for a while, but the work looks mighty impressive. I think Robert's question about different users is the key. The examples are absolutely fantastic and work great for some, not so great for others. Tutorials seem to be a helpful bridge. (The original goal of the NPS tutorial set was to get students w/out engineering background comfortable enough to dive into the examples.) Soo... What does it take to move the tutorials currently on the NPS web site over to the osg wiki site? Is there anybody that can spare some resources to help the effort? Thanks, Joe S. > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: Wednesday, August 22, 2007 11:55 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Tutorials > > On 8/22/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-08-22 at 19:16 +0100, Robert Osfield wrote: > > > Are the examples of no use to any one??? Shall I just do a > > > > > > svn rm examples > > > > > > ? > > > > No, they very much are. :) It's just that those of us that DO use the > > examples don't post here saying so... > > Its O.K. I'm not serious about to remove them, just frustrating my > frustration at big chunks of work that is dedicated to helping new > users being ignored. > > > As far as example usefulness is concerned, "no news is good news." > > Honestly, in contrast to the entire discussion at hand, I _rarely_ use > > documentation. I always just look at the code. Documentation in a formal > > sense makes me want to take a nap... > > In other projects I do occasionally look for documentation, but rarely > does it help me more than a succinct code example. If you are > experienced programmer than its the code that tells you everything. > > It would be interesting to do a profile of different users to see what > types of assistance to get their programs written they find most > effective. When I say assistance I mean documentation, mailing list > archives, examples, code comments, code itself, class naming, method > naming. > > I do wonder if too many developers these days are expecting to put in > too little real effort for the amount of results they are wanting. > Programming is hard. Real-time graphics is a BIG topic. To master > them you have lavish lots of time. > > When I first started programming as a kid there was just practically > nothing available relative to today, I didn't know any better, I > enjoyed in a perverse way learning by myself how to code Z80 > assembler. Yes it took weeks just to get a few coloured sprites > animating across the screen, but I didn't go ranting at anyone for > lack of guidance and docs, I just enjoyed figuring it out and getting > the final result. Fast forward to today and the with 10 lines of code > in the OSG you can create and load a terabyte sized 3D world and > interact with it at a solid 60Hz. But yet some people seem to expect > more much more. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
