Re: [osg-users] Laptop switchable graphics and OSG / OpenGL apps?

[Martins Innus]

J-S,
Thanks for the update.

 Since Optimus is currently Windows-only anyways I think that's the 
path they'll choose.




Just as an extra point, Ironhide lets you use Optimus under Linux.  I 
haven't done any performance testing, but I was able to to manually 
activate the Nvidia card under linux and run OpenGL apps on it.


http://www.martin-juhl.dk/2011/08/ironhide-reporting-for-duty/

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Laptop switchable graphics and OSG / OpenGL apps?

[Martins Innus]

J-S,

Which version of the drivers are you using?



I'm using 268.30, the most recent as provided by Dell specifically for 
my laptop. I have not tried any of the drivers on Nvidia's site.


I'm using 280.26 from nVidia's site, and even creating a profile and 
setting that profile to run on "High-performance NVIDIA Processor" 
didn't work for me. Even if I tried to force it to the discrete 
graphics globally (in the "Global Settings" instead of "Program 
Settings" where you create a profile) didn't work either. The only 
thing that worked for me was forcing it in the BIOS.




My only option is to create a profile for each application as you 
described above, as Dell doesn't provide any option to force it from the 
Bios.  If I could, I would just disable it that way.


That's something that should work, and I guess it might be a bug in my 
version of the nVidia control panel. Still, if we could just have the 
app tell the driver that it needs discrete graphics, instead of having 
to make a profile for *each* app, on *each* laptop, that would be better.


I hope a better solution becomes available.  This could be a support 
nightmare when distributing applications.


Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Laptop switchable graphics and OSG / OpenGL apps?

[Martins Innus]

J-S,

On 9/9/11 12:29 PM, Jean-Sébastien Guay wrote:


However, our own OSG-based apps seem to not be recognized as "needing 
the discrete graphics", and even adding a profile for our app's 
executable in nVidia Control Panel, telling it to force using the 
discrete graphics for that app, doesn't work. Our app crashes when 
loading textures, somewhere in the Intel driver.


Just this morning I started testing on one of these laptops (Dell 
XPS17).  By adding a profile for the specific .exe I wanted to run, I 
got the Nvidia graphics to kick in for our OSG application.  I have not 
yet found a way for that card to start automatically with OpenGL apps.


Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VirtialPlanetBuilder-0.9.12 dev release tagged, and plans for VPB-1.0

[Martins Innus]

Robert,

Builds fine with OSG 3.0rc2 on Mac OSX 10.6.7 64 bit.

Martins

On 6/21/11 9:13 AM, Robert Osfield wrote:

Hi All,

OpenSceneGraph-3.0.0 release seems to be going smoothly so it looks
like I might have a little time this week to squeeze in getting
VirtualPlanetBuilder to 1.0 as well.  This morning I merged a couple
of changes to VPB from the community and made a a little cleanup
myself so it reminded me that VPB-1.0 is as long overdue as OSG-3.0 so
why not go with the flow and get VPB-1.0 out the door.  It's basically
feature complete for it's 1.0 and has been so for quite so time now -
it's just I've been so busy with the OSG and client work that it's sat
a little neglected in the corner.

The first step was to tag a dev release which you can now grab from:

   svn co  
http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.12
VirtualPlanetBuilder

Could members of the community update to svn/trunk of VPB or the
0.9.12 dev release above and let me know how well things are building
working on your system.  If things look solid I'll just go right ahead
and make the 1.0 later this week.

Cheers,
Robert.
___
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

Re: [osg-users] Question on OSX frameworks

[Martins Innus]

Hi Steven,

On 4/24/10 6:04 AM, Stephan Huber wrote:

Hi Martins,

Am 23.04.10 20:12, schrieb Martins Innus:

 I've been using the frameworks generated by the latest CMake updates
in my own projects under osx, and it works great.  However it doesn't
seem like its working for the osg provided applications. I build the
frameworks and application bundles using svn from yesterday.  Then when
i run osgviewer i get:

dyld: Library not loaded:
@executable_path/../Frameworks/OpenThreads.framework/Versions/2.5.0/OpenThreads

   Referenced from: /util/osg/svn64/bin/osgconv.app/Contents/MacOS/osgconv

Same thing with osgconv, etc

The path appears correct, but the frameworks are not being copied into
the application bundle during the install stage i guess.

In my own project, I just add a "copy Files" build stage to copy the
frameworks to the application bundle.  I'm not sure how to do that under
CMake though for OSG itself.

Has any body else run into this or is there something misconfigured on
my machine?

no, that's not a problem on your end.  The frameworks-support is still
in its beginnings, and the embedding-part is missing for the examples,
and I am not sure if it's good to copy the frameworks into every
example-app-bundle. IMHO as long as you don't build the install target,
the examples do work, because they are linked against the frameworks
inside the build directory.

I'll check the next week some alternatives to get the examples working.


Sorry to bring up an old thread, but I just downloaded svn from today 
and built with frameworks and application bundles and I can't get 
osgviewer.app to work.  It still complains about the missing 
frameworks.  Any suggestions on how to get it working after install?  I 
tried adding a Copy files build stage myself from within XCode to get 
the frameworks copied in but get the following error:


PBXCp 
build/bin/Release/osgviewer.app/Contents/Frameworks/OpenThreads.framework build/bin/Release/OpenThreads.framework

cd /util/src/osg_dec2010
/Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp 
-exclude .DS_Store -exclude CVS -exclude .svn -strip-debug-symbols 
-resolve-src-symlinks 
/util/src/osg_dec2010/build/bin/Release/OpenThreads.framework 
/util/src/osg_dec2010/build/bin/Release/osgviewer.app/Contents/Frameworks


pbxcp: OpenThreads.framework: No such file or directory

I can't figure out why its trying to copy from build/bin instead of 
build/lib.


I am running CMake 2.8.0.  I'll update to see if that helps.

Thanks for any insight.

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG seems to have a problem scaling to multiple windows on multiple graphics cards

[Martins Innus]

John,

Can't help much except to say I saw the same thing.  I had access 
to a system when the GTX 470 cards came out that had 2 cards and 4 
displays hooked up.  We could never get one instance of our software 
spanned across the 4 displays to run as fast as 4 separate instances. 
Tried twinview, xinerama, separate x-screens.  I don't have access to 
the system anymore, but at the time I chalked it up to bad drivers since 
the cards had just come out.  I can't remember if the frame drop was as 
dramatic, but it was certainly there.


Martins

On 10/19/10 3:11 PM, John Kelso wrote:

Hi,

We have a pretty simple setup.  4 graphics cards, each is its own X11
display, as in :0.0, :0.1, :0.2, :0.3.  No Twinview or Xinerama.

We've found out that our hardware doesn't support mosaic mode.  We 
installed

the latest Nvidia driver and it made no difference.  We're really sort of
completely stumped at this point.

Can anyone think of any test we can try to determine the cause of the 
problem?


Is anyone else on the list using a similar setup?  If so, have you 
seen this problem?


Thanks,

John

On Mon, 11 Oct 2010, J.P. Delport wrote:


Hi,

On 07/10/10 23:39, John Kelso wrote:

Hi,

Many thanks for your speedy reply.

We were considering trying mosaic mode if we couldn't come up with
something
that would fix the problem with our current display configuration.

Switching to mosaic mode will require a good bit of code rewrite, 
but if

that's the way to go I guess it's worth it in the long run.

I'll look into WGL_NV_swap_group extension too.

Any other ideas from the group?


How is the nvidia driver set up? Single X screen, or screen per card?
Twinview? Xinerama?

We've found strange driver issues with X screens spanning multiple 
cards.


jp



Thanks,

John

On Thu, 7 Oct 2010, Wojciech Lewandowski wrote:


Hi John,

This is odd but it sounds bit like swap buffers of the windows are
somehow
waiting for each other. I believe that WGL_NV_swap_group extension 
is not

used by OSG. This extension could possible help you there.

But I could be wrong on above. It is not really my main point I 
wanted to

mention. Instead I wanted to suggest you check SLI mosaic mode. We
have done
some experiments on 4 channels on Linux / Nvidia QuadroPlex D2 in the
past.
At first we tried to go the same path as you describe. But later we 
have

read somewhere that fastest method is to use one window filing whole
desktop
and split this window into 4 screen quarter slave views. Each slave 
view
could be positioned so that it covers one monitor output. Such 4 
monitor

setup is possible with QP D2 drivers in SLI mosaic mode.

Using producer config files one may easily create a .cfg that could be
passed from command line to osgViewer and set 4 channel slaves on 
single

window. Best thing with using one window is that all four views use
the same
context so GL resources are shared and all four are swaped at once 
with

single SwapBuffer call.

In our project we ended up with 4 channel rendering using SLI mosaic
and we
were pleasently surprised how fast it was performing in comparison to
separate gl contexts on 4 windows. You may check SLI mosaic if you
haven't
done this before

Hope this helps,
Wojtek Lewandowski
--
From: "John Kelso" 
Sent: Thursday, October 07, 2010 9:35 PM
To: 
Subject: [osg-users] OSG seems to have a problem scaling to multiple
windows
on multiple graphics cards


Hi all,

Our immersive system is a single host computer with 8 cores and 4
graphics
cards running Linux. (1) We are using OSG 2.8.3.

We are having a heck of a hard time getting OSG to take advantage of
our multiple graphics cards. Help!

Here's what we did:

If we load a fairly large model into our test program we can get a 
frame

rate of about 150 FPS when displaying in a single window. (2) We are
running single-threaded, and assign to a specific core.

When we background this and run a second copy of the program to 
another
graphics card and core then both programs run at 150 FPS. Same 
thing for

running three and four copies at once.

That is, four processes using four graphics cards on four cores 
run just

as
fast as a single process. All four cores are at near 100% CPU
utilization
according to top. So far, so good.

Now we modify the program to load the model and create multiple
windows on
multiple cards. There's one window per card and each uses a different
core. (3)

The threading model is "CullThreadPerCameraDrawThreadPerContext", the
default chosen by OSG. The environment variable
OSG_SERIALIZE_DRAW_DISPATCH
is not set, so it defaults to ON, which we think means draw in 
serial.


If we draw to four windows on four different cards we get about 36 
FPS.
There are four different cores being used, and each has about 25% 
of the

CPU. This probably this makes sense as the draws are in serial. 150
FPS/4
is about 36 FPS. As expected, we get nearly identical results if we
create
four windows on 

Re: [osg-users] Develop for XP/Vista/Windows 7

[Martins Innus]

I was able to test on machines locally and had the same results on both 
Windows 7 and Vista with both ATI and NVidia graphics.  It turns out 
that Visual Studio was including OpenGL32.dll in my .msi as an 
automatically detected dependency which I had never noticed.  I removed 
that and everything works great.  Not sure how this worked anywhere with 
that file in there.


Thanks J-S and Jason for the suggestions.

Martins

On 5/12/2010 4:11 PM, Jason Daly wrote:

Jean-Sébastien Guay wrote:



Until now we have only run our software on XP, but we just
had a user try to run on Vista and our application ran, but without
textures and a much lower framerate.



With nothing else to go on, I would suspect outdated drivers or a bad
video card rather than it being Vista causing the problem. As I've said,
we've used many flavors of Windows without too many problems.



Missing textures and slow frame rate sound a lot like old ATi drivers to
me. I had those exact symptoms once and fixed it by installing the
latest drivers.

--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Develop for XP/Vista/Windows 7

[Martins Innus]

Is it possible to create a single OSG application that runs on XP, Vista 
and Windows 7?  I develop under VS2003 on XP and create an installer 
package from within VS that has all the dll's and main exe in one 
directory. Until now we have only run our software on XP, but we just 
had a user try to run on Vista and our application ran, but without 
textures and a much lower framerate.  I'm waiting to hear back if there 
was anything printed to the console, but I don't have a Vista machine 
locally to test on.  I know this is sparse on details, but I'm just 
curious to know if this should work.


I'm assuming there are OSG developers who've done this.  I can upgrade 
Visual Studio if necessary.


Thanks for any insight.

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] fbx writer texture support

[Martins Innus]

I found the cause of missing textures.  If you have a Stateset with 
textures applied to a Geometry node, it generates an fbx file with 
textures.  If the Stateset instead is applied to the Geode parent of the 
Geometry, you get no texture.  Unless Sukender has some suggestions on 
how to tackle this, I'll try to figure out whats going on in 
WriterNodeVisitor::apply(osg::Geode& node).  It appears that the 
triangles are being generated before the stateset of the Geode is queried.


Martins

On 5/11/10 8:39 AM, Martins Innus wrote:

Michael,

   OK, I'll take a look.  I saw code in there for writing the texture 
information out.  I'll see if I can figure out where the missing 
connection is.


Thanks

Martins

On 5/11/10 5:26 AM, Michael Platings wrote:

Hi Martins,
the writer is still a work in progress so I suspect that feature 
hasn't yet been implemented. Talk to Sukender 
(http://sukender.free.fr/) to find out if it's on his to-do list, if 
not then your help will be appreciated ;)


On 10 May 2010 18:29, Martins Innus <mailto:min...@ccr.buffalo.edu>> wrote:


Hello,
   Has anybody had luck converting textured models to fbx format
using the writer in OSG?

   I narrowed it down to simple case of:

osgconv skydome.osg skydome.fbx

The resulting file when viewed in osgviewer is just a solid
color.  Converting that file back to .osg results in no reference
to the texture in the osg file.

This is on svn of today, with the 20112 SDK on Mac OS X.
 Converting to other formats: obj, ive, etc works fine.  I tried
turning the optimizer off as well as setting  OSG_NOTIFY_LEVEL to
DEBUG.  The image gets read fine on load, but there's no
information on whats going on at the write stage.

Thanks

Martins

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] fbx writer texture support

[Martins Innus]

Michael,

   OK, I'll take a look.  I saw code in there for writing the texture 
information out.  I'll see if I can figure out where the missing 
connection is.


Thanks

Martins

On 5/11/10 5:26 AM, Michael Platings wrote:

Hi Martins,
the writer is still a work in progress so I suspect that feature 
hasn't yet been implemented. Talk to Sukender 
(http://sukender.free.fr/) to find out if it's on his to-do list, if 
not then your help will be appreciated ;)


On 10 May 2010 18:29, Martins Innus <mailto:min...@ccr.buffalo.edu>> wrote:


Hello,
   Has anybody had luck converting textured models to fbx format
using the writer in OSG?

   I narrowed it down to simple case of:

osgconv skydome.osg skydome.fbx

The resulting file when viewed in osgviewer is just a solid color.
 Converting that file back to .osg results in no reference to the
texture in the osg file.

This is on svn of today, with the 20112 SDK on Mac OS X.
 Converting to other formats: obj, ive, etc works fine.  I tried
turning the optimizer off as well as setting  OSG_NOTIFY_LEVEL to
DEBUG.  The image gets read fine on load, but there's no
information on whats going on at the write stage.

Thanks

Martins

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] fbx writer texture support

[Martins Innus]

Hello,
Has anybody had luck converting textured models to fbx format using 
the writer in OSG?


I narrowed it down to simple case of:

osgconv skydome.osg skydome.fbx

The resulting file when viewed in osgviewer is just a solid color.  
Converting that file back to .osg results in no reference to the texture 
in the osg file.


This is on svn of today, with the 20112 SDK on Mac OS X.  Converting to 
other formats: obj, ive, etc works fine.  I tried turning the optimizer 
off as well as setting  OSG_NOTIFY_LEVEL to DEBUG.  The image gets read 
fine on load, but there's no information on whats going on at the write 
stage.


Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Slave-cameras and update-callbacks

[Martins Innus]

Stephan,

See Robert's response below in a thread entitled "setUpdateCallback 
fails under slave-camera"


Martins

Hi Peter,

The update traversal is currently only applied to the View's
SceneData, not the individual Camera's subgraphs.  This is typically
desirable as you wouldn't want to run the update traversal multiple
times on the same scene graph on each frame as it would be both
inefficient and could lead to objects be moved multiple times.

I presume in your case your slave Camera is not share the same scene
graph as the View's SceneData, is it a hud? special effect?

One possible way to handle this type of usage model would be to have a
flag on the slaves that enables/disables the update and event
traversals on the Camera's subgraph.  It would of be off by default.
Another possible scheme might be to collect all the unique scene
graphs attached to all Camera's and then traverse all these.  Both of
these would require mods to the core OSG.

If you wish to modify the core OSG then just manually running an
update traversal on these subgraphs would do the trick.

Robert.


On 4/27/10 4:00 PM, Stephan Huber wrote:

Hi all,

before starting a debugging session I'll ask the community:

(using osg 2.9.x, revision 11314)

I have the suspicion, that update-callbacks are not called for nodes who
are childs of a slave-camera. If the same child with it's update
callback is added to the main camera or via setSceneData, the
update-callback gets called. Adding the same node to a slave camera will
disable the update-callback. (I am adding the slave-camera with
useMastersSceneData=false)

Is this intentional? If not I'll try to debug the scenario and send a
fix if possible,

cheers,
Stephan


___
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

Re: [osg-users] Question on OSX frameworks

[Martins Innus]

Bruce,
Yeah, thanks, thats what I've been doing in my own projects and it 
works fine.  The problem is, when I do this from within the osg XCode 
project for osgviewer, I get the following:


PBXCp build/bin/Release/osgviewer.app/Contents/Frameworks/osg.framework 
build/bin/Release/osg.framework

cd /util/src/osgsvn64
/Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp 
-exclude .DS_Store -exclude CVS -exclude .svn -strip-debug-symbols 
-resolve-src-symlinks /util/src/osgsvn64/build/bin/Release/osg.framework 
/util/src/osgsvn64/build/bin/Release/osgviewer.app/Contents/Frameworks


Note that its trying to copy from build/bin instead of build/lib which 
fails.  Yet when I choose "Get Info" or "Show in Finder"  for those 
frameworks, it shows them correctly as being in lib. Seems like its 
using the BUILT_PRODUCTS_DIR from the application instead of from the 
framework.


Good to know that this should work at least, just need to find what the 
hangup is on this end.


Martins

On 4/24/10 11:15 AM, Bruce Wheaton wrote:

Martins,

I was under the impression that the projects were 'partial' in this 
way so you had an option of installing OSG frameworks.


What I do, to make standard, distributable examples, is:

Add a build stage to the target you're building, a 'Copy Files' stage. 
Set the destination to 'Frameworks'.


Go up to products and pick it, in the top right contents pane, you 
should see all the Frameworks.


Drag the OpenThreads, OSG, OSGViewer, OSGDB and any other frameworks 
you need into your copy stage - make sure you have OpenThreads plus 
all the frameworks the targets you linked to.


Now make a Copy Files stage set to 'Plugins'. Go and find all the 
osgdb_xxx products. Drag any of these you might need into that stage. 
Be aware that some of them, if used in an OSG file, may need 
additional frameworks, even if the app didn't.


Now build the example app. You'll end up with all the libraries you 
need being copied into it.


Bruce

On Apr 23, 2010, at 11:12 AM, Martins Innus wrote:


Hello,

   I've been using the frameworks generated by the latest CMake 
updates in my own projects under osx, and it works great.  However it 
doesn't seem like its working for the osg provided applications. I 
build the frameworks and application bundles using svn from 
yesterday.  Then when i run osgviewer i get:


dyld: Library not loaded: 
@executable_path/../Frameworks/OpenThreads.framework/Versions/2.5.0/OpenThreads 


 Referenced from: /util/osg/svn64/bin/osgconv.app/Contents/MacOS/osgconv

Same thing with osgconv, etc

The path appears correct, but the frameworks are not being copied 
into the application bundle during the install stage i guess.


In my own project, I just add a "copy Files" build stage to copy the 
frameworks to the application bundle.  I'm not sure how to do that 
under CMake though for OSG itself.


Has any body else run into this or is there something misconfigured 
on my machine?


Thanks

Martins
___
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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Question on OSX frameworks

[Martins Innus]

Hello,

I've been using the frameworks generated by the latest CMake 
updates in my own projects under osx, and it works great.  However it 
doesn't seem like its working for the osg provided applications. I build 
the frameworks and application bundles using svn from yesterday.  Then 
when i run osgviewer i get:


dyld: Library not loaded: 
@executable_path/../Frameworks/OpenThreads.framework/Versions/2.5.0/OpenThreads

  Referenced from: /util/osg/svn64/bin/osgconv.app/Contents/MacOS/osgconv

Same thing with osgconv, etc

The path appears correct, but the frameworks are not being copied into 
the application bundle during the install stage i guess.


In my own project, I just add a "copy Files" build stage to copy the 
frameworks to the application bundle.  I'm not sure how to do that under 
CMake though for OSG itself.


Has any body else run into this or is there something misconfigured on 
my machine?


Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] looking for a terrain database building

[Martins Innus]

Terry,
I have a couple of suggestions based on our use:

1.  Units.  My database defaults to being built in degrees.  I would
prefer meters, which can be achieved using the --range option.
   
Not sure here.  Our source data is GeoTiffs in feet, and the resulting 
DB units are feet, without having to specify any options on the command 
line.



6.  Creator loads up my .flt files in bad, indescribable, uneditable
ways (probably due to my horribly outdated version of Creator).

   
We had to convert the mesh nodes to triangles in creator as well as 
flatten the transforms.  Otherwise we had all kinds of issues.  Couldn't 
edit certain areas, crashes, lighting errors, etc. This was with a 
fairly recent version of creator.



7.  I need the output image files to be separate from the terrain
files when editing .flt.  I don't see a way to build tiles with
separate image files, but I think I've seen a code snippet somewhere
for extracting images.  Other options are welcome.

   
If you output to "osg"  you can get the images as separate files.  The 
folowing worked for us: "--RGB_24 --image-ext rgb -o foo.osg"  Don't 
remember why, but there was some logic in the code that didn't output 
the textures separately if you generated ive files. I keep meaning to go 
back and code up a patch for that, but havent had a chance.  This was a 
few months ago, so maybe this has changed.



8.  I still need to work out the reasons for the big file size
differences between my output .ive files and the .flt files I convert
them too.  Converting back to .osg I noticed huge lists of Geodes each
containing one triangle.  Maybe I can do some tri-stripifying when
converting back from .flt to .ive.
   
As I mentioned in a previous email.  If you are generating "TERRAIN" 
based files from vpb, the process of going to flt and then back to ive, 
will give you geometry, and that will be a huge size difference.  If 
have vpb generate geometry already, I'm not sure why that would happen.


Martins


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] looking for a terrain database building

[Martins Innus]

Hi Terry and J-S,


Hi Terry,


Hi J-S.  When you convert a file to .flt and then back to .ive, your
PagedLOD nodes are lost.


I meant converting the leaf tiles. Unless I'm mistaken (it's been a 
while since I analyzed the structure so I might remember wrong), in a 
VPB database, you have a master .ive file, which has PagedLOD nodes 
that refer to other .ive files, which might have other PagedLODs, etc. 
Eventually you have geometry in .ive files that have no PagedLODs. You 
could convert these to flt, edit the geometry, and reconvert. But it 
does mean that each LOD of each tile is in a separate file, so it's a 
bit of a pain to edit all LODs of a certain region to match (you have 
to convert and edit as many files as you have levels, separately).
We have done this for small areas and it works alright ( just editing 
the leaf tiles ).




The new .ive file is
also 50X larger than the original and missing its textures, but those
problems are probably solvable.


The 50x larger is weird, but the textures you just have to convert to 
.osg with -O OutputTextureFiles to recover them (convert to .osg and 
to .flt then delete the .osg file). I don't know if the flt output 
plugin has a similar option, I know about that one for the .osg output 
plugin so I've always used that.


When you convert from a --TERRAIN based ive file to flt, this gets 
converted to geometry.  Then when you convert back to ive, you still 
have geometry.  I don't remember the size difference, but we have 
noticed an increase in size.


Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] need help with cmake / osg / os x / frameworks

[Martins Innus]

This works for me as well.  Thanks!  I wasn't getting Openthreads 
compiled as a framework and noticed the:


INCLUDE(ModuleInstall OPTIONAL)

line commented out in its CMakeLists.txt.

Adding it back in and now everything seems to be ok.  Not sure why that 
was.  Will do some tests on compiling our projects against this now.


Martins

On 3/25/10 1:48 PM, Jordi Torres wrote:

Hi Matheiu,

Your changes are working for me and now I am able to compile OSG 
frameworks installing the headers in the right place. Good job!


Cheers.

2010/3/25 Mathieu Marache <mailto:mathieu.mara...@gmail.com>>


Hi Martin, Stephan,

I've had a chance to finally look at your contribution and looking
at CMake's internals I found out that if one want's a file to be
placed into the MACOSX_FRAMEWORK_LOCATION it must neither be a
PUBLIC_HEADER, PRIVATE_HEADER nor a RESOURCE.

I modified osgViewer's CMakeLists.txt accordingly and it works for
me (I have CMake 2.8 btw).

See the changeset on my git clone :

http://github.com/mathieu/osg/commit/ed5aefc9ec062df70957c72e655cb1388b4a1557

And the attached file.

If you could test it on your side ?

Le 24 mars 10 à 18:01, Stephan Maximilian Huber a écrit :


Hi Martins,
    Am 24.03.10 16:03, schrieb Martins Innus:

 Have you made any progress on this?  I tried your files
and got
similar behavior with respect to the osgViewer headers in the
framework.  Although I don't even get an api directory in

osgViewer.framework/headers/

Let me know if you have any news files to test.  I'll
continue to dig on
this end.


Unfortunately no progress made on my end. If I have some
spare-time this
or next week I'll subscribe to the cmake-mailing list and ask
for help.

cheers,
Stephan


HTH
Mathieu

___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es


___
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

Re: [osg-users] need help with cmake / osg / os x / frameworks

[Martins Innus]

Stephan,

Have you made any progress on this?  I tried your files and got 
similar behavior with respect to the osgViewer headers in the 
framework.  Although I don't even get an api directory in


osgViewer.framework/headers/

Let me know if you have any news files to test.  I'll continue to dig on 
this end.


Thanks

Martins


On 3/10/10 10:21 AM, Stephan Maximilian Huber wrote:

Hi all,

I am trying to add framework-support to the cmake-files, and I am
hitting a wall. I am not a cmake-expert so I'll ask the community for help.

Attached you'll find my modified cmake-files (based on current trunk),
which adds compiling osg as frameworks, which can be embedded into
application bundles (this is the main reason for the existance of the
deprecated xcode-project)

To compile frameworks with cmake you'll have to:

set OSG_COMPILE_FRAMEWORKS to TRUE
modify OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR if needed
set the CMAKE_INSTALL_PREFIX to something reasonable, I use a folder on
my desktop as destination.

Click Configure, click generate, open the xcode project, click build,
select the "install"-target, click build again. So you'll find in
CMAKE_INSTALL_PREFIX a bunch of folders, in lib you'll find the
frameworks, ready to be embedded into your app.

You'll get valid frameworks ONLY if you run the install-target. Without
that, the install_name_dirs are bound to the local storage of the
frameworks, and will not work on other computers, or other destinations.

And here's the big BUT:

I have problems to move the api-headers of osgViewer into their right
places (osgViewer.framework/headers/api/(Carbon|Cocoa)/*)

They end all in osgViewer.framework/headers/

There is a special property for this called MACOSX_PACKAGE_LOCATION,
which should move the corresponding files to the special place in the
framework-bundle, but it doesn't work for the api-headerfiles. Perhaps
someone can look at the source in src/osgViewer/CMakeLists.txt and check
my approach. cmake copies two cpp-files into that place instead of the
header-files.

So please, please test the packaged cmake-files and perhaps there is
someone out there who can help with the issues with the
osgviewer-header-files!

thanks in advance,

Stephan


   



___
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

Re: [osg-users] Mac Serializer Compile Error

[Martins Innus]

I have attempted to add a ADD_GLINT_SERIALIZER for the cases where I got 
errors.  I did as Robert suggested and just blindly cast to int.  
Figured I'd post here first instead of to submissions since I have no 
idea if this will break other builds, but it allows the serializers to 
compile for me under the 10.4 SDK.


Martins

On 3/18/10 4:28 AM, Robert Osfield wrote:

HI Matrin&  Wang Rui

On Thu, Mar 18, 2010 at 3:15 AM, Wang Rui  wrote:
   

Hi Martins,

I have no experience in Mac. But it seems that type definition of
GLint changes to some other types in your system. In most other cases,
we have:

typedef int GLint;

in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

Maybe we should have more tests on 64bit systems and try to find out
if an independent ADD_GLINT_SERIALIZER was required to keep compatible
on different platforms.
 

An ADD_GLINT_SERIALIZER may well be required.  We'd need to
static_cast the GLint to int for portability of the data format.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
   


#include 
#include 
#include 
#include 

REGISTER_OBJECT_WRAPPER( LineStipple,
 new osg::LineStipple,
 osg::LineStipple,
 "osg::Object osg::StateAttribute osg::LineStipple" )
{
ADD_GLINT_SERIALIZER( Factor, 1 );  // _factor
ADD_HEXSHORT_SERIALIZER( Pattern, 0x );  // _pattern
}
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
 *
 * This library is open source and may be redistributed and/or modified under
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * OpenSceneGraph Public License for more details.
*/
// Written by Wang Rui, (C) 2010

#ifndef OSGDB__SERIALIZER
#define OSGDB__SERIALIZER

#include 
#include 
#include 
#include 
#include 
#include 
#include 


namespace osgDB
{

#ifndef OBJECT_CAST
#define OBJECT_CAST static_cast
#endif

class IntLookup
{
public:
typedef int Value;
typedef std::map StringToValue;
typedef std::map ValueToString;

IntLookup() {}
unsigned int size() const { return _stringToValue.size(); }

void add( const char* str, Value value )
{
if ( _valueToString.find(value)!=_valueToString.end() )
{
osg::notify(osg::WARN) << "Duplicate enum value " << value
   << " with old string: " << 
_valueToString[value]
   << " and new string: " << str << std::endl;
}
_valueToString[value] = str;
_stringToValue[str] = value;
}

Value getValue( const char* str )
{
StringToValue::iterator itr = _stringToValue.find(str);
if ( itr==_stringToValue.end() )
{
Value value;
std::stringstream stream;
stream << str; stream >> value;
_stringToValue[str] = value;
return value;
}
return itr->second;
}

const std::string& getString( Value value )
{
ValueToString::iterator itr = _valueToString.find(value);
if ( itr==_valueToString.end() )
{
std::string str;
std::stringstream stream;
stream << value; stream >> str;
_valueToString[value] = str;
return _valueToString[value];
}
return itr->second;
}

protected:
StringToValue _stringToValue;
ValueToString _valueToString;
};

class UserLookupTableProxy
{
public:
typedef void (*AddValueFunc)( IntLookup* lookup );
UserLookupTableProxy( AddValueFunc func ) { if ( func ) (*func)(&_lookup); }

IntLookup _lookup;
};

#define BEGIN_USER_TABLE(NAME, CLASS) \
static void add_user_value_func_##NAME(osgDB::IntLookup*); \
static osgDB::UserLookupTableProxy 
s_user_lookup_table_##NAME(&add_user_value_func_##NAME); \
static void add_user_value_func_##NAME(osgDB::IntLookup* lookup) { typedef 
CLASS MyClass
#define ADD_USER_VALUE(VALUE) lookup->add(#VALUE, MyClass::VALUE)
#define END_USER_TABLE() }

#define USER_READ_FUNC(NAME, FUNCNAME) \
static int FUNCNAME(osgDB::InputStream& is) { \
int value; if (is.isBinary()) is >> value; \
else { std::string str; is >> str; \
value = (s_user_lookup_table_##NAME)._lookup.getValue(str.c_str()); } \
return value; }

#define USER_WRITE_FUNC(NAME, FUNCNAME) \
static void FUNCNAME(osgDB::OutputStream& os, int value) { \
if (os.isBinary()) o

Re: [osg-users] Mac Serializer Compile Error

[Martins Innus]

Wang Rui,

Looking at gl.h under the different SDK's here are the typedefs:

10.4 : long
10.5 : int
10.6 : int

So I'm not sure what that means in terms of being able to support 
different types with the serializer.


Martins

On 3/17/2010 11:15 PM, Wang Rui wrote:

Hi Martins,

I have no experience in Mac. But it seems that type definition of
GLint changes to some other types in your system. In most other cases,
we have:

typedef int GLint;

in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

Maybe we should have more tests on 64bit systems and try to find out
if an independent ADD_GLINT_SERIALIZER was required to keep compatible
on different platforms.

Wang Rui


2010/3/18 Martins Innus:

Hello,

I get the following 2 errors when trying to compile the latest svn on a Mac
running 10.6 but using the 10.4 SDK.  This compiles fine using the 10.6 SDK
with gcc-4.2, but since the 10.4 SDK requires gcc-4.0, I assume its a
compiler quirk.  Any suggestions on how to get around it?

/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp: In
function 'void wrapper_propfunc_LineStipple(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp:11: error:
no matching function for call to 'osgDB::PropByValSerializer::PropByValSerializer(const char [7], int, GLint
(osg::LineStipple::*)()const, void (osg::LineStipple::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
osgDB::PropByValSerializer::PropByValSerializer(const char*, P, P
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note:
osgDB::PropByValSerializer::PropByValSerializer(const
osgDB::PropByValSerializer&)

/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp: In function
'void wrapper_propfunc_Texture(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp:89: error: no
matching function for call to 'osgDB::PropByValSerializer::PropByValSerializer(const char [12], int, GLint
(osg::Texture::*)()const, void (osg::Texture::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
osgDB::PropByValSerializer::PropByValSerializer(const char*, P, P
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note:
osgDB::PropByValSerializer::PropByValSerializer(const
osgDB::PropByValSerializer&)


Thanks

Martins
___
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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac Serializer Compile Error

[Martins Innus]

Hello,

I get the following 2 errors when trying to compile the latest svn on a 
Mac running 10.6 but using the 10.4 SDK.  This compiles fine using the 
10.6 SDK with gcc-4.2, but since the 10.4 SDK requires gcc-4.0, I assume 
its a compiler quirk.  Any suggestions on how to get around it?


/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp: In 
function 'void wrapper_propfunc_LineStipple(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp:11: 
error: no matching function for call to 
'osgDB::PropByValSerializer::PropByValSerializer(const 
char [7], int, GLint (osg::LineStipple::*)()const, void 
(osg::LineStipple::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are: 
osgDB::PropByValSerializer::PropByValSerializer(const char*, P, P 
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note: 
osgDB::PropByValSerializer::PropByValSerializer(const 
osgDB::PropByValSerializer&)


/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp: In 
function 'void wrapper_propfunc_Texture(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp:89: error: 
no matching function for call to 'osgDB::PropByValSerializerint>::PropByValSerializer(const char [12], int, GLint 
(osg::Texture::*)()const, void (osg::Texture::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are: 
osgDB::PropByValSerializer::PropByValSerializer(const char*, P, P 
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note: 
osgDB::PropByValSerializer::PropByValSerializer(const 
osgDB::PropByValSerializer&)



Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] help with osgCluster...

[Martins Innus]

Shayne,
Right, you use the same scenegraph on all machines.

The following should work on the master:

osgcluster -m cow.osg

and on the slave:

osgcluster -s cow.osg


	I just tested this and if you want to viewports to match, you'll need 
to tweak the fov and offset parameters.  With the above command line, 
the slave will just show a portion of the view.  If you zoom in from the 
master window, the cow will eventually come into view on the slave.


Martins

Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:

Martins,

Thanks for the input. I was looking more for some command line examples on
how I would execute the osgCluster example where one machine is the master
and another is the slave. Obviously you should use the same scenegraph on
each machine right?

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martins
Innus
Sent: Friday, December 18, 2009 11:27 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] help with osgCluster...

Shayne,

We run it under linux and if I remember correctly, it just
broadcasts 
out to the local subnet based on whatever your broadcast mask is set to. 
  If you have multiple network interfaces, I think there is a spot in 
the socket setup to specify which one you want.  I don't have the code 
in front of me right now, but thats how I recall it works. Let me know 
if you need any more information.


Martins


Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:

All,

 

I'm looking at the osgCluster example and I have a question on getting 
in going.


 

I'm assuming you can execute osgCluster on different machines where one 
is the master and the other is the slave. I can see where I specify the 
socket # but where do I specify the IP address? Does anyone have example 
of executing osgCluster on different machines that would provide some 
direction?


 


Any enlightenment would be appreciated.

 


-Shayne




___
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




___
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

Re: [osg-users] help with osgCluster...

[Martins Innus]

Shayne,

	We run it under linux and if I remember correctly, it just broadcasts 
out to the local subnet based on whatever your broadcast mask is set to. 
 If you have multiple network interfaces, I think there is a spot in 
the socket setup to specify which one you want.  I don't have the code 
in front of me right now, but thats how I recall it works. Let me know 
if you need any more information.


Martins


Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:

All,

 

I’m looking at the osgCluster example and I have a question on getting 
in going.


 

I’m assuming you can execute osgCluster on different machines where one 
is the master and the other is the slave. I can see where I specify the 
socket # but where do I specify the IP address? Does anyone have example 
of executing osgCluster on different machines that would provide some 
direction?


 


Any enlightenment would be appreciated…

 


-Shayne




___
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

Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Martins Innus]

Kim,
	OK, I upgraded the driver to the latest version (185.85) and have made 
some progress.


	It now works at any resolution in 32 bit color, but with some 
"shimmering" black pixels where the sky meets the ocean.  Kind of like 
you get if you had a bad DVI cable going to your monitor.


	At 16 bit color, I can get it to work if I toggle off "glare".  I still 
get the FBO setup errors, but it seems to look ok, and the out of memory 
errors are gone.


	So I guess I'll chalk it up to drivers, I'll keep checking for newer 
ones. Thanks for the suggestions.


Martins

Kim C Bale wrote:
Hi Martins, 
 
Sorry, little hasty with the send button there.
 
This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. 
 
I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. 
 
Perhaps J-S has some ideas on this one.
 
In the mean time you should be able to disable all the effects that use FBOs with the following keys.
 
r - reflections

R - refractions
o - depth of field
g - glare
G - godrays
 
Regards,
 
Kim.




From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus
Sent: Wed 17/06/2009 15:16
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released



Hi,
I'm having trouble getting this to run.

Machine Specs:

Windows XP
Visual Studio 2003
NVIDIA Quadro FX 1600M
OSG 2.8.1

Compiled osgOcean with FFTSS and it builds fine.

With my display set to 1920x1200 at 16 bit color I get the following:

E:\Windows\OSG\2.8.1\install\bin>oceanExample.exe
Building scene...
   . Loading cubemaps: 0.212617s
   . Generating ocean surface: 2.43048e-005s
   . Creating ocean scene: 0.000286629s
   . Loading islands: 0.0594939s
   . Setting up lighting: 2.26286e-005s
complete.
Time Taken: 0.274954s
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd

and just a blank screen shows up.



If I change to 32 bit color at the same resolution, I get a couple
frames that show up properly, then the window goes blank with the
following printed to the console:

Building scene...
   . Loading cubemaps: 0.213689s
   . Generating ocean surface: 1.89968e-005s
   . Creating ocean scene: 0.000278248s
   . Loading islands: 0.0593453s
   . Setting up lighting: 1.73206e-005s
complete.
Time Taken: 0.276148s
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5




It works fine if I run at 1024x768.

Is this likely a driver problem, or is there something I can tweak in
the FBO setup?  I'm not familiar with their use at all.

Thanks

Martins

Kim C Bale wrote:

Hi all,

After much clawing and gnashing of teeth I've tagged version 1.0 of
osgOcean.

http://code.google.com/p/osgocean/

Feature list:

- FFT ocean simulation model and rendering
- Foam caps
- Refraction/Reflection Passes
- God Rays
- Surface glare
- Underwater depth of field
- Underwater/above water fogging
- Simulated light absorption and scattering
- Silt effects
- Screen distortion effects
- Choice of FFT library dependancy

Possibly the most important change is that the library is now held under
a LGPL license.

The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL)
for the FFT library dependancy which resolves the license issue. FFTW is
the faster option, but the differance if fairly negliable within the
context that it's used.

The library now searches for it's resource dependancies using the osgDB
registry so they're not bound to a specific path.

I've also included a fix for the shader bug on 7 series nVidia cards
which caused an error when indexing arrays using uniform variables.

The example application now supports real-time changes to the ocean
surface and effects so you can have a play with the settings to see what
they do.

A lot of the work has been submitted by Jean-Sebastian. If anybody else
would like to contribute do get in touch. Many hands make light work and
all that ;)

For t

Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Martins Innus]

Hi,
I'm having trouble getting this to run.

Machine Specs:

Windows XP
Visual Studio 2003
NVIDIA Quadro FX 1600M
OSG 2.8.1

Compiled osgOcean with FFTSS and it builds fine.

With my display set to 1920x1200 at 16 bit color I get the following:

E:\Windows\OSG\2.8.1\install\bin>oceanExample.exe
Building scene...
  . Loading cubemaps: 0.212617s
  . Generating ocean surface: 2.43048e-005s
  . Creating ocean scene: 0.000286629s
  . Loading islands: 0.0594939s
  . Setting up lighting: 2.26286e-005s
complete.
Time Taken: 0.274954s
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd

and just a blank screen shows up.



If I change to 32 bit color at the same resolution, I get a couple 
frames that show up properly, then the window goes blank with the 
following printed to the console:


Building scene...
  . Loading cubemaps: 0.213689s
  . Generating ocean surface: 1.89968e-005s
  . Creating ocean scene: 0.000278248s
  . Loading islands: 0.0593453s
  . Setting up lighting: 1.73206e-005s
complete.
Time Taken: 0.276148s
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5




It works fine if I run at 1024x768.

Is this likely a driver problem, or is there something I can tweak in 
the FBO setup?  I'm not familiar with their use at all.


Thanks

Martins

Kim C Bale wrote:

Hi all,
 
After much clawing and gnashing of teeth I've tagged version 1.0 of 
osgOcean.
 
http://code.google.com/p/osgocean/
 
Feature list:
 
- FFT ocean simulation model and rendering

- Foam caps
- Refraction/Reflection Passes
- God Rays
- Surface glare
- Underwater depth of field
- Underwater/above water fogging
- Simulated light absorption and scattering
- Silt effects
- Screen distortion effects
- Choice of FFT library dependancy
 
Possibly the most important change is that the library is now held under 
a LGPL license.
 
The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) 
for the FFT library dependancy which resolves the license issue. FFTW is 
the faster option, but the differance if fairly negliable within the 
context that it's used.
 
The library now searches for it's resource dependancies using the osgDB 
registry so they're not bound to a specific path.
 
I've also included a fix for the shader bug on 7 series nVidia cards 
which caused an error when indexing arrays using uniform variables.
 
The example application now supports real-time changes to the ocean 
surface and effects so you can have a play with the settings to see what 
they do.
 
A lot of the work has been submitted by Jean-Sebastian. If anybody else 
would like to contribute do get in touch. Many hands make light work and 
all that ;)
 
For those of you that suggested features/enhancement that aren't in this 
release, don't worry I haven't forgotten about them, they're still on my 
list of things to do.
 
 
Regards,
 
 
Kim.
 
 





*
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*




___
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

[osg-users] 3D HUD Elements

[Martins Innus]

Hello,
	I've got a HUD working great with an osg::Camera attached to the 
scenegraph like in the examples with the orthographic projection, 
POST_RENDER, etc. Now I want to add a simple 3D axis element, like they 
have in modeling software that spins around based on your view and am 
having some trouble.  The best I can do is have it show up as a 
squished, flat shaded blob.  I'm sure someone has done this before, do i 
need a separate camera for 3D hud elements?


Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Skybox example problem

[Martins Innus]

If its the vertex program example, I had the same issue when using it 
with a large scene.  The skybox would disappear as you zoomed out.  If I 
increased the size of the Shape Drawable Sphere that the skybox was 
mapped to, everything worked fine, so it seems like it was being clipped 
by the near plane.  Going to size 100 worked fine and didn't seem to 
cause any other problems.


I don't think its a bug, just something to look out for.

Martins

Robert Osfield wrote:
2009/4/7 Großer Martin >


Hello,

ok, it seems that nobody has an idea. Maybe is the problem the range of
values?


Perhaps the problem is that no-one knows what skybox example you are 
talking about...


Robert.




___
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

Re: [osg-users] --tile-terrain-size in VPB

[Martins Innus]

Robert,

	It seems that this issue is caused by the use of DrawElementsUShort and 
"unsigned short" indexes in "osg::Node* 
DestinationTile::createPolygonal()".  Such that each level can only have 
a maximum of 65536 vertexes.  And I do see that a terrain-tile size of 
256x256 works, yet 512x12 doesn't, which makes sense.


	Is this something you'd accept a change for to be included in VPB?  Not 
sure what the performance implications would be, or how extensive the 
changes would need to be.


Martins

Martins Innus wrote:

Robert,
What fun would it be if people didn't abuse your code :)  I agree 
that in general VPB does a great job with default settings, I've used it 
several times to generate 100 GB databases over large areas.


In this case though I'm trying to generate terrain at the resolution 
of the source data for a very small area in as few tiles as possible. I 
realize this is not the intended purpose, but I was trying to see if 
anyone had done this successfully.


It doesn't seem to be a display issue, becase I can generate the 
model with default options and load all the highest resolution tiles 
directly into osgviewer and it runs fine, about 4 million vertices.


Going down to 512x512 causes the same problem.

I'll keep digging if no one has run into this before.

Martins

Robert Osfield wrote:

Hi Martins,

Jikes, some days I regret making osgdem quite so flexible...

A 1024x1204 grid weights in at million vertices, and near two million 
triangles.  Normally graphics cards should be able to handle this, 
but... it would seem that your's doesn't, perhaps it just doesn't have 
the memory to handle such a big geometry.  The other chance might be 
that numerical precision is becoming an issue, although I'd be 
surprised by this one.


I really would very strongly recommend that you stick to defaults 
unless you really know what you are doing, the defaults are chosen for 
a good performance and scalability.


Robert.

2009/3/23 Martins Innus <mailto:min...@ccr.buffalo.edu>>


Hello,
   I'm using the --tile-image-size and --tile-terrain-size
options to tweak the generation of the dataset.  The image option
works great, but when I try to use the terrain option I get the
results attached.

   If I zoom in, it seems like a lot of overlapping geometry
like the y-coordinate is not being updated properly, but I dug
through the code and could see any obvious causes.

I'm using the following command-line:

osgdem --tile-image-size 4096 --tile-terrain-size 1024 -t
../input_ims/ -d ../input_terrain/ -e 1065536 1043840 8192 8192 -o
output/vpb_out.ive

I even added --no-terrain-simplification to see if that was the
problem, but no help there.

   I'm not using the --TERRAIN option, since I need to
post-process the geometry using an existing tool.

Thanks

Martins

___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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

___
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

Re: [osg-users] --tile-terrain-size in VPB

[Martins Innus]

Robert,
	What fun would it be if people didn't abuse your code :)  I agree that 
in general VPB does a great job with default settings, I've used it 
several times to generate 100 GB databases over large areas.


	In this case though I'm trying to generate terrain at the resolution of 
the source data for a very small area in as few tiles as possible. I 
realize this is not the intended purpose, but I was trying to see if 
anyone had done this successfully.


	It doesn't seem to be a display issue, becase I can generate the model 
with default options and load all the highest resolution tiles directly 
into osgviewer and it runs fine, about 4 million vertices.


Going down to 512x512 causes the same problem.

I'll keep digging if no one has run into this before.

Martins

Robert Osfield wrote:

Hi Martins,

Jikes, some days I regret making osgdem quite so flexible...

A 1024x1204 grid weights in at million vertices, and near two million 
triangles.  Normally graphics cards should be able to handle this, 
but... it would seem that your's doesn't, perhaps it just doesn't have 
the memory to handle such a big geometry.  The other chance might be 
that numerical precision is becoming an issue, although I'd be surprised 
by this one.


I really would very strongly recommend that you stick to defaults unless 
you really know what you are doing, the defaults are chosen for a good 
performance and scalability.


Robert.

2009/3/23 Martins Innus <mailto:min...@ccr.buffalo.edu>>


Hello,
   I'm using the --tile-image-size and --tile-terrain-size
options to tweak the generation of the dataset.  The image option
works great, but when I try to use the terrain option I get the
results attached.

   If I zoom in, it seems like a lot of overlapping geometry
like the y-coordinate is not being updated properly, but I dug
through the code and could see any obvious causes.

I'm using the following command-line:

osgdem --tile-image-size 4096 --tile-terrain-size 1024 -t
../input_ims/ -d ../input_terrain/ -e 1065536 1043840 8192 8192 -o
output/vpb_out.ive

I even added --no-terrain-simplification to see if that was the
problem, but no help there.

   I'm not using the --TERRAIN option, since I need to
post-process the geometry using an existing tool.

Thanks

Martins

___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Image Resolution in VPB

[Martins Innus]

Robert,

	OK, no problem, thanks.  It's pixelated just because i zoomed in to the 
image to highlight the effect i was seeing.


Martins


Robert Osfield wrote:

Hi Matins,

Slight variations of the pixel colour may come about due to GDAL 
interpolating data, interpolation done with VPB, or the edge boundary 
equalization.  The small variation you are seeing might simply be down 
to this, it's not something at this stage I'd even flag up as a 
problem.  It certainly doesn't looked to be the corner equalization bug, 
as this just effects the corners.


BTW, the way is there a reason for the image being pixelated?  VPB 
typically generates databases that use linear texture filtering.


Robert.

2009/3/19 Martins Innus <mailto:min...@ccr.buffalo.edu>>


Robert,
   Thanks. Using -e with appropriate options did exactly what I
wanted, except for a slight error on the edges of the created
images.  If i overlay the created image tiles from the highest
resolution level on top of the original source imagery, they are
pixel to pixel exact except for a 1 pixel strip all the way around
the image.
   It appears that the edge values are an average of what the
pixel value actually should be and the pixel directly adjacent to it
but what should be the next tile.
   If you layer the attached good and bad images on top of each
other in an image viewer and toggle back and forth you can see the
pixels changing.
   The good image is just the original source imagery zoomed in.
 The bad image shows the vpb generated tile overlayed  on the left side.

   I saw the "corner equalization bug" posts, but this seems
like a different issue.

This is under Redhat Enterpise Linux, x86_64, with OSG 2.8 and VPB
svn of a couple days ago.

Martins


Robert Osfield wrote:

Hi Martins,

You could try to use the -e option.  It takes lat/longs as
input.  I don't know if it'll pad though, as I suspect it won't
unless the at least some of the input data covers the region.  
If you want to force the resolution to be the same then just use

the image and height res option.  I can't recall what they off
the top of my head, run osgdem --help to list them all.

    Robert.

On Mon, Mar 16, 2009 at 6:12 PM, Martins Innus
mailto:min...@ccr.buffalo.edu>
<mailto:min...@ccr.buffalo.edu <mailto:min...@ccr.buffalo.edu>>>
wrote:

   Hello,
  I'm using VPB to generate a terrain database with 2ft
   resolution elevation data and 1 ft resolution imagery. What I'm
   trying to do is make the imagery in the highest resolution tiles
   have the exact same resolution as the source imagery and also
still
   be a power of 2 for the image tiles.
  I've verified that if I take a small input area where the
   source imagery dimensions are a power of 2, I get what i want for
   the final model.
  It seems that if I could tell VPB to "pad out" the
extents of
   my input data to a power of 2 that should work as well.  I don't
   care if its black or garbage or whatever.

  Would the "-e" option do what I want if I specify extents
   larger than the input data?  I'm about to give that a try but it
   takes about three days for this job to run to completion, so I
   figured I would ask if anyone has tried to do the same thing.

   Thanks for any insight.

   Martins
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
   <mailto:osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>>

 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org







___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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.

Re: [osg-users] Image Resolution in VPB

[Martins Innus]

Robert,
	Thanks. Using -e with appropriate options did exactly what I wanted, 
except for a slight error on the edges of the created images.  If i 
overlay the created image tiles from the highest resolution level on top 
of the original source imagery, they are pixel to pixel exact except for 
a 1 pixel strip all the way around the image.
	It appears that the edge values are an average of what the pixel value 
actually should be and the pixel directly adjacent to it but what should 
be the next tile.
	If you layer the attached good and bad images on top of each other in 
an image viewer and toggle back and forth you can see the pixels changing.
	The good image is just the original source imagery zoomed in.  The bad 
image shows the vpb generated tile overlayed  on the left side.


	I saw the "corner equalization bug" posts, but this seems like a 
different issue.


This is under Redhat Enterpise Linux, x86_64, with OSG 2.8 and VPB svn 
of a couple days ago.


Martins


Robert Osfield wrote:

Hi Martins,

You could try to use the -e option.  It takes lat/longs as input.  I 
don't know if it'll pad though, as I suspect it won't unless the at 
least some of the input data covers the region.   If you want to force 
the resolution to be the same then just use the image and height res 
option.  I can't recall what they off the top of my head, run osgdem 
--help to list them all.


Robert.

On Mon, Mar 16, 2009 at 6:12 PM, Martins Innus <mailto:min...@ccr.buffalo.edu>> wrote:


Hello,
   I'm using VPB to generate a terrain database with 2ft
resolution elevation data and 1 ft resolution imagery. What I'm
trying to do is make the imagery in the highest resolution tiles
have the exact same resolution as the source imagery and also still
be a power of 2 for the image tiles.
   I've verified that if I take a small input area where the
source imagery dimensions are a power of 2, I get what i want for
the final model.
   It seems that if I could tell VPB to "pad out" the extents of
my input data to a power of 2 that should work as well.  I don't
care if its black or garbage or whatever.

   Would the "-e" option do what I want if I specify extents
larger than the input data?  I'm about to give that a try but it
takes about three days for this job to run to completion, so I
figured I would ask if anyone has tried to do the same thing.

Thanks for any insight.

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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
<><>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Image Resolution in VPB

[Martins Innus]

Hello,
	I'm using VPB to generate a terrain database with 2ft resolution 
elevation data and 1 ft resolution imagery. What I'm trying to do is 
make the imagery in the highest resolution tiles have the exact same 
resolution as the source imagery and also still be a power of 2 for the 
image tiles.
	I've verified that if I take a small input area where the source 
imagery dimensions are a power of 2, I get what i want for the final model.
	It seems that if I could tell VPB to "pad out" the extents of my input 
data to a power of 2 that should work as well.  I don't care if its 
black or garbage or whatever.


	Would the "-e" option do what I want if I specify extents larger than 
the input data?  I'm about to give that a try but it takes about three 
days for this job to run to completion, so I figured I would ask if 
anyone has tried to do the same thing.


Thanks for any insight.

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Loss of Precision in .osg files

[Martins Innus]

Hello,

I was having trouble getting my models lined up when converting 
them to .osg format.  Attached are just the tops of the files from doing a:


osgconv cow0.osg cow1.osg

You can see that the one element of "Matrix" loses precision.

Any thoughts on increasing the default precision for output of some of 
these fields?


I assume a change to osgDB::Output is required?

This is under OSG 2.7.3, Redhat x86_64

Thanks

Martins
Group {
  DataVariance STATIC
  name "cow.osg"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1234567 0 1
}
Group {
  DataVariance STATIC
  name "cow.osg"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1.23457e+006 0 1
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] mac -install_name

[Martins Innus]

Yeah, thats what I do, but I only have a couple files in my case I need 
to worry about.


Although I just tried adding:

"-install_name @executable_path/../Frameworks/file.dylib"

to LDFLAGS and that seemed to work.  I do this in a Makefile project and 
use the resulting dylib in a larger XCode project.  Then i didn't have 
to do the install_name_tool voodoo.


Martins

Andy Skinner wrote:

Thanks, but that's what I'm trying to avoid.  Don't you have to do the -id 
version for every file (changing its own name) and the -change version for 
every dependency in every file?  I'm hoping I can do something in the link 
commands and avoid having to patch up the files.

andy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martins Innus
Sent: Tuesday, May 27, 2008 1:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] mac -install_name

Andy,

I use "install_name_tool -change ." and "install_name_tool -id ..."
in a script as a Run Script Build phase.  I don't know if you can do it
in XCode directly.  Seems to work.  Let me know if you need more info
and I'll dig up the exact script.

Martins

Andy Skinner wrote:

I'll admit to being a little past the limit of my knowledge here ...



We would like to specify the -install_name arg with which we link the
shared libraries.  I think it is because we don't want the paths where
these things were built to be in the files.  We're trying to replace the
value with something like: "@load_path/".



Is there a way to specify the -install_name argument on the Mac?



I tried setting it in our linker flags, then saw it was in there
already, and I think it is added by the OSG build.



I have looked at the gmane archive, and found some mention of
-install_name, but nothing I can see how to use.



thanks

andy






___
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
___
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

Re: [osg-users] mac -install_name

[Martins Innus]

Andy,

	I use "install_name_tool -change ." and "install_name_tool -id ..." 
in a script as a Run Script Build phase.  I don't know if you can do it 
in XCode directly.  Seems to work.  Let me know if you need more info 
and I'll dig up the exact script.


Martins

Andy Skinner wrote:

I’ll admit to being a little past the limit of my knowledge here ...

 

We would like to specify the –install_name arg with which we link the 
shared libraries.  I think it is because we don’t want the paths where 
these things were built to be in the files.  We’re trying to replace the 
value with something like: [EMAIL PROTECTED]/”.


 


Is there a way to specify the –install_name argument on the Mac?

 

I tried setting it in our linker flags, then saw it was in there 
already, and I think it is added by the OSG build.


 

I have looked at the gmane archive, and found some mention of 
–install_name, but nothing I can see how to use.


 


thanks

andy

 





___
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

[osg-users] Loss of Precision in .osg and .dae files

[Martins Innus]

Hello,
	I was having trouble getting my models lined up when converting them to 
collada or .osg format.  Attached are just the tops of the files from 
doing a:


osgconv cow0.osg cow1.osg

You can see that the one element of "Matrix" loses precision.

Any thoughts on increasing the default precision for output of these 
ascii formats?


I assume a change to osgDB::Output is required for .osg, but not sure 
about collada.


This is under OSG 2.0, WinXP, although i didn't see any changes that 
would affect this in svn.


Thanks

Martins
Group {
  DataVariance STATIC
  name "cow.osg"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1234567 0 1
}
Group {
  DataVariance STATIC
  name "cow.osg"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1.23457e+006 0 1
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] SpeedTree

[Martins Innus]

Hi,

Just wondering if anyone has had luck integrating a recent version of 
SpeedTree or anything else like it with a recent version of OSG.

Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org