Re: [osg-users] How to install libraries into lib64 instead of lib?

[Eric Sokolowsky]

Thank you. I will try this. But as you say, I don't know why it's doing
this already.


On Thu, Sep 30, 2021 at 10:15 AM Alberto Luaces  wrote:

> It's the parameter LIB_POSTFIX, so you could call
>
> cmake -DLIB_POSTFIX=64
>
> although it is the default, I wonder why it's not the case for you.
>
> Eric Sokolowsky writes:
>
> > I'm building OpenSceneGraph 3.6.5 for Fedora 34. The cmake build
> > system installs libraries into lib though I want it to install them
> > into lib64 (this is under the base installation
> > directory). I'm not familiar enough with cmake to fix this, though I
> > have poked around in the cmake files to try to do this. Can anyone
> > give me some pointers or help? 64-bit libraries
> > should go in lib64 for Linux, generally.
> >
>
> --
> Alberto
>
> ___
> 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] How to install libraries into lib64 instead of lib?

[Eric Sokolowsky]

I'm building OpenSceneGraph 3.6.5 for Fedora 34. The cmake build system
installs libraries into lib though I want it to install them into lib64
(this is under the base installation directory). I'm not familiar enough
with cmake to fix this, though I have poked around in the cmake files to
try to do this. Can anyone give me some pointers or help? 64-bit libraries
should go in lib64 for Linux, generally.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG and Xinerama

[Eric Sokolowsky]

In case this helps someone else, here are the variables that Robert
referred to:

OSG_CONFIG_FILE - set to a filename where a configuration is read. I'm
still trying to determine the format of this.
OSG_SCREEN - Set to a screen number. Under Linux it appears to refer to an
X11 screen number (seems like it would be more useful to be an Xinerama
screen number, though).
OSG_WINDOW - Same as using --window. Set to 4 values separated by spaces: x
y w h; where x and y give the origin of the window and w and h is the size
of the window. The window will have decorations (window bar etc.)
OSG_BORDERLESS_WINDOW - same as OSG_WINDOW but without a border. This is
what I was originally looking for.


On Sat, Sep 8, 2018 at 3:40 AM Robert Osfield 
wrote:

> HI Eric,
>
> The change in behaviour is actually a fix for a regressions that
> happened when the Linux window managers changed.  It's just the
> default behavior that has changed for setUpViewAcrossAllScreens(), so
> it now behaves as it should.  You can adjust what happens by default
> using the Producer config files still if you want, or one of the env
> vars.  Run osgviewer --help-env to see the env vars.  The env vars
>
> You don't have to rely upon defaults in your application for window
> creation, you can explicitly set up the views windowing via on of the
> include/osgViewer/config/*, or st up the Camera and Windows manually
> as per the osgcamera example.
>
> 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] OpenSceneGraph-3.6.3 release candidate 1 tagged!

[Eric Sokolowsky]

I just tried my application with 3.6.3-rc1 and it seems to work fine.
Fedora 26 (Linux). I still would like to know if there's an easy way to
limit usage to one of my two screens set up with Xinerama, like what
happened by default in 3.4.

Eric

On Thu, Sep 6, 2018 at 11:27 AM Robert Osfield 
wrote:

> Hi Glenn,
>
> The changes look OK from a a first scan.  Could you generate a PR
> against OSG master or 3.6 and I'll do a full review.
>
> Cheers,
> Robert.
> On Thu, 6 Sep 2018 at 15:58, Glenn Waldron  wrote:
> >
> > Robert,
> >
> > I apologize for not proposing this sooner. I made a couple updates to
> the Font and Glyph classes to address some thread-safety problems, and then
> forgot about them until now :)
> >
> > Creating objects from different threads was causing some unprotected
> access and this cleans that up.
> >
> >
> https://github.com/pelicanmapping/OpenSceneGraph/commit/c8b5a925459aa624a1d779192d3b8b0d7c4fa767
> >
> > I made this change against the 3.6.x branch. It's a small patch, but if
> you need a proper PR let me know and I'll spend some time putting it
> together.
> >
> > Glenn Waldron
> >
> >
> > On Thu, Sep 6, 2018 at 7:38 AM Robert Osfield 
> wrote:
> >>
> >> Hi All,
> >>
> >> I have tagged the first release candidate for the upcoming 3.6.3 stable
> release:
> >>
> >>
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.3-rc1
> >>
> >> To make sure that this stable release is a rock solid as we can make
> >> it I need the community to help out with build and runtime testing
> >> across all the build platforms that our users are working with. Any
> >> issues please post them to this thread and we can work together to
> >> resolve them.
> >>
> >> My goal for 3.6.3 is to make sure all reported issues have be resolved
> >> prior to tagging the final release.   I would love to be able to get
> >> 3.6.3 out by the end of next week, so prompt testing would be very
> >> much appreciated.
> >>
> >> 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
> ___
> 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] OSG and Xinerama

[Eric Sokolowsky]

I have been using OpenSceneGraph 3.4 with my application. Recently I tried
out OSG 3.6 and everything seems to work, with the following difference.
When I run my app with OSG 3.4 on a dual-monitor setup (Linux using
Xinerama) the application only uses one monitor, while the same application
using OSG 3.6 spreads the window across both monitors. I actually prefer my
application to just use one monitor. Once upon a time, Producer had these
text-based configuration files which I found to be very useful, but I'm not
sure if such configuration is possible any more. Is there a way to indicate
that only one monitor is to be used, using OSG API calls, environment
variables, or some sort of configuration file?

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

Re: [osg-users] The naming of VulkanSceneGraph

[Eric Sokolowsky]

Trademark holders *must* defend their trademarks, or they lose them.

On Mon, Jun 25, 2018 at 6:43 PM, Chris Hanson  wrote:

> I think the Vulkan compliance tests (and name usage) only applies to
> implementations OF the Vulkan API. I don't think it applies to software
> USING Vulkan.
>
> I think VulkanSceneGraph is a good and descriptive name, I just don't want
> to see a lot of activity sunk into that name and then have it torpedoed by
> Khronos as I feel might happen.
>
> Trademark holders are notably defensive about their properties, whether we
> like that or not.
>
>
>
> On Mon, Jun 25, 2018 at 12:51 PM Curtis Rubel  wrote:
>
>> Hi,
>>
>>  https://www.khronos.org/vulkan/adopters/
>>
>>  I think this page will alleviate anymore discussion, at
>> least it sounds pretty straight forward to me that as long as
>> VulcanSceneGraph passes their tests it seems OK to use the name.
>> Of course I am no a lawyer either but this text seems to be pretty
>> simple and in laymen's terms.
>>
>> Cheers,
>> Curtis
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=74159#74159
>>
>>
>>
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel  facebook.com/alphapixel (775)
> 623-PIXL [7495]
>
> ___
> 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] [ A Stack Overflow for OSG? ]

[Eric Sokolowsky]

On Mon, Feb 20, 2017 at 4:04 AM, Jan Ciger  wrote:

>
>
> I encourage anyone suggesting that the list moves to some new shiny thing
> XY, because it is better/nicer/more modern/I don't like e-mail/forum/etc to
> consider these issues in the future. You are getting free support, so
> making the life easier for the project leads like Robert is probably the
> least they can ask for in exchange.
>
>
If I could upvote this response I would. :) As much as I like
StackOverflow, it is not the answer for OSG. Making life easier for the
developers (especially Robert) is paramount for this project.

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

Re: [osg-users] [A little bit off topic] A simple graphics library

[Eric Sokolowsky]

You might also find this page useful:
https://www.opengl.org/wiki/Related_toolkits_and_APIs


On Mon, Nov 14, 2016 at 5:55 AM, Nickolai Medvedev 
wrote:

> Hi, Andrew.
>
> You can try one of this:
>
> GLFW
> SFML
> http://www.dhpoware.com/source/gl3framework.html
> OGLPlus
> http://openframeworks.cc
>
>
> if you are interested in development of games:
>
> http://softpixelengine.sourceforge.net
> https://www.game-coder.de/page/pixellight
> http://www.maratis3d.org
>
>
> Good luck!
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=69357#69357
>
>
>
>
>
> ___
> 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] OpenSceneGrah-3.4.0 release candidate 4 tagged

[Eric Sokolowsky]

Hi Robert,

I'm away from my office at the moment, but I plan to test the latest beta
with my project next week when I return (probably be able to test Monday or
Tuesday. If you want to wait for my feedback before you proceed that would
be helpful.

Eric

On Mon, Jul 20, 2015 at 9:43 AM, Robert Osfield 
wrote:

> Hi Dizl,
>
> Thanks for the testing and clarification.  I have checked the
> following into OSG svn/trunk and OSG-3.4 branch.  The next 3.4.0-rc
> will have this fix.
>
> Cheers,
> Robert.
>
> On 20 July 2015 at 08:37, DizL  wrote:
> > oops,
> >
> > #if defined(WIN32) && !defined(__MINGW32__) && (!defined(_MSC_VER) ||
> > _MSC_VER<=1600)
> > inline int isfinite( double x ) { return _finite( x ); }
> > inline int isinf( double x ) { return !_finite( x ) && !_isnan( x ); }
> > #endif
> >
> > should be 1700 instead of 1600
> > (in last post '=' was lost)
> >
> > regards,
> > DizL
> >
> >
> > ___
> > 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] Texture2D subload woes

[Eric Sokolowsky]

I subclassed Texture2D and implemented apply(), and it now works very well,
without duplicating code. I'm not sure if there's a better solution but I'm
happy with this one.

Eric

On Fri, Mar 6, 2015 at 3:52 PM, Eric Sokolowsky  wrote:

> Hi Robert,
>
> I am using that function to get the image from the texture in my custom
> subload callback. The problem is how or when do I call that? It must be in
> the draw thread, so that's why I was using a subload callback, but I no
> longer want to override the default processing found in Texture2D::apply(),
> so I don't want to use a subload callback any more.
>
> Eric
>
> On Fri, Mar 6, 2015 at 3:45 PM, Robert Osfield 
> wrote:
>
>> Hi Eric,
>>
>> It's a long time since I looked at the subload callback.  Having the load
>> and subload methods available in osg::Texture2D seems like a sensible
>> option.
>>
>> However, it might be that you don't need the callback at all.  Have you
>> looked at the osg::Image::Image::readImageFromCurrentTexture(..) method?
>>
>> Robert.
>>
>>
>> On 6 March 2015 at 19:50, Eric Sokolowsky  wrote:
>>
>>> I have need for some custom code to run after the
>>> Texture2D::applyTexImage2D_subload function is called. (I am reading back
>>> the image from OpenGL, which might have been compressed by the graphics
>>> card, and saving it to disk.) So I have been using a subloadCallback to put
>>> the custom code in place. This works, but I don't require any custom code
>>> for the Texture2D::applyTexImage2D_load function. But since the
>>> subloadCallback requires me to implement both the load and the subload I
>>> must do both. But I can't replicate the code in Texture2D::apply in my
>>> subloadCallback because there are lots of mutable members in Texture2D and
>>> getting them from the subloadCallback doesn't make them mutable for me, so
>>> I get lots of errors of losing constness and qualifiers if I try this path.
>>>
>>> So I am wondering how best to proceed from here. Should I derive a class
>>> from Texture2D so I can intercept calls to apply(), then call the base
>>> class version and do my custom processing from there, or can we add a hook
>>> to call a custom callback after the Texture2D::applyTexImage2D_load and/or
>>> the Texture2D::applyTexImage2D_subload functions?
>>>
>>> Or is there a better way to read the texture back from the graphics card
>>> that is independent of the Texture2D::apply function? Of course this will
>>> need to be done in the draw thread.
>>>
>>> Any help will be appreciated..
>>>
>>> Eric
>>>
>>> ___
>>> 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] Texture2D subload woes

[Eric Sokolowsky]

Hi Robert,

I am using that function to get the image from the texture in my custom
subload callback. The problem is how or when do I call that? It must be in
the draw thread, so that's why I was using a subload callback, but I no
longer want to override the default processing found in Texture2D::apply(),
so I don't want to use a subload callback any more.

Eric

On Fri, Mar 6, 2015 at 3:45 PM, Robert Osfield 
wrote:

> Hi Eric,
>
> It's a long time since I looked at the subload callback.  Having the load
> and subload methods available in osg::Texture2D seems like a sensible
> option.
>
> However, it might be that you don't need the callback at all.  Have you
> looked at the osg::Image::Image::readImageFromCurrentTexture(..) method?
>
> Robert.
>
>
> On 6 March 2015 at 19:50, Eric Sokolowsky  wrote:
>
>> I have need for some custom code to run after the
>> Texture2D::applyTexImage2D_subload function is called. (I am reading back
>> the image from OpenGL, which might have been compressed by the graphics
>> card, and saving it to disk.) So I have been using a subloadCallback to put
>> the custom code in place. This works, but I don't require any custom code
>> for the Texture2D::applyTexImage2D_load function. But since the
>> subloadCallback requires me to implement both the load and the subload I
>> must do both. But I can't replicate the code in Texture2D::apply in my
>> subloadCallback because there are lots of mutable members in Texture2D and
>> getting them from the subloadCallback doesn't make them mutable for me, so
>> I get lots of errors of losing constness and qualifiers if I try this path.
>>
>> So I am wondering how best to proceed from here. Should I derive a class
>> from Texture2D so I can intercept calls to apply(), then call the base
>> class version and do my custom processing from there, or can we add a hook
>> to call a custom callback after the Texture2D::applyTexImage2D_load and/or
>> the Texture2D::applyTexImage2D_subload functions?
>>
>> Or is there a better way to read the texture back from the graphics card
>> that is independent of the Texture2D::apply function? Of course this will
>> need to be done in the draw thread.
>>
>> Any help will be appreciated..
>>
>> Eric
>>
>> ___
>> 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] Texture2D subload woes

[Eric Sokolowsky]

I have need for some custom code to run after the
Texture2D::applyTexImage2D_subload function is called. (I am reading back
the image from OpenGL, which might have been compressed by the graphics
card, and saving it to disk.) So I have been using a subloadCallback to put
the custom code in place. This works, but I don't require any custom code
for the Texture2D::applyTexImage2D_load function. But since the
subloadCallback requires me to implement both the load and the subload I
must do both. But I can't replicate the code in Texture2D::apply in my
subloadCallback because there are lots of mutable members in Texture2D and
getting them from the subloadCallback doesn't make them mutable for me, so
I get lots of errors of losing constness and qualifiers if I try this path.

So I am wondering how best to proceed from here. Should I derive a class
from Texture2D so I can intercept calls to apply(), then call the base
class version and do my custom processing from there, or can we add a hook
to call a custom callback after the Texture2D::applyTexImage2D_load and/or
the Texture2D::applyTexImage2D_subload functions?

Or is there a better way to read the texture back from the graphics card
that is independent of the Texture2D::apply function? Of course this will
need to be done in the draw thread.

Any help will be appreciated..

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

Re: [osg-users] Does OSG support reading RGB8/RGBA8 PNG image data?

[Eric Sokolowsky]

On Wed, Dec 10, 2014 at 9:32 AM, Robert Osfield 
wrote:

>
>
>>
>> My final objective is if my texture sizes are less I should have more
>> texture memory available in graphics memory to load additional textures.
>> And i am trying to verify whether OSG loads OpenGL with actual texture size
>> (in my case RGBA8) or uses always RGB/RGBA format only. The display anyway
>> will not be affected but unnecessary texture memory will be allocated I
>> guess. The discussion above is on OSG with OpenGL & not OSG with OpenGL ES.
>> I am using OSG for our Simulation research & I do not doubt its
>> capabilities. But since I am neither a novice nor a full expert in OSG I
>> came across above doubts that someone in forum can answer/reply.
>
>
> If you want to minimize the texture object size on the GPU then you should
> use OpenGL compressed textures.
>
> Robert.
>

This advice from Robert is spot on. You will achieve 8x or 16x savings by
using OpenGL compressed textures rather than standard 32-bit RGBA in your
.ive files. You don't achieve any savings in .ive by converting to 8-bit
PNG because OSG unpacks all such images to 32-bit RGBA before storing in
memory (since 8-bit PNG is not a format the graphics card understands).

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

[osg-users] Old Developer releases

[Eric Sokolowsky]

I see that most of the older developer releases are located at
http://trac.openscenegraph.org/downloads/developer_releases/, but the
OpenSceneGraph-2.8.5.zip is not located there. Is this an oversight? It
would be really nice if that were put back up there.

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

Re: [osg-users] How change the vertical sync?

[Eric Sokolowsky]

If you have an Nvidia card, you can set the environment variable
__GL_SYNC_TO_VBLANK=1 or =0 to enable or disable vertical syncing, but this
must be done before the graphics context is initialized. I'm not sure how
to do it for ATI or Intel chips. A google search turned up this tip for ATI
cards: http://www.stolk.org/debian/vblank-fglrx.html (I haven't tried it
though).


On Tue, Oct 15, 2013 at 11:08 AM, Julio Jerez  wrote:

> In my app I wrote this class function
>
> ** **
>
> void InitWindowsSystem (osgViewer::Viewer& viewer, const char* const title,
> int x, int y, int width, int height)
>
> {
>
>   viewer.setUpViewInWindow(x, y, width, height);
>
> ** **
>
>   //Get the traits of the current window
>
>   osg::ref_ptr< osg::GraphicsContext::Traits > traits = new osg::
> GraphicsContext::Traits( *viewer.getCamera()->getGraphicsContext()->
> getTraits());
>
> ** **
>
>   //Set the title
>
>   traits->windowName = title;
>
> ** **
>
>   // disable vertical sync
>
>   traits->vsync = false;
>
> ** **
>
>   //Create a new graphics context with the modified traits
>
>   osg::ref_ptr< osg::GraphicsContext > gc = osg::GraphicsContext::
> createGraphicsContext( traits.get() );
>
> ** **
>
> //test to see if vsync has changed, but vsyn is alway true
>
> osg::ref_ptr< osg::GraphicsContext::Traits > traits1 = new osg::
> GraphicsContext::Traits( *viewer.getCamera()->getGraphicsContext()->
> getTraits());
>
> ** **
>
> ** **
>
> I have searched on forum for a way to do this but no one seem to have a
> clear way.
>
> can someone tell me how to do this, pleases?
>
> ** **
>
> Julio 
>
> ** **
>
> ** **
>
> ** **
>
> ___
> 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] Flexibility of osgPango vs osgText

[Eric Sokolowsky]

Hello all,

Until now I have been using osgText for rendering text to the screen, which
has been working fairly well for the most part. However, I have found that
I need more sophisticated text rendering, such as having certain words in
bold or italicized that are in line with the regular text. Is this possible
to do with the baseline osgText? Will osgPango do this better/easier? I
want to be able to measure the pixel size of text rendering after I
generate it, so I can make it bigger or smaller to fit the area of the
screen I'm targeting. I'm using the SourceSansPro series of fonts in my
application, and there are different font files for each style (Italics,
Bold, etc.)

Thanks for any direction you can provide.

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

Re: [osg-users] Make a text scroller

[Eric Sokolowsky]

I use a osgText::Text object, put the text into it with all the appropriate
attributes. I put the osgText::Text under an osg::Geode with addDrawable().
I put the geode under an osg::MatrixTransform (I believe it may have
changed name in the latest version of OSG) with addChild(). Then I use a
osg::Projection and put the transform under that. Then you can change the
position of the object by calling text->setPosition().


On Fri, Aug 30, 2013 at 6:35 AM, Sebastien le Goff wrote:

> Hi,
>
> I'm looking for a way to create a text scroller. My pb is that I can move
> dynamicaly the TextBaseElement using a positionAttittudTransform by I can't
> hide the top or the bottom of the Element
>
> Have you got some tips ?
>
> Thank you!
>
> Cheers,
> sebastien
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=56033#56033
>
>
>
>
>
> ___
> 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] Modern OSG vs. OSG 2.8.5; also a question about word splitting in osgText

[Eric Sokolowsky]

Thanks Robert. I'll spend some time getting the newest OSG working here,
and then try applying my patch, and submit it for your perusal.

Eric


On Mon, Jun 3, 2013 at 7:26 AM, Robert Osfield wrote:

> Hi Eric,
>
> On 3 June 2013 11:42, Eric Sokolowsky  wrote:
> > I have been an active contributor to OSG in the past but have not kept up
> > with recent developments. I have an application that uses OSG 2.8.5
> mostly
> > unmodified except for one patch that changes the way osgText breaks up
> > words. I am wondering how easy it is generally to port programs forward
> from
> > OSG 2.8.5 to the current release (appears to be 3.0.1, at least that is
> what
> > is available by default in Fedora 17).
>
> Mostly it should be just a re-compile.  The main changes were
> additions that won't require changes to most applications that use the
> OSG.
>
> > I am of course willing to submit the changes I made to the word
> splitting in
> > OSG, but how accepted will that be to the community? With the default
> word
> > splitting, I was seeing things like:
> >
> > Large numbers split in the middle: "1,000\n,000,000" (The \n is where the
> > line split occurred)
> > Punctuation shown at the beginning of the next line instead of at the
> end of
> > a line: "This is the end\n. This is another sentence."
> > Date/time split in strange places: "15:27\n:12"
> >
> > My new rules make the only splitting points at spaces and at hyphens
> > (leaving the hyphen at the end of the line). If others depend on the
> current
> > line-splitting method, I can create a patch that would allow the user to
> > choose which method to use.
>
> It's hard to know without seeing the submission, feel free to submit
> and I can then have a think.  We also have a TextNode implementation
> in the works that allows custom control of layout among other elements
> so it might be a good place for the custom work.
>
> 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

[osg-users] Modern OSG vs. OSG 2.8.5; also a question about word splitting in osgText

[Eric Sokolowsky]

Hello all,

I have been an active contributor to OSG in the past but have not kept up
with recent developments. I have an application that uses OSG 2.8.5 mostly
unmodified except for one patch that changes the way osgText breaks up
words. I am wondering how easy it is generally to port programs forward
from OSG 2.8.5 to the current release (appears to be 3.0.1, at least that
is what is available by default in Fedora 17).

I am of course willing to submit the changes I made to the word splitting
in OSG, but how accepted will that be to the community? With the default
word splitting, I was seeing things like:

Large numbers split in the middle: "1,000\n,000,000" (The \n is where the
line split occurred)
Punctuation shown at the beginning of the next line instead of at the end
of a line: "This is the end\n. This is another sentence."
Date/time split in strange places: "15:27\n:12"

My new rules make the only splitting points at spaces and at hyphens
(leaving the hyphen at the end of the line). If others depend on the
current line-splitting method, I can create a patch that would allow the
user to choose which method to use.

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

[osg-users] dds plugin for OSG

[Eric Sokolowsky]

Hello OSG users,

It seems as if the dds plugin reads in images upside down. Am I the only
one to see this? When I use ImageMagick's "display" the images I'm loading
are displayed with the proper orientation. These are compressed dds images.
I'm not sure what else to try in order to see if it's OSG that is doing
things wrong. I'm running on Linux and see the same behavior on Centos 5
and Fedora 14. I'm running OSG 2.8.5; perhaps this is fixed in 3.0 or later?

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

Re: [osg-users] Linux: Compile nvtt with cuda

[Eric Sokolowsky]

I also tried this. I finally got nvtt working with cuda, but some of the
files produced by the tool didn't work in one of my OSG applications (but
it did work with another, simpler OSG application). I didn't have time to
dig and find out what the problem was, so now I just use the nvtt without
cuda and run it on our render farm.

On Thu, Jul 19, 2012 at 3:10 PM, Torben Dannhauer wrote:

> Hi,
>
> No finally I faileds to set NVTT+Cuda working. It compiled but never run.
> So finally I skipped this feature, but it is still written down in the
> osgVisual tutorial I wrote.
>
>
> Cheers,
> Torben
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=48929#48929
>
>
>
>
>
> ___
> 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] OpenScenegraph Siggraph 2012 BOF Final Call for Presentations

[Eric Sokolowsky]

I'm interested in giving a very short (probably no more than 5-10 minutes)
presentation on the work I do with OSG. I wrote an OSG application many
years ago and still use it, but now I use it primarily on a display wall in
my work at NASA. I run one instance of my application on each screen to
show very large animations on either a 3x3 or a 5x3 display wall.

I am also interested in consulting opportunities for OSG particularly, but
also graphics and computer programming in general. At one time I was quite
active on the OSG mailing lists and have contributed many enhancements and
fixes, and want to get back into this arena once more.

Eric

On Mon, Jul 23, 2012 at 8:22 PM, John Richardson
wrote:

> Greetings and Salutations,
>
>
>
> There is ONE 15 minute slot left. The DEADLINE is 27 July 2012 to claim the
> slot. After that I will give the other presenters 5 more minutes or plan a
> panel at the end. I need to plan the final agenda.
>
>
>
> The OpenScenegraph Siggraph 2012 BOF will be held in the Los Angeles
> Convention Center on 8 August 2012 at 10AM.
>
> Highlight your work.
> Show off your institution.
> Hawk your consulting skills.
>
> As long as it is OSG related. Step up now and be virtual.
>
>
> John F. Richardson
>
> ___
> 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] OT: User GUI toolkit

[Eric Sokolowsky]

My application uses FLTK 1.1, but I'm about to try 1.3 as it has some
improvements I've been waiting for. Integration is pretty easy, especially
on Linux. Windows and OSX have some additional rules (only draw FLTK windows
in main thread; OSG can use other threads) but it's not too bad.

Eric

On Tue, Nov 23, 2010 at 11:52 AM, Jeremy Moles wrote:

> On Mon, 2010-11-22 at 18:31 +0100, Anders Backman wrote:
> > Old as,... I don't know. But this question pops up now and then.
>
> This will hopefully--eventually--be solved by osgWidget/osgWidget(2).
> Unfortunately, right in the middle of my passionate development I had
> some serious medical issues, and as I recover I spend the majority of my
> free coding time doing various, small paid OSG projects.
>
> I haven't forgot about this huge gap in OSG, and I really want to tackle
> it as soon as I can. In the meantime, you could adapt current osgWidget,
> or perhaps someone else will have advice.
>
> At any rate, some of the components necessary to REALLY make an
> incredible GUI toolkit (vector drawing and good text layout support,
> osgCairo/osgPango) are really coming along. :)
>
> > Assume you need a OpenGL based SDK, lean (in terms of dependencies)
> > gui, for In-graphics GUI, multiplatform.
> > With basic support for sliders, buttons, text, windows.
> >
> >
> > What do people use?
> > Is it QT for everything (with their OpenGL based widgets), is it FLTK?
> > wxWidgets? Seems that most of the small, OpenGL based stuff are mostly
> > stalled in development.
> > Some are integrating Java (JOGL)...
> >
> >
> > Really curious to see what people use, perhaps there are some new
> > interesting stuff out there?
> >
> > --
> >
> >
> > ___
> > 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] please review: 2.8.5 press release

[Eric Sokolowsky]

I have the .zip file ready, and the Fedora 14 packages ready. Where should I
upload them? I am still working on Centos5 (had a build problem).

Eric

On Fri, Jun 10, 2011 at 4:15 AM, Robert Osfield wrote:

> Hi Paul,
>
> On Fri, Jun 10, 2011 at 12:09 AM, Paul Martz 
> wrote:
> > Hi all -- I've placed a short paragraph at the main OSG wiki home page,
> > which links to the press release here:
> >
> >
> http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8.5?version=1
> >
> > Please review this when you have a second. If you spot any typos, please
> > don't hesitate to edit and fix. Thanks!
>
> Thanks for the putting up the page.  I've just read it and feel that
> the info abou the community size/role is repeated albeit with slightly
> different phrasing.  We could probably combine the paragraphs or just
> cut out the repitition.   Perhaps one tweak would be to quote the
> number of contributors in the paragraph that leads with 2.8.5.
>
> > Robert, I lack permission to edit the Project News page or the Download
> > page, so please update those as time allows.
>
> I'll up date this once I've completed my trawl through my emails.
>
> >  For the Project News page, you
> > could just cut and paste what I've placed on the wiki home page. For the
> > downloads page, you could copy what is already there for 2.8.4, update
> the
> > svn URL, and reference the source zip that Eric S mentioned in a recent
> > post.
>
> Will do.
>
> 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] 2.8.5 release tag

[Eric Sokolowsky]

The first thing to do is update the wiki, and generate the official zip
distribution. I have made a zip file by exporting the subversion tag given,
and I can upload it somewhere if that would help. I'm in the process of
creating rpm files for use on Fedora 14, x86_64. I will also soon make rpm
files for Centos 5, which should also work with Red Hat Enterprise Linux.

I'd be willing to help edit the wiki but alas I have forgotten (again) how
to get access.

Eric

On Mon, Jun 6, 2011 at 9:14 PM, Paul Martz  wrote:

> Hi all -- OSG 2.8.5 is now released. The official svn tag is:
>
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5
>
> Will need to get info on the wiki about this shortly.
>
> Thanks to everyone who pitched in to help test this release! Fingers
> crossed, we didn't introduce too many issues with our changes.
>
> --
>  -Paul Martz  Skew Matrix Software
>   http://www.skew-matrix.com/
> ___
> 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] WWDC 2011

[Eric Sokolowsky]

Hi Eric,

I didn't make it this year (the 12-hour window before it sold out was way
too short!) Perhaps I'll make it next year, but I'm not doing much on my mac
these days (besides running Linux on it).

Eric S.

On Tue, Jun 7, 2011 at 11:45 PM, Eric Wing  wrote:

> Hi all,
> If anybody is at WWDC this year, please drop me a line if you'd like to
> meet up.
>
> Thanks,
> Eric
> --
> Beginning iPhone Games Development
> http://playcontrol.net/iphonegamebook/
> ___
> 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] 2.8.5 release imminent!

[Eric Sokolowsky]

After several hours of testing with my application, I think 2.8.5 is ready
to go. I'm looking forward to its release. I will probably make rpm packages
for Fedora 14 and Centos 5 soon after its release, and I'll make them
available for anyone to try out.

Eric


On Mon, Jun 6, 2011 at 9:18 AM, Eric Sokolowsky  wrote:

> I'm testing my application under the latest svn (2.8 branch); so far it
> appears fine, but I'm going to be testing for a few more hours at least.
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8.5 release imminent!

[Eric Sokolowsky]

I'm testing my application under the latest svn (2.8 branch); so far it 
appears fine, but I'm going to be testing for a few more hours at least.

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

Re: [osg-users] 2.8.5 Call for testing

[Eric Sokolowsky]

I've been testing it with my application without problems, on Fedora 14
Linux x64.

On Fri, May 27, 2011 at 10:47 AM, Paul Martz  wrote:

> Hi all -- I've just tagged 2.8.5 RC1 and would like to request your help in
> testing. You can check out the release candidate from here:
>
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc1
>
> All features are in place at this time, with the one exception of the 3DS
> plugin backport. Assuming that work is complete soon, and there is
> sufficient testing, we should be able to release in the very near future.
>
> Features in 2.8.5:
>
>  * Uniform performance enhancement.
> r11952, Michael Plating's performance enhancement for large numbers of
> uniforms, which effectively eliminates the std::map lookup.
> r11998, Wojciech Lewandowski's backwards compatibility fix for 11952.
> r12074, Chris Hanson's backwards compatibility fix for 11952.
>
>  * Support for Texture2DMultisample
> r11218, changes to Extensions.
> r11229, fix warnings.
> r11365, 2D multisample support.
>
>  * Added new "OutputRelativeTextures" dot OSG plugin export option (not on
> trunk).
>
>  * Enhancements for OcclusionQueryNode.
> r11760 (plus r11472 for OQN.cpp only).
> Support for RTT Camera (not on trunk).
>
>  * osgconv "--use-world-frame" option.
>
>  * NOTIFY_WARN (and friends) macros to ease backporting.
> OSG_NOTIFY_DISABLED CMake variable.
>
>  * FLT plugin update.
> A complete backport of the trunk FLT plugin (as if May 4 2010) to the
> 2.8 branch.
> Includes export fixes for multitexture.
> Includes osgSim MultiSwitch changes in r11971.
>
>  * PNM plugin enhancements:
> r12220, adds support for reading and writing images using streams.
> Bug fixes for reading 8-bit and 16-bit images, including loading the
> images upside-down.
>
>  * Fix issue with linking apps to libdl on Linux systems.
>
>  * osgText fix (r11768) to improve text appearance.
>
>  * Updated osgWrappers for all API changes.
>
>  * Bump version# 2.8.5, SO# 74.
>
>
> Thanks for your help!
>
> --
>  -Paul Martz  Skew Matrix Software
>   http://www.skew-matrix.com/
> ___
> 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] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

Robert,

I tested your changes and I could not get it to crash, so it looks 
squashed to me. Thanks!


Eric

Robert Osfield wrote:

Hi Eric et. al,

I have now reverted the problematic part the r12294 that original
moved the check for close events from the swapBuffersImplementation to
checkEvents, this caused problems because the check was being done on
the _display member variable that is X11 Display connection setup for
access from the graphics thread only.

Could you please do an svn update and let me know how you get on.

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] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

Robert Osfield wrote:

Hi All,

I'm just doing a code review from before and after the r12294 rev and
it looks like the move of the code from a method being called in the
graphics thread GraphicsWindowX11::swapBufferImplentation() to on
being called from the main thread GraphcisWindowX11::checkEvents()
without the display being changed from the one used for the graphics
thread to the one used for events.  If I am correct then it should be
a simple fix of just replacing the _display variable usage to the
local display variable.

I will test in the svn/trunk configuration and then with my suggested
change.  Will update you all soon on how I get on.

  


I think this is getting close to the problem. I have further narrowed 
the problem to the last section of differences in GraphicsWindowX11.cpp  
between r12293 and r12294 (I applied all the other parts of the 
difference and there is no problem). If I comment out the second while( 
XPending(_display) ) loop (see around line 1467) there is no crash. Is 
the _display variable changed in the first loop?


I also tried putting a sleep(1) call just above line 1467 the first time 
the function is run and now I can not get it to crash, further 
suggesting a race condition that the loop is triggering.


Eric

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

Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

Here's some more information about the problem. I have narrowed it down 
to the patch r12294. Before this change I cannot get osgviewer to fail, 
but after this patch it is very easy to get osgviewer to fail. Something 
there caused the timing instability we are seeing. I'm going to 
investigate further but if there are others who want to look at it too 
you are welcome.


Eric

J.P. Delport wrote:

Hi Eric,

some info in this recent thread too.

http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/

jp

On 26/05/11 18:14, Eric Sokolowsky wrote:

Robert Osfield wrote:

Hi Eric,

On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky 
wrote:

Yes, this is what I mean. X11 itself crashes and restarts. One of the
weird
issues is that this happens only for OSG trunk, not for OSG 2.8 svn,
on the
same machine. Perhaps there is some OpenGL3+ weirdness going on here.


I doubt it has anything to do with GL3 as the svn/trunk doesn't do
anything special
for GL3 unless you compile the OSG specifically for the GL3 subset.


Ok, thanks for the info.


There have been a few changes to GraphisWindowX11.cpp since 2.8.x so
you revert these to see if
one of the changesets is the culprit. It could be just a co-incidence
though, sometimes threading
problems can appear and disappear just with slight changes in timing.
I'm afraid I'll have to leave it
to you to try out different versions of GraphicsWindowX11.cpp as I
can't reproduce the problem at
my end so have no way of know which changes might be introducing
problems.


Well I'm making some progress. After updating my nvidia driver X11 no
longer crashes, but osgviewer still does. I'm going to try this on
another mac machine also running Fedora 14. Anyone else using Fedora 14
out there? I'll try messing with GraphicsWindowX11.cpp next.

Eric
___
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] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

J.P. Delport wrote:

Hi Eric,

some info in this recent thread too.

http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/

jp
Thanks for the pointer. I must have skipped over that thread. The 
problem described there looks like what is happening to me (I'm glad I'm 
not the only one!) Following Robert's suggestion to look into changes 
made to GraphicsWindowX11.cpp, I reverted back to r12292 and everything 
seems to work reliably, and now I'm working forward. There were a pretty 
major couple of changes r12293 and r12294 and that's what I suspect 
caused the problem. The only other change to this file after then was 
r12339.


I saw the discussion of making the viewer single-threaded, which of 
course is not a long-term solution. Did anyone find anything in their 
digging?


Eric



On 26/05/11 18:14, Eric Sokolowsky wrote:

Robert Osfield wrote:

Hi Eric,

On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky 
wrote:

Yes, this is what I mean. X11 itself crashes and restarts. One of the
weird
issues is that this happens only for OSG trunk, not for OSG 2.8 svn,
on the
same machine. Perhaps there is some OpenGL3+ weirdness going on here.


I doubt it has anything to do with GL3 as the svn/trunk doesn't do
anything special
for GL3 unless you compile the OSG specifically for the GL3 subset.


Ok, thanks for the info.


There have been a few changes to GraphisWindowX11.cpp since 2.8.x so
you revert these to see if
one of the changesets is the culprit. It could be just a co-incidence
though, sometimes threading
problems can appear and disappear just with slight changes in timing.
I'm afraid I'll have to leave it
to you to try out different versions of GraphicsWindowX11.cpp as I
can't reproduce the problem at
my end so have no way of know which changes might be introducing
problems.


Well I'm making some progress. After updating my nvidia driver X11 no
longer crashes, but osgviewer still does. I'm going to try this on
another mac machine also running Fedora 14. Anyone else using Fedora 14
out there? I'll try messing with GraphicsWindowX11.cpp next.

Eric
___
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] Unicode text with osg

[Eric Sokolowsky]

Farshid Lashkari wrote:

Hi Eric

On Thu, May 26, 2011 at 7:07 AM, Eric Sokolowsky <mailto:esok@gmail.com>> wrote:


Is it possible to use international text (probably unicode) with
osgText? I just get garbled characters when I use my application
which uses osgText for the text. When using vi or other text
editors I can see the international characters normally. I am
using OSG 2.8.3 primarily.


Are you specifying the correct encoding type when setting the string 
on the osgText object? I am able to display Unicode characters fine on 
Windows using UTF-8 encoding. I haven't tried other encodings though.

Farshid,

Thank you! This was the problem. I was using the regular setText() with 
one argument, and not the proper setText() with two arguments, the 
second being the encoding. I have changed my code and it now works as 
expected.


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

Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

Robert Osfield wrote:

Hi Eric,

On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky  wrote:
  

Yes, this is what I mean. X11 itself crashes and restarts. One of the weird
issues is that this happens only for OSG trunk, not for OSG 2.8 svn, on the
same machine. Perhaps there is some OpenGL3+ weirdness going on here.



I doubt it has anything to do with GL3 as the svn/trunk doesn't do
anything special
for GL3 unless you compile the OSG specifically for the GL3 subset.

  

Ok, thanks for the info.


There have been a few changes to GraphisWindowX11.cpp since 2.8.x so
you revert these to see if
one of the changesets is the culprit.  It could be just a co-incidence
though, sometimes threading
problems can appear and disappear just with slight changes in timing.
I'm afraid I'll have to leave it
to you to try out different versions of GraphicsWindowX11.cpp as I
can't reproduce the problem at
my end so have no way of know which changes might be introducing problems.

  
Well I'm making some progress. After updating my nvidia driver X11 no 
longer crashes, but osgviewer still does. I'm going to try this on 
another mac machine also running Fedora 14. Anyone else using Fedora 14 
out there? I'll try messing with GraphicsWindowX11.cpp next.


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

Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

Robert Osfield wrote:

Hi Eric,

Others including myself has see X11/GLX related errors on start up of
apps, but I haven't had X11 crash and restart, I presume you mean
though whole X11 desktop crashes and restarts rather than just an OSG
app,

  


Yes, this is what I mean. X11 itself crashes and restarts. One of the 
weird issues is that this happens only for OSG trunk, not for OSG 2.8 
svn, on the same machine. Perhaps there is some OpenGL3+ weirdness going 
on here.



For point of reference he's the details of my system - later driver
and kernal than you have.

$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  270.41.06  Mon Apr 18
14:53:56 PDT 2011
GCC version:  gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

$  uname -r
2.6.38-8-generic

Robert.
  


Thanks for this data point. I'll try a later driver.

Eric

On Thu, May 26, 2011 at 3:52 PM, Eric Sokolowsky  wrote:
  

I'm running OSG under Linux, specifically Fedora 14 on MacBook Pro hardware.
I am having trouble running anything with the latest OSG trunk svn.
Symptoms: X11 crashes and restarts. Since others are not reporting the same
issue, I'm presuming that my nvidia driver is buggy. What version(s) of the
nvidia driver are others running? It can be found by typing:

 cat /proc/driver/nvidia/version

Here is mine:

escher:esokolow:~$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  256.53  Fri Aug 27 20:27:48
PDT 2010
GCC version:  gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)

escher:esokolow:~$ uname -r
2.6.35.6-37.fc14.x86_64


What crashes:
osgviewer --image whatever.png

Thanks,

Eric
___
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] OSG trunk crashing, perhaps an nvidia driver problem?

[Eric Sokolowsky]

I'm running OSG under Linux, specifically Fedora 14 on MacBook Pro 
hardware. I am having trouble running anything with the latest OSG trunk 
svn. Symptoms: X11 crashes and restarts. Since others are not reporting 
the same issue, I'm presuming that my nvidia driver is buggy. What 
version(s) of the nvidia driver are others running? It can be found by 
typing:


 cat /proc/driver/nvidia/version

Here is mine:

escher:esokolow:~$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  256.53  Fri Aug 27 
20:27:48 PDT 2010

GCC version:  gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)

escher:esokolow:~$ uname -r
2.6.35.6-37.fc14.x86_64


What crashes:
osgviewer --image whatever.png

Thanks,

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

[osg-users] Unicode text with osg

[Eric Sokolowsky]

Hello OSG users,

Is it possible to use international text (probably unicode) with 
osgText? I just get garbled characters when I use my application which 
uses osgText for the text. When using vi or other text editors I can see 
the international characters normally. I am using OSG 2.8.3 primarily.


Linux Fedora 14 running on 2008 15" Mac Book Pro
nVidia GeForce 8600M GT
nVidia driver 256.53

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

Re: [osg-users] Backporting help from trunk to 2.8.x, osg::State::drawQuads and osg::State::color

[Eric Sokolowsky]

Paul Martz wrote:

On 5/23/2011 12:56 PM, Eric Sokolowsky wrote:

Hello OSG users,

I'm attempting to backport a patch made in osg trunk (specifically 
r11768 that
fixes some text clipping problems using osgText), and the official 
trunk patch

calls two functions that seem to be not yet present in 2.8.

It seems that the call to osg::State::Color() can be replaced by a 
call to

glColor4f().

Is there an equivalent to osg::State::drawQuads()? How was this done 
before?


Any pointers or help would be greatly appreciated. Thanks.


Possibly you could take the trunk source function bodies, and put them 
in 2.8 osgText instead of in State, thereby having the functionality 
available to osgText, but not impacting core OSG.

   -Paul



Yes, that is a good idea. I'll look into that next. I hope it doesn't 
pull in too much.


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

Re: [osg-users] OSG image representation in memory

[Eric Sokolowsky]

Farshid Lashkari wrote:

Hi Eric,

On Mon, May 23, 2011 at 11:46 AM, Eric Sokolowsky <mailto:esok@gmail.com>> wrote:


How are OSG images stored in memory, top row first or bottom row
first (in memory order)? Thanks.


Every image loader I have used places the bottom row first.



Thank you! This explains my problem.

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

[osg-users] Backporting help from trunk to 2.8.x, osg::State::drawQuads and osg::State::color

[Eric Sokolowsky]

Hello OSG users,

I'm attempting to backport a patch made in osg trunk (specifically 
r11768 that fixes some text clipping problems using osgText), and the 
official trunk patch calls two functions that seem to be not yet present 
in 2.8.


It seems that the call to osg::State::Color() can be replaced by a call 
to glColor4f().


Is there an equivalent to osg::State::drawQuads()? How was this done before?

Any pointers or help would be greatly appreciated. Thanks.

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

[osg-users] OSG image representation in memory

[Eric Sokolowsky]

Hello OSG users,

How are OSG images stored in memory, top row first or bottom row first 
(in memory order)? Thanks.


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

[osg-users] Reading OSG images from streams?

[Eric Sokolowsky]

I was perusing the source code and was surprised to see that in
osgDB/ReaderWriter there are stub functions for reading images from streams
but that they are all disabled, returning
ReadResult(ReadResult::NOT_IMPLEMENTED). Is it the case that nobody has
needed this functionality yet, or are there other technical reasons for
this? I am interested in reading image streams over the network using
sockets, and to do that I'll probably create a class that will derive from
std::streambuf to read information over sockets. Is anyone else doing this
sort of thing?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Image brightness using osg::DrawPixels and polygon texture rendering

[Eric Sokolowsky]

On Wed, Feb 16, 2011 at 4:12 PM, Chuck Seberino wrote:

> You should look at your TexEnv parameters.  Use something like DECAL or
> REPLACE.  Looks like you are using the default, which is MODULATE, which
> takes into account the color of the polygon with the texture.  Of course
> these modes (DECAL,REPLACE) will disable any lighting that is going on, but
> you seem to want that anyway.
>


Chuck,

Thank you! This is what I was missing. I used REPLACE mode and now the
textured version is the same brightness as the DrawPixels version. You are
right in that I don't need any lighting. Thanks again!

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

[osg-users] RPM packages for OSG 2.8.3 under Red Hat Enterprise Linux 5

[Eric Sokolowsky]

All,

I have been out of the loop as far as OSG development goes for a good while
now. However, I have made RPM packages for RHEL5 if they would be useful to
anyone. I also anticipate making packages for openSUSE 11.3 in the near
future. Robert, where can I upload them?

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

[Eric Sokolowsky]

Did these changes make it into the 2.8.3 stable release? If not I'd like to
get them into the stable branch for the next release.


On Fri, Mar 26, 2010 at 7:15 AM, Stephan Maximilian Huber <
ratzf...@digitalmind.de> wrote:

> Hi,
>
> Am 26.03.10 14:22, schrieb 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.
>
> I forgot in my first mail to attach the cmake-file specific for
> OpenThreads, so this should be fixed now.
>
> There was another bad default-value for the install_name_dir which I fixed.
>
> The frameworks and plugins compiled via cmake work with my own code
> without problems.
>
> I packaged all modified files together and sent them to osg.submissions
> for inclusion.
>
> So hopefully, we can move the old xcode-project-files into the
> deprecated branch :)
>
> thanks to all who helped!
>
> 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] OpenGL capture/logging in OSG

[Eric Sokolowsky]

Paul,

I am interested in this work. I seem to recall we talked about this a bit
last Siggraph, during the OpenGL BOF. I think Don's GL Debugging code is a
good place to start. I'm also willing to help.

-Eric

On Mon, Dec 14, 2009 at 3:06 PM, Paul Martz  wrote:

> Hi Robert --
>
>
> Robert Osfield wrote:
>
>> Having a single class is not extensible by end users - something which
>> is essential for authors of external NodeKits.
>>
>
> It's not a requirement that external source use the new interface for
> calling OpenGL. If they don't use it, code will still function properly, but
> there will be no logging or other instrumentation of their code's OpenGL
> calls.
>
> This is analogous to how OSG's plugin documentation feature works. External
> code that doesn't use the feature is still able to load files, but doing an
> "osgconv --format" for that plugin displays no information. But I don't
> think anyone would say that the plugin documentation feature is "not
> extensible".
>
> This new capability should be very extensible in that, if you needed to log
> calls into a new OpenGL feature or extension not currently in OSG's OpenGL
> class, it would be as easy as dropping in the enum defs and function
> signatures and rebuilding OSG.
>
>
>  Using an optional compile between macro's/inline functions and the
>> modified versions to avoid performance degradation will lead to binary
>> in-compatibility between the code with diagnostics and one without.
>>
>
> Binary compatibility is not an issue. Developers will never turn on
> instrumentation in production code. It'll only be used during development,
> where binary compatibility isn't needed.
>
>
>  I don't know if this might help, but Don Burns wrote a parser of the
>> gl.h to automatically produce a wrapper library that allowed you that
>> calls GL for you, and you just link to the Don's OglDump library.  For
>> more details:
>>
>>   http://www.andesengineering.com/OglDump/ogldump.html
>>
>> It's written for unix, using lex/yacc, so one would need to do some
>> more work to get it working under Windows, but it might give one a leg
>> up.
>>
>
> Thanks for the pointer. If I'm already going to look at the Linux-centric
> BuGLe, then I could give this a shot too. (Lex and yacc, wow, I used to know
> how to use those back in 1986...)
>   -Paul
>
>
>
> ___
> 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] is the osg inventor loader broken?

[Eric Sokolowsky]

I tried out the file below, and I can confirm all of John's results. Since I
use SGI's Inventor instead of Coin, it appears that the bug is in the
Inventor plugin, and not Coin. I wonder if it's a problem with 64-bit
builds? I have been using Centos 5.2/5.3 on a 64-bit machine for a while
now, and my previous use of Inventor was probably on our old 32-bit
machines.

-Eric

On Fri, Oct 9, 2009 at 3:12 PM, John Kelso  wrote:

> Hi,
>
> We're running 2.8.2 on a 64-bit Centos system.  OSG was configured to use
> Coin-3.1.1.
>
> Not too long ago I ran an old demo using the new releases and noticed that
> an Inventor file that used to load properly no longer did.  Checking
> around,
> many others also didn't.
>
> Here's a simple example file that demonstrates the problem:
>
>  #Inventor V2.0 ascii
>  Material { diffuseColor 1 0 0 }
>  Cone { bottomRadius 1 height 2 }
>
>  Rotation { rotation 1 0 0 3.14159 }
>  Material { diffuseColor 0 1 0  }
>  Cone { bottomRadius 1 height 2 }
>
> If you look at this with ivview, also linked with Coin-3.1.1, you see two
> intersecting cones, red on the bottom and green on the top.
>
> If you load this same file with osgviewer you just see the red cone.
>
> If you use osgconv to create an osg file from the iv file you see both
> cones
> in the osg file with identical vertex data and the green one isn't rotated.
> I'm surprised I don't see any z-fighting in osgviewer.
>
> Anyway, can anyone else try loading this Inventor file and see if it works
> for them?
>
> Many thanks,
>
> John
>
>
>
> ___
> 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] 0bit Stencil Buffer

[Eric Sokolowsky]

Mathias Buhr wrote:
> Hi everyone,
> 
> I'm trying to use the stencil buffer to render only parts of the final
> image through other graph-attached cameras. The app works fine on ATI
> hardware but NVIDIA fails. OpenGL reports that the stencil buffer has
> only 0 bits (which is 8 bits on ATI, via
> glGetInterv(GL_STENCIL_BUFFER_BITS) in a DrawCallback). I have tested
> this on various linux boxes (Ubuntu 9.04, Fedora 11) with recent
> hardware and recent drivers.
> I'm pretty sure that a stencil buffer is available on this hardware
> because OSG seems to be able to utilize it (stereo-mode in
> osgUtil::SceneView uses stenciling and works fine). I'm pretty sure I've
> missed something. Is there anything special to do to get or enable a
> stencil buffer on Nvidia?

My OSG application uses a stencil buffer on Nvidia hardware, so it is
definitely possible. There should be a mechanism (depending on how you
create your context) to request a stencil-buffer-enabled context. I'm
using FLTK to create my OpenGL context, so my code's example might not
be useful to you.

It looks like osg/DisplaySettings has a method setMinimumNumStencilBits
that may be helpful to you. You could also look at the osgreflect demo.

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

Re: [osg-users] OSG 2.8.2 rpms for Centos 5 and RedHat 5

[Eric Sokolowsky]

Peter Bear wrote:
> Hi,
> results show:
> 
> [r...@pciii pciii]# rpm -qa | grep curl
> libcurl-7.19.4-9.fc11.i586
> libcurl-7.19.4-9.fc11.x86_64
> curl-7.19.4-9.fc11.x86_64
> [r...@pciii pciii]#
> 
> Cheers,
> Peter

It looks like you are using Fedora 11. The package I built is for RedHat
5/Centos 5, which is based on Fedora 6. Your curl is too new for my
package. If you did this command:

   rpm -q --filesbypkg curl | grep libcurl

You would probably find libcurl.so.4 instead of libcurl.so.3. Perhaps
you can find a Fedora 11 package for curl 7.15.5 which is the version I
have on my machine, or else you can try downloading the source rpm (the
one with .srpm suffix) and then issuing this command:

  RPM_BASE=/tmp rpmbuild --rebuild name_of_source_rpm_here.srpm

Let me know if you need more help.

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

Re: [osg-users] OSG 2.8.2 rpms for Centos 5 and RedHat 5

[Eric Sokolowsky]

Peter Bear wrote:
> Hi,
> 
> I got the error "libcurl.so.3()(64bit) is needed by package 
> OpenSceneGraph-libs-2.8.2-1.x86_64 (/OpenSceneGraph-libs-2.8.2-1.x86_64)" 
> while installing the libraries, and yes, I have checked and yum says curl is 
> installed.
> 
> Cheers,
> Peter

Can you show me the output of this command:

  rpm -qa | grep curl

If it doesn't show the 64-bit version of curl, you can install it with
this command:

  yum install curl.x86_64

The 64-bit version of libcurl should be in /usr/lib64.

I'm trying to get a public yum repository set up so yum can be used to
automatically install required, missing dependencies (to avoid problems
such as this one).

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

Re: [osg-users] OSG 2.8.2 rpms for Centos 5 and RedHat 5

[Eric Sokolowsky]

Robert Osfield wrote:
> Hi Eric,
> 
> On Mon, Aug 17, 2009 at 5:54 PM, Eric Sokolowsky wrote:
>> I have created some binary rpm packages for Centos 5 for the most recent
>> stable release. Where do I upload these files? It's been a while since
>> I've done that.
> 
> Thanks.  The place to upload them is via ftp, I'm afraid I can't
> recall the standard username and password off hand, a search through
> the archives/website will probably unearth it.  Or... if Jose Luis
> spots this email!

I found the ftp location and uploaded the packages. I would appreciate
any feedback from people who download it. It's broken up into several
rpm packages so users can better control the installation of dependencies.

Files with md5 sums:

1834f25e2e434e48f77f4a442d38eeae  OpenSceneGraph-2.8.2-1.x86_64.rpm

2d25764e62412d5c5a3377eda5307161
OpenSceneGraph-debuginfo-2.8.2-1.x86_64.rpm

77fc1ec019496790f319a3a5bdad23eb  OpenSceneGraph-devel-2.8.2-1.x86_64.rpm

d04dc40b0384f7e3c6851af4f7f6dec0  OpenSceneGraph-examples-2.8.2-1.x86_64.rpm

055af5a3a2bc46aed80bf5279139a000
OpenSceneGraph-examples-SDL-2.8.2-1.x86_64.rpm

3e3d14a9366bb69e1f3d6c9ec9397368
OpenSceneGraph-examples-fltk-2.8.2-1.x86_64.rpm

d356ab6363cd6f52321c0e1856339e6d
OpenSceneGraph-examples-qt-2.8.2-1.x86_64.rpm

fa88a546d6efd98ee03005e7946c7e2c  OpenSceneGraph-libs-2.8.2-1.x86_64.rpm
2b81e733959bf996ae5d859363c29b7c  OpenThreads-2.8.2-1.x86_64.rpm
1f5ee56829d388f7e1cf40d9e6d460e6  OpenThreads-devel-2.8.2-1.x86_64.rpm
a8f7184ed8d72fbf7a102af875b6e12d  OpenSceneGraph-2.8.2.spec
acd87a307d6cc2b589b2b7d4408c8f47  OpenSceneGraph-2.8.2-1.src.rpm


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

[osg-users] OSG 2.8.2 rpms for Centos 5 and RedHat 5

[Eric Sokolowsky]

Robert,

I have created some binary rpm packages for Centos 5 for the most recent
stable release. Where do I upload these files? It's been a while since
I've done that.

I'm also willing to set up and help maintain a yum repository that makes
it easy to update OpenSceneGraph on Centos and RedHat. All that is
required is a directory accessible through a web server. When new
packages are available, a command-line utility is used to update the
metadata files.

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

Re: [osg-users] build errors with 2.8.1

[Eric Sokolowsky]

Jason Daly wrote:
> Eric Sokolowsky wrote:
>> John and everyone,
>>
>> I realize I'm getting into this discussion very late (I've been pretty
>> absent from OSG development lately). We also use Centos (currently at
>> 5.2), and the older package versions is a problem for us as well. I have
>> taken it upon myself to make RPMs of several newer packages we require.
>> I can provide .spec files for those who are interested. Here are some of
>> the newer packages I have made (or packages not included in the distro):
>>
>> flex-2.5.35
>> Inventor-2.1.5
>> fltk-1.1.9
>> xxdiff-3.2
>> cmake-2.6.4
>>   
> 
> A couple of those are available at ATrpms (http://atrpms.net/dist/el5/)
> already.  Just mentioning it in case you didn't know (might save you
> some work in the future)

I've avoided ATrpms lately, because some of the packages there didn't
seem to work (and conflicted with other packages we were using).
RPMforge packages, on the other hand, seem to work well for us.

The packages I mentioned above are easy enough to build that the spec
file is really simple, so it really wasn't that much work.

> 
> I also recently discovered the EPEL repository that is run by the Fedora
> project. This one is even nicer because it integrates seamlessly with
> yum (https://fedoraproject.org/wiki/EPEL).

I'll have to look at that one; it sounds interesting.

Thanks!

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

Re: [osg-users] build errors with 2.8.1

[Eric Sokolowsky]

John Kelso wrote:
> Below is from our sysadmin when I asked him about getting a newer
> version cmake.
> 
> Any comments, anyone?
> 
> Can we really be the only site having this problem?


John and everyone,

I realize I'm getting into this discussion very late (I've been pretty
absent from OSG development lately). We also use Centos (currently at
5.2), and the older package versions is a problem for us as well. I have
taken it upon myself to make RPMs of several newer packages we require.
I can provide .spec files for those who are interested. Here are some of
the newer packages I have made (or packages not included in the distro):

flex-2.5.35
Inventor-2.1.5
fltk-1.1.9
xxdiff-3.2
cmake-2.6.4

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

Re: [osg-users] osgViewer in a FLTK window...

[Eric Sokolowsky]

I have been busy playing with this. You can have an osgViewer embedded in a
FLTK window. I haven't tried to render with multiple threads yet, but it
works for a single thread. You can draw FLTK windows in multiple threads but
you have to use a mutex (part of the FLTK system) so you can only draw in
one window at a time. I am not sure if this also applies to OpenGL (and thus
OSG) drawing in FLTK windows.

Under Linux (and Windows I think) you can have an OSG window that processes
OSG events in a separate thread from your FLTK window in the FLTK thread
processing FLTK events. This approach does not work on the Mac, and I'm not
entirely sure why. I had to combine my two event processing threads into one
to get it to work on the Mac. One annoying limitation in this approach is
that if you are selecting an FLTK menu, OSG rendering stops in your other
window. There seems to be no way around this.

I am playing with an improved FLTK viewer which expands upon the
osgviewerFLTK example, but it is still in progress.

-Eric

On Tue, Apr 14, 2009 at 12:03 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:

>  Another question…
>
>
>
> Can you have an osgViewer embedded in a FLTK windowing framework? If so,
> can osgViewer still render with multi-threading? I know there are some
> limitations along this line when an osgViewer is embedded in a GLUT window.
> I’m wondering if having an osgViewer in a FLTK window suffers from the same
> limitations…
>
>
>
> Any input 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] Discovering displays on X11 using Xinerama

[Eric Sokolowsky]

Is there any interest in supporting Xinerama calls to determine what the
resolutions of monitors are? Right now, if say Twinview is used on X11
for an Nvidia card, and more than one monitor is hooked up, osg
applications (such as osgviewer) do not read the resolution correctly.
I'm looking at possible solutions, and was wondering if anyone else had
comments on the issue.

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

Re: [osg-users] FLTK2 port of osgviewerFLTK

[Eric Sokolowsky]

Robert Osfield wrote:
> Hi Michael,
> 
> Does the code still work under FLTK1.x?
> 
> Has FLTK2 finally been officially release yet?
> 
> Robert.
> 

FLTK 2 has not been officially released. It has been under development
for at least 4 years, with no end in sight. Version 1.1.x is stable and
the recommended version to use. The FLTK developers are working more on
their 1.3.x branch, which adds UTF8 and (at least until recently) a tree
browser widget. I would love to have the browser widget for my
application because I'm using an unsupported one from a third party at
present, so eventually I may move to 1.3.x, but even that is not yet API
-stable.

Originally I was also using FLTK 2 because of the built-in tree browser
widget and the fltk namespace, but it did not ever work well with my
application on the Mac, so I started over with FLTK 1.1.x. I do not
recommend having any dependency on FLTK 2.x because it is not stable.

For a school project FLTK2 is probably fine.

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

[osg-users] Fix for Producer camera config files plugin

[Eric Sokolowsky]

The osgViewer::CompositeViewer had partial support for Producer Camera
config files, but it was not working completely. Here is the completed
implementation. File: src/osgViewer/CompositeViewer.cpp.

-Eric
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 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.
*/

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

#include 

using namespace osgViewer;

CompositeViewer::CompositeViewer()
{
constructorInit();
}

CompositeViewer::CompositeViewer(const CompositeViewer& cv,const osg::CopyOp& copyop):
ViewerBase()
{
constructorInit();
}

CompositeViewer::CompositeViewer(osg::ArgumentParser& arguments)
{
constructorInit();

std::string filename;
bool readConfig = false;
while (arguments.read("-c",filename))
{
readConfig = readConfiguration(filename) || readConfig;
}

while (arguments.read("--SingleThreaded")) setThreadingModel(SingleThreaded);
while (arguments.read("--CullDrawThreadPerContext")) setThreadingModel(CullDrawThreadPerContext);
while (arguments.read("--DrawThreadPerContext")) setThreadingModel(DrawThreadPerContext);
while (arguments.read("--CullThreadPerCameraDrawThreadPerContext")) setThreadingModel(CullThreadPerCameraDrawThreadPerContext);

osg::DisplaySettings::instance()->readCommandLine(arguments);
osgDB::readCommandLine(arguments);
}

void CompositeViewer::constructorInit()
{
_endBarrierPosition = AfterSwapBuffers;
_startTick = 0;

// make sure View is safe to reference multi-threaded.
setThreadSafeRefUnref(true);

_frameStamp = new osg::FrameStamp;
_frameStamp->setFrameNumber(0);
_frameStamp->setReferenceTime(0);
_frameStamp->setSimulationTime(0);

_eventVisitor = new osgGA::EventVisitor;
_eventVisitor->setFrameStamp(_frameStamp.get());

_updateVisitor = new osgUtil::UpdateVisitor;
_updateVisitor->setFrameStamp(_frameStamp.get());

setViewerStats(new osg::Stats("CompsiteViewer"));
}

CompositeViewer::~CompositeViewer()
{
osg::notify(osg::INFO)<<"CompositeViewer::~CompositeViewer()"getDatabasePager()->cancel();
scene->setDatabasePager(0);
}
}

Contexts contexts;
getContexts(contexts);

// clear out all the previously assigned operations
for(Contexts::iterator citr = contexts.begin();
citr != contexts.end();
++citr)
{
(*citr)->close();
}

osg::notify(osg::INFO)<<"finished CompositeViewer::~CompositeViewer()"< obj = osgDB::readObjectFile(filename);
osgViewer::View * view = dynamic_cast(obj.get());
if (view)
{
addView(view);
return true;
}
return false;
}


void CompositeViewer::addView(osgViewer::View* view)
{
if (!view) return;

bool alreadyRealized = isRealized();

bool threadsWereRunning = _threadsRunning;
if (threadsWereRunning) stopThreading();

_views.push_back(view);

view->_viewerBase = this;

if (view->getSceneData())
{
// make sure that existing scene graph objects are allocated with thread safe ref/unref
if (getThreadingModel()!=ViewerBase::SingleThreaded) 
{
view->getSceneData()->setThreadSafeRefUnref(true);
}

// update the scene graph so that it has enough GL object buffer memory for the graphics contexts that will be using it.
view->getSceneData()->resizeGLObjectBuffers(osg::DisplaySettings::instance()->getMaxNumberOfGraphicsContexts());
}

view->setFrameStamp(_frameStamp.get());

if (alreadyRealized)
{
Contexts contexts;
if (view->getCamera()->getGraphicsContext())
{
contexts.push_back(view->getCamera()->getGraphicsContext());
}
for(unsigned int i=0; igetNumSlaves(); ++i)
{
if (view->getSlave(i)._camera->getGraphicsContext())
{
contexts.push_back(view->getSlave(i)._camera->getGraphicsContext());
}
}

for(Contexts::iterator itr = contexts.begin();
itr != contexts.end();
++itr)
{
if (!((*itr)->isRealized()))
{
(*itr)->realize();
}
}

}

if (threadsWereRunning) startThreading();
}

void CompositeViewer::removeView(osgViewer::View* view)
{
   

Re: [osg-users] OpenGL 3.1 at GDC

[Eric Sokolowsky]

Paul Martz wrote:
> I realize that by speaking out, I'm running the risk of looking just as
> closed-minded, opinionated, and foolish as we view the D3D community. If I'm
> ever _way_ off base, please call me on it. I'd rather be quiet than somehow
> do OpenGL a disservice.

One fact is indisputable in this debate: OpenGL runs on many platforms,
and D3D runs on one. (Two if you count Xbox.) This is unlikely to
change. Developers who want to target all platforms use OpenGL.

Enlightened developers use OSG. :)

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

Re: [osg-users] Osgconv --formats broke on Mac OSX

[Eric Sokolowsky]

My plugins all have the .so extension. The main libraries all have .dylib.
Someday we'll get Frameworks working properly but that day is not today.

The only thing I know of that changed very recently was that under OSX, the
debug library suffix (by default "d") was not being added properly when
using the Debug configuration, because _DEBUG was not being passed
correctly. This is still potentially a problem for Makefile builds. Are you
doing a Debug build or a Release build? Plugins were broken for Debug
builds. One of my submissions has not yet been integrated; see
osg-submissions for details.

You might also try using the Xcode generator; you can use the command-line
compiler to actually compile things if you don't like the IDE (I use an
install directory in my home directory for testing):

xcodebuild -configuration Release -target install

-Eric

2009/3/24 Paul Martz 

>  I am generating Makefiles using CMake, and I have installed OSG.
>
> The problem seems to be that osgDB expects plugins to have a ".dylib"
> extension, when in fact they have a ".so" extension on my system (and no
> they are not sym links). Eric, I'd be interested to know what you have on
> your system.
>
> Did the extension for OS X plugins change very recently? My build is a
> couple weeks old now.
>
> Paul Martz
> *Skew Matrix Software LLC*
> http://www.skew-matrix.com
> +1 303 859 9466
>
>
>  --
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Eric Sokolowsky
> *Sent:* Tuesday, March 24, 2009 11:42 AM
> *To:* OpenSceneGraph Users
> *Subject:* Re: [osg-users] Osgconv --formats broke on Mac OSX
>
> It works for me (latest svn). Did you "install" the OSG library? If you did
> not, there is no way to get to the plugins, because Xcode inserts a "Debug"
> or "Release" intermediate directory. This assumes you use the Xcode
> generator for OSX. If you are using the Makefiles generator, or the old
> pre-generated Xcode project, then I have no idea.
>
> -Eric
>
> 2009/3/24 Paul Martz 
>
>>  Is anyone else encountering this? "osgconv --formats" immediately
>> returns to the shell prompt. With OSG_NOTIFY_LEVEL set to DEBUG_INFO I see
>> that it finds the plugin directory, then pretty much just exits, as if there
>> are no plugins there.
>>
>> Oddly, "osgconv --format flt" (and other extensions) works OK, and with
>> the notify output I see it finding the plugin immediately, followed by the
>> expected output relating to that plugin.
>>
>> OSG 2.6.1 works OK. but svn head is broke as of at least late February
>> (that's when I took the snapshot for our OSG training in DC, and one of the
>> students there with a macbook encountered the issue). I haven't tried this
>> with 2.8.
>>
>> Paul Martz
>> *Skew Matrix Software LLC*
>> http://www.skew-matrix.com
>> +1 303 859 9466
>>
>>
>> ___
>> 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] Osgconv --formats broke on Mac OSX

[Eric Sokolowsky]

It works for me (latest svn). Did you "install" the OSG library? If you did
not, there is no way to get to the plugins, because Xcode inserts a "Debug"
or "Release" intermediate directory. This assumes you use the Xcode
generator for OSX. If you are using the Makefiles generator, or the old
pre-generated Xcode project, then I have no idea.

-Eric

2009/3/24 Paul Martz 

>  Is anyone else encountering this? "osgconv --formats" immediately returns
> to the shell prompt. With OSG_NOTIFY_LEVEL set to DEBUG_INFO I see that it
> finds the plugin directory, then pretty much just exits, as if there are no
> plugins there.
>
> Oddly, "osgconv --format flt" (and other extensions) works OK, and with the
> notify output I see it finding the plugin immediately, followed by the
> expected output relating to that plugin.
>
> OSG 2.6.1 works OK. but svn head is broke as of at least late February
> (that's when I took the snapshot for our OSG training in DC, and one of the
> students there with a macbook encountered the issue). I haven't tried this
> with 2.8.
>
> Paul Martz
> *Skew Matrix Software LLC*
> http://www.skew-matrix.com
> +1 303 859 9466
>
>
> ___
> 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] OSX Cmake/Xcode path problems under Debug

[Eric Sokolowsky]

When I build OSG (latest svn) with Xcode (generated by Cmake), I've
noticed some problems when compiling with the Debug configuration. I'm
trying to fix these, but if anybody has some clue how to force Cmake to
work better, please chime in.

1. I submitted a patch (not yet committed) that will use the
OSG_DEBUG_POSTFIX (by default: "d") when loading plugins, but this
depends on _DEBUG being defined at compile time. However, _DEBUG is not
being defined. Thus, plugins are not being loaded unless I put in a
symbolic link from the name OSG is expecting to the name it is actually
given.

2. Under my build directory (I am doing out of source builds), the
libraries are built in the directory: build/lib/Debug, and the plugins
are built in the directory: build/lib/osgPlugins-2.9.1/Debug. This
causes problems when testing (without installing) because osg doesn't
try to to add the intermediate Debug directory. It would be really nice
if the two paths above were build/lib/Debug and
build/lib/Debug/osgPlugins-2.9.1. Anyone know how to get cmake to do this?

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

Re: [osg-users] [build] osgdb_freetype build problem on Mac OS/X 10.5.6

[Eric Sokolowsky]

I  compiled svn with cmake 2.6.3 on OSX without difficulty, in a clean
directory, using all of the default settings, so I cannot confirm the
existence of this bug.

-Eric

On Mon, Mar 16, 2009 at 9:19 PM, john casu  wrote:

> I'm trying to build the latest svn version of OSG 2.8.0 on OS/X, and I'm
> having a problem when building osgdb_freetype, specifically the header file
> ft2build.h cannot be located:
> Scanning dependencies of target osgdb_freetype
> [ 98%] Building CXX object
> src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/FreeTypeFont.cpp.o
> In file included from
> /Users/casuj/OpenSceneGraph/OpenSceneGraph-2.8.0-svn/src/osgPlugins/freetype/FreeTypeFont.cpp:14:
> /Users/casuj/OpenSceneGraph/OpenSceneGraph-2.8.0-svn/src/osgPlugins/freetype/FreeTypeFont.h:19:22:
> error: ft2build.h: No such file or directory
> /Users/casuj/OpenSceneGraph/OpenSceneGraph-2.8.0-svn/src/osgPlugins/freetype/FreeTypeFont.h:20:10:
> error: #include expects "FILENAME" or 
>
> However, CMakeCache.txt shows that this file has been located:
> enterprise:OpenSceneGraph-2.8.0-svn casuj$ fgrep FREETYPE CMakeCache.txt
>
> CMakeCache.txt:FREETYPE_INCLUDE_DIR_freetype2:PATH=/usr/local/include/freetype2
> CMakeCache.txt:FREETYPE_INCLUDE_DIR_ft2build:PATH=/usr/local/include
> CMakeCache.txt:FREETYPE_LIBRARY:FILEPATH=/usr/local/lib/libfreetype.dylib
>
> and the file itself does in fact exist:
> enterprise:OpenSceneGraph-2.8.0-svn casuj$ ls -l
> /usr/local/include/ft2build.h
> -rw-r--r--  1 root  admin  3890 Mar  5  2007 /usr/local/include/ft2build.h
>
> Can anyone shed light on how to workaround this ?
>
> Thanks,
>
> -john c.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=8569#8569
>
>
>
>
>
> ___
> 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] [OS X] Request for testing the new Cocoa backend + imageio-plugin

[Eric Sokolowsky]

I just ran a preliminary test, and the imageio plugin seemed to load and
work correctly. I will post more as I test further.

Thanks Stephan for integrating this!

-Eric

On Wed, Mar 4, 2009 at 11:09 AM, Stephan Maximilian Huber <
ratzf...@digitalmind.de> wrote:

> Hi all,
>
> I've finished the coding of the new Cocoa backend for osgViewer and I
> integrated the imageio-plugin from E.Wing into CMake / the XCode-project.
>
> I did some tests but as of my limited ressources I can't test every
> combination of hardware etc. So please if you have some spare-time and
> an OS X machine can you please test the new code? Thanks!
>
> *Here's how to get the new code:*
>
> svn checkout
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/osg-cocoa-dev
>
> or if you already have svn trunk on your computer
>
> svn switch
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/osg-cocoa-dev
>
> start CMake and change the following two options:
>
> OSG_WINDOWING_SYSTEM = Cocoa (X11, Carbon, and Cocoa available)
> OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio (imageio + quicktime available)
>
> If you want to compile for 64bit, be sure to change
> CMAKE_OSX_ARCHITECTURES to "ppc;i386;ppc64;x86_64", (the carbon backend
> and quicktime are not compatible with 64bit, and get not compiled even
> when enabled!)
>
> create your project files, compile and test against your application /
> environment.
>
> If you want to use the depecated os x project then be sure to define the
> follwing flags for the project:
>
> USE_DARWIN_COCOA_IMPLEMENTATION (for cocoa backend)
> USE_DARWIN_CARBON_IMPLEMENTATION (for carbon backend)
>
> for osgDB:
> DARWIN_IMAGEIO (imagio as default image-plugin)
> DARWIN_QUICKTIME (quicktime as default image-plugin)
>
>
> *What's missing, not tested:*
>
> + I don't know if all tablet-events are handled well, because my tablet
> does not support all available events (rotation + tilt)
>
> + if you resize a window you'll get some artifacts while resizing, I
> don't know how to fix this, I tried some approaches but nothing good came
> up
>
> + switching from fullscreen to windowed mode and vice versa works only
> for the main-screen reliably (this affects also the carbon backend). See
> my other post regarding this issue.
>
> #scroll-wheel-events are not tested that well.
>
> SO, I hope no major problems arise, and we can merge the staff with
> trunk the next days.
>
> 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] Eric Wing's osgdb_ImageIO image plugin for OSX

[Eric Sokolowsky]

Excellent. I look forward to trying it out.

On Fri, Feb 27, 2009 at 7:58 AM, Stephan Maximilian Huber <
ratzf...@digitalmind.de> wrote:

> Hi,
>
> Eric Sokolowsky schrieb:
> > Here's Eric Wing's ImageIO plugin. It was actually submitted to
> > osg-submissions in October 2007 but nothing was ever done with it. If
> > someone wants to take a stab at integration please go ahead. I want to
> > do it, but have no time... isn't that always the way?
>
> thanks Eric,
>
> I am integrating it now and update it's source to 2.8. I'll submit it to
> osg-submissions next week if everything went ok.
>
> @Robert:
>
> Is there a chance to get a private branch of osg/subversion with
> write-access, so multiple people can try getting the cocoa-backend
> finished?
>
> 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] Wash DC OSG Users Group meeting?

[Eric Sokolowsky]

Paul Martz wrote:
> Hi all -- Many of you have asked if there would be a UG meeting in
> conjunction with the upcoming OSG training in Washington DC, March 9-12 (see
> http://www.skew-matrix.com/training.html).
>  
> The best evening for me would be the last day of the course, Thursday March
> 12. Unfortunately, the hotel I'm staying at does not have a meeting room
> available.
>  
> Can anyone suggest an alternate location? (My hotel is just a few blocks
> away from the White House; perhaps President Obama would rent us a room? Ha
> ha.)

I'm not very familiar with what's open in the area late. I would suggest
the Corner Bakery on 14th (about a block east of the White House), but
they close at 6. Perhaps a nearby hotel would have a small room
available? Union Station has several less expensive eating options and
they close at 9, but it's not very close to the White House.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] New ffmpeg plugin checked into svn/trunk

[Eric Sokolowsky]

Jean-Sébastien Guay wrote:
> Hi Eric,
> 
>> This is my second attempt to send Eric Wing's plugin.
> 
> The first one came through as far as I can see.
> 
> J-S

Thanks for the feedback. The first time I sent it, I got back a couple
of error email messages, and I didn't check them carefully to see where
they had come from, so I sent it again, without attaching the original
email. It looks like a couple of users work at places that prohibit .eml
attachments.

Hopefully the plugin won't get lost again, though.

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

Re: [osg-users] New ffmpeg plugin checked into svn/trunk

[Eric Sokolowsky]

Robert Osfield wrote:
> Hi Eric,
> 
> On Thu, Feb 26, 2009 at 1:41 PM, Eric Sokolowsky  wrote:
>> This problem can also be solved on OSX by integrating Eric Wing's
>> ImageIO plugin to handle static images. I have the code; I just need to
>> find time to integrate the plugin. Unfortunately I haven't had much time
>> to devote to OSG and my OSG-based application lately.
> 
> Ahh more good news on the OSX front :-)
> 
> You could always post the code which would allow others to help out
> with the wrapping up as plugin.


This is my second attempt to send Eric Wing's plugin. This was actually
originally submitted to osg-submissions in October 2007, but nothing was
done with it. If anyone wants to work on integrating it, please go
ahead. My plate seems to always be full with other tasks...

-Eric S.

-- Forwarded message --
From: "E. Wing"
Date: Fri, 26 Oct 2007 16:43:59 -0700
Subject: New image handling plugin for OS X (osgdb_ImageIO)
To: osg-submissi...@lists.openscenegraph.org

Yea! The Leopard NDA is finally lifted.

This is a submission for a new osg plugin, osgdb_ImageIO. This is the
first piece of the puzzle that we need to get 64-bit support on OS X.
This plugin is intended to partially replace the current osgdb_qt
(classic Quicktime) plugin. There are many issues with the current
osgdb_qt, but perhaps the biggest is that there are many APIs used in
it that have been marked deprecated for awhile now and will not make
it to 64-bit on OS X.

ImageIO is Apple's (semi-)new (as of 10.4 Tiger) fundamental image
framework that provides access to all image formats handled by the
platform. This new osgdb_ImageIO plugin intends to replace all of
osgdb_qt's image handling duties as well as introduce support to new
image formats as they become available to the platform (e.g. JPEG2000,
RAW, HDR, etc).

osgdb_ImageIO does not replace osgdb_qt's movie handling capabilities.
I envision that to be handled by a planned second plugin using Apple's
semi-new (10.4 Tiger) QuickTimeKit framework, tentatively osgdb_QTKit.
So this plugin is just the first step.

Would you please add this to src/osgPlugins/ImageIO?

Improvements over osgdb_qt plugin:
- Supports istream and ostream
- Supports a lot more image formats
- ImageIO framework should be well supported from 10.4 to the future
(which should include 64-bit and new/future image formats)
- Doesn't require explicit initialization/close-out
- (Hopefully) efficient...avoids the manual byte-by-byte manipulation
of the old QuickTime plugin. Calls Apple's Accelerate framework when
useful.
- Seems to fix/avoid AutoreleasePool related leak warnings which I
believe the current qt plugin triggers if not using Cocoa (i.e.
actually having an autorelease pool created).

Missing:
- No movie file support (planning/expecting a separate QTKit plugin to
handle that).
- Need to update osgDB::Registry for new plugin
- Need to update build system(s)

Additional Notes:
- The old Quicktime plugin will need to remain for both Windows users
(who happen to use it) and pre-10.4 OS X versions. It will also need
to remain for movies until we get a QTKit plugin written.
- This plugin probably could use additional testing for
16-bit/LUMINANCE/ALPHA stuff. I'm not terribly confident I understood what
needs to happen in these cases so behavior could be different/broken
compared to osgdb_qt.


Once I figure out all the build system details, I'm proposing that for
the next release of OSG, if building for OS X 10.4 or 10.5, the
ImageIO plugin gets built and set as the default image handling
plugin. For legacy 10.3 and Quicktime for Windows users, the existing
osgdb_qt plugin should remain available. For now though, I wanted to
make this piece of code available in case anybody has a pressing need
to get 64-bit going soon.


Thanks,
Eric

// Copyright Eric Wing
// This plugin is the bridge to OS X's ImageIO framework
// which provides access to all of Apple's supported image types.
// This plugin plus the QTKit plugin obsoletes the old QuickTime plugin.
// This requires 10.4+. (The old QuickTime plugin will not support 64-bit.)


// Needs testing, especially in:
// 8-bits per pixel (256 color vs GL_ALPHA, and what about GL_LUMINANCE)?
// 16-bits per pixel (is GL_LUMINANCE_ALPHA a safe assumption?)
// Non-power-of-two textures (especially odd sizes)
// istream code path
// ostream code path
// write image, especially GL_LUMINANCE and GL_ALPHA paths and image formats other than PNG/JPEG

// Enhancements needed:
// Way to provide image type hint to ImageIO calls (via CFDictionary),
// probably especially important for istream which lacks extension information.
// Is there information we can use in the OSG options parameter?

// For ImageIO framework and also LaunchServices framework (for UTIs)
#include 
// For the vImage framework (part of the Accerlate framework)
#include 

[osg-users] Eric Wing's osgdb_ImageIO image plugin for OSX

[Eric Sokolowsky]

Here's Eric Wing's ImageIO plugin. It was actually submitted to
osg-submissions in October 2007 but nothing was ever done with it. If
someone wants to take a stab at integration please go ahead. I want to
do it, but have no time... isn't that always the way?

-Eric S.
--- Begin Message ---
-- Forwarded message --
From: "E. Wing" 
Date: Fri, 26 Oct 2007 16:43:59 -0700
Subject: New image handling plugin for OS X (osgdb_ImageIO)
To: osg-submissi...@lists.openscenegraph.org

Yea! The Leopard NDA is finally lifted.

This is a submission for a new osg plugin, osgdb_ImageIO. This is the
first piece of the puzzle that we need to get 64-bit support on OS X.
This plugin is intended to partially replace the current osgdb_qt
(classic Quicktime) plugin. There are many issues with the current
osgdb_qt, but perhaps the biggest is that there are many APIs used in
it that have been marked deprecated for awhile now and will not make
it to 64-bit on OS X.

ImageIO is Apple's (semi-)new (as of 10.4 Tiger) fundamental image
framework that provides access to all image formats handled by the
platform. This new osgdb_ImageIO plugin intends to replace all of
osgdb_qt's image handling duties as well as introduce support to new
image formats as they become available to the platform (e.g. JPEG2000,
RAW, HDR, etc).

osgdb_ImageIO does not replace osgdb_qt's movie handling capabilities.
I envision that to be handled by a planned second plugin using Apple's
semi-new (10.4 Tiger) QuickTimeKit framework, tentatively osgdb_QTKit.
So this plugin is just the first step.

Would you please add this to src/osgPlugins/ImageIO?

Improvements over osgdb_qt plugin:
- Supports istream and ostream
- Supports a lot more image formats
- ImageIO framework should be well supported from 10.4 to the future
(which should include 64-bit and new/future image formats)
- Doesn't require explicit initialization/close-out
- (Hopefully) efficient...avoids the manual byte-by-byte manipulation
of the old QuickTime plugin. Calls Apple's Accelerate framework when
useful.
- Seems to fix/avoid AutoreleasePool related leak warnings which I
believe the current qt plugin triggers if not using Cocoa (i.e.
actually having an autorelease pool created).

Missing:
- No movie file support (planning/expecting a separate QTKit plugin to
handle that).
- Need to update osgDB::Registry for new plugin
- Need to update build system(s)

Additional Notes:
- The old Quicktime plugin will need to remain for both Windows users
(who happen to use it) and pre-10.4 OS X versions. It will also need
to remain for movies until we get a QTKit plugin written.
- This plugin probably could use additional testing for
16-bit/LUMINANCE/ALPHA stuff. I'm not terribly confident I understood what
needs to happen in these cases so behavior could be different/broken
compared to osgdb_qt.


Once I figure out all the build system details, I'm proposing that for
the next release of OSG, if building for OS X 10.4 or 10.5, the
ImageIO plugin gets built and set as the default image handling
plugin. For legacy 10.3 and Quicktime for Windows users, the existing
osgdb_qt plugin should remain available. For now though, I wanted to
make this piece of code available in case anybody has a pressing need
to get 64-bit going soon.


Thanks,
Eric


osgdb_ImageIO.cpp
Description: Binary data
--- End Message ---
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] New ffmpeg plugin checked into svn/trunk

[Eric Sokolowsky]

Robert Osfield wrote:
> 
> On Thu, Feb 26, 2009 at 12:10 PM, Stephan Maximilian Huber
>  wrote:
>> Currently, I am against deprecating the quicktime-lib, because:
>>
>> 1.) it handles images default for OS X
> 
> Which images does Quicktime support that we don't have other plugins
> for?  Ideally I'd like to see us have cross platform support for all
> types of imagey that OSG users come across, this way users are locked
> into a single platform just because of a data type.

This problem can also be solved on OSX by integrating Eric Wing's
ImageIO plugin to handle static images. I have the code; I just need to
find time to integrate the plugin. Unfortunately I haven't had much time
to devote to OSG and my OSG-based application lately.

As far as using our standard, cross-platform image plugins on OSX, that
works too. I used to do that when the Quicktime plugin didn't handle
transparency very well.

>
> The first step in this process has to be getting the ffmpeg up and
> running with video and audio across all platforms, then to start
> looking at a set of test video/features that we can use a unit tests
> that we measure the plugin against.

I think that the ffmpeg plugin, once we determine if it will work well
enough for our purposes, combined with the ImageIO plugin, will be able
to replace the old Quicktime plugin, providing (at last) a 64-bit path
for OSG-based apps on OSX.

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

Re: [osg-users] Streaming of high resolution images

[Eric Sokolowsky]

Francesco Argese wrote:
> Hi all,
> 
> I'm trying to stream high resolution images in real-time. My problem is that 
> performance degenerate after some time; this is due to the complete 
> occupation of the ram and to the slow process of loading an image in memory 
> that is slower than the visualization frequency needed by my application.
> 
> In which classes is this process handled? Is there a manner to avoid (or to 
> mitigate) this problem using a different approach?
> 
> I remember that i have already seen this same argument in mailing list but, 
> doing a search, I have not found what I'm searching for.
> 

It is faster to use texture compression and save the compressed textures
as .ive files, then load those. This requires either a preprocessing
step to compress the textures or a caching mechanism to use compressed
textures once they've been generated. I use the second technique in my
application with pretty good results.


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

Re: [osg-users] need to port an application from OSG v1.2 (OSG::Producer based) to OSG 2.0 (OsgViewer based)

[Eric Sokolowsky]

Jean-Sébastien Guay wrote:
> Hi Eric,
> 
>> hiding the mouse pointer is not supported
> 
> osgViewer::GraphicsWindow::useCursor(false) should do that... Though
> you're on Mac so perhaps GraphicsWindowCarbon doesn't work properly?
> 
> J-S

I know the message you sent is very old, but I just now got to
implementing this change in my application. It took a bit of work to
find out how to get the GraphicsWindow, but once I figured that out (I
needed to call GetWindows() on my osgViewer::Viewer), everything worked
very well. Thank you!

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

Re: [osg-users] ANN: OSG Training in Washington DC

[Eric Sokolowsky]

Paul Martz wrote:
> Hi all -- Just a reminder regarding the upcoming public OSG training course,
> to be held in Washington DC, March 9-12, 2009.
>  

While I probably won't be attending the training, I hope that there will
be a small user's group meeting one evening while you're in town. The
last one was worthwhile. I'm not available on Monday, but any of the
other days should work for me.

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

Re: [osg-users] MAC

[Eric Sokolowsky]

Wasileski, Bryan J. wrote:

Hi,

 

I’ve not monitored the group mail for a while and was wondering if 
anyone could give me some user/developer experiences of OSG with the Mac.


I was the most recent to push things along with OSG on the Mac. I was 
working a bit with the X11 path and 64-bit compiles, and think it works 
with cmake generating xcode projects. However, things like QT and 
quicktime are not available this way (which means that common image file 
formats are also broken). Eric Wing developed an ImageIO plugin for 
images that I have partially integrated but not yet finished. To get 
animations working on 64-bit a new plugin that uses QTKit needs to be 
developed. For 32-bit compiles all the old stuff should still work. The 
stuff that doesn't work is automatically excluded when a 64-bit platform 
is included in the Xcode generation. Currently the Xcode projects (the 
ones generated by CMake) just make shared libraries. I also intend on 
getting it to generate Frameworks, but that work is not very far along. 
The hand-generated Xcode projects make Frameworks, but I'm not sure if 
they are up-to-date.


There are a lot of permutations on how to build on the Mac. I am 
interested in suggestions on what is broken so it can be improved. The 
way forward is through CMake. The old Xcode projects may or may not 
function, and will probably not be maintained into the future.


As for getting CMake to run on the mac, I downloaded a binary package of 
cmake 2.6.x from CMake's web site, and it just worked for me, with a GUI 
and everything. I didn't try to compile CMake myself, nor use MacPorts 
or any other package repository. I haven't tried to run cmake on the 
command line. I believe that the binary CMake bundle has the 
command-line executables contained within. I usually generate Xcode 
projects from cmake and then compile. This is the easiest way to produce 
a universal binary.


As I was making changes this summer I tried to maintain compatibility 
with 10.4, and even cross-compiling for 10.4 on 10.5. I'm not sure how 
well I succeeded.


Suggestions and questions are welcome.

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

Re: [osg-users] need to port an application from OSG v1.2 (OSG::Producer based) to OSG 2.0 (OsgViewer based)

[Eric Sokolowsky]

Jean-Sébastien Guay wrote:

Hi Eric,


hiding the mouse pointer is not supported


osgViewer::GraphicsWindow::useCursor(false) should do that... Though 
you're on Mac so perhaps GraphicsWindowCarbon doesn't work properly?


J-S


Hey, thanks! I guess I should have looked more carefully.

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

Re: [osg-users] need to port an application from OSG v1.2 (OSG::Producer based) to OSG 2.0 (OsgViewer based)

[Eric Sokolowsky]

Gianluca Natale wrote:

Is there any tutorial that explains how to do that without any pain?


No pain, no gain. :)

All joking aside, it really is not that painful. I migrated my OSG 1.2 
application (using old Producer libraries) to new osgViewer in a couple 
of hours. There was some functionality that was lost (Producer config 
files don't work properly yet, hiding the mouse pointer is not 
supported, multimonitor strangeness), but for the most part the port was 
straightforward.


I just recommend checking out a copy of your application out of your 
source control (you do use source control, don't you?) and compiling it 
against OSG 2.6, fixing the errors along the way.


I didn't keep good notes of my own experience, but if you have specific 
questions about porting functionality, email the list and I'll do my 
best to answer.


-Eric

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

Re: [osg-users] 2.6 Mac OS X issues and some solutions

[Eric Sokolowsky]

Filip Wänström wrote:
Hi again, wanted to add that the template xcode "OSG Application" 
needs to be updated. (and changed if you want it to work right now)


Since I tried the CMake route that creates regular .so files and 
headers in /usr/local instead of creating mac os frameworks the 
template need to be changed by removing all the framework linkings. In 
addition, some of the headers in the precompiled header file is out of 
date it seems. Introspection and osgSim/OpenFlightOptimizer


I willl change the template so it works with libs and am of course 
willing to share if anyone want it.


I'm not saying that the template should be changed to using regular 
libs instead of frameworks in the long run but for the time being that 
is the easiest way for me to start developing on the mac (and get a 
homey linux feeling as well..)


I'm not sure what the status is for generating frameworks from the 
xcode project that CMake creates. Hopeully this is remedied in a not 
to far future. For now, I'm glad that I can use xcode to create osg 
projects that works fine.





Yes, for now, the cmake project does not create OSG frameworks. We're 
working on this. Creating dylibs works fine. These dylibs can be 
installed on a developer's system or embedded into an application. Since 
most of the example programs require command-line arguments to run 
properly, it's not too much of a burden to set environment variables. 
Once we get frameworks built with cmake the environment variables should 
not be necessary.


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

Re: [osg-users] 2.6 Mac OS X issues and some solutions

[Eric Sokolowsky]

Filip Wänström wrote:

Hi there!

I tried out to run the 2.6 source release on my MacBook Pro (Leopard 
10.5.4) And run into some issues but it seems that I resolved them in 
the process and I want to share my experience in order to help others 
in a similar situation.


First:

1. The provided Xcode project is out of date/doesn't work. I didn't 
bother further with that after the initial failure to get it to work.
2. There seems to be no updated info on what to do with the Mac 
version except that its seems hard, its not supported and Apple has 
broken binary compatibility going from Tiger to Leopard. Scary stuff. 
I would have stopped here if it wasn't for that I badly want Mac to be 
a viable development environment for me. Maybe  some old info could be 
removed and replaced with a simple "1.2.3" list of what to do now.


Anyway, I decided to go the CMake route even though it's not exactly 
well documented anywhere (neither osg site or CMake homepage talks 
much about the current status of Mac)
This is the recommended route on OSX. There are some notes in the 
README.txt in the root of the OSG distribution on OSX that outline many 
of the steps you list below.


In short it worked, but not completely flawlessly. I found the 
following issues:


1. There is not much documentation (The biggest problem is that a lot 
of documentation is contradictory or just to old). So it's trial and 
error (and patience).
There is documentation, but it is true that much of it is old. I haven't 
done much cleaning up yet.
2. The install script doesn't work since you have to run as root/su to 
install in /usr/local

This is probably true. The install script probably needs work.
3. After install. You need to set OSG_LIBRARY_PATH to the plugin 
install dir
Yes, I realize that this is not standard for OSX. I'm still trying to 
improve the process for OSX users. This is documented in the README.txt.
3b. Since this is very far from common practice when it comes to mac I 
think It can be good to provide an example:



Recommended:
1. Download source (from svn or zipped, I use OpenSceneGraph-2.6.0 as 
the example here)

2. Extract
3. Open terminal and go to your newly created directory (something 
like ~/tmp/OpenSceneGraph-2.6.0)

4. Create a place for building the project (like: ~/tmp/osgbuild)
5. Enter that dir
5. run cmake with the flag -GXcode (cmake -GXcode ../OpenSceneGraph-2.6.0)
6. start ccmake to configure further (you probably want to build the 
examples) (ccmake  ../OpenSceneGraph-2.6.0)
I recommend downloading the OSX GUI cmake tool from the cmake website to 
do the configuration.
7. In the text-gui of ccmake. make changes like turn on the examples 
build. then configure and generate project (c, g)

8. Start the xcodeproject and build (
9. run the installscript from the command line with su privileges ( or 
login as root user for this task)
10. in order to test examples and make sure that plugins work: set the 
environment variables:

Create a file called .profile in you root.
export OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0/
export OSG_FILE_PATH=/path/to_where/you_put/OpenSceneGraph-Data-2.6.0/


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

Re: [osg-users] Recommended version?

[Eric Sokolowsky]

Frank van Meurs wrote:

Hi Eric,

Thanks for the notification and I did indeed read that. I'd already
stopped hoping for a working Xcode project, seeing as the project provided
with the 2.5.5 release led to me fixing several errors and still lacking
working build. So, knowing a bit more by now, maybe i shouldn't have lost
faith that soon.

  
Yes, OSX is a big learning curve, even for someone familiar with Linux 
and other *nix distributions. I am relatively new to the OSX platform 
myself and am not an expert by any stretch, but I have learned a lot and 
helped improve the build on OSX to a useful point, at least for my own 
project. (The application I'm developing on OSX still has problems, but 
that's another story.) I know how frustrating it can be to have things 
not just work, and my work was designed to help with some of that 
frustration. Many of the improvements I made were placed in OSG just 
after you tried 2.5.5, in the run-up to the 2.6.0 release. There are 
still issues to be sure (the ones I'm aware of are enumerated in the 
README.txt), but I'm committed to helping with them.

However, useful as all your support may be, the OS X story has by now come
to an end for me. I'll (unfortuantely?) be fiddling around on windows in
the future.
  
This is unfortunate. There should be lots of people who can help you 
with issues on that platform. I am not one of them.


-Eric

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

Re: [osg-users] Recommended version?

[Eric Sokolowsky]

Frank,

One more thing: if you have not done so already, you should read the
README.txt file in the base of the distribution of OSG 2.6.0 (or later). It
contains some important information about OSX (in the bottom part of the
file) that might help you.

-Eric

On Tue, Sep 2, 2008 at 8:51 AM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
>
>> Hi everybody,
>>
>> Although I would have loved it to be otherwise, all of my attempts at
>> installing/building OSG on my MacBook Pro (10.5.latest) have failed. So, I
>> have had to resort to arranging a windows machine on which I hope to be
>> able to get things working. However, to circumvent any problems arising
>> from minor bugs possibly left in the code, I would really like to know
>> which OSG version is the recommended one. I'm seeing quite a few tags
>> amongst the sources, but which one is 'the right one'? 2.6.0, 2.7.0 or
>> perhaps 2.7.2?
>>
>>
> Frank,
>
> I spent a lot of effort in getting OSG working well on OSX, so I am
> concerned that you are having so many problems. I recommend that you start
> with 2.6.0. Can you be more specific in how you are trying to build, and
> what error messages you are getting? Do any of the examples compile and/or
> run? There are issues in double-clicking example programs that require
> command-line arguments, but some do not and they at least should run. All
> the examples should run from the command line. The osgviewerCocoa example
> should run either on the command line or by double-clicking.
>
> Please post some more detail and I will try to help.
>
> -Eric
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Recommended version?

[Eric Sokolowsky]

[EMAIL PROTECTED] wrote:

Hi everybody,

Although I would have loved it to be otherwise, all of my attempts at
installing/building OSG on my MacBook Pro (10.5.latest) have failed. So, I
have had to resort to arranging a windows machine on which I hope to be
able to get things working. However, to circumvent any problems arising
from minor bugs possibly left in the code, I would really like to know
which OSG version is the recommended one. I'm seeing quite a few tags
amongst the sources, but which one is 'the right one'? 2.6.0, 2.7.0 or
perhaps 2.7.2?
  

Frank,

I spent a lot of effort in getting OSG working well on OSX, so I am 
concerned that you are having so many problems. I recommend that you 
start with 2.6.0. Can you be more specific in how you are trying to 
build, and what error messages you are getting? Do any of the examples 
compile and/or run? There are issues in double-clicking example programs 
that require command-line arguments, but some do not and they at least 
should run. All the examples should run from the command line. The 
osgviewerCocoa example should run either on the command line or by 
double-clicking.


Please post some more detail and I will try to help.

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

Re: [osg-users] usb joystick in openscenegraph

[Eric Sokolowsky]

You may also find that DIVERSE can fill your needs. It's a virtual reality
controller that can be used with osg.
See: http://diverse-vr.org/index.php?page=documentation/introduction

-Eric

On Tue, Aug 12, 2008 at 12:35 PM, Jan Ciger <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Mike (and Joe),
>
> Mike Connell wrote:
> | Hi,
> |
> | I was in the same position this summer. Previously I'd used SDL for a
> |  gamepad, but now needed to resurrect that code and redo it for a
> | wheel+pedals.
> |
> | I looked at vrpn but failed to really grok it. In the same time it
> | took me to bash my head against the vrpn examples, I wrote the sdl
> | code. The following should be enough for you to do a quick test. SDL
> | also supports "hats", and force-feedback was part of the Google
> | Summer of Code, but I haven't seen any results of that yet.
> |
>
> SDL is good if you need only simple joysticks/wheels etc. and do not
> need network transparency.
>
> On the other hand, if one requires network transparency because the
> simulator machine(s) are separate from controller input or you need
> support for HID controllers that are not joysticks - such as tablets,
> the SpaceNavigator and similar, or virtual reality hardware, SDL will
> not help you. VRPN was built for that. BTW, basic VRPN client is
> probably even shorter than you SDL example.
>
> Regarding force feedback - there is no support for that in any
> officially released SDL version.
>
> Regards,
>
> Jan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFIoeX5n11XseNj94gRAlR8AKC2RXleH50RFXFUzBKnAAhUNiu/aACg0DI6
> JkOK/FuthnNucluwVmY05OI=
> =Ogbu
> -END PGP SIGNATURE-
>
> ___
> 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 / X-Code build problem

[Eric Sokolowsky]

Glad to hear this. I'm also glad to know that it works with installing OSG
into /usr/local.  My next task will be to get CMake to make real OSX
frameworks installed in /Library/Frameworks, or in a custom location, for
inclusion in a distributable app.
I'm also experiencing some strange crashing in my app under OSX (in
Leopard). It may be a library initialization issue. (But the same code works
perfectly under Linux.)

On Sun, Aug 10, 2008 at 5:01 AM, James Turner <[EMAIL PROTECTED]> wrote:

>
> On 8 Aug 2008, at 17:10, Eric Sokolowsky wrote:
>
>  So, bit of a mystery. I guess I'll build debug, see if I get the same
>>> issue, then step through the osgDB plugin loading code.
>>>
>> Yes, strange. Let me know what you find. It bothers me that it's not Just
>> Working (TM). Are you using Carbon or X11 for OSG_WINDOWING_SYSTEM? What is
>> CMAKE_OSX_ARCHITECTURES set to?
>>
>> Has anyone else tried building and using the recent release on OSX?
>>
>
> Okay, I don't know what happened, but a completely clean build is working
> fine. Apologies for the trouble. Just to be clear, that's on two different
> 10.5 machines, using the CMake build to produce X-Code projects, and either
> not installed, or installed to /usr/local, OSG seems to work fine - I played
> around with many examples.
>
> Annoyingly the app I'm actually trying to get working is still crashing in
> OSG/GL code, but at least I'm now confident it's not OSG itself that is the
> culprit.
>
> Thanks for the advice,
>
> James
> ___
> 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] XCode 2.4.x build error on MAC OSX 10.4...

[Eric Sokolowsky]

In CMake, enable OSG_GLU_TESS_CALLBACK_TRIPLEDOT and see if that helps.
-Eric

On Mon, Aug 11, 2008 at 10:58 AM, Adrian Egli OpenSceneGraph (3D) <
[EMAIL PROTECTED]> wrote:

> cd /Users/PWD/dev/OpenSceneGraphSVN
> /usr/bin/gcc-4.0 -x c++ -arch ppc -pipe -Wno-trigraphs -fpascal-strings
> -fasm-blocks -O3 -DCMAKE_INTDIR=\"Release\" -DosgUtil_EXPORTS
> -DOSG_DEBUG_POSTFIX=\"d\" -DOSGUTIL_LIBRARY -fmessage-length=0 -mtune=G4
> -mmacosx-version-min=10.4 -Wmost -Wno-four-char-constants
> -Wno-unknown-pragmas -O3 -F/Users/PWD/dev/OpenSceneGraphSVN/lib/Release
> -I/Users/PWD/dev/OpenSceneGraphSVN/lib/Release/include
> -I/Users/PWD/dev/OpenSceneGraphSVN/include
> -I/Users/PWD/dev/OpenSceneGraphSVN/lib/OpenSceneGraph.build/Release/libosgUtil.dylib.build/DerivedSources
> -mmacosx-version-min=10.4 -ftree-vectorize -fvisibility-inlines-hidden -O3
> -DNDEBUG -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp -o
> /Users/PWD/dev/OpenSceneGraphSVN/lib/OpenSceneGraph.build/Release/libosgUtil.dylib.build/Objects-normal/ppc/Tessellator.o
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp: In member
> function 'void osgUtil::Tessellator::beginTessellation()':
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:44: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:44: error:
> initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum,
> GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:45: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:45: error:
> initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum,
> GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:46: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:46: error:
> initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum,
> GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:47: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:47: error:
> initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum,
> GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:48: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:48: error:
> initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum,
> GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp: At global
> scope:
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:603: warning:
> 'unsigned int _computeNumberOfPrimitives(const osg::Geometry&)' defined but
> not used
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:44: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:44:
> error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*,
> GLenum, GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:45: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:45:
> error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*,
> GLenum, GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:46: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:46:
> error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*,
> GLenum, GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:47: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:47:
> error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*,
> GLenum, GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:48: error:
> invalid conversion from 'void (*)()' to 'GLvoid (*)(...)'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp:48:
> error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*,
> GLenum, GLvoid (*)(...))'
> /Users/PWD/dev/OpenSceneGraphSVN/src/osgUtil/Tessellator.cpp: At global
> scope:
>
>
> --
> 
> Adrian Egli
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-use

Re: [osg-users] Mac / X-Code build problem

[Eric Sokolowsky]

James Turner wrote:


On 8 Aug 2008, at 14:43, Eric Sokolowsky wrote:

Hmm. This is very strange. I do not get this problem. The only thing 
that I do differently is that I don't install into /usr/local. Can 
you try running osgviewer from the directory where it is built? You 
may need to set OSG_LIBRARY_PATH to point to your plugins directory. 
Can you also show the results of "otool -L /path/to/osgviewer"?


Tried using the 'uninstalled' versions, same result.

otool -L gives the following, which all looks sane to me:

MacPro:Release jmt$ otool -L osgviewer
osgviewer:
/Users/jmt/Code/OSG/build-release/lib/Release/libosgViewer.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libosgGA.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libosgText.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libosgDB.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libosgUtil.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libosg.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/jmt/Code/OSG/build-release/lib/Release/libOpenThreads.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 111.1.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 136.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)


You can also set your OSG_FILE_PATH to point to the 
OpenSceneGraph-Data directory if you don't want to keep typing that 
path.


Yep,. had actually done that, hadn't realised it worked for command 
line args as well.


So, bit of a mystery. I guess I'll build debug, see if I get the same 
issue, then step through the osgDB plugin loading code.
Yes, strange. Let me know what you find. It bothers me that it's not 
Just Working (TM). Are you using Carbon or X11 for OSG_WINDOWING_SYSTEM? 
What is CMAKE_OSX_ARCHITECTURES set to?


Has anyone else tried building and using the recent release on OSX?

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

Re: [osg-users] Mac / X-Code build problem

[Eric Sokolowsky]

James Turner wrote:


On 6 Aug 2008, at 22:22, James Turner wrote:

Anyway, thanks for pointing this out. I will go and try a CMake build 
now.


With a Cmake based build of 2.6.0, I can build OSG fine, but again at 
runtime things don't seem at all happy. (In a different way to the 
problems I encountered with the Xcode projects, though - no crazy 
crashes, so far)


For example, trying to view one of the sample data files with 
osgviewer, I get: (with OSG_NOTIFY_LEVEL=DEBUG)


MacPro:Release jmt$ ./osgviewer 
/Users/jmt/Code/OSG/OpenSceneGraph-Data/cow.osg

GraphicsContext::setWindowingSystemInterface() 0x70a5b00x620c48
CullSettings::readEnvironmentalVariables()
<4 repeats>
DriveManipulator::_height set to ==1.5
CullSettings::readEnvironmentalVariables()
<9 repeats>
itr='/Users/jmt/Library/Application Support/OpenSceneGraph/PlugIns'
FindFileInPath() : trying /Users/jmt/Library/Application 
Support/OpenSceneGraph/PlugIns/osgPlugins-2.6.0/osgdb_osg.so ...

itr='/Library/Application Support/OpenSceneGraph/PlugIns'
FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/osgdb_osg.so 
...

FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_osg.so
CullSettings::readEnvironmentalVariables()
CullSettings::readEnvironmentalVariables()
Opened DynamicLibrary osgPlugins-2.6.0/osgdb_osg.so
Warning: Could not find plugin to read objects from file 
"/Users/jmt/Code/OSG/OpenSceneGraph-Data/cow.osg".

./osgviewer: No data loaded

And the same happens with any other example - plugins are found and 
'opened' fine, but that's immediately followed by an error message 
indicating that no suitable plugin could be found.


As far as I know, I've followed the instructions in the README - 
unpack the zip, use the Cmake gui, build with Xcode, install to 
/usr/local


So I come back to, I must have screwed something up, but I'm unclear 
what.
Hmm. This is very strange. I do not get this problem. The only thing 
that I do differently is that I don't install into /usr/local. Can you 
try running osgviewer from the directory where it is built? You may need 
to set OSG_LIBRARY_PATH to point to your plugins directory. Can you also 
show the results of "otool -L /path/to/osgviewer"?


You can also set your OSG_FILE_PATH to point to the OpenSceneGraph-Data 
directory if you don't want to keep typing that path.


-Eric

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

Re: [osg-users] Mac / X-Code build problem

[Eric Sokolowsky]

James Turner wrote:
I'm encountering a bizarre problem with my X-Code build - with (so 
far) 2.5.5 and the 2.6.0-rc2 (will try 2.6.0-final in a moment). I'll 
say right now that I assume it must be a local config problem, I'm not 
trying to blame OSG for the problem (much), just need some help to get 
things working.


Using the supplied X-Code projects, I can build all of OSG just fine. 
It so happens that I'm switching the SDK from 10.4 to 10.5, and I have 
to fix one path in project to build : the osgWidgets path references 
itself via a path that only works in checkout, not a snapshot. Both of 
these things seem pretty minor and unrelated to the problem I'm having.


The problem is, having built **all** of OSG (in either debug or 
release, BTW), nothing works - all the OSG apps launch, but segfault 
within a few seconds - some immediately, some others sort of work 
(osgplanets, untextured) but then crash, others load but the display 
is broken (osgforrest, the tree billboard quads are random colors, 
then it crashes) and so on. The crashes are all very strange - deep 
inside the AGL / CGL code, pthread mutex or condvar internal segfaults 
(loads of these), or just in the guts of the GL driver. Most seem to 
be mangled pointers, but when I look at the OSG objects on the stack, 
they usually look okay - no obvious corruption, though I'm guessing 
what values are sane for the OSG internals.


So, something is obviously very screwed up with my build (or my 
runtime environment). I've built and run countless other GL 
applications with the same tool chain, and I build C++ apps every day 
- I am sceptical that something is seriously wrong with my compiler / 
OpenGL framework / GL driver. Oh, yes, this happens on two different 
machines (both running 10.5 and X-Code 3.0 / 3.1), a MacPro and a 
MacBook Pro.


S - what on earth can be going on? I'm looking forward to testing 
a binary 2.6.0 release, but I'm also mystified. The whole thing feels 
like memory corruption or some hellish threading problem, but I don't 
see why I would be getting those when no one else is.


So, any bright ideas? I'd be happy to have my amazingly dumb mistake 
pointed out.


I suppose I should try a Cmake build of 2.6.0 as well.

James,

I can't speak about the Xcode project that comes with OSG, but I believe 
it is no longer actively maintained. While Xcode support is still far 
from perfect within CMake, I have made many recent improvements to the 
CMake build system Xcode generator. Give it a try. CMake 2.6 is 
required, and there is a nice GUI version on the CMake downloads page.


There are several caveats to building OSG on OSX that you should be 
aware of. Read the README.txt file in the base directory of the OSG 2.6 
source code. Feedback is welcome.


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

Re: [osg-users] OpenScenGraph-2.6.0-rc2 tagged

[Eric Sokolowsky]

That works for me. Thanks.

On Tue, Aug 5, 2008 at 3:22 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Eric,
>
> Rather than go for a separate README just for OSX, I've added your
> release notes at the bottom of existing README.txt.  This is now
> checked in the OpenSceneGraph-2.6 branch and svn.
>
> Robert.
>
> On Tue, Aug 5, 2008 at 7:54 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > I'm not opposed to adding the notes to the wiki, but I really want to
> > include the text file with the distribution also. I propose a new file,
> > README-OSX.txt in the main directory. I have attached a copy. I welcome
> > suggestions.
> > -Eric
> >
> > On Tue, Aug 5, 2008 at 1:55 PM, Robert Osfield <[EMAIL PROTECTED]
> >
> > wrote:
> >>
> >> On Tue, Aug 5, 2008 at 5:50 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> >> wrote:
> >> > Robert,
> >> > For the release notes of 2.6, I'd like to include a statement on OSX
> >> > compatibility. I'll draft something up for inclusion in about half an
> >> > hour
> >> > or so.
> >>
> >> We'll we've never actually had proper release notes before ;-)
> >>
> >> What we could do is just put release notes on the wiki.
> >>
> >> 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
> >
> >
> ___
> 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] OpenScenGraph-2.6.0-rc2 tagged

[Eric Sokolowsky]

I'm not opposed to adding the notes to the wiki, but I really want to
include the text file with the distribution also. I propose a new file,
README-OSX.txt in the main directory. I have attached a copy. I welcome
suggestions.
-Eric

On Tue, Aug 5, 2008 at 1:55 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> On Tue, Aug 5, 2008 at 5:50 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > Robert,
> > For the release notes of 2.6, I'd like to include a statement on OSX
> > compatibility. I'll draft something up for inclusion in about half an
> hour
> > or so.
>
> We'll we've never actually had proper release notes before ;-)
>
> What we could do is just put release notes on the wiki.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
OpenSceneGraph 2.6 Release Notes for Macintosh OSX

There are several ways to compile OpenSceneGraph under OSX.  The
recommended way is to use CMake 2.6 to generate Xcode projects, then use
Xcode to build the library. The default project will be able to build
Debug or Release libraries, examples, and sample applications. Here are
some key settings to consider when using CMake:

BUILD_OSG_EXAMPLES - By default this is turned off. Turn this setting on
to compile many great example programs.

CMAKE_OSX_ARCHITECTURES - Xcode can create applications, executables,
libraries, and frameworks that can be run on more than one architecture.
Use this setting to indicate the architectures on which to build OSG.
Possibilities include ppc, ppc64, i386, and x86_64. Building OSG using
either of the 64-bit options (ppc64 and x86_64) has its own caveats
below.

OSG_BUILD_APPLICATION_BUNDLES - Normally only executable binaries are
created for the examples and sample applications. Turn this option on if
you want to create real OSX .app bundles. There are caveats to creating
.app bundles, see below.

OSG_WINDOWING_SYSTEM - You have the choice to use Carbon or X11 when
building applications on OSX. Under Leopard and later, X11 applications,
when started, will automatically launch X11 when needed. However,
full-screen X11 applications will still show the menu bar at the top of
the screen. Since many parts of the Carbon user interface are not
64-bit, X11 is the only supported option for OSX applications compiled
for ppc64 or x86_64.

There is an Xcode directory in the base of the OSG software
distribution, but its future is limited, and will be discontinued once
the CMake project generator completely implements its functionality.


APPLICATION BUNDLES (.app bundles)

The example programs when built as application bundles only contain the
executable file. They do not contain the dependent libraries as would a
normal bundle, so they are not generally portable to other machines.
They also do not know where to find plugins. An environmental variable
OSG_LIBRARY_PATH may be set to point to the location where the plugin
.so files are located. OSG_FILE_PATH may be set to point to the location
where data files are located. Setting OSG_FILE_PATH to the
OpenSceneGraph-Data directory is very useful when testing OSG by running
the example programs.

Many of the example programs use command-line arguments. When
double-clicking on an application (or using the equivalent "open"
command on the command line) only those examples and applications that
do not require command-line arguments will successfully run. The
executable file within the .app bundle can be run from the command-line
if command-line arguments are needed.


64-BIT APPLICATION SUPPORT

OpenSceneGraph will not compile successfully OSG_WINDOWING_SYSTEM is
Carbon and either x86_64 or ppc64 is selected under
CMAKE_OSX_ARCHITECTURES. A version of the osgviewer library written in
Cocoa is needed. However, OSG may be compiled under 64-bits if the X11
windowing system is selected. However, Two parts of the OSG default
distribution will not work with 64-bit X11: the osgviewerWX example
program and the osgdb_qt (Quicktime) plugin. These must be removed from
the Xcode project after Cmake generates it in order to compile with
64-bit architectures. The lack of the latter means that images such as
jpeg, tiff, png, and gif will not work, nor will animations dependent on
Quicktime. A new ImageIO-based plugin is being developed to handle the
still images, and a QTKit plugin will need to be developed to handle
animations.



Created by Eric Sokolowsky, August 5, 2008
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenScenGraph-2.6.0-rc2 tagged

[Eric Sokolowsky]

With a clean build, OSX 64-bit works well, except for the parts that are
known not to work; i.e. osgviewerWX example and osgdb_qt (Quicktime plugin).
-Eric

On Tue, Aug 5, 2008 at 12:46 PM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:

> With a clean build, OSX 32-bit X11 works well. I tried a number of
> examples, including osgviewer. I'm going to test OSX 64-bit with X11 with a
> clean build next.
> -Eric
>
>
> On Tue, Aug 5, 2008 at 11:39 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:
>
>> Hi All,
>>
>> Over the last hours I have merged a change to Notify.cpp from me, and
>> two CMakeLists.txt changes for OSX build from Eric Sokolowski, I'm not
>> expecting fallout from these merges but it'll need testing...
>>
>> So... pretty please, could users do a svn update/checkout of the
>> OpenSceneGraph-2.6 branch.  I'll wait another couple of hours for
>> feedback then if there is no reported problems go ahead and tag 2.6.0
>> this evening.
>>
>> Thanks for your help in testing ;-)
>> 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] OpenScenGraph-2.6.0-rc2 tagged

[Eric Sokolowsky]

Robert,
For the release notes of 2.6, I'd like to include a statement on OSX
compatibility. I'll draft something up for inclusion in about half an hour
or so.

-Eric

On Tue, Aug 5, 2008 at 12:46 PM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:

> With a clean build, OSX 32-bit X11 works well. I tried a number of
> examples, including osgviewer. I'm going to test OSX 64-bit with X11 with a
> clean build next.
> -Eric
>
>
> On Tue, Aug 5, 2008 at 11:39 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:
>
>> Hi All,
>>
>> Over the last hours I have merged a change to Notify.cpp from me, and
>> two CMakeLists.txt changes for OSX build from Eric Sokolowski, I'm not
>> expecting fallout from these merges but it'll need testing...
>>
>> So... pretty please, could users do a svn update/checkout of the
>> OpenSceneGraph-2.6 branch.  I'll wait another couple of hours for
>> feedback then if there is no reported problems go ahead and tag 2.6.0
>> this evening.
>>
>> Thanks for your help in testing ;-)
>> 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] OpenScenGraph-2.6.0-rc2 tagged

[Eric Sokolowsky]

With a clean build, OSX 32-bit X11 works well. I tried a number of examples,
including osgviewer. I'm going to test OSX 64-bit with X11 with a clean
build next.
-Eric

On Tue, Aug 5, 2008 at 11:39 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi All,
>
> Over the last hours I have merged a change to Notify.cpp from me, and
> two CMakeLists.txt changes for OSX build from Eric Sokolowski, I'm not
> expecting fallout from these merges but it'll need testing...
>
> So... pretty please, could users do a svn update/checkout of the
> OpenSceneGraph-2.6 branch.  I'll wait another couple of hours for
> feedback then if there is no reported problems go ahead and tag 2.6.0
> this evening.
>
> Thanks for your help in testing ;-)
> 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] OSX X11 build

[Eric Sokolowsky]

Perhaps I did. Let me try again.

On Tue, Aug 5, 2008 at 11:22 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Eric,
>
> The file is identical to the one that is already in svn/trunk.  Did
> you send the wrong file?
>
> Robert.
>
> On Tue, Aug 5, 2008 at 4:13 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > Ok, here it is, attached.
> >
> > On Tue, Aug 5, 2008 at 11:04 AM, Robert Osfield <
> [EMAIL PROTECTED]>
> > wrote:
> >>
> >> Hi Eric,
> >>
> >> I could edit by hand, but I won't be able to check whether the change
> >> works or not.  Could you edit it and test then post the changes to me.
> >>
> >> Thanks,
> >> Robert
> >>
> >> On Tue, Aug 5, 2008 at 3:55 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> >> wrote:
> >> > After updating to the latest svn, I noticed that 64-bit compilation is
> >> > enabled by default on OSX (See line 532 of the main CMakeLists.txt).
> >> > This is
> >> > still broken. The default should be for 32-bit compilations so the
> build
> >> > is
> >> > not broken out of the box. We just need to remove ppc64 and x86_64
> from
> >> > that
> >> > build. Users that know what they are doing can easily add it back in
> >> > through
> >> > cmake and use the other workarounds I already posted.
> >> > -Eric
> >> >
> >> > On Tue, Aug 5, 2008 at 10:45 AM, Eric Sokolowsky <[EMAIL PROTECTED]>
> >> > wrote:
> >> >>
> >> >>
> >> >> On Tue, Aug 5, 2008 at 10:44 AM, Eric Sokolowsky <[EMAIL PROTECTED]
> >
> >> >> wrote:
> >> >>>
> >> >>> This change only fixes libosgviewer for X11 (32- and 64-bit). It
> does
> >> >>> not
> >> >>> fix the two remaining issues: the osgviewerWX example and the
> osgdb_qt
> >> >>> Quicktime plugin. Neither compile with 64-bit. So, out of the box,
> the
> >> >>> 64-bit build on OSX is still broken. However, another bug (which I
> >> >>> have
> >> >>> deliberately not fixed yet) keeps the default to 32-bit compilation,
> >> >>> so
> >> >>> things are not broken out-of-the-box.
> >> >>> So here are the steps to take to compile 64-bit on OSX:
> >> >>> Add ppc64 and/or x86_64 to CMAKE_OSX_ARCHITECTURES
> >> >>> Generate the Xcode project
> >> >>> Remove osgdb_qt and osgviewerWX from the list of targets within
> Xcode
> >> >>> Build
> >> >>> Doing this will compile, but images such as tiff, jpeg, gif, and png
> >> >>> will
> >> >>> not be supported.
> >> >>
> >> >> Note that this is only for 64-bit apps. 32-bit apps seem to work just
> >> >> fine
> >> >> when compiled against X11 or Carbon.
> >> >> -Eric
> >> >
> >> > ___
> >> > 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
>
IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4 
AND ${CMAKE_PATCH_VERSION} LESS 7)
MESSAGE("Warning: A critical CMake bug exists in 2.4.6 and below. 
Trying to build Universal Binaries will result in a compile error that seems 
unrelated. Either avoid building Universal Binaries by changing the 
CMAKE_OSX_ARCHITECTURES field to list only your architecture, or upgrade to the 
current CVS version of CMake or a newer stable v

Re: [osg-users] OSX X11 build

[Eric Sokolowsky]

Ok, here it is, attached.

On Tue, Aug 5, 2008 at 11:04 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Eric,
>
> I could edit by hand, but I won't be able to check whether the change
> works or not.  Could you edit it and test then post the changes to me.
>
> Thanks,
> Robert
>
> On Tue, Aug 5, 2008 at 3:55 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > After updating to the latest svn, I noticed that 64-bit compilation is
> > enabled by default on OSX (See line 532 of the main CMakeLists.txt). This
> is
> > still broken. The default should be for 32-bit compilations so the build
> is
> > not broken out of the box. We just need to remove ppc64 and x86_64 from
> that
> > build. Users that know what they are doing can easily add it back in
> through
> > cmake and use the other workarounds I already posted.
> > -Eric
> >
> > On Tue, Aug 5, 2008 at 10:45 AM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> >>
> >>
> >> On Tue, Aug 5, 2008 at 10:44 AM, Eric Sokolowsky <[EMAIL PROTECTED]>
> >> wrote:
> >>>
> >>> This change only fixes libosgviewer for X11 (32- and 64-bit). It does
> not
> >>> fix the two remaining issues: the osgviewerWX example and the osgdb_qt
> >>> Quicktime plugin. Neither compile with 64-bit. So, out of the box, the
> >>> 64-bit build on OSX is still broken. However, another bug (which I have
> >>> deliberately not fixed yet) keeps the default to 32-bit compilation, so
> >>> things are not broken out-of-the-box.
> >>> So here are the steps to take to compile 64-bit on OSX:
> >>> Add ppc64 and/or x86_64 to CMAKE_OSX_ARCHITECTURES
> >>> Generate the Xcode project
> >>> Remove osgdb_qt and osgviewerWX from the list of targets within Xcode
> >>> Build
> >>> Doing this will compile, but images such as tiff, jpeg, gif, and png
> will
> >>> not be supported.
> >>
> >> Note that this is only for 64-bit apps. 32-bit apps seem to work just
> fine
> >> when compiled against X11 or Carbon.
> >> -Eric
> >
> > ___
> > 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
>
IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4 
AND ${CMAKE_PATCH_VERSION} LESS 7)
MESSAGE("Warning: A critical CMake bug exists in 2.4.6 and below. 
Trying to build Universal Binaries will result in a compile error that seems 
unrelated. Either avoid building Universal Binaries by changing the 
CMAKE_OSX_ARCHITECTURES field to list only your architecture, or upgrade to the 
current CVS version of CMake or a newer stable version if it exists.")
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4 
AND ${CMAKE_PATCH_VERSION} LESS 7)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)

if(COMMAND cmake_policy)
# Works around warnings libraries linked against that don't
# have absolute paths (e.g. -lpthreads)
cmake_policy(SET CMP0003 NEW)

# Works around warnings about escaped quotes in ADD_DEFINITIONS
# statements.
cmake_policy(SET CMP0005 NEW)
endif(COMMAND cmake_policy)

PROJECT(OpenSceneGraph)

SET(OPENSCENEGRAPH_MAJOR_VERSION 2)
SET(OPENSCENEGRAPH_MINOR_VERSION 6)
SET(OPENSCENEGRAPH_PATCH_VERSION 0)
SET(OPENSCENEGRAPH_SOVERSION 44)

SET(OPENSCENEGRAPH_VERSION 
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})

SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})

SET(OSG_PLUGIN_PREFIX "")

IF (CYGWIN)
SET(OSG_PLUGIN_PREFIX "cygwin_")
ENDIF(CYGWIN)

IF(MINGW)
SET(OSG_PLUGIN_PREFIX "mingw_")
ENDIF(MINGW)


# We want to build SONAMES shared librariess
SET(OPENSCENEGRAPH_SONAMES TRUE)
SET(OPENTHREADS_SONAMES TRUE)

SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR})

# We have some custom .cmake scripts not in the official distribution.
# Maybe this can be used override existing behavior if needed?
SET(CMAKE_MODULE_PATH 
"${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH}")

# Mainly for Windows as a convenience. This will find a directory in parallel 
with the
# O

Re: [osg-users] OSX X11 build

[Eric Sokolowsky]

I did not text all of the apps and examples. I did test osgviewer with an
image as the object to view. I also tested osgversion.

On Tue, Aug 5, 2008 at 11:01 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> On Tue, Aug 5, 2008 at 3:57 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
>
> > Yes. The change is required to get the osgviewer library to compile
> without
> > errors under X11.
>
> But does it run successfully? i.e. do all the osg apps and examples
> compile and run in X11 mode?
>
> 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] OSX X11 build

[Eric Sokolowsky]

On Tue, Aug 5, 2008 at 10:49 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Eric,
>
> On Tue, Aug 5, 2008 at 3:45 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > Note that this is only for 64-bit apps. 32-bit apps seem to work just
> fine
> > when compiled against X11 or Carbon.
>
> Just to be clear, with your change to CMakeLists.txt, osgviewer
> application and libosgViewer libs work fine under X11?
>

Yes. The change is required to get the osgviewer library to compile without
errors under X11.

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

Re: [osg-users] OSX X11 build

[Eric Sokolowsky]

After updating to the latest svn, I noticed that 64-bit compilation is
enabled by default on OSX (See line 532 of the main CMakeLists.txt). This is
still broken. The default should be for 32-bit compilations so the build is
not broken out of the box. We just need to remove ppc64 and x86_64 from that
build. Users that know what they are doing can easily add it back in through
cmake and use the other workarounds I already posted.
-Eric

On Tue, Aug 5, 2008 at 10:45 AM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:

>
>
> On Tue, Aug 5, 2008 at 10:44 AM, Eric Sokolowsky <[EMAIL PROTECTED]>wrote:
>
>> This change only fixes libosgviewer for X11 (32- and 64-bit). It does not
>> fix the two remaining issues: the osgviewerWX example and the osgdb_qt
>> Quicktime plugin. Neither compile with 64-bit. So, out of the box, the
>> 64-bit build on OSX is still broken. However, another bug (which I have
>> deliberately not fixed yet) keeps the default to 32-bit compilation, so
>> things are not broken out-of-the-box.
>> So here are the steps to take to compile 64-bit on OSX:
>> Add ppc64 and/or x86_64 to CMAKE_OSX_ARCHITECTURES
>> Generate the Xcode project
>> Remove osgdb_qt and osgviewerWX from the list of targets within Xcode
>> Build
>>
>> Doing this will compile, but images such as tiff, jpeg, gif, and png will
>> not be supported.
>>
>
> Note that this is only for 64-bit apps. 32-bit apps seem to work just fine
> when compiled against X11 or Carbon.
>
> -Eric
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSX X11 build

[Eric Sokolowsky]

On Tue, Aug 5, 2008 at 10:44 AM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:

> This change only fixes libosgviewer for X11 (32- and 64-bit). It does not
> fix the two remaining issues: the osgviewerWX example and the osgdb_qt
> Quicktime plugin. Neither compile with 64-bit. So, out of the box, the
> 64-bit build on OSX is still broken. However, another bug (which I have
> deliberately not fixed yet) keeps the default to 32-bit compilation, so
> things are not broken out-of-the-box.
> So here are the steps to take to compile 64-bit on OSX:
> Add ppc64 and/or x86_64 to CMAKE_OSX_ARCHITECTURES
> Generate the Xcode project
> Remove osgdb_qt and osgviewerWX from the list of targets within Xcode
> Build
>
> Doing this will compile, but images such as tiff, jpeg, gif, and png will
> not be supported.
>

Note that this is only for 64-bit apps. 32-bit apps seem to work just fine
when compiled against X11 or Carbon.

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

Re: [osg-users] OSX X11 build

[Eric Sokolowsky]

This change only fixes libosgviewer for X11 (32- and 64-bit). It does not
fix the two remaining issues: the osgviewerWX example and the osgdb_qt
Quicktime plugin. Neither compile with 64-bit. So, out of the box, the
64-bit build on OSX is still broken. However, another bug (which I have
deliberately not fixed yet) keeps the default to 32-bit compilation, so
things are not broken out-of-the-box.
So here are the steps to take to compile 64-bit on OSX:
Add ppc64 and/or x86_64 to CMAKE_OSX_ARCHITECTURES
Generate the Xcode project
Remove osgdb_qt and osgviewerWX from the list of targets within Xcode
Build

Doing this will compile, but images such as tiff, jpeg, gif, and png will
not be supported.

-Eric

On Tue, Aug 5, 2008 at 10:29 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Thanks Eric,
>
> I'm just trying a build with your changed CMakeLists.txt file, so far so
> good.
>
> Does this change mean that OSX Cmake build is able to correctly
> compile, link and run against X11?
>
> Robert.
>
> On Tue, Aug 5, 2008 at 3:16 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> wrote:
> > Attached is src/osgViewer/CMakeLists.txt. Log message, if you choose to
> > include the changes:
> > From Eric Sokolowsky: Fixed the build of the osgViewer library to get
> > GL/glx.h from the right place, when building on OSX with X11.
> >
> > -Eric
> >
> > On Tue, Aug 5, 2008 at 9:10 AM, Robert Osfield <[EMAIL PROTECTED]
> >
> > wrote:
> >>
> >> Hi Eric,
> >>
> >> On Tue, Aug 5, 2008 at 1:40 PM, Eric Sokolowsky <[EMAIL PROTECTED]>
> >> wrote:
> >> > The proper place to get GL/glx.h depends on which target platform
> you're
> >> > compiling against. If you are compiling against the 10.4u SDK, then
> the
> >> > first location (in the list that you found below) is proper. If 10.5,
> >> > the
> >> > second. I have implemented a change (not checked in yet, I'm planning
> on
> >> > checking it in later today) that will, using CMake, automatically
> detect
> >> > where glx.h is located and use that one.
> >>
> >> Could you send the changes to me to review so I can make a judgement
> >> call on whether it's safe to integrate this change before 2.6.0 gets
> >> tagged.
> >>
> >> Thanks,
> >> 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
> >
> >
> ___
> 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