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 robert.osfi...@gmail.com
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 karc...@poczta.onet.pl 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

[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] 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 robert.osfi...@gmail.com
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 e...@byu.net 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]

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 e...@byu.net 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 robert.osfi...@gmail.com
 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 e...@byu.net 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] Does OSG support reading RGB8/RGBA8 PNG image data?

[Eric Sokolowsky]

On Wed, Dec 10, 2014 at 9:32 AM, Robert Osfield robert.osfi...@gmail.com
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 jerezjul...@gmail.com 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 se.leg...@gmail.comwrote:

 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 robert.osfi...@gmail.comwrote:

 Hi Eric,

 On 3 June 2013 11:42, Eric Sokolowsky esok@gmail.com 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

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
richa...@spawar.navy.milwrote:

 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 jer...@emperorlinux.comwrote:

 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 robert.osfi...@gmail.comwrote:

 Hi Paul,

 On Fri, Jun 10, 2011 at 12:09 AM, Paul Martz pma...@skew-matrix.com
 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] 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 ewmail...@gmail.com 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 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 pma...@skew-matrix.com 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] 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 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 esok@gmail.com 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 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 pma...@skew-matrix.com 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::mapstd::string 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]

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 esok@gmail.com
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]

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 esok@gmail.com
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]

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]

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

[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

[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

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 esok@gmail.com 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

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 esok@gmail.com 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] Unicode text with osg

[Eric Sokolowsky]

Farshid Lashkari wrote:

Hi Eric

On Thu, May 26, 2011 at 7:07 AM, Eric Sokolowsky esok@gmail.com 
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

[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] 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

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 esok@gmail.com 
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

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

[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 seber...@energid.orgwrote:

 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] 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 ke...@nist.gov 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] 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] 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,
 
 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

[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] 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 Sokolowskyesok@gmail.com 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

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] 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] 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 shayne.tuel...@hill.af.mil 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

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

[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 osg/GLExtensions
#include osgUtil/GLObjectsVisitor
#include osgGA/TrackballManipulator
#include osgViewer/CompositeViewer
#include osgViewer/Renderer
#include osgDB/Registry
#include osgDB/ReadFile

#include osg/io_utils

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()std::endl;

stopThreading();

Scenes scenes;
getScenes(scenes);

for(Scenes::iterator sitr = scenes.begin();
sitr != scenes.end();
++sitr)
{
Scene* scene = *sitr;
if (scene-getDatabasePager())
{
scene-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()std::endl;
}

bool CompositeViewer::readConfiguration(const std::string filename)
{
osg::notify(osg::NOTICE)CompositeViewer::readConfiguration(filename)std::endl;
osg::ref_ptrosg::Object obj = osgDB::readObjectFile(filename);
osgViewer::View * view = dynamic_castosgViewer::View *(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; iview-getNumSlaves(); ++i)
   

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 pma...@skew-matrix.com

  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

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 pma...@skew-matrix.com

  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 pma...@skew-matrix.com

  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

[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 osgfo...@tevs.eu 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 FILENAME

 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] New ffmpeg plugin checked into svn/trunk

[Eric Sokolowsky]

Robert Osfield wrote:
 
 On Thu, Feb 26, 2009 at 12:10 PM, Stephan Maximilian Huber
 ratzf...@digitalmind.de 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

[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.
---BeginMessage---
-- Forwarded message --
From: E. Wing ewmail...@gmail.com
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:
 Hi Eric,
 
 On Thu, Feb 26, 2009 at 1:41 PM, Eric Sokolowsky esok@gmail.com 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 ApplicationServices/ApplicationServices.h
// For the vImage framework (part of the Accerlate framework)
#include Accelerate/Accelerate.h

// Used because CGDataProviderCreate became deprecated

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

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] 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] 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-users@lists.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] 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:


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:
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]

Paul,
It looks like the osgviewerWX plugin is pulling in Carbon stuff and/or
Quicktime stuff for 64-bit. I imagine it's actually in the WXWidgets library
itself, not necessarily the example code. I'm sorry I don't have the error
in front of me, and it would take some time to generate. I am willing to do
it if it will be useful to you though.

-Eric

On Mon, Aug 4, 2008 at 4:58 PM, Paul Melis [EMAIL PROTECTED] wrote:

 Eric Sokolowsky wrote:

 Robert Osfield wrote:

 Hi All,

 I have now tagged the 2.6.0 release candidate 2, you can grab it from
 the downloads page:




 libosgviewer will not build in 64-bit under Carbon (ppc64 or x86_64)
 osgviewerWX example will not build in 64-bit under Carbon or X11 (ppc64 or
 x86_64)

 What's the build error you get with osgviewerWX?

 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] OSX X11 build

[Eric Sokolowsky]

Frank van Meurs wrote:

On Jul 25, 2008, at 11:33 PM, Eric Sokolowsky wrote:

I've been away from OSG for a few weeks (vacations, other projects, 
etc) but I have some time to get back to it. I'm encountering trouble 
building OSG with X11 because CMake can't find GL/glx.h. I'm going to 
keep banging away at this, but if anyone offhand knows how to get 
CMake to find the file in the right place, please let me know. This 
header file is needed to compile osgViewer (the library, not the 
application).


I intend to get this resolved before Robert releases OSG 2.6. I'm 
also trying to see if the X11 build will support 64-bit, which the 
Carbon build will not.


I'm wondering as to what the outcome of this was. I seem to encounter 
the same problem, but I can't figure out how to point the cmake system 
in the right direction as I don't know which (if there are any) 
options to set. Looking at my system, there's a few place where 
GL/glx.h is installed:


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.


-Eric

---SNIP---
dyn251% locate glx.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/GL/glx.h
/Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/GL/glx.h
/Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/xcb/glx.h
/usr/X11/include/GL/glx.h
/usr/X11/include/xcb/glx.h
--/SNIP---

So, apparently, the file missing entirely is not the problem.

Anybody?

Thanks! Frank
___
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]

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

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: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]

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]

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
# OSG source that contains 3rd party headers and libraries.
# Use of relative paths in CMake is ill-advised, but don't know of any 
alternatives in this case
#SET(CMAKE_INCLUDE_PATH 
${OpenSceneGraph_SOURCE_DIR}/../3rdParty/include;${CMAKE_INCLUDE_PATH})
#SET(CMAKE_LIBRARY_PATH 
${OpenSceneGraph_SOURCE_DIR}/../3rdParty/lib;${CMAKE_LIBRARY_PATH})
IF(USING_OSG_OP_OT_TRIPLE_SET)
SET(CMAKE_INCLUDE_PATH 
${OpenSceneGraph_SOURCE_DIR}/../../3rdParty/include;${CMAKE_INCLUDE_PATH})
SET(CMAKE_LIBRARY_PATH 
${OpenSceneGraph_SOURCE_DIR}/../../3rdParty/lib;${CMAKE_LIBRARY_PATH})
ENDIF(USING_OSG_OP_OT_TRIPLE_SET)


# Okay, here's the problem

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

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

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]

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]

Robert Osfield wrote:

Hi All,

I have now tagged the 2.6.0 release candidate 2, you can grab it from
the downloads page:

  


Robert,

I have made some minor fixes to the build system for OSX, but they are 
not complete yet. I have been swamped with other pressing issues at work 
and have not finished the work I was starting. The following issues are 
known:


libosgviewer will not build in 64-bit under Carbon (ppc64 or x86_64)
osgviewerWX example will not build in 64-bit under Carbon or X11 (ppc64 
or x86_64)


I want to at least let the user know that the build will fail in the 
first case by adding a fatal error. I think I can just disable the 
latter example from building with 64-bit compiles. There may be a couple 
of other examples that do not compile under 64-bit. I am testing the 
build by making bundle applications.


I'd really like these fixes to make it into this release. However, it's 
not ready yet. I can try to work on it tonight at home, if you can give 
me a day or so. Then I'd like at least a few others to test the build. 
If this is not feasible for this release, I understand, and life will go 
on, and these changes will make it to 2.6.1 or something.


-Eric

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

[osg-users] OSX X11 build

[Eric Sokolowsky]

I've been away from OSG for a few weeks (vacations, other projects, etc) but
I have some time to get back to it. I'm encountering trouble building OSG
with X11 because CMake can't find GL/glx.h. I'm going to keep banging away
at this, but if anyone offhand knows how to get CMake to find the file in
the right place, please let me know. This header file is needed to compile
osgViewer (the library, not the application).

I intend to get this resolved before Robert releases OSG 2.6. I'm also
trying to see if the X11 build will support 64-bit, which the Carbon build
will not.

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

Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3devreleasese

[Eric Sokolowsky]

On Wed, Jul 2, 2008 at 11:42 AM, Robert Osfield [EMAIL PROTECTED]
wrote:

 Hi Gerrick,

 I have never built VPB under OSX, and have to defer to developers that
 work under OSX for fixes/direction on that platforms.  What I have
 done is to try and mirror some of the changes that have being going
 into to core OSG to help with the OSX build side, but I don't have any
 first hand experience of testing it yet.

 I do have an G4 on loan, so I do plan to get this machine setup and
 test builds against it.  I will still need direction on OSX issues,
 though, as I'm no expert on this platform.


This has been fixed in the OSG hierarchy in CMakeModules/OsgMacroUtils.cmake
by replacing:

INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION
share/OpenSceneGraph/bin)

with:

IF(APPLE)
  INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION
share/OpenSceneGraph/bin BUNDLE DESTINATION share/OpenSceneGraph/bin)
ELSE(APPLE)
  INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION
share/OpenSceneGraph/bin)
ENDIF(APPLE)

You can also just use:
  cmake_policy(SET CMP0006 OLD)
but this just masks the warning without really fixing the problem.
-Eric




 Robert.

 On Wed, Jul 2, 2008 at 4:19 PM, Gerrick Bivins
 [EMAIL PROTECTED] wrote:
  Hi All,
  I thought I'd try to build VPB and I ran into this error (on MacOSX
 10.5.3
  with OSG svn):
 
  CMake Warning (dev) at CMakeModules/VpbMacroUtils.cmake:215 (INSTALL):
   Policy CMP0006 is not set: Installing MACOSX_BUNDLE targets requires a
   BUNDLE DESTINATION.  Run cmake --help-policy CMP0006 for policy
 details.
   se the cmake_policy command to set the policy and suppress this warning.
   Call Stack (most recent call first):
applications/osgdem/CMakeLists.txt:9 (SETUP_APPLICATION)
   This warning is for project developers.  Use -Wno-dev to suppress it.
 
 
   CMake Warning (dev) at CMakeModules/VpbMacroUtils.cmake:215 (INSTALL):
Policy CMP0006 is not set: Installing MACOSX_BUNDLE targets requires a
BUNDLE DESTINATION.  Run cmake --help-policy CMP0006 for policy
  details.
Use the cmake_policy command to set the policy and suppress this
 warning.
   Call Stack (most recent call first):
applications/vpbcache/CMakeLists.txt:9 (SETUP_APPLICATION)
   This warning is for project developers.  Use -Wno-dev to suppress it.
 
 
   CMake Warning (dev) at CMakeModules/VpbMacroUtils.cmake:215 (INSTALL):
Policy CMP0006 is not set: Installing MACOSX_BUNDLE targets requires a
BUNDLE DESTINATION.  Run cmake --help-policy CMP0006 for policy
  details.
Use the cmake_policy command to set the policy and suppress this
 warning.
   Call Stack (most recent call first):
applications/vpbsizes/CMakeLists.txt:9 (SETUP_APPLICATION)
   This warning is for project developers.  Use -Wno-dev to suppress it.
 
 
   CMake Warning (dev) at CMakeModules/VpbMacroUtils.cmake:215 (INSTALL):
Policy CMP0006 is not set: Installing MACOSX_BUNDLE targets requires a
BUNDLE DESTINATION.  Run cmake --help-policy CMP0006 for policy
  details.
Use the cmake_policy command to set the policy and suppress this
 warning.
   Call Stack (most recent call first):
applications/vpbmaster/CMakeLists.txt:9 (SETUP_APPLICATION)
   This warning is for project developers.  Use -Wno-dev to suppress it.
 
 
  I have VPB_BUILD_APPLICATION_BUNDLES enabled...Turning that option off
 makes
  the error go away. Is VPB not supposed to run as a bundled application?
  biv
 
 
 
 
 
 
 
 
 
  CMake produced the following output
 
  CMake Version 2.6 - patch 0
  Press [e] to exit help
 
 
 
 
  On 7/2/08 7:51 AM, Jean-Sébastien Guay 
 [EMAIL PROTECTED]
  wrote:
 
  Hi Adrian,
 
  osgshaders.exe
  osgthirdpersonview.exe
 
  hangs on exit.
 
  I can't reproduce that hang. Any chance you could give a stack trace?
 
  J-S
 
  ___
  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] Testing of OSG and VPB SVN in prep for 2.5.3devreleasese

[Eric Sokolowsky]

On Wed, Jul 2, 2008 at 2:02 PM, Gerrick Bivins [EMAIL PROTECTED]
wrote:

  Ok. I'll try the bundled flag again once I see the change is submitted.
 Thanks.
 Gerrick



I didn't (nor do I plan to) submit this change for VPB. You might want to
try it yourself and submit the change.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org