Alex,
The short answer is no.
However, this question has already been addressed...
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/59941/focus=
59966
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Paul,
For HAT, you only need one point. LOS requires a start and end point. Both
require that the points be specified in the database coordinates (i.e.
geocentric Cartesian coordinates for round earth databases).
I haven't worked with .flt databases but the osgSim methods appear to work
for
All,
I have a need to attach osgParticle effects on a moving object (i.e smoke
and fire trail from a moving missile). I've looked at the
osgparticleeffects.cpp example in where they attach these effects based off
a hit node from the pick event to see how I might do this. Unfortunately I
need
Lucie,
This is how you would place your model...
osg::Matrixd position;
ellipsoid-computeLocalToWorldTransformFromLatLongHeight(osg::DegreesToRadia
ns(lat),
osg::DegreesToRadians(lon), altitude, position);
transform-setMatrix(position);
where transform is an
All,
I have a simple question regarding osgParticle effects.
Is there a simple way to restart the effects once they expire? For example,
I have a burning object emitting a smoke effect that I want to restart after
the smoke disappears. Is there a clean way to restart the smoke effect?
Yes, they're both equivalent in that they return position info but the
former returns a matrix for you to use in your transform node so that your
model will be positioned correctly on the spheroid. I believe the up
vector of the model will then match the up vector at that position on the
spheroid
Lucie,
If you're on a flat earth, you shouldn't be using the
convertLatLongHeightToXYZ method. This is only used for mapping spheroid
coordinates to geocentric (origin is at the center of the spheroid)
coordinates. Because you were referencing this method, it was assumed that
you were using this
Matt,
Just for giggles, have you tried loading your .FLT file in osgviewer? In
other words, try osgviewer campus08-19.flt and see what happens. It should
just load your openflight file for viewing...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
VPB currently does not support this functionality. There have been other
developers that have proposed or even implemented solutions to provide
something like this in the future. Perhaps they can chime in...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Daniele,
Bezier Curves are parametric functions that are defined by their control
points. The number of control points will determine the degree of the curve
minus 1 so four control points will yield curve of degree three (cubic). The
control points can be specified in whatever dimension you want
All,
I'm seeing some issues with VPB when attempting to build a very large
database. My command is the following:
vpbmaster -TERRAIN -PagedLOD -geocentric -whole-globe -t wholeearthtexture
-t detailtexture -d dted -l 24 -o database.ive
What I'm seeing is that vpbmaster creates the
/10 20:31, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:
All,
I'm seeing some issues with VPB when attempting to build a very large
database. My command is the following:
vpbmaster -TERRAIN -PagedLOD -geocentric -whole-globe -t
wholeearthtexture -t detailtexture -d dted -l 24 -o
at the recent threads on osg-users and
osg-submissions about NVidia Texture Tools integration.
Robert.
On Fri, Oct 22, 2010 at 3:48 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:
Jp,
Thanks for the suggestion. I'll give it a try.
Thinking that it might
Try the following gdal command on your data (infile) that is not
geo-referenced...
gdalwarp -t_srs +proj=latlong +datum=WGS84 -r bilinear infile outfile
and feed the resulting outfile into osgdem...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Robert,
Thanks for the reply. No, our app does not override new and delete. It's
using the standard operators in C++. I'm not sure on how to answer your last
question. Are you referring to OpenThreads?
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
13 that we start seeing the
problem.
I'll dig more and report my findings...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Thursday, November
Meir,
I would suggest looking at the OSG examples to get started. Those come as
part of the OSG package when you install it. Without knowing the specifics
of your project, you will need to determine if the SceneGraph paradigm fits
with what you're trying to accomplish. The links below should also
Just a few questions from your code...
1) I noticed that your osgdem command isn't using --geocentric in the
command line. Are you building a geocentric database?
2) Are your lat lon values in degrees or radians? The
convertLatLongHeightToXYZ() method requires lat, lon radians.
3) Why is your
Agreed...
The terrain is only as accurate as the original source data.
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Glenn
Sent: Friday, December 03, 2010 12:30 PM
To:
I don't know what functionality osgTDS provided, but as to the original
question at hand, osgSim for osgTerrain paged databases is the answer...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Glenn and Robert,
Thanks much for the input. I'll try out osgEarth to see how it works in a
small app I have...
Thanks again,
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Glenn
Waldron
Sent:
Deniz,
If you're using osgdem with the --geocentric flag set, you're building a
geocentric database which is correct.
Here's a code snippet that may help you position your camera on the spheroid
in geocentric space. It sets the view matrix for the camera given the lat,
lon and alt. Roll, pitch,
Deniz,
Which method in EllipsoidModel were you using to do the transform from
(lat,lon,alt) to (X,Y,Z)?
Can you provide a code snippet on how you're doing the transform? Also
provide the actual osgdem command you're using to build your database...
-Shayne
-Original Message-
From:
A couple more questions...
1) Are your lat, lon in radians when you call convertLatLongHeightToXYZ?
2) Have you tried viewing your database (terrain.ive) with osgviewer to see
what it looks like (osgviewer terrain.ive)? If you can't see your database
with osgviewer, then there's a problem with
I'm glad things are working for you...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of deniz
diktas
Sent: Tuesday, December 28, 2010 4:25 PM
To: osg-users@lists.openscenegraph.org
Subject: Re:
Dan,
Take a look at the osgintersection example. It uses osgSim::LineOfSight
class...
Regards,
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Darko
Radiceski
Sent: Monday, January 03, 2011
If you're using a geocentric database, you can use the
osgSim::GetHeightAboveTerrain(...) method to get the altitude of either the
terrain itself or an altitude above the terrain at a given lat,lon. This
method takes into account paged databases in extracting the correct value...
-Shayne
May I suggest you look at how OpenGL sets up the projection matrix. This is
what OSG uses. gluPerspective is the routine that uses fovy and aspect to set
up the projection matrix;
It may be more intuitive for you to use the setProjectionMatrixAsFrustum()
method in OSG to establish the
Robert,
Thanks for the input.
I will try to compile and run the latest trunk with NVTT on Fedora core 13
and report any problems...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
I agree with Robert that you need to jettison GLUT. It's a mickey mouse
framework for mickey mouse apps. It was never intended to be used in real
applications. Embedding an OSG viewer in a GLUT window reduces the viewer
down to running single threaded which is not good for performance.
Our
You can declare and register a PostDrawCallback with the camera class to do
OGL rendering. It will get called after the OSG rendering traversal...
void PushOSG_GL_State()
{
// since OSG and OGL share the same render context, push OGL state
used by OSG
Just a quick comment...
Unless you're debugging into OSG code, I would not use the debug libraries.
Things will run SLOOOW.
Use osg.lib, osgDB.lib, etc...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On
J-S,
The setting that you amply described IS what we do. We do it quite often so
that things don't run so slow when we're debugging our app (not OSG). We may
need to run a while before we break into our code for debugging. Running
with OSG debug libs is too slow for this scenario so we use the
J-S,
I appreciate the input and insightful discussion. This is good information
to have for both new and experienced developers.
Thank you!
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Thanks Robert.
I'll investigate the logs and report my findings...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Tuesday, February 01, 2011 1:59 AM
To:
This is an interesting thread of discussion.
In terms of communicating with a simulation host, are there any plans to
support CIGI for communicating between the host and osgVisual? I would think
that would be a good thing to support...
-Shayne
-Original Message-
From:
I suppose if you're unable to build from source, this would be a viable
option. However, I would rather download the source and build OSG and VPB
myself if I have the means and tools to do so.
Building both from source is trivial and there are ample instructions for
accomplishing the task..
Torben,
Thanks for the information. I ask this because I'm currently working on
doing a CIGI tie-in to an OSG-based IG backend I've been developing. I'm not
a proponent for reinventing the wheel so to speak so I'm always on the
lookout for other options in this regard.
osgVisual would be
Can't get there from Utah either...for both links...
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris
'Xenon' Hanson
Sent: Friday, February 04, 2011 11:54 AM
To: osg-users@lists.openscenegraph.org
The PATH env variable should really only contain the paths to shared objects
and executables (i.e. /usr/local/bin). LD_LIBRARY_PATH should be set to
/usr/local/lib instead...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
as well. But I am not familiar with the CIGI
standard.
Would this include the ability to manage object motions and behaviors across
the cluster? (e.g., not only camera positioning).
thnx,
t
On Fri, Feb 4, 2011 at 11:40 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil
CIGI uses UDP so updating osgVisual to use CIGI shouldn't be an issue in
terms of performance. Effectively you'd be replacing one UDP implementation
with another that uses an industry wide standard for the packet
description...a big plus IMO.
Like I stated earlier, CIGI is used by most commercial
Boeing's multipurpose viewer (MPV) was designed to simply be a test harness
for the CIGI protocol. It's a far cry from it being used as a general
purpose IG.
I've downloaded MPV from the CIGI site and played with it. It does use old
OSG stuff (osgProducer). I had to modify it to use the newer
Martin,
How do you have your composite viewer set up? Is it multiple views in a window
or a single view per window?
If you're using multiple views/viewports embedded in a single window, the
viewport (x,y) are relative to the window. If your views are set up in separate
windows (i.e. a view
Shyuan,
What version of OSG are you using? I believe osgProducer/Viewer has been
replaced by osgViewer/Viewer...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tze Shyuan
Sent: Tuesday,
There is an example of the usage of the marching cubes algorithm in the
Nvidia GPU computing SDK (OpenCL Marching Cubes Isosurfaces)...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David
This is a true statement for the parametric surface stuff. In a previous life
when I worked on OpenGL drivers, evaluators were always implemented in the
slow path...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
If the source data is using UTM coordinates already, you can just do
osgdem --TERRAIN --PagedLOD -t texturedir -d elevdir -l 10 -o
utmdatabase.ive
If the source data is not using UTM, you can use gdal to reproject the
data by
gdalwarp -t_srs proj=utm +zone=11 +datum=WGS84 infile outfile
If
Perhaps you can be a bit more specific on your problem mathematically.
Your original post was somewhat vague on what you're trying to
accomplish...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Impressive...
Thank you.
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Glenn
Waldron
Sent: Thursday, February 24, 2011 10:02 AM
To: OpenSceneGraph Users
Subject: [osg-users] ANN: osgEarth 2.0
You can take a look at the .ive file. Even though most of it is
unreadable, you can look for the ellipsoid axis and flattening values.
Both of those will determine if it's round earth.
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
If you want to use delta3D or subrscene to render the terrain, don't use
the --geocentric option in osgdem. Neither one of those applications
support VPB round earth databases...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Very cool...:)
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Massimo
Tarantini
Sent: Friday, March 25, 2011 4:57 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] [vpb] short video flying
Most of the IG industry uses CIGI to pass data from the host to the IG
(and back for end of frame and mission functions stuff). I'm sure the
architecture is well defined on this.
For starters, you can take a look at Boeing's Multi Purpose Viewer
software which is an IG test bed for the CIGI
Sanat,
You have to use the osgSim class to achieve your objective. In
particular, use the method
osgSim::HeightAboveTerrain::computeHeightAboveTerrain(terrain_node,
osg::Vec3d(X,Y,Z))
where X,Y,Z is the geocentric coordinates (earth centered) calculated
from a given lat,lon,alt.
The method to
Sanat,
The code I gave you assumes that your VPB terrain was built using the
--geocentric flag (e.g. round earth). If not, then you must resort to
what Glenn recommended in his email and handle the coordinate
conversions correctly from a flat UTM (or whatever) to a round earth.
If you do decide
Rusty,
If your altimeter renders correctly and gives you correct results, then
I'd say your implementation is probably fine. There are plenty of OSG
examples and tutorials that you can compare with to see if you're on the
right track.
On understanding how normals are used, I would suggest that
Try using the following to reproject your data...
gdalwarp -s_srs proj=latlong +datum=WGS84 -t_srs proj=utm +zone=11
+datum=WGS84 infile outfile
Do this before using osgdem on your data files. UTM zone selection will be
dependent upon where your lat/lon is...
-Shayne
-Original
Try omitting the s_srs portion of the gdalwarp command to see if that makes any
difference.
I believe dted files will need to be reprojected as well since VPB builds the
database using the source data coordinate system.
-Shayne
-Original Message-
From:
If I understand you correctly, you want to tweak the viewing frustum?
You should be able to rotate and scale (move in and out) the clipping planes of
an asymmetric viewing frustum (projection matrix) so that the four sides of
intersection with the near clipping plane form a general
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Friday, May 06, 2011 1:54 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users
Alexander,
By moving the corners of the frustum, are you wanting to tweak the
frustum corners so that they have different depths (i.e. tilt the near
plane so that it is no longer orthogonal to the eye)? I don't think OGL
(and hence OSG) will allow you to do this directly. There is a munge
that
Craig,
We've done something similar to what you want to do but in a separate process
rather than a separate thread. We have done it in an asynchronous thread as
well. The reason we chose to go with a process is that it allows us to run it
on a remote machine away from the rendering process if
J-S,
Yes, a great point I failed to bring up about the mutex. Thanks for mentioning
that. We did have to do that to protect the shared resource when we used
threading.
For our stuff, one process (out-the-window) does the usual traversal (via
viewer.frame) while the other sits idle until a
Try using the --TERRAIN option in the osgdem command to see if that
makes a difference in your build times...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of ijustfu
Sent: Friday, May 27, 2011
If you used VPB to build an osgTerrain database, you can get what you
want with the osgSim class.
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
abhishek agarwal
Sent: Thursday, June 02, 2011
Diana,
First off, I don't see where you're setting the view matrix for the
camera in your code below. You compute the transform, but you'll need to
attach it to the camera.
Since it looks like you're navigating on a sphere, I would try the
following in your while loop below...
Try using the following on your texture file (intexturefile)...
gdalwarp -t_srs +proj=latlong +datum=WGS84 -r bilinear intexturefile
outtexturefile
outtexturefile will then be used as input for osgdem.
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Just as a follow-up question on this topic, what settings are included
in the DEFAULT_CULLING?
Thanks,
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul
Martz
Sent: Thursday, June 23, 2011
Thanks Tony...:)
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tony
Horrobin
Sent: Friday, June 24, 2011 8:19 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users]
Chris,
Great defense of OGL. Clearly there were a few OGL bigots in that forum
that really spiced things up with some of their comments. The DirectX
vs. OGL debate is more akin to a religious war than anything else.
Long live OGL...and of course, OSG...
-Shayne
-Original Message-
From:
Michael,
Position and orientation of the ownship on a VPB sphere has been
discussed at length on this forum. You should have no problem finding
what you need to do.
Check out http://forum.openscenegraph.org/viewtopic.php?p=40200#40200
for more info.
For an arbitrary entity (aircraft or
Torben,
My guess is that the quads are geometrically represented by two
triangles with a shared edge. I believe the intersector is returning a
ray/triangle intersection so one (that is hit) of the two triangles that
make up the quad is being returned.
This probably doesn't solve your problem but
It is true that QUAD is an OpenGL primitive but the GL driver
tessellates it into two triangles underneath the hood.
As for how OSG handles quads relative to intersections, it is my
understanding that the intersector works with line/triangle
intersections. If you're trying to intersect a quad,
] intersection with quad mesh: only 3
verticesreturned
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, August 02, 2011 4:49 PM
To: osg-users@lists.openscenegraph.org
I've had this problem before with models that are unit-less. I just
manually scaled the models (as Paul suggests) until they looked right
based on landmarks in the database where the sizes were known. It's an
empirical approach but it's the best you can really do if you don't know
the units of the
It has worked for us just fine in the absence of data.
Good luck with your effort...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sanat
Talmaki
Sent: Friday, August 12, 2011 2:59 PM
To:
However, it is targeted for a specific host OS / GPU combination and is
NOT a general enhancement. Of course, the problem may not exist on
Red Hat or Fedora or Ubuntu [or insert Linux variant here] or Windows
or Macintosh.
Can NIST prove that it does not exist on those platforms!
They provide
The transform below for the orthogonal projection is indeed linear, mapping
[n,f] to [-1,1] in linear fashion.
If you want to linearize depth with a perspective projection (i.e. survive the
perspective divide between the vertex and fragment shader), here's a way to do
that. The example uses
You've got mail...
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris
Hanson
Sent: Monday, September 24, 2012 1:59 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] VPB in VS10...
We specify the near far planes manually and we don't have z-buffer
issues with models on the earth's surface. Perhaps you should select the
option DO_NOT_COMPUTE_NEAR_FAR for cull settings...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Take a look at the createAxis() in the osgbillboard.cpp file for the
osgbillboard example. There's code in there to set linewidth...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Filip
Arlet
If you're modeling on the earth, you should be using double precision
for your camera position...
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Dmitry
K.
Sent: Tuesday, October 30, 2012 2:16 AM
To:
Another thing to check is make sure you're not mixing debug version of
OSG with a release version of your app and vice versa. They must be the
same.
I've had readNodeFile() fail as below when I accidently linked my
release built app with debug OSG...
-Shayne
-Original Message-
From:
This thread of discussion may help you...
http://forum.openscenegraph.org/viewtopic.php?t=11461
Also, since you are new to the OSG, I would suggest that you look
closely at the provided examples to obtain an understanding on how the
OSG classes are used in the applications. Looking at the OSG
Both would be great to have. Thank you...
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris
Hanson
Sent: Thursday, January 17, 2013 5:35 PM
To: OpenSceneGraph Users
Subject: [osg-users] Basic
Whatever you end up doing, you want to avoid doing the equivalent of
glReadPixels since that stalls the pipe and is relatively slow. I
noticed that this was one of the suggestions in the link provided
below...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
If you enable two-sided lighting, the driver flips the lighting normals
so that the back side of the polygon is lit correctly. There should be
no need to do this in a shader (with OGL that supports fixed
functionality...).
-Original Message-
From:
just called it a modeling bug. :-)
On Thu, Mar 14, 2013 at 12:27 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:
If you enable two-sided lighting, the driver flips the lighting
normals
so that the back side of the polygon is lit correctly
SGI? I didn't know they were still around...;^)
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David
Glenn
Sent: Monday, March 25, 2013 3:54 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users]
Thanks. I will do that.
I'll most likely have more questions as I move along...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan
Ciger
Sent: Tuesday, April 02, 2013 1:25 PM
To:
All,
I'm attempting to load a height field by using
osg::HeightField *grid = osgDB::readHeightFieldFile(...)
where the file is a gdal supported dem/image file format. When I attempt
to read the file, I'm getting the error
Warning: could not find plugin to read objects from file...
Is this
in this way you'll either need to
preload the gdal plugin or append the .gdal extension to your filename
so that the OSG knows to load the gdal plugin to attempt the load the
data.
Robert.
On 11 April 2013 23:19, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
shayne.tuel...@hill.af.mil wrote
The methods provided in osgSim work for geocentric databases. Is your
terrain built as a geocentric database?
If so, you can get the HAT/HOT with this...
earth-convertLatLongHeightToXYZ(osg::DegreesToRadians(lat),
osg::DegreesToRadians(lon), alt, X,Y,Z);
hat =
Our host talks with several different IGs on the backend (OSG, Quantum3D,
Aechelon) . All use the CIGI protocol. If it wasn't for CIGI, our host would
have to support different ways of communicating with each IG which would be
a pain.
The OSG-based IG is one that we developed in-house. Like both
That's neat...a lot more folks coming out of the closet that are using
OSG-based IGs using CIGI...;^).
Actually CIGI is quite prolific in the IG industry which is nice for anyone
who has a host that has to interface with different IGs or wants to upgrade
to a different IG that supports CIGI. You
All,
This question may have already been asked, but has anyone successfully
converted/exported a VPB terrain (*.ive file) to an OpenFlight (*.flt)
file? Is this possible to do?
If so, is it better to use osgconv or to do it programmatically?
Thanks,
-Shayne
-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Friday, June 14, 2013 11:52 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VPB terrain to OpenFlight...
Hi Shayne,
On 14 June 2013 18:35, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
shayne.tuel...@hill.af.mil wrote
To: OpenSceneGraph Users
Subject: Re: [osg-users] VPB terrain to OpenFlight...
Hi Shayne,
On 14 June 2013 19:05, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
shayne.tuel...@hill.af.mil wrote:
Thanks for the timely reply. That's basically what I needed to know.
I'm assuming if I had a database
I would recommend that you become familiar with VirtualPlanetBuilder and
osgdem. These tools specifically build to osg databases.
Here's one way to build your SRTM data to an osg database...
osgdem.exe --geocentric -d SRTM_dir --terrain -o outputfile.ive
Then you can look at it by...
osgviewer
201 - 300 of 348 matches
Mail list logo
