date:20081127

Hi,

Mathieu MARACHE wrote:

Ubuntu 8.10 x86 and x86_64
I edit mostly with vim and use eclipse ganymede CDT, codeblocks or
KDevelop as IDEs (thanks to CMake)
I diff graphically with meld ( http://meld.sourceforge.net for
screenshots, try it and forget xxdiff :-) )
I checkout with git-svn

P.S. thanks JP for the cscope hint, you learn every day :-)

cscope integrates nicely with emacs ;)

Do you know if meld can integrate nicely with svn? E.g. I can do

svn diff
svn merge

on command line and then it brings up xxdiff. Can meld do this (be an
diff app for svn)? If it can I will definitely try.

--
Mathieu

2008/11/26 Bob Huebert [EMAIL PROTECTED]:

Fedora Core 7 x86_64 with gcc 4.1.2

Sun box with AMD Opteron P250, 4GB

nVidia QuadroFX 3000 (agp 8x) with 256MB

-bob

Can T. Oguz wrote:

Dear OSG Users,

May I Ask which linux distribution and development environment you
chose to work on ?

Thank you for your time,

Can

___
osg-users mailing list
osg-users@lists.openscenegraph.org

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

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

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

Re: [osg-users] Packaging granularity + platform specific scripts

Hi J-S,

On Thu, Nov 27, 2008 at 3:01 AM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
 I agree, the biggest challenge for Windows is the number of different
 toolsets available. What we call the build matrix is just too large to be
 doable. There's MSVC7.1, MSVC8, MSVC9, cygwin, mingw. Then there's debug,
 release, relWithDebugInfo, ... Then there's static, dynamic, dynamic but
 with statically linked dependencies...

There isn't any way we can cover all the different combinations, the
best we can do is try and come up with a scheme where the
dependencies, and the OSG components can be built as seamlessly as
possible by end users.

Another step would then provide a community mechanism for uploading
the resulting binary/headers/source packages that others can
leverage.  Using the svn repository has been discussed as possible
location for this.

 On Linux, what's the strategy? Do we aim to offer binaries for all distros,
 some distros, the most popular, those which are used by the packagers? I
 think our strategy for distros on Linux could be transposed to be our
 strategy for toolsets on Windows.

Dependencies are much easier to deal with thanks to package managers
and great repositories.  The part that needs wrapping up under Linux
is making it easier for the distro's maintainers to pick up the OSG
sources and then generate the required binaries that they wish to
distribute.  The later is similar to needs of Windows.  We could
possible manage the packages ourselves and let the distro's grab
these, or just provide the scripts for them to use.

What I'm not currently happy about with the present status quo under
Linux is that there is little or no coordinate upstream from the
distro's to OSG development or granularity/versioning/naming of
packing.  What we should have is scheme that works well for the
distro's but is consistent across them so end users know that can grab
dependencies from a rpm or deb repository without any worries about
them contain different components/dependencies.


 As you've said, in the past only the dependencies and binaries for VC8 SP1
 were available. That was the most popular, and that was what Mike had / was
 willing to take the time out of his schedule to provide.

 That touches on the issue of volunteering time. As you said, people surely
 have built the VC7.1 and VC9 dependencies, but they just haven't put them up
 somewhere public. If that's the case, in all this time since 2.4 (when we
 had the last refresh of Mike's dependencies package), then I wonder if we'll
 be able to find someone willing to volunteer the time to do it officially.

This is reflection of our over dependence on the time and skills of
too small a group of engineers (i.,e Mike) , and lack of a process for
getting binaries made available in straight forward way.

Automating the process of creating dependency packages or more to the
point de-skilling the process would make it possible for more users to
get involved.   Automating the dependency build isn't trivial
though...

 That's one place where the Linux package management systems are a real boon,
 they totally remove this issue - you can just build an OSG package that
 depends on a given version of libjpeg-dev, freetype-dev, etc. and you're
 done, the package system will pull down the right version of the dependency
 automatically. I really wish there was something like that on Windows, at
 least for open source applications/libraries. That and a system-default
 place to install libraries like on Linux too...

Could we come up with a scheme that mirrors these packaging systems a
little?  I don't mean a full blown implementation of packaging system.
  Would it be possible to write a Cmake or Python script that manages
a directory tree of dependencies?

On the the dependency from I do wonder if providing CMakeLists.txt
files for the various dependencies and then a high level
CMakeLists.txt or other script that would pull together the
components.  Would we need to branch the source codes of the various
dependences for this?  Could we push support for such a coordinate
build scheme back upstream to the projects themselves?

 Then there's the issue of installers. I'm not sure an installer is the best
 way to package OSG for Windows. OSG itself is not an application, it's a set
 of developer libraries and example programs. I think making an installer
 would make people think that the examples can be run with a double-click,
 which in most cases is not true (most of the examples require command line
 arguments to run).

 I think a zip containing binaries and headers (what's needed to build a
 project linking to OSG) would be good enough. Sure, some libraries use
 installers (Wx, Qt come to mind) but I think it adds extra complexity and
 goes into parts of the system (the registry) which are not necessary. Plus,
 since there's no easy way to update software that's installed with
 installers (unistall + reinstall is the norm), just unzipping the new
 version is

Re: [osg-users] Linux Dev. Env. Poll


Hi,

Paul Melis wrote:

J.P. Delport wrote:

Hi,

Mathieu MARACHE wrote:

Do you know if meld can integrate nicely with svn? E.g. I can do

svn diff
svn merge

on command line and then it brings up xxdiff. Can meld do this (be an 
diff app for svn)? If it can I will definitely try.
There does seem to be the environment variable SVN_MERGE that subversion 
looks at, but I'm not sure if that one has only been introduced in a 
very recent subversion release.


I usually set diff-cmd and diff3-cmd in  ~/.subversion/config
to xx-diff-proxy. I was wondering if meld had something similar?

jp



Regards,
Paul




--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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

Re: [osg-users] Nvidia bug report [Fwd: Unable to create many (300) FBOs under Linux]


Hi all,

I have some progress to report on this, yay :)

I did not get a reply after I sent the email to [EMAIL PROTECTED], 
so yesterday I posted the same info to the nvnews forum.


http://www.nvnews.net/vbulletin/showthread.php?p=1856407

I received a reply within 24 hours, see below:

8
jamesjones
NVIDIA Corporation

FBO's are a limited resource. Do you really need hundreds of FBO's or do 
you just need to render to 100's of textures/renderbuffers? If the 
latter, change your FBO's textures rather than creating so many FBO's. 
There is a slight performance penalty for changing FBO bindings, but it 
shouldn't be too bad.


If you really need an unbounded number of FBO's, that's not gonna work. 
We can modify the limit, but you'd have to give us a good reason to.


The X errors, however, are a bug. That should be fixed in r180. The only 
side effect of creating too many FBO's should be a GL_OUT_OF_MEMORY 
error and bad framebuffer status.

8

I believe the first point is quite valid and one can try to limit the 
number of FBOs created. Doing the rebinding might be a bit challenging 
using current OSG, but maybe we can streamline the process. I can look 
at this, but any help and ideas are welcome. Does anyone know if OSGPPU 
supports the rebinding in an easy to use way? Art?


I understand that an unbounded number might not be possible, but I'd 
like an app that works on Windows to also work on Linux, so I'd like the 
limit to at least be the same. Anyone have any other reasons I can put 
forward?


I'm going to try r180 asap and will report any changes.

regards
jp

J.P. Delport wrote:

Hi all,

I've sent a bug report regarding the FBO problems under Linux to 
[EMAIL PROTECTED]


Will report back if I hear anything. I am not yet registered with NVidia 
so could not use the web form, but I hope the email will get somewhere.


jp

 Original Message 
Subject: Unable to create many (300) FBOs under Linux
Date: Tue, 18 Nov 2008 15:43:11 +0200
From: J.P. Delport [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

Good day,

we are trying to implement an image processing application using OpenGL
and OpenSceneGraph. Recenly one of our algorithms that require many FBOs
failed to run under Linux. The same code works fine under Windows.

I have attached a simple example that recreates the same errors on both
a Laptop with a GeForce Go 7400 and a desktop machine with a GTX280.

See the fbo_test.tgz file. The readme explains how to compile and run
the test application.

The errors from the two machines are in fbo_test_Go7400.txt and
fbo_test_GTX280.txt.

The nvidia-bug-report from the two machines are also attached.

The application was modified from a same problem report on the forums,
see here:

http://www.nvnews.net/vbulletin/showthread.php?t=88178

The issue has also been discussed on the OpenSceneGraph mailing list in
the following threads:

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

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

The osgmemorytest example was run by quite a few people and displayed
similar problems on a variety of Linux/NVidia machines. The
osgmemorytest example also manages to kill the X server on occasion.

A typical error report from osgmemorytest:

osgmemorytest --window --fbo 512 512 -g 300
iteration 0
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe574d0
BadAlloc (insufficient resources for operation)
Major opcode: 143
Minor opcode: 27
Error code: 11
Request serial: 2848
Current serial: 2849
   ResourceID: 48234499
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe57530
BadDrawable (invalid Pixmap or Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 9
Request serial: 2849
Current serial: 2849
   ResourceID: 48234499
Warning: detected OpenGL error 'out of memory' after applying attribute
FrameBufferObject 0x80aa470

Any information regarding this problem would be welcomed. Also please
contact me if further information is required.

regards
J.P. Delport








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


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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

Re: [osg-users] Nvidia bug report [Fwd: Unable to create many (300) FBOs under Linux]

Hi J.P.

Thanks for pursuing this.  Gotta say I'm a bit unimpressed by the
response from the Nvidia engineer, kinda sounds like he hasn't
properly read your post or the thread and has placed it under the
ignore it's a user problem category.

Rebinding textures with different FBO's is something we could look at
but it'll complicate the code significantly - we'd need to maintain a
pool of FBO's, and bind them dynamically.  While this might be a
worthy thing to do if we really want to be throwing tens of thousands
of FBO's into the system, but given we already know that Windows and
OSX drivers can manage a 1000 FBO's, the need for doing the rebinding
is rather moot - this is a driver issue.

Robert.

On Thu, Nov 27, 2008 at 11:25 AM, J.P. Delport [EMAIL PROTECTED] wrote:
 Hi all,

 I have some progress to report on this, yay :)

 I did not get a reply after I sent the email to [EMAIL PROTECTED], so
 yesterday I posted the same info to the nvnews forum.

 http://www.nvnews.net/vbulletin/showthread.php?p=1856407

 I received a reply within 24 hours, see below:

 8
 jamesjones
 NVIDIA Corporation

 FBO's are a limited resource. Do you really need hundreds of FBO's or do you
 just need to render to 100's of textures/renderbuffers? If the latter,
 change your FBO's textures rather than creating so many FBO's. There is a
 slight performance penalty for changing FBO bindings, but it shouldn't be
 too bad.

 If you really need an unbounded number of FBO's, that's not gonna work. We
 can modify the limit, but you'd have to give us a good reason to.

 The X errors, however, are a bug. That should be fixed in r180. The only
 side effect of creating too many FBO's should be a GL_OUT_OF_MEMORY error
 and bad framebuffer status.
 8

 I believe the first point is quite valid and one can try to limit the number
 of FBOs created. Doing the rebinding might be a bit challenging using
 current OSG, but maybe we can streamline the process. I can look at this,
 but any help and ideas are welcome. Does anyone know if OSGPPU supports the
 rebinding in an easy to use way? Art?

 I understand that an unbounded number might not be possible, but I'd like an
 app that works on Windows to also work on Linux, so I'd like the limit to at
 least be the same. Anyone have any other reasons I can put forward?

 I'm going to try r180 asap and will report any changes.

 regards
 jp

 J.P. Delport wrote:

 Hi all,

 I've sent a bug report regarding the FBO problems under Linux to
 [EMAIL PROTECTED]

 Will report back if I hear anything. I am not yet registered with NVidia
 so could not use the web form, but I hope the email will get somewhere.

 jp

  Original Message 
 Subject: Unable to create many (300) FBOs under Linux
 Date: Tue, 18 Nov 2008 15:43:11 +0200
 From: J.P. Delport [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]

 Good day,

 we are trying to implement an image processing application using OpenGL
 and OpenSceneGraph. Recenly one of our algorithms that require many FBOs
 failed to run under Linux. The same code works fine under Windows.

 I have attached a simple example that recreates the same errors on both
 a Laptop with a GeForce Go 7400 and a desktop machine with a GTX280.

 See the fbo_test.tgz file. The readme explains how to compile and run
 the test application.

 The errors from the two machines are in fbo_test_Go7400.txt and
 fbo_test_GTX280.txt.

 The nvidia-bug-report from the two machines are also attached.

 The application was modified from a same problem report on the forums,
 see here:

 http://www.nvnews.net/vbulletin/showthread.php?t=88178

 The issue has also been discussed on the OpenSceneGraph mailing list in
 the following threads:

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

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

 The osgmemorytest example was run by quite a few people and displayed
 similar problems on a variety of Linux/NVidia machines. The
 osgmemorytest example also manages to kill the X server on occasion.

 A typical error report from osgmemorytest:

 osgmemorytest --window --fbo 512 512 -g 300
 iteration 0
 Got an X11ErrorHandling call display=0x80c3418 event=0xbfe574d0
 BadAlloc (insufficient resources for operation)
 Major opcode: 143
 Minor opcode: 27
 Error code: 11
 Request serial: 2848
 Current serial: 2849
   ResourceID: 48234499
 Got an X11ErrorHandling call display=0x80c3418 event=0xbfe57530
 BadDrawable (invalid Pixmap or Window parameter)
 Major opcode: 145
 Minor opcode: 4
 Error code: 9
 Request serial: 2849
 Current serial: 2849
   ResourceID: 48234499
 Warning: detected OpenGL error 'out of memory' after applying attribute
 FrameBufferObject 0x80aa470

 Any information regarding this problem would be welcomed. Also please
 contact me if further information is required.

 regards
 J.P. Delport

Re: [osg-users] Linux Dev. Env. Poll

2008-11-27 Thread Gerwin de Haan

Ubuntu Hardy, g++/python , Visual Slickedit (commercial, but a really
powerful and fast IDE)

On Wed, Nov 26, 2008 at 1:36 PM, Can T. Oguz [EMAIL PROTECTED] wrote:
 Dear OSG Users,

 May I Ask which linux distribution and development environment you chose to
 work on ?

 Thank you for your time,

 Can
 ___
 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] lights not seem to be updated after load an object

2008-11-27 Thread Steffen B.

Hi,

i use the collada plugin from osg to load a *.dae file and display the 3d 
object in the osgProducer::Viewer.
If i load a scene with 1 light the first time everything is ok. now i load a 
scene with  8 lights and after that
i reload the scene with 1 light. the scene is really bright now. it seems as if 
all lights are still on. I google
a lot but i don't found a solution. has anyone a tip for me?

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

Re: [osg-users] Nvidia bug report [Fwd: Unable to create many (300) FBOs under Linux]


Hi Robert,

Robert Osfield wrote:

Hi J.P.

Thanks for pursuing this.  Gotta say I'm a bit unimpressed by the 
response from the Nvidia engineer, kinda sounds like he hasn't 
properly read your post or the thread and has placed it under the 
ignore it's a user problem category.


Well, I'm glad I at least got some reply. I'll keep pushing. The problem
was actually reported earlier (albeit a bit cryptically) on the forums
as well, but there were no responses.



Rebinding textures with different FBO's is something we could look at
 but it'll complicate the code significantly - we'd need to maintain
a pool of FBO's, and bind them dynamically.


I agree that this would be the most general and complicated solution. It
would take care of everything without user intervention, but I'm trying
to think if there could be some explicit way for a user to set this up
in a graph like manner. E.g. I know that I want X render passes and I
want to generate Y textures, but I might only need a limited number of
cameras (X and Y) and hence FBOs. I would somehow like to reuse
cameras. I'm not sure if this kind of reuse is used in other parts of
OSG. If not, then I should stop promising myself to look at osgPPU and
actually look at it, maybe it is the best place to cater for this type
of use.


While this might be a worthy thing to do if we really want to be
throwing tens of thousands of FBO's into the system, but given we
already know that Windows and OSX drivers can manage a 1000 FBO's,
the need for doing the rebinding is rather moot - this is a driver
issue.


Couldn't agree more. I can accept that there is a limit, but given the
same hardware, the OS and drivers should not influence this limit. I'll
aim to get the driver fixed before wondering about workarounds any further.

jp



Robert.

On Thu, Nov 27, 2008 at 11:25 AM, J.P. Delport [EMAIL PROTECTED]
wrote:

Hi all,

I have some progress to report on this, yay :)

I did not get a reply after I sent the email to
[EMAIL PROTECTED], so yesterday I posted the same info to the
nvnews forum.

http://www.nvnews.net/vbulletin/showthread.php?p=1856407

I received a reply within 24 hours, see below:

8 jamesjones NVIDIA Corporation

FBO's are a limited resource. Do you really need hundreds of FBO's
or do you just need to render to 100's of textures/renderbuffers?
If the latter, change your FBO's textures rather than creating so
many FBO's. There is a slight performance penalty for changing FBO
bindings, but it shouldn't be too bad.

If you really need an unbounded number of FBO's, that's not gonna
work. We can modify the limit, but you'd have to give us a good
reason to.

The X errors, however, are a bug. That should be fixed in r180. The
only side effect of creating too many FBO's should be a
GL_OUT_OF_MEMORY error and bad framebuffer status. 8

I believe the first point is quite valid and one can try to limit
the number of FBOs created. Doing the rebinding might be a bit
challenging using current OSG, but maybe we can streamline the
process. I can look at this, but any help and ideas are welcome.
Does anyone know if OSGPPU supports the rebinding in an easy to use
way? Art?

I understand that an unbounded number might not be possible, but
I'd like an app that works on Windows to also work on Linux, so I'd
like the limit to at least be the same. Anyone have any other
reasons I can put forward?

I'm going to try r180 asap and will report any changes.

regards jp

J.P. Delport wrote:

Hi all,

I've sent a bug report regarding the FBO problems under Linux to 
[EMAIL PROTECTED]


Will report back if I hear anything. I am not yet registered with
NVidia so could not use the web form, but I hope the email will
get somewhere.

jp

 Original Message  Subject: Unable to create many
(300) FBOs under Linux Date: Tue, 18 Nov 2008 15:43:11 +0200 
From: J.P. Delport [EMAIL PROTECTED] To:

[EMAIL PROTECTED]

Good day,

we are trying to implement an image processing application using
OpenGL and OpenSceneGraph. Recenly one of our algorithms that
require many FBOs failed to run under Linux. The same code works
fine under Windows.

I have attached a simple example that recreates the same errors
on both a Laptop with a GeForce Go 7400 and a desktop machine
with a GTX280.

See the fbo_test.tgz file. The readme explains how to compile and
run the test application.

The errors from the two machines are in fbo_test_Go7400.txt and 
fbo_test_GTX280.txt.


The nvidia-bug-report from the two machines are also attached.

The application was modified from a same problem report on the
forums, see here:

http://www.nvnews.net/vbulletin/showthread.php?t=88178

The issue has also been discussed on the OpenSceneGraph mailing
list in the following threads:

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


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


The osgmemorytest example was run by quite a few people and
displayed similar

Re: [osg-users] Nvidia bug report [Fwd: Unable to create many (300) FBOs under Linux]


Robert,

btw, thanks for posting to the forum. After my previous email I was 
about to reply on the forum but saw you beat me to it :)


jp

Robert Osfield wrote:

Hi J.P.

Thanks for pursuing this.  Gotta say I'm a bit unimpressed by the
response from the Nvidia engineer, kinda sounds like he hasn't
properly read your post or the thread and has placed it under the
ignore it's a user problem category.

Rebinding textures with different FBO's is something we could look at
but it'll complicate the code significantly - we'd need to maintain a
pool of FBO's, and bind them dynamically.  While this might be a
worthy thing to do if we really want to be throwing tens of thousands
of FBO's into the system, but given we already know that Windows and
OSX drivers can manage a 1000 FBO's, the need for doing the rebinding
is rather moot - this is a driver issue.

Robert.

On Thu, Nov 27, 2008 at 11:25 AM, J.P. Delport [EMAIL PROTECTED] wrote:

Hi all,

I have some progress to report on this, yay :)

I did not get a reply after I sent the email to [EMAIL PROTECTED], so
yesterday I posted the same info to the nvnews forum.

http://www.nvnews.net/vbulletin/showthread.php?p=1856407

I received a reply within 24 hours, see below:

8
jamesjones
NVIDIA Corporation

FBO's are a limited resource. Do you really need hundreds of FBO's or do you
just need to render to 100's of textures/renderbuffers? If the latter,
change your FBO's textures rather than creating so many FBO's. There is a
slight performance penalty for changing FBO bindings, but it shouldn't be
too bad.

If you really need an unbounded number of FBO's, that's not gonna work. We
can modify the limit, but you'd have to give us a good reason to.

The X errors, however, are a bug. That should be fixed in r180. The only
side effect of creating too many FBO's should be a GL_OUT_OF_MEMORY error
and bad framebuffer status.
8

I believe the first point is quite valid and one can try to limit the number
of FBOs created. Doing the rebinding might be a bit challenging using
current OSG, but maybe we can streamline the process. I can look at this,
but any help and ideas are welcome. Does anyone know if OSGPPU supports the
rebinding in an easy to use way? Art?

I understand that an unbounded number might not be possible, but I'd like an
app that works on Windows to also work on Linux, so I'd like the limit to at
least be the same. Anyone have any other reasons I can put forward?

I'm going to try r180 asap and will report any changes.

regards
jp

J.P. Delport wrote:

Hi all,

I've sent a bug report regarding the FBO problems under Linux to
[EMAIL PROTECTED]

Will report back if I hear anything. I am not yet registered with NVidia
so could not use the web form, but I hope the email will get somewhere.

jp

 Original Message 
Subject: Unable to create many (300) FBOs under Linux
Date: Tue, 18 Nov 2008 15:43:11 +0200
From: J.P. Delport [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

Good day,

we are trying to implement an image processing application using OpenGL
and OpenSceneGraph. Recenly one of our algorithms that require many FBOs
failed to run under Linux. The same code works fine under Windows.

I have attached a simple example that recreates the same errors on both
a Laptop with a GeForce Go 7400 and a desktop machine with a GTX280.

See the fbo_test.tgz file. The readme explains how to compile and run
the test application.

The errors from the two machines are in fbo_test_Go7400.txt and
fbo_test_GTX280.txt.

The nvidia-bug-report from the two machines are also attached.

The application was modified from a same problem report on the forums,
see here:

http://www.nvnews.net/vbulletin/showthread.php?t=88178

The issue has also been discussed on the OpenSceneGraph mailing list in
the following threads:

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

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

The osgmemorytest example was run by quite a few people and displayed
similar problems on a variety of Linux/NVidia machines. The
osgmemorytest example also manages to kill the X server on occasion.

A typical error report from osgmemorytest:

osgmemorytest --window --fbo 512 512 -g 300
iteration 0
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe574d0
BadAlloc (insufficient resources for operation)
Major opcode: 143
Minor opcode: 27
Error code: 11
Request serial: 2848
Current serial: 2849
  ResourceID: 48234499
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe57530
BadDrawable (invalid Pixmap or Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 9
Request serial: 2849
Current serial: 2849
  ResourceID: 48234499
Warning: detected OpenGL error 'out of memory' after applying attribute
FrameBufferObject 0x80aa470

Any information regarding this problem would be welcomed. Also please
contact me if further information is required.

regards
J.P. Delport

[osg-users] Videos of DBGS Trian3D

2008-11-27 Thread Stephan Kussmaul


Hi OSG Users,

We have created a few new videos about our terrain generation software 
Trian3D. Maybe some of you like to see what we are doing with OSG. Here 
is the link to our website:


www.triangraphics.de/index.php?1=Download2=Videosl=eng

or if you prefer to watch them on YouTube (in modest quality though):

www.youtube.com/user/TrianGraphics

Any comments or suggestions are welcome. If anyone is interested in 
meeting me at the I/ITSEC, just let me know.


Best regards and thanks to all OSG developers,

Stephan

--
-
Stephan Kussmaul
Geschaeftsfuehrender Gesellschafter / Managing Director
TrianGraphics GmbH
Schoenhauser Allee 45
10435 Berlin
Germany
Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
Email: [EMAIL PROTECTED]
Web: www.triangraphics.de
-
Sitz der Gesellschaft / Corporate Headquarters:
TrianGraphics GmbH, Berlin
Registereintragung / Registration:
Amtsgericht Berlin-Charlottenburg HRB 93807 B
Geschaeftsfuehrer / Managing Directors:
Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz 


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

Re: [osg-users] Videos of DBGS Trian3D

2008-11-27 Thread Ümit Uzun

Hi Stephan,

I tried demo version Trian3D 2.0 and it's really practical stuff.

Good work.

Regards.

2008/11/27 Serge Lages [EMAIL PROTECTED]

 Hi,

 It's really impressive, good work !


 On Thu, Nov 27, 2008 at 10:50 AM, Stephan Kussmaul 
 [EMAIL PROTECTED] wrote:

 Hi OSG Users,

 We have created a few new videos about our terrain generation software
 Trian3D. Maybe some of you like to see what we are doing with OSG. Here is
 the link to our website:

 www.triangraphics.de/index.php?1=Download2=Videosl=eng

 or if you prefer to watch them on YouTube (in modest quality though):

 www.youtube.com/user/TrianGraphics

 Any comments or suggestions are welcome. If anyone is interested in
 meeting me at the I/ITSEC, just let me know.

 Best regards and thanks to all OSG developers,

 Stephan

 --
 -
 Stephan Kussmaul
 Geschaeftsfuehrender Gesellschafter / Managing Director
 TrianGraphics GmbH
 Schoenhauser Allee 45
 10435 Berlin
 Germany
 Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
 Email: [EMAIL PROTECTED]
 Web: www.triangraphics.de
 -
 Sitz der Gesellschaft / Corporate Headquarters:
 TrianGraphics GmbH, Berlin
 Registereintragung / Registration:
 Amtsgericht Berlin-Charlottenburg HRB 93807 B
 Geschaeftsfuehrer / Managing Directors:
 Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 --
 Serge Lages
 http://www.tharsis-software.com

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




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

Re: [osg-users] Linux Dev. Env. Poll

2008-11-27 Thread Paul Melis


J.P. Delport wrote:

Hi,

Mathieu MARACHE wrote:

Do you know if meld can integrate nicely with svn? E.g. I can do

svn diff
svn merge

on command line and then it brings up xxdiff. Can meld do this (be an 
diff app for svn)? If it can I will definitely try.
There does seem to be the environment variable SVN_MERGE that subversion 
looks at, but I'm not sure if that one has only been introduced in a 
very recent subversion release.


Regards,
Paul

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

Re: [osg-users] osgAudio / osgAL

Hi Robert, hi everyone,

I totally agree that we need an abstraction layer and plugins. So let's say 
osgAudio is that abstraction layer, and that osgAL is a future plugin based 
on the current osgAL work.
- What would be in the osgAudio then?
- Should we (and how could we do to) leave a degree of freedom to plugins so 
that users can access specific features (= not handled in osgAudio)?

I guess osgAudio has to be very simple. Here are some of my ideas:
- As LightSources, there should be AudioSources nodes that we can position 
somewhere.
- AudioSource may be absolute (= heard everywhere = no distance attenuation = 
no culling).
- AudioSource should be attached to a Sound (= AudioData = buffer or stream + 
some parameters like doppler factor, gain, velocity...)
- Sound should be able to read many formats/codecs (PCM, Vorbis...)
- There should be a cache for sounds (for buffers but not for streams I guess!)
- The user may update the Sounds parameters on update traversal (mainly for the 
velocity - For me, the physics will drive this value)
- There should be Listeners, and the main Listener should be by default linked 
with the main camera (Is that easy to do?)
- Sounds may be occuled, but I wonder if it's better to add occulder 
geometries in the world, or set a specific flag on existing geometries to say 
they occult sounds.
Well this looks much like osgAL, but that's normal! However, I'd like to remove 
the presence of the osgAL manager if possible.

About allocation/deallocation of internal sound buffers, I have two ideas:
1. As for lights, the user is limited to a given number and he has to manually 
switch on/off those (s)he wants.
2. This not be the matter of the user. Eventually (s)he could set their number, 
but not much more. The sources are given a base priority, which can be lowered 
if the sound is attenuated (= if listener is far). The 'n' most important 
AudioSources would then be active and the other inactive. Eventually, a 
parameter would have to say if AudioSources may or may not be stopped suring 
playing to leave another one play (= a more imporant one).

Which one do you prefer? The second idea looks a little bit like the 
LightSourcesManager I wrote (that switch on the 8 most important lights), and 
that can easily be generalized. The advantage is simplicity for the user, and 
the drawback is that we then cannot remove the osgAL manager I told before.

I hope this will help to see an osgAudio soon!

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 27 Nov 2008 11:17:01 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 Hi Sukender,

 Previously I have looked at merging osgAL into svn/trunk, but on
 review of the code decided that a straight merge was inappropriate.
 For end user build simplicity OpenAL++ and osgAL would be best merged.

 The structure of an audio library for the core OSG are something I
 feel need abstraction from any specific audio implementation.  So in
 my ideal world an osgAudio library would provide the basic glue for
 adding audio into the scene graph, and the base classes that provide
 the hooks into the implementations, then implementations would be
 provided via plugins.   No such library currently exists so it'd have
 to be written.   The need for abstraction is required to ensure that
 future portability to embedded platforms isn't hampered by large extra
 dependencies.

 Robert.

 On Wed, Nov 26, 2008 at 10:40 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi all,

 I'd like to know who's interested in audio for OSG:
 - Who would like to use it?
 - Who would like to see some osgAudio included in OSG?
 - Who would like to develop such a thing?

 Well, actually I use osgAL, that depends on OpenAL and OpenAL++ (and Ogg and 
 Vorbis if needed). It can do interesting things, including spatialized audio.
 I'd really like to see osgAL included in OSG but its author is not that 
 active (he told me!) and I guess there is some work to be done before this. 
 And to begin, the CMake build system for it (Compiling it was not that easy).

 But I also have to say that compiling OpenAL under Win32 was a PAIN (much 
 more than osgAL), because I could not find TWO IDENTICAL libs that were 
 structured the same way. I finally compiled from 
 svn://connect.creativelabs.com/OpenAL/trunk, and I had to tweak the project 
 files to fit my needs:
 - Added 'd' as debug suffix.
 - Added Win32 libs (because I'm using an Express version of VC).
 - Manually deployed the binaries by copying them at the right spot.
 Moreover, OpenAL needs DirectSound under Windows (!!!), so I also needed the 
 DirectX SDK...

 If someone is ready to cleanup/structure/merge into OSG... PLEASE DO IT! :)

 Also feel free to tell anything interesting about audio in OSG. Maybe are 
 there interesting cross-platforms and open-source libs? Thread's started!

 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

Re: [osg-users] Videos of DBGS Trian3D

2008-11-27 Thread Serge Lages

Hi,

It's really impressive, good work !

On Thu, Nov 27, 2008 at 10:50 AM, Stephan Kussmaul 
[EMAIL PROTECTED] wrote:

 Hi OSG Users,

 We have created a few new videos about our terrain generation software
 Trian3D. Maybe some of you like to see what we are doing with OSG. Here is
 the link to our website:

 www.triangraphics.de/index.php?1=Download2=Videosl=eng

 or if you prefer to watch them on YouTube (in modest quality though):

 www.youtube.com/user/TrianGraphics

 Any comments or suggestions are welcome. If anyone is interested in meeting
 me at the I/ITSEC, just let me know.

 Best regards and thanks to all OSG developers,

 Stephan

 --
 -
 Stephan Kussmaul
 Geschaeftsfuehrender Gesellschafter / Managing Director
 TrianGraphics GmbH
 Schoenhauser Allee 45
 10435 Berlin
 Germany
 Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
 Email: [EMAIL PROTECTED]
 Web: www.triangraphics.de
 -
 Sitz der Gesellschaft / Corporate Headquarters:
 TrianGraphics GmbH, Berlin
 Registereintragung / Registration:
 Amtsgericht Berlin-Charlottenburg HRB 93807 B
 Geschaeftsfuehrer / Managing Directors:
 Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgswig manifest blues

2008-11-27 Thread Hartmut Seichter

Just to follow up on that - I will add a wiki page on the osgSWIG google 
code about this. With Python 2.6 the default compiler on Windows is 
Visual Studio 2008



Cheers,
Hartmut


http://docs.python.org/whatsnew/2.6.html#build-and-c-api-changes




R Fritz wrote:
Oh-ho!  Yes, that's it.  I think we've got a copy of VS 2003 around; 
I'll take a look.


Randolph

On Nov 26, 2008, at 2:00 AM, Hartmut Seichter wrote:



Mhh, I was just wondering if you are trying to compile osgSWIG / 
Python with Visual Studio 2005 against a Python 2.5 version? If so - 
this is unsupported as Python 2.5 is being compiled with Visual 
Studio 2003 .NET SP1 - in general it shouldn't be a problem because 
of Pythons C - API - but I guess when a Python script is pulling in 
different versions of wrapped C++ DLLs the situation becomes more 
tricky. I have to investigate more closely the new Python 2.6 but 
from some initial scanning it seems things changed.


To come to the core - a proper install script is not existing yet, 
only my old InnoSetup files which I adapted each time a package. I 
will investigate if we can add an install target ...



Cheers,
H


Randolph Fritz wrote:
OK, now that I've got the files to build, how do I avoid the R6034 
(manifest file) error when I move them into site-packages? There 
doesn't seem to be a cmake generated install script, that would 
presumably take care of the problem.


Randolph

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




--
Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, 
HITLabNZ


___
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



--
Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ

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

Re: [osg-users] osgAudio / osgAL

Hi Sukender,

Previously I have looked at merging osgAL into svn/trunk, but on
review of the code decided that a straight merge was inappropriate.
For end user build simplicity OpenAL++ and osgAL would be best merged.

The structure of an audio library for the core OSG are something I
feel need abstraction from any specific audio implementation.  So in
my ideal world an osgAudio library would provide the basic glue for
adding audio into the scene graph, and the base classes that provide
the hooks into the implementations, then implementations would be
provided via plugins.   No such library currently exists so it'd have
to be written.   The need for abstraction is required to ensure that
future portability to embedded platforms isn't hampered by large extra
dependencies.

Robert.

On Wed, Nov 26, 2008 at 10:40 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi all,

 I'd like to know who's interested in audio for OSG:
 - Who would like to use it?
 - Who would like to see some osgAudio included in OSG?
 - Who would like to develop such a thing?

 Well, actually I use osgAL, that depends on OpenAL and OpenAL++ (and Ogg and 
 Vorbis if needed). It can do interesting things, including spatialized audio.
 I'd really like to see osgAL included in OSG but its author is not that 
 active (he told me!) and I guess there is some work to be done before this. 
 And to begin, the CMake build system for it (Compiling it was not that easy).

 But I also have to say that compiling OpenAL under Win32 was a PAIN (much 
 more than osgAL), because I could not find TWO IDENTICAL libs that were 
 structured the same way. I finally compiled from 
 svn://connect.creativelabs.com/OpenAL/trunk, and I had to tweak the project 
 files to fit my needs:
 - Added 'd' as debug suffix.
 - Added Win32 libs (because I'm using an Express version of VC).
 - Manually deployed the binaries by copying them at the right spot.
 Moreover, OpenAL needs DirectSound under Windows (!!!), so I also needed the 
 DirectX SDK...

 If someone is ready to cleanup/structure/merge into OSG... PLEASE DO IT! :)

 Also feel free to tell anything interesting about audio in OSG. Maybe are 
 there interesting cross-platforms and open-source libs? Thread's started!

 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
 ___
 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] Videos of DBGS Trian3D

2008-11-27 Thread Alejandro Segovia

Very cool indeed :)

Does it run on other platforms? Are you using wxWidgets or Qt for the UI
stuff or calling into win32 directly?

Alejandro.-

On Thu, Nov 27, 2008 at 7:50 AM, Stephan Kussmaul 
[EMAIL PROTECTED] wrote:

 Hi OSG Users,

 We have created a few new videos about our terrain generation software
 Trian3D. Maybe some of you like to see what we are doing with OSG. Here is
 the link to our website:

 www.triangraphics.de/index.php?1=Download2=Videosl=eng

 or if you prefer to watch them on YouTube (in modest quality though):

 www.youtube.com/user/TrianGraphics

 Any comments or suggestions are welcome. If anyone is interested in meeting
 me at the I/ITSEC, just let me know.

 Best regards and thanks to all OSG developers,

 Stephan

 --
 -
 Stephan Kussmaul
 Geschaeftsfuehrender Gesellschafter / Managing Director
 TrianGraphics GmbH
 Schoenhauser Allee 45
 10435 Berlin
 Germany
 Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
 Email: [EMAIL PROTECTED]
 Web: www.triangraphics.de
 -
 Sitz der Gesellschaft / Corporate Headquarters:
 TrianGraphics GmbH, Berlin
 Registereintragung / Registration:
 Amtsgericht Berlin-Charlottenburg HRB 93807 B
 Geschaeftsfuehrer / Managing Directors:
 Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
[EMAIL PROTECTED]
http://varrojo.linuxuruguay.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and memory

Hi Brad,

On Wed, Nov 26, 2008 at 6:47 PM, Brad Colbert [EMAIL PROTECTED] wrote:
 I remember running into this once before.  I believe I was able to tell
 if the pager had died, but was unable to do anything else (maybe out of
 lack of knowledge).  Is there a way to flush the memory that the dead
 thread left hanging and restart the paging thread?  This would at least
 keep us up in the short term until we are able to attack the other
 issues.

If a paging thread has hung then you could try and cancel the threads
and restart the pager.  I've never tried this myself so can't give
particular guidance on it.

Personally if threads have died you have already pushed this too far
and you should be fixing things in your database and app usage so this
doesn't occur in the first place rather than trying to patch a system
that is grinding to a halt because you've pushed things too far.

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

Re: [osg-users] Packaging granularity + platform specific scripts

2008-11-27 Thread Middleton, Colin (GE EntSol, Intelligent Platforms)

Hi Cedric,

On Wed, Nov 26, 2008 at 10:00 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
 For gentoo package it's nice to be able to setup option in the
 cmakelists.txt then i can add option on the package
 to select module to compile and install. It's already the case so i dont
 need more.

I'm not clear on what you mean here.

Do you already have gentoo packing files that you use?  Are these
compatible with CMake?  Do these already work with CMake?  If so how?

I would like packing to become more centralised and consistent,
understand what there is already out there is a good first step in
know what would be needed in bring this support into the core.

 In my opinion the main issue is windows, I tried to build an openscenegraph
 environment on windows, and it's not as
 easy.

Yep, it's another big issue, in which I'll dive into in as reply to
JS's post, but here I'll note that windows problems doesn't preclude
the need for straightening out all the bits that are easier to
straighten out...   So your knowledge about Gentoo is something that
would be useful to leverage.

Robert.

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

Re: [osg-users] Calculating the volume of a model through OSG



Another simple way of calculating the volume of a arbitary closed 3d mesh is 

Choose an arbitary point ( let's call it o )
For each triangle with vertices ( a,b,c ) 
Calculate the volume of the tetrahedron ( a,b,c,o ) using a scalar triple 
product ( ((b-a)x(c-a)).(o-a)/3 ).
Add the volumes of all of the tetrahedrons together, some of these volume will 
be negative and some will be positive, depending on whether the triangle is 
facing the arbitary point or not. These negative volumes cancel out the 
positive ones, leaving only the enclosed area.

This relies on the 2 assumptions:-
1) All of the triangles in the 3d object have the same winding order, otherwise 
the volumes' sign cannot be trusted.
2) The object has no holes.

If the object has holes then the placing of the arbitary point will affect the 
volume of the object, a triangular hole will mean that the volume of a 
tetrahedron between the hole and the arbitary point will be missed in the 
calcalation. As a result of this placing it in the centroid of the 3d object is 
probably the best plan.

I hope this helps.

Colin.

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf 
 Of Alberto Luaces
 Sent: 27 November 2008 08:42
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] Calculating the volume of a model through OSG
 
 Hi,
 
 in addition to Janusz pointers, if you need also the rest of 
 the mass properties, you could take a look at this famous paper:
 
 http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html
 
 Alberto
 
 El Jueves 27 Noviembre 2008ES 09:09:34 [EMAIL PROTECTED] escribió:
  Dusten:
 
  You might find these two helpful:
 
  accurate: http://tetgen.berlios.de/
  approximate  simple:
  http://www.gamedev.net/reference/articles/article2247.asp
 
  The second one could be easily added to osg I guess.
  Janusz
 
  Dnia Wed, 26 Nov 2008 23:47:57 -0600, Dusten Sobotta napisał(a):
   Hello,
  
   Manually modifying various attributes of models is quite tedious, 
   and tends to set back the development of games.  To work 
 around this 
   issue, I'd like to implement a feature to calculate the 
 volume of an 
   in-game model, so that given a surface attribute such as 
 'wood' or 
   'metal', (which have pre-defined density values), the mass of an 
   object can be computed and later exported. Might anyone have an 
   example for finding the approximate volume of an object 
 through OSG?
  
  
   Thanks in advance,
  
   Dusten
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
   
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap
   h.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-opensce
 negraph.org
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgAudio / osgAL

Hi Sukender,

I was to develop osgAudio I would use osgAL/OpenAL as a template,
much in the same way as you seem to be look at the topic.  I'd also
see how SDL audio might map as this has cross platform audio support
that might be reasonable implementation for non spaitialized sound.

I would also try to keep things decoupled so items like a Manager
would be something that is implementation dependent, rather that
something that end user need worry about.  I would have thought that
one might be able to capture the camera position relative to
listener/sound sources by using the existing cull traversal as the way
to extract the required info to pass on to OpenAL.   Threading and
multiple camera traversals might throw this a bit though...  so
perhaps a standard alone audio traversal would be appropriate as one
would only have one audio context.  Perhaps the ideal would be to
allow the viewer to run an audio thread that runs in parallel with the
cull/draw traversal threads.

I am overloaded with my existing work so I can't take on any of this
work myself, I'll happy cheer on from the side lines though.  I
certainly want to see an osgAudio merged into the core OSG.  Perhaps a
feature for OSG-2.10.

Robert.

On Thu, Nov 27, 2008 at 1:37 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert, hi everyone,

 I totally agree that we need an abstraction layer and plugins. So let's say 
 osgAudio is that abstraction layer, and that osgAL is a future plugin 
 based on the current osgAL work.
 - What would be in the osgAudio then?
 - Should we (and how could we do to) leave a degree of freedom to plugins so 
 that users can access specific features (= not handled in osgAudio)?

 I guess osgAudio has to be very simple. Here are some of my ideas:
 - As LightSources, there should be AudioSources nodes that we can position 
 somewhere.
 - AudioSource may be absolute (= heard everywhere = no distance attenuation = 
 no culling).
 - AudioSource should be attached to a Sound (= AudioData = buffer or stream + 
 some parameters like doppler factor, gain, velocity...)
 - Sound should be able to read many formats/codecs (PCM, Vorbis...)
 - There should be a cache for sounds (for buffers but not for streams I 
 guess!)
 - The user may update the Sounds parameters on update traversal (mainly for 
 the velocity - For me, the physics will drive this value)
 - There should be Listeners, and the main Listener should be by default 
 linked with the main camera (Is that easy to do?)
 - Sounds may be occuled, but I wonder if it's better to add occulder 
 geometries in the world, or set a specific flag on existing geometries to 
 say they occult sounds.
 Well this looks much like osgAL, but that's normal! However, I'd like to 
 remove the presence of the osgAL manager if possible.

 About allocation/deallocation of internal sound buffers, I have two ideas:
 1. As for lights, the user is limited to a given number and he has to 
 manually switch on/off those (s)he wants.
 2. This not be the matter of the user. Eventually (s)he could set their 
 number, but not much more. The sources are given a base priority, which can 
 be lowered if the sound is attenuated (= if listener is far). The 'n' most 
 important AudioSources would then be active and the other inactive. 
 Eventually, a parameter would have to say if AudioSources may or may not be 
 stopped suring playing to leave another one play (= a more imporant one).

 Which one do you prefer? The second idea looks a little bit like the 
 LightSourcesManager I wrote (that switch on the 8 most important lights), and 
 that can easily be generalized. The advantage is simplicity for the user, and 
 the drawback is that we then cannot remove the osgAL manager I told before.

 I hope this will help to see an osgAudio soon!

 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 27 Nov 2008 11:17:01 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 Hi Sukender,

 Previously I have looked at merging osgAL into svn/trunk, but on
 review of the code decided that a straight merge was inappropriate.
 For end user build simplicity OpenAL++ and osgAL would be best merged.

 The structure of an audio library for the core OSG are something I
 feel need abstraction from any specific audio implementation.  So in
 my ideal world an osgAudio library would provide the basic glue for
 adding audio into the scene graph, and the base classes that provide
 the hooks into the implementations, then implementations would be
 provided via plugins.   No such library currently exists so it'd have
 to be written.   The need for abstraction is required to ensure that
 future portability to embedded platforms isn't hampered by large extra
 dependencies.

 Robert.

 On Wed, Nov 26, 2008 at 10:40 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi all,

 I'd like to know who's interested in audio for OSG:
 - Who would like to use it?
 - Who would like to see some osgAudio included in OSG?
 - Who

Re: [osg-users] Packaging granularity + platform specific scripts

2008-11-27 Thread Cedric Pinson


Hi Robert,

I think it's better if you read an example of an ebuild. Because source 
are compiled when installing package it's easy to setup the cmakelist 
option when installing the package. In the ebuild example we could add 
option like gdal, osgal, and what you want.


But i think it's not a good idea to create a new package format that 
could be common with all system. In my opinion the best way to setup 
package should be to have some vserver that automatically make package. 
Like a compiling farm. It sound big but could be made step by step.


But in fact we just need more maintainer, having those build system 
limit the amount of work by a human. Just need to check when new 
version. If we got
more maintainers on differents distribution the package problem would 
not really exist. Maybe we need to find a comunity manager :)



I am not sure to understand the big picture you have about packaging so 
maybe i am wrong


Cheers,
Cedric


Robert Osfield wrote:

Hi Cedric,

On Wed, Nov 26, 2008 at 10:00 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
  

For gentoo package it's nice to be able to setup option in the
cmakelists.txt then i can add option on the package
to select module to compile and install. It's already the case so i dont
need more.



I'm not clear on what you mean here.

Do you already have gentoo packing files that you use?  Are these
compatible with CMake?  Do these already work with CMake?  If so how?

I would like packing to become more centralised and consistent,
understand what there is already out there is a good first step in
know what would be needed in bring this support into the core.

  

In my opinion the main issue is windows, I tried to build an openscenegraph
environment on windows, and it's not as
easy.



Yep, it's another big issue, in which I'll dive into in as reply to
JS's post, but here I'll note that windows problems doesn't preclude
the need for straightening out all the bits that are easier to
straighten out...   So your knowledge about Gentoo is something that
would be useful to leverage.

Robert.

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


--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: 
/cvs/underware/osg/OpenSceneGraph/gentoo/dev-cpp/openscenegraph/openscenegraph-1.0.0-r1.ebuild,v
 1.2 2006/07/31 13:04:33 cpinson Exp $

inherit eutils

DESCRIPTION=Cross platform, object orientated threading library maintained by 
the OpenSceneGraph team.
HOMEPAGE=http://www.openscenegraph.org;
MY_P=OpenSceneGraph-${PV}
SRC_URI=http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.6/OpenSceneGraph-2.6.0.zip
examples? ( 
http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.6/OpenSceneGraph-Data-2.6.0.zip
 )
SLOT=0
LICENSE=OSGPL-0.0
KEYWORDS=x86 amd64
IUSE=examples

DEPEND=virtual/opengl 
app-arch/unzip
media-libs/jpeg 
media-libs/tiff
media-libs/giflib
media-libs/freetype
net-misc/curl
dev-util/cmake
sci-libs/gdal
x11-libs/cairo
=media-libs/libpng-1.2 
media-libs/lib3ds

S=${WORKDIR}/${MY_P}

src_unpack() {
unpack ${MY_P}.zip
if use examples
then
unpack OpenSceneGraph-Data-2.6.0.zip
fi
epatch ${FILESDIR}/openscenegraph-2.6.0-gcc-4.3-compile-patch
}

src_compile() {

CCACHE=$(echo $FEATURES | grep 'ccache' | sed 's/.*ccache.*/ccache/g')
if  use examples
then
cmake ${S} -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DBUILD_OSG_EXAMPLES=ON -DBUILD_OSG_WRAPPERS=ON
else
cmake ${S} -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DBUILD_OSG_EXAMPLES=OFF -DBUILD_OSG_WRAPPERS=ON
fi
emake
}

src_install() {
make DESTDIR=${D} install || die einstall failed
insinto /usr/lib/pkgconfig
doins ${S}/packaging/pkgconfig/openthreads.pc
doins ${S}/packaging/pkgconfig/openscenegraph.pc
if use examples
then
cp -r ${WORKDIR}/OpenSceneGraph-Data-2.6.0 \
${D}/usr/share/OpenSceneGraph-Data-2.6.0

echo OSG_FILE_PATH=/usr/share/OpenSceneGraph-Data-2.6.0 \
 ${T}/99${PN}
doenvd ${T}/99${PN} || die doenvd failed
fi
}

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

Re: [osg-users] Videos of DBGS Trian3D

2008-11-27 Thread Stephan Kussmaul


Hi Alejandro,

thanks for the feedback.
Does it run on other platforms? Are you using wxWidgets or Qt for the 
UI stuff or calling into win32 directly?
We are only offering a Windows version at the moment. This will not 
change on short term as the GUI is Windows stuff. This is due to 
historical reasons- the software was originally developped as internal 
tool.


If enough people shout here we will think about porting Trian3D to 
other platforms ;)


-Stephan-



Alejandro.-

On Thu, Nov 27, 2008 at 7:50 AM, Stephan Kussmaul 
[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hi OSG Users,

We have created a few new videos about our terrain generation
software Trian3D. Maybe some of you like to see what we are doing
with OSG. Here is the link to our website:

www.triangraphics.de/index.php?1=Download2=Videosl=eng
http://www.triangraphics.de/index.php?1=Download2=Videosl=eng

or if you prefer to watch them on YouTube (in modest quality though):

www.youtube.com/user/TrianGraphics
http://www.youtube.com/user/TrianGraphics

Any comments or suggestions are welcome. If anyone is interested
in meeting me at the I/ITSEC, just let me know.

Best regards and thanks to all OSG developers,

Stephan

-- 
-

Stephan Kussmaul
Geschaeftsfuehrender Gesellschafter / Managing Director
TrianGraphics GmbH
Schoenhauser Allee 45
10435 Berlin
Germany
Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
Email: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Web: www.triangraphics.de http://www.triangraphics.de
-
Sitz der Gesellschaft / Corporate Headquarters:
TrianGraphics GmbH, Berlin
Registereintragung / Registration:
Amtsgericht Berlin-Charlottenburg HRB 93807 B
Geschaeftsfuehrer / Managing Directors:
Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
[EMAIL PROTECTED]
http://varrojo.linuxuruguay.org


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


--
-
Stephan Kussmaul
Geschaeftsfuehrender Gesellschafter / Managing Director
TrianGraphics GmbH
Schoenhauser Allee 45
10435 Berlin
Germany
Tel: +49 (0)30 48495565   FAX: +49 (0)30 48495581
Email: [EMAIL PROTECTED]
Web: www.triangraphics.de
-
Sitz der Gesellschaft / Corporate Headquarters:
TrianGraphics GmbH, Berlin
Registereintragung / Registration:
Amtsgericht Berlin-Charlottenburg HRB 93807 B
Geschaeftsfuehrer / Managing Directors:
Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz 


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

Re: [osg-users] Packaging granularity + platform specific scripts

Hi Cedric,

On Thu, Nov 27, 2008 at 2:29 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
 I think it's better if you read an example of an ebuild. Because source are
 compiled when installing package it's easy to setup the cmakelist option
 when installing the package. In the ebuild example we could add option like
 gdal, osgal, and what you want.

Thanks for the ebuild example, this is exactly what I need to get on
an idea of the different needs of packing on different platforms.




 But i think it's not a good idea to create a new package format that could
 be common with all system. In my opinion the best way to setup package
 should be to have some vserver that automatically make package. Like a
 compiling farm. It sound big but could be made step by step.

I'm not thinking about replacing existing packaging system, just
better supporting
the ones that are already there.

In the case of windows there is rather a vacuum.  How to solve this
one I can't answer.

 But in fact we just need more maintainer, having those build system limit
 the amount of work by a human. Just need to check when new version. If we
 got
 more maintainers on differents distribution the package problem would not
 really exist. Maybe we need to find a comunity manager :)

More maintainers isn't just what we require.   We need coordinated
maintenaners, something that is rather lacking right now.  It's a case
of who has the itch goes scratch it for as long as them have time and
interest.

The maintainers also need to be working off the same general script,
and to getting required changes back up stream, engaging directly with
the OSG community.

 I am not sure to understand the big picture you have about packaging so
 maybe i am wrong

I don't have any strong idea of the ideal system for the OSG and it's
community, which is why I raised this thread.

My plan is just - Set out a rough goal of wanting to improving the
packaging situation, gather information, and then tryto resolve some
workable plan going going.  We're at the information gathering point
right now.

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

Re: [osg-users] CUDA + osg compilation issues???

Hi Paul,

yes it does, and I am currently investigating the output ;)
Interesting thign is that replacing the line in the test case

#include osg/State

by this:

#include GL/gl.h
#define GLenum unsigned int 
#include osg/State

does remove the first error and breaks down on other definitions of GLxxx 
types. It could be that for whatever reasons the headers are not processed very 
well.

cheers

--- Paul Melis [EMAIL PROTECTED] schrieb am Do, 27.11.2008:

 Von: Paul Melis [EMAIL PROTECTED]
 Betreff: Re: [osg-users] CUDA + osg compilation issues???
 An: [EMAIL PROTECTED], OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
 Datum: Donnerstag, 27. November 2008, 15:50
 Art Tevs wrote:
  Hi folks,
 
  has anybody of you ever tried to compile .cu cuda-file
 with nvcc, which does include osg headers. Here is just a
 simple test case which doesn't compile for whatever
 reasons:
 
  #include stdio.h
  #include osg/State
 
 
  int main()
  {
  osg::State* test = new osg::State;
  printf(%d\n,
 test-getContextID());
  return 0;
  }
 
  compiled with:
  nvcc -cuda test.cu
 
  The compilation breaks down with the error:
  /osg/State(1289): error: identifier-list parameters
 may only be used in a function definition
  /osg/State(1290): error: identifier-list parameters
 may only be used in a function definition
  /osg/State(1290): error: expected an identifier
 
  and so on.
 
 
  I don't know what could be wrong there. If
 somebody was able to get CUDA code compiled beside of osg, I
 would be very appreciated to know more ;)

 Does nvcc have a preprocess-only mode (something like -E)?
 So you can 
 see what the real input is to the compiler...
 
 Paul


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

[osg-users] CUDA + osg compilation issues???

Hi folks,

has anybody of you ever tried to compile .cu cuda-file with nvcc, which does 
include osg headers. Here is just a simple test case which doesn't compile for 
whatever reasons:

#include stdio.h
#include osg/State


int main()
{
osg::State* test = new osg::State;
printf(%d\n, test-getContextID());
return 0;
}

compiled with:
nvcc -cuda test.cu

The compilation breaks down with the error:
/osg/State(1289): error: identifier-list parameters may only be used in a 
function definition
/osg/State(1290): error: identifier-list parameters may only be used in a 
function definition
/osg/State(1290): error: expected an identifier

and so on.


I don't know what could be wrong there. If somebody was able to get CUDA code 
compiled beside of osg, I would be very appreciated to know more ;)

Best regards,
art


 


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

[osg-users] osgViewer osgCool

2008-11-27 Thread Renan Mendes

Hi, everyone.

 I was looking through the examples and found an effect that can be useful
to my application. It is in osgviewer osgcool, but I can't find the code
neither in the examples I've download with the osg package nor at the osg
website... Does anyone have it and can send it to me?

 Thanks,

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

Re: [osg-users] CUDA + osg compilation issues???

After some more investigation it seems that cudafe (a tool from the CUDA 
compilation chain, which separates C/C++ from GPU code) isn't able to parse the 
files correctly. The problem is, that there are no decription of how to use 
cudafe as standalone thing, so that it seems to be more or less unsuccessful to 
find out what goes wrong there.

I check out if it would be possible to generate a bug report, however requiring 
the whole osg/include directory just to regenerate a bug is somehow overblown ;(

If somebody does know more, I would be very appreciated.


Cheers
art



--- Art Tevs [EMAIL PROTECTED] schrieb am Do, 27.11.2008:

 Von: Art Tevs [EMAIL PROTECTED]
 Betreff: Re: [osg-users] CUDA + osg compilation issues???
 An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Datum: Donnerstag, 27. November 2008, 15:55
 Hi Paul,
 
 yes it does, and I am currently investigating the output ;)
 Interesting thign is that replacing the line in the test
 case
 
 #include osg/State
 
 by this:
 
 #include GL/gl.h
 #define GLenum unsigned int 
 #include osg/State
 
 does remove the first error and breaks down on other
 definitions of GLxxx types. It could be that for whatever
 reasons the headers are not processed very well.
 
 cheers
 
 --- Paul Melis [EMAIL PROTECTED] schrieb am Do,
 27.11.2008:
 
  Von: Paul Melis [EMAIL PROTECTED]
  Betreff: Re: [osg-users] CUDA + osg compilation
 issues???
  An: [EMAIL PROTECTED], OpenSceneGraph
 Users osg-users@lists.openscenegraph.org
  Datum: Donnerstag, 27. November 2008, 15:50
  Art Tevs wrote:
   Hi folks,
  
   has anybody of you ever tried to compile .cu
 cuda-file
  with nvcc, which does include osg headers. Here is
 just a
  simple test case which doesn't compile for
 whatever
  reasons:
  
   #include stdio.h
   #include osg/State
  
  
   int main()
   {
   osg::State* test = new osg::State;
   printf(%d\n,
  test-getContextID());
   return 0;
   }
  
   compiled with:
   nvcc -cuda test.cu
  
   The compilation breaks down with the error:
   /osg/State(1289): error: identifier-list
 parameters
  may only be used in a function definition
   /osg/State(1290): error: identifier-list
 parameters
  may only be used in a function definition
   /osg/State(1290): error: expected an identifier
  
   and so on.
  
  
   I don't know what could be wrong there. If
  somebody was able to get CUDA code compiled beside of
 osg, I
  would be very appreciated to know more ;)
 
  Does nvcc have a preprocess-only mode (something like
 -E)?
  So you can 
  see what the real input is to the compiler...
  
  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] Packaging granularity + platform specific scripts


Hi Robert,


Another step would then provide a community mechanism for uploading
the resulting binary/headers/source packages that others can
leverage.  Using the svn repository has been discussed as possible
location for this.


Some open repository would be useful, sure, but it would increase the 
need for testing, since anyone could replace a given working revision of 
the binaries with a non-working one, someone would need to constantly 
monitor what's going on on the repository and test the changes...



This is reflection of our over dependence on the time and skills of
too small a group of engineers (i.,e Mike) , and lack of a process for
getting binaries made available in straight forward way.


Yep.


Automating the process of creating dependency packages or more to the
point de-skilling the process would make it possible for more users to
get involved.   Automating the dependency build isn't trivial
though...


...


On the the dependency from I do wonder if providing CMakeLists.txt
files for the various dependencies and then a high level
CMakeLists.txt or other script that would pull together the
components.  Would we need to branch the source codes of the various
dependences for this?  Could we push support for such a coordinate
build scheme back upstream to the projects themselves?


I doubt the upstream maintainers would be willing to maintain files for 
a build system they don't use. None of the 7 dependencies I built 
recently for our own internal packages use CMake. Each one has their own 
build system, which is what makes it a pain. Some build using Visual 
Studio, some using nmake.


When you need to change settings, you either have to dig in the VS 
project files, or the makefiles, and the makefiles are always set up 
differently, so it takes a lot of time. Adding the d postfix for debug 
libraries is an example. I doubt the projects themselves will be open to 
changes to their build system, that's generally a preference of the 
build maintainers, so these changes will need to be re-done each time we 
bump the version of one of the dependencies.


All in all, I'm already doing it once every 4-6 months for work, I 
personally don't want to do it any more than that. Mike seems to have a 
similar stance. If someone wants to do it feel free.



Could we come up with a scheme that mirrors these packaging systems a
little?  I don't mean a full blown implementation of packaging system.
  Would it be possible to write a Cmake or Python script that manages
a directory tree of dependencies?


Perhaps. Or we could compile apt for Windows :-)


I'm happy to start simple and work our way up if required.

Perhaps in a final installer nirvana we could have an cross platform
interactive script (in a browser maybe) that could run, you tick the
bits of the OSG you want have it go install all the
binaries/headers/source you need, or update any components when
updates are available... ;-)

What are the first steps on this road though...


Not sure.

I really think the dependencies are the biggest hurdle. If someone can 
streamline the dependencies build process, then at least we would have 
dependencies for the 3 major toolsets (VC7.1, VC8, VC9). Building OSG 
with those is a piece of cake... Even if we have to do it 6 times (3 
toolsets * (debug + release)).


The basic dependencies included in Mike's repo (and I think we should 
start with that basic set too) are:


   1. curl (not necessary but will be useful in the future)
   2. freetype
   3. libjpeg
   4. libungif
   5. libpng
   6. libtiff
   7. zlib (included with libpng)

Choosing which to build as static libs and which as dynamic libs is a 
first decision to take. I would personally go static all the way because 
there are more and more applications that add themselves to your PATH on 
install and include for example libpng, so your OSG app ends up picking 
up the wrong DLL and crashing. But it does increase the plugins' size a bit.


I didn't want to, but I could volunteer to build the dependencies for 
the next release. Given a few weeks to do it in my off time, I would be 
able to do it. From that, I would have a better idea of what can / needs 
to be streamlined and I could suggest some next steps.


Comments?

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer osgCool

Hi Renan,

Do you mean the osgcool.osg file?  There isn't an osgCool nodekit or example.

The osgcool.osg just has a particle effect with the emitter lined up
along the positions of the text.

Robert.

On Thu, Nov 27, 2008 at 3:04 PM, Renan Mendes [EMAIL PROTECTED] wrote:
 Hi, everyone.

  I was looking through the examples and found an effect that can be useful
 to my application. It is in osgviewer osgcool, but I can't find the code
 neither in the examples I've download with the osg package nor at the osg
 website... Does anyone have it and can send it to me?

  Thanks,

  Renan M Z Mendes

 ___
 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] osgAudio / osgAL


Hi Robert,


I am overloaded with my existing work so I can't take on any of this
work myself, I'll happy cheer on from the side lines though.


I've never met you personally, but I just can't picture you as a 
cheerleader with pom-pons and such... ;-)


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer osgCool

2008-11-27 Thread Renan Mendes

My mistake, I thought it was an example but it is only an argument for the
application.

Either way, I really wanted to learn how that particular particle effect was
generated... How can I do it?

Thanks,

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

Re: [osg-users] osgViewer osgCool


Hi Renan,

Either way, I really wanted to learn how that particular particle effect 
was generated... How can I do it?


Examine the osgcool.osg file, it's a direct dump of the scene graph to 
.osg file (the same thing you get whenever you use 
osgDB::writeNodefile(*sceneRoot, file.osg); ) so you can read it and 
see what the scene graph setup looks like.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer osgCool

2008-11-27 Thread Renan Mendes

I will look into that. Thanks J-S.

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

Re: [osg-users] Packaging granularity + platform specific scripts

Hi J-S,

On Thu, Nov 27, 2008 at 3:22 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
 Another step would then provide a community mechanism for uploading
 the resulting binary/headers/source packages that others can
 leverage.  Using the svn repository has been discussed as possible
 location for this.

 Some open repository would be useful, sure, but it would increase the need
 for testing, since anyone could replace a given working revision of the
 binaries with a non-working one, someone would need to constantly monitor
 what's going on on the repository and test the changes...

One couldn't have a totally open system for uploading. Only
maintainers would be able to upload.  We could include a number of
maintainers for each platform.  Testing would need to happen of
course, and perhaps a holding area for proposed packages would suit
this phase.  Once a package is tested and approved only then would
link to it from the download pages/move it to general public downloads
area.


 I doubt the upstream maintainers would be willing to maintain files for a
 build system they don't use. None of the 7 dependencies I built recently for
 our own internal packages use CMake. Each one has their own build system,
 which is what makes it a pain. Some build using Visual Studio, some using
 nmake.

Could we just provide our own external CMake system for them then?
Most of these dependencies are complex beasts.

 All in all, I'm already doing it once every 4-6 months for work, I
 personally don't want to do it any more than that. Mike seems to have a
 similar stance. If someone wants to do it feel free.

For the most part I would expect dependencies would change rarely.
Certainly less often than OSG releases.

 Not sure.

 I really think the dependencies are the biggest hurdle. If someone can
 streamline the dependencies build process, then at least we would have
 dependencies for the 3 major toolsets (VC7.1, VC8, VC9). Building OSG with
 those is a piece of cake... Even if we have to do it 6 times (3 toolsets *
 (debug + release)).

So what options do we have for streamlining the build of the dependencies?

 The basic dependencies included in Mike's repo (and I think we should start
 with that basic set too) are:

   1. curl (not necessary but will be useful in the future)
   2. freetype
   3. libjpeg
   4. libungif
   5. libpng
   6. libtiff
   7. zlib (included with libpng)

 Choosing which to build as static libs and which as dynamic libs is a first
 decision to take. I would personally go static all the way because there are
 more and more applications that add themselves to your PATH on install and
 include for example libpng, so your OSG app ends up picking up the wrong DLL
 and crashing. But it does increase the plugins' size a bit.

I'd be inclined towards static linking of these libs too, the only
other alternative is for use to name/version our built dependencies
uniquely so as not to risk overlapping with other installs of similar
but not quite the same libs.

There are also other heavier weight dependencies like COLLADA,
OpenVRML, LibXUL/xulrunner that users might want to pull in.  The
existing Win32 dependency list is really just the core dependencies.
How far out one should encompass centrally will something we should
leave the community - if volunteers are willing to support a
particular dependency package and there is a mechanism for us to
provide download space and consistent scheme for naming then we can
just leave the door open to this more specialist add ons.

I would suggest we come up with set of packages and associated
dependencies.  There is also the aspect that we may have packages
within general packages - for instance OpenThreads could be a package
in its own right, and the OSG core libraries could be another package
that has minimal dependencies.  Then the standard openscenegraph
package would contains these packages + the standard dependencies that
already exist in the Win32 package.

Robert.



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

[osg-users] Understanding node/traversal masks

2008-11-27 Thread Morné Pistorius

Hi guys,

I have a scene setup problem that I am sure is easy to solve with OSG
if someone could help me properly understand the use of node masks.
Consider this scene:

   Root
/\
   /  \
   __/ \__
  /\
DecorateGroupRenderGroup
   \   |
\ /\
 \  ___/  \
  \/\
   \___ PAT Subgraph with more objects
 /\
/  \
   GeodeA GeodeB



I have a group of objects that I want to render, all children of the
RenderGroup.  Some of these objects I want to decorate by drawing the
same geometry with a different stateset that enables cartoon outlines
when I pick it.  Now I want to add a subgraph to this decoration, but
I only want to allow some of the nodes within the subgraph to be
affected by the stateset in DecorateGroup.  For example, if I attach
PositionAttitudeTransform PAT to DecorateGroup, I only want GeodeA to
be decorated.

I think one way would be to protect attributes that are overridden by
the stateset in DecorateGroup, but I don't want to have to do that for
all objects that might be picked. I expect this can be done with node
masks, but I am not sure how to set up a node mask so that GeodeB is
drawn only once when RenderGroup is traversed and not drawn when
DecorateGroup is traversed.

I would be really grateful if someone could explain this to me.

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

Re: [osg-users] Packaging granularity + platform specific scripts

Hi All,

I've just put up a wiki page to coordinate suggestions for packaging
names/contents/dependencies.  Feel free to add to/amend.

http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging

This isn't an exhaustive list, there are no doubt mistakes, but my
hope is that it's a some concrete that we can build old/discuss
specifics of.

I would like to know how existing packaging available fits in with
this, so please review it and pass on whether X disto fits with or
does something different.  Post these comments here first, then we can
amend the page.


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

Re: [osg-users] Videos of DBGS Trian3D


Hello Stephan,

We have created a few new videos about our terrain generation software 
Trian3D. Maybe some of you like to see what we are doing with OSG.


Very nice stuff. I've looked through your sample databases, and it looks 
very good. I have a few questions:


* Is the representation of trees configurable? Some situations might 
need only a billboard, others a cross of quads, others a more detailed 
tree model (LODs with all three even?)


* Why is the lowest LOD of your terrain a flat white quad? Couldn't it 
be a quad with the terrain texture at least? Or even a very low-poly 
version of the terrain, so we still get a general impression of the 
hills... It looks a bit weird when we zoom way out and it becomes a flat 
white plane.


* Are the building models configurable too? If we have an in-house 
modeler, could he use his own building models (with LODs etc.) in 
Trian3D Builder?


We (CM Labs) will have some people at I/ITSEC, so I've talked to them 
and they will go check your stuff out firsthand.


Thanks for sharing,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Understanding node/traversal masks

2008-11-27 Thread Roger James





Morn Pistorius wrote:

  Hi guys,

I have a scene setup problem that I am sure is easy to solve with OSG
if someone could help me properly understand the use of node masks.
Consider this scene:

   Root
/\
   /  \
   __/ \__
  /\
DecorateGroupRenderGroup
   \   |
\ /\
 \  ___/  \
  \/\
   \___ PAT Subgraph with more objects
 /\
/  \
   GeodeA GeodeB



I have a group of objects that I want to render, all children of the
RenderGroup.  Some of these objects I want to decorate by drawing the
same geometry with a different stateset that enables cartoon outlines
when I pick it.  Now I want to add a subgraph to this decoration, but
I only want to allow some of the nodes within the subgraph to be
affected by the stateset in DecorateGroup.  For example, if I attach
PositionAttitudeTransform PAT to DecorateGroup, I only want GeodeA to
be decorated.

I think one way would be to protect attributes that are overridden by
the stateset in DecorateGroup, but I don't want to have to do that for
all objects that might be picked. I expect this can be done with node
masks, but I am not sure how to set up a node mask so that GeodeB is
drawn only once when RenderGroup is traversed and not drawn when
DecorateGroup is traversed.

I would be really grateful if someone could explain this to me.


  

The term node mask NodeMask referred to in the method
osg:Node::setNodeMask and the member varibale osg::Node::-nodeMask can
be a little misleading. It may help you to think of it as a set of flag
bits to which a traversal mask is applied. If doing a bit wise AND of
these flag bits and the current traversal mask results in a non zero
value the node will be processed (traversed) otherwise it will be
ignored along with all its children.

Roger


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

Re: [osg-users] Packaging granularity + platform specific scripts


Hi Robert,


One couldn't have a totally open system for uploading. Only
maintainers would be able to upload.  We could include a number of
maintainers for each platform.  Testing would need to happen of
course, and perhaps a holding area for proposed packages would suit
this phase.  Once a package is tested and approved only then would
link to it from the download pages/move it to general public downloads
area.


I agree, that sounds like a good way to manage that. It all hinges on 
getting maintainers to sign up though.



Could we just provide our own external CMake system for them then?
Most of these dependencies are complex beasts.


Yeah, I think that would be unweildly. But I won't know until I try it.


For the most part I would expect dependencies would change rarely.
Certainly less often than OSG releases.


Of course. And we will *need* to bump a dependency's version even less 
often (we don't need to always be up to date, just use the version 
that's stable and has the features we need).



So what options do we have for streamlining the build of the dependencies?


That's what I'm not sure about.

One option would be scripting, as you said. A Visual Studio project can 
be built from the command line (through arguments to devenv.exe), so it 
can be scripted. The same goes without saying for nmake-based builds.


Mike's way of working is not bad I think. He has a script that fetches 
the upstream sources (a specific version, which can be controlled in 
another script), unzips them to a directory, and then either builds it 
or gives instructions on which project to open up and what to do to 
build it. He also commits to his repo any changed project files, so that 
the sources are not forked but there is a trace of what he needed to change.


So just modifying that methodology to build Visual Studio projects from 
the command line too, and then automating the packaging (just zipping up 
the necessary build products and headers) would be a good place to start 
I think.


The part that's tedious is changing project settings and build options 
to be able to build debug and release side by side, and so they use the 
same VC runtime, etc. But as you said, we shouldn't have to update 
dependencies too often, so it might not be so bad. If the rest is 
automated, it'll be OK I think.



I'd be inclined towards static linking of these libs too, the only
other alternative is for use to name/version our built dependencies
uniquely so as not to risk overlapping with other installs of similar
but not quite the same libs.


Agreed.


There are also other heavier weight dependencies like COLLADA,
OpenVRML, LibXUL/xulrunner that users might want to pull in.  The
existing Win32 dependency list is really just the core dependencies.
How far out one should encompass centrally will something we should
leave the community - if volunteers are willing to support a
particular dependency package and there is a mechanism for us to
provide download space and consistent scheme for naming then we can
just leave the door open to this more specialist add ons.


Agreed.

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release

Hi All,

I'm now pretty well on top of submissions, so am looking towards
making a dev release tomorrow morning. Could users check out the
latest version of the OSG to see how things build and run on your
platform.

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

Re: [osg-users] Packaging granularity + platform specific scripts


Hi Robert,


I've just put up a wiki page to coordinate suggestions for packaging
names/contents/dependencies.  Feel free to add to/amend.

http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging


Looks good to me.

For Windows:
* I haven't built COLLADA, OpenVRML or Coin on Windows in a while, so 
not sure what they entail. They used to build fine before, though they 
needed a few tweaks to their build settings, see the now outdated


http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio/VisualStudioPlugins

* The PDF plugin depends on cairo and poppler. For cairo, we could get 
the gtk-bundle, and take only what we need (cairo headers and libs). I 
still haven't been able to compile poppler on Windows, though I admit I 
haven't put that much time into trying.


* The others (SVG, Gecko, VNC) I have never tried to compile the 
dependencies for on Windows, so I can't say anything for those.


It all comes down to not knowing until I try it though. So I suggest I 
put some time aside in the next few weeks to build a set of core 
dependencies for VC7.1, VC8 and VC9, and if I have time, COLLADA and 
OpenVRML too. Then I'll be in a better position to offer input on what 
can be improved.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release


Hi Robert,


I'm now pretty well on top of submissions, so am looking towards
making a dev release tomorrow morning. Could users check out the
latest version of the OSG to see how things build and run on your
platform.


I did an update this morning and built to test the wldap32 addition, it 
all built fine then. There are a few updated files since then so I'm 
running a new build, but I don't expect any surprises.


Windows Vista 32 bit, CMake 2.6.1, Visual C++ 2005.

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release


Hi Robert,

I did an update this morning and built to test the wldap32 addition, it 
all built fine then. There are a few updated files since then so I'm 
running a new build, but I don't expect any surprises.


Windows Vista 32 bit, CMake 2.6.1, Visual C++ 2005.


Confirmed, builds fine.

While we're talking about packaging, we should probably also start a 
thread about a related subject: what constitutes a good test suite for 
OSG builds. I typically run osgviewer cow.osg, and then a few other 
models that load png/jpg textures, a few OpenFlight models, etc. But 
perhaps we could make a list of examples that we could run in a batch 
file, and if they all run well then the build is considered to be in 
generally good shape.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linux Dev. Env. Poll

2008-11-27 Thread Mathieu MARACHE

Hi jp,

Sorry didn't see this earlier. Yes you can use meld within svn,
provided you use a script like described here :
http://svnbook.red-bean.com/en/1.4/svn.advanced.externaldifftools.html

here is the script I reproduced from here :
http://article.gmane.org/gmane.comp.gnome.meld.general/362

 Start: svn-diff-meld
#!/bin/sh
# SVN Diff Wrapper for Meld
# KOG 2008-02

left=$6
right=$7

meld $left $right
 End: svn-diff-meld

Then adapting it to diff3

 Start: svn-diff3-meld
#!/bin/sh
# SVN Diff3 Wrapper for Meld

mine=$9
older=$10
yours=$11

meld $mine $older $yours
 End: svn-diff3-meld

then modifying your ~/.subversion/config with these values should do the trick

[helpers]
diff-cmd = ABSOLUTE_PATH_TO/svn-diff-meld
diff3-cmd = ABSOLUTE_PATH_TO/svn-diff3-meld
diff3-has-program-arg = false



HTH

--
Mathieu



2008/11/27 J.P. Delport [EMAIL PROTECTED]:
 Hi,

 Paul Melis wrote:

 J.P. Delport wrote:

 Hi,

 Mathieu MARACHE wrote:

 Do you know if meld can integrate nicely with svn? E.g. I can do

 svn diff
 svn merge

 on command line and then it brings up xxdiff. Can meld do this (be an
 diff app for svn)? If it can I will definitely try.

 There does seem to be the environment variable SVN_MERGE that subversion
 looks at, but I'm not sure if that one has only been introduced in a very
 recent subversion release.

 I usually set diff-cmd and diff3-cmd in  ~/.subversion/config
 to xx-diff-proxy. I was wondering if meld had something similar?

 jp


 Regards,
 Paul



 --
 This message is subject to the CSIR's copyright terms and conditions, e-mail
 legal notice, and implemented Open Document Format (ODF) standard. The full
 disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks Transtec
 Computers for their support.

 ___
 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 test SVN of OpenSceneGraph in pre for 2.7.6 dev release

HI J-S,

On Thu, Nov 27, 2008 at 6:35 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
 While we're talking about packaging, we should probably also start a thread
 about a related subject: what constitutes a good test suite for OSG builds.
 I typically run osgviewer cow.osg, and then a few other models that load
 png/jpg textures, a few OpenFlight models, etc. But perhaps we could make a
 list of examples that we could run in a batch file, and if they all run well
 then the build is considered to be in generally good shape.

I run OpenSceneGraph/runexamples.bat as my base test.  It does have
all the examples, but does have most.  We've added quite a few since
it was last updated, for instance osgwidget and osganimation examples.

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

Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release


Hi Robert,


I run OpenSceneGraph/runexamples.bat as my base test.  It does have
all the examples, but does have most.  We've added quite a few since
it was last updated, for instance osgwidget and osganimation examples.


Perhaps we could devise a more minimal set of examples which cover the 
essentials but no more? runexamples.bat has too many IMHO. We should 
also include osgWidget and osgAnimation examples in the test run of 
course, but you knew that. :-)


Anyways, I'll use runexamples.bat for now. Thanks,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release

2008-11-27 Thread Alejandro Segovia

Hi Robert,

I'm having trouble building on Debian Etch. I'm getting the following error
when configuring within ccmake:

 IF had incorrect arguments: POLICY CMP0008 (Unknown arguments specified).

Perhaps my cmake version is too old, I'm using: cmake version 2.4-patch 5

Alejandro.-

On Thu, Nov 27, 2008 at 3:34 PM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi All,

 I'm now pretty well on top of submissions, so am looking towards
 making a dev release tomorrow morning. Could users check out the
 latest version of the OSG to see how things build and run on your
 platform.

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




-- 
[EMAIL PROTECTED]
http://varrojo.linuxuruguay.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release

2008-11-27 Thread Stephan Huber

Robert Osfield schrieb:
 Hi All,
 
 I'm now pretty well on top of submissions, so am looking towards
 making a dev release tomorrow morning. Could users check out the
 latest version of the OSG to see how things build and run on your
 platform.

Compile went smooth on OS X (using 10.4 + 10.5 sdk) with the deprecated
xcode-project-files. I added all missing files and added also the new
osganimation-lib as a framework and a new example osganimationviewer
(checked in already). I tested some of the examples -- no problem.

Additionally I enabled support for atomic operations when using the 10.5
sdk _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC, I think this would be a good
idea to add this to the cmake files. If I find some time this week, I'll
try to add it myself.

I'll try the cmake build the next days and report back.

cheers,
Stephan

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

[osg-users] Stats crashes on windows

2008-11-27 Thread Joakim Simonsson



Is there anybody else here who can easily crash osgViewer when pressing  
's' 3 or 4 times?


I'm running quite a complex model, and I can reproduce the crash  
everytime. I can reproduce it on both WinXP and Vista x64. Sometimes it  
crashes when 's' has been pressed 3 times, and sometime when it is presses  
4 times. When using a simpler model, it is more difficult to make it crash.


If the camera is standing still and I display the detailed stats, it  
doesn't seem to crash. But as soon as I start to move around it crashes.


It is in stl's vector header file where things stops:

_DEBUG_ERROR(vector iterator not dereferencable);

Callstack is attached as a text file, so unwanted linebreaks are avoided.


Oh.. By the way... I just discovered that the crashes does not seem to  
appear when running single threaded...






--
Joakim Simonssonmsvcp80d.dll!std::_Debug_message(const wchar_t * message=0x01a75578, const 
wchar_t * file=0x01a74ec8, unsigned int line=99)  Line 24
osg51-osgUtild.dll!std::_Vector_const_iteratorosgUtil::StateGraph 
*,std::allocatorosgUtil::StateGraph * ::operator*()  Line 99 + 0x14 bytes
osg51-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics  
stats={...})  Line 518 + 0x17 bytes
osg51-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics  
stats={...})  Line 538 + 0x1d bytes
osg51-osgUtild.dll!osgUtil::RenderStage::getStats(osgUtil::Statistics  
stats={...})  Line 1296 + 0xc bytes
osg51-osgUtild.dll!osgUtil::SceneView::getStats(osgUtil::Statistics  
stats={...})  Line 1694
osg51-osgViewerd.dll!osgViewer::CameraSceneStatsTextDrawCallback::drawImplementation(osg::RenderInfo
  renderInfo={...}, const osg::Drawable * drawable=0x08d3f7f0)  Line 359 + 
0x1e bytes
osg51-osgd.dll!osg::Drawable::draw(osg::RenderInfo  renderInfo={...})  Line 
896 + 0x27 bytes
osg51-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf * previous=0x03d4bb60)  Line 60 + 0x19 
bytes
osg51-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 419 + 0x19 
bytes
osg51-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo  renderInfo={...}, 
osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 384 + 0x17 bytes
osg51-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 469 + 0x35 
bytes
osg51-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 1253
osg51-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo  renderInfo={...}, 
osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 384 + 0x17 bytes
osg51-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf *  previous=0x03d4bb60, bool  
doCopyTexture=false)  Line 848
osg51-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo  
renderInfo={...}, osgUtil::RenderLeaf *  previous=0x03d4bb60)  Line 1108 + 
0x1b bytes
osg51-osgUtild.dll!osgUtil::SceneView::draw()  Line 1504 + 0x37 bytes
osg51-osgViewerd.dll!osgViewer::Renderer::cull_draw()  Line 545 + 0xf bytes
osg51-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext * 
context=0x0a4a8d28)  Line 646 + 0xf bytes
osg51-osgd.dll!osg::GraphicsContext::runOperations()  Line 688 + 0x33 bytes
osg51-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext * 
context=0x0a4a8d28)  Line 135
osg51-osgd.dll!osg::GraphicsOperation::operator()(osg::Object * 
object=0x0a4a8d28)  Line 50 + 0x19 bytes
osg51-osgd.dll!osg::OperationThread::run()  Line 413 + 0x26 bytes
osg51-osgd.dll!osg::GraphicsThread::run()  Line 40
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * 
data=0x0a752994)  Line 113 + 0xf bytes

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

Re: [osg-users] CUDA + osg compilation issues???

Ok, after just some break and cleaner head, I was able to reproduce the error 
by some smaller code. This piece of code doesn't compile:

#include stdio.h
#include GL/gl.h

class Test
{
public :
int getMagic() const { return (int)_glBindBuffer; }

private:

typedef void (*TestCase) (GLenum target);
TestCase _glBindBuffer;
};

int main()
{
Test* test = new Test;
printf(%d\n, test-getMagic());
return 0;
}

However changing private to public definition solve the issue. I have already 
posted the problem on the nvidia forum. Let see, if the right people do react 
on this ;)

Cheers,
art


--- Art Tevs [EMAIL PROTECTED] schrieb am Do, 27.11.2008:

 Von: Art Tevs [EMAIL PROTECTED]
 Betreff: Re: [osg-users] CUDA + osg compilation issues???
 An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Datum: Donnerstag, 27. November 2008, 16:16
 After some more investigation it seems that cudafe (a tool
 from the CUDA compilation chain, which separates C/C++ from
 GPU code) isn't able to parse the files correctly. The
 problem is, that there are no decription of how to use
 cudafe as standalone thing, so that it seems to be more or
 less unsuccessful to find out what goes wrong there.
 
 I check out if it would be possible to generate a bug
 report, however requiring the whole osg/include directory
 just to regenerate a bug is somehow overblown ;(
 
 If somebody does know more, I would be very appreciated.
 
 
 Cheers
 art
 
 
 
 --- Art Tevs [EMAIL PROTECTED] schrieb am Do,
 27.11.2008:
 
  Von: Art Tevs [EMAIL PROTECTED]
  Betreff: Re: [osg-users] CUDA + osg compilation
 issues???
  An: OpenSceneGraph Users
 osg-users@lists.openscenegraph.org
  Datum: Donnerstag, 27. November 2008, 15:55
  Hi Paul,
  
  yes it does, and I am currently investigating the
 output ;)
  Interesting thign is that replacing the line in the
 test
  case
  
  #include osg/State
  
  by this:
  
  #include GL/gl.h
  #define GLenum unsigned int 
  #include osg/State
  
  does remove the first error and breaks down on other
  definitions of GLxxx types. It could be that for
 whatever
  reasons the headers are not processed very well.
  
  cheers
  
  --- Paul Melis [EMAIL PROTECTED] schrieb am
 Do,
  27.11.2008:
  
   Von: Paul Melis [EMAIL PROTECTED]
   Betreff: Re: [osg-users] CUDA + osg compilation
  issues???
   An: [EMAIL PROTECTED], OpenSceneGraph
  Users osg-users@lists.openscenegraph.org
   Datum: Donnerstag, 27. November 2008, 15:50
   Art Tevs wrote:
Hi folks,
   
has anybody of you ever tried to compile .cu
  cuda-file
   with nvcc, which does include osg headers. Here
 is
  just a
   simple test case which doesn't compile for
  whatever
   reasons:
   
#include stdio.h
#include osg/State
   
   
int main()
{
osg::State* test = new osg::State;
printf(%d\n,
   test-getContextID());
return 0;
}
   
compiled with:
nvcc -cuda test.cu
   
The compilation breaks down with the error:
/osg/State(1289): error: identifier-list
  parameters
   may only be used in a function definition
/osg/State(1290): error: identifier-list
  parameters
   may only be used in a function definition
/osg/State(1290): error: expected an
 identifier
   
and so on.
   
   
I don't know what could be wrong there.
 If
   somebody was able to get CUDA code compiled
 beside of
  osg, I
   would be very appreciated to know more ;)
  
   Does nvcc have a preprocess-only mode (something
 like
  -E)?
   So you can 
   see what the real input is to the compiler...
   
   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


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

Re: [osg-users] bump mapping using GLSL shaders

Hi Ümit,

Considering you want to *animate* your bump/normal map, you may:
- Use an image sequence of normal maps, that has the advantage of being almost 
the same code as for a non animated bump.
- Or look at (procedural) shaders, that will have the advantage of not taking 
memory for textures, even if you want a very smooth animation.

I just can't help you for shaders because I don't know anything about them. Try 
searching the web.

For non animated bumps, well maybe many wrote examples or code using it but I 
can't indicate you where.
For my part, I used a bump for the loading screen of a tiny game: the bump is 
loaded from a gray-scale, then converted to a normal map using my function, 
applied to a quad, and then modulated by the color texture. The light source 
then moves during the loading process. The code can be found at 
http://paratrooper.svn.sourceforge.net/viewvc/paratrooper/trunk/Src/App.cpp?view=markup
 (search for TexEnvCombine::DOT3_RGB and you'll find a block of code about 
the logo). Code is GPL, but as long as you just take a few lines, there's no 
problem for me using it the way you want.
Once it works for you, you'll be able to replace the texture by an image 
sequence.

However, you should try to have a look to shaders. If you find or acheive to 
write a nice animation, please tell me!

Hope it helps.

Just for curiosity: what are you working on?

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 27 Nov 2008 08:27:53 +0100, Ümit Uzun [EMAIL PROTECTED] a écrit:

 Hi Sukender,

 Thanks for reply. Sorry I can't express my expected result because of my
 english :P Yes you understood me albeit my bad express. I have RGB texture
 and want to create bump map animated surface to make more realistic surface.
 I find normal map usage only osgVolume.cpp sample. If you know more sample,
 please let me know.

 Thanks for helps.
 Best Regards.

 2008/11/27 Sukender [EMAIL PROTECTED]

 Hi Ümit,

 Err... I'm terribly sorry but I did not understood all of what you wrote...
 (maybe my english?)

 What do you call Ocean wave texture? Is that simply the RGB texture
 describing the color of your ocean's surface? If so, then the color of the
 texture is rarely related to bump/normal mapping. You'll have to create from
 scratch (or find) a bump/normal map. You can try using a picture edition
 software (such as the Gimp) and use filters or generators to create a
 gray-scaled image (where white=high and black=low). This is what I often do
 when I don't need to bee 100% realistic: that's just a nice bump map.

 I know you can create normal mapping for low polys from hi polys, but
 that's not the goal of the function I told you. createNormalMap() only
 converts a gray-scaled image to a normal map (texture that is blueish). The
 normal map can be then used more easily in OSG/OpenGL, using
 TexEnvCombine::DOT3_RGB. If you need examples, you can look at the OSG
 samples (I guess there is a normal map somewhere), or ask me.

 Note that using Google, I easily found some bump maps examples:
 http://www.filterforge.com/filters/216-bump.jpg
 http://www.m3corp.com/a/download/3d_textures/bump/instantcarpet.jpg

 I just hope this answers your questions.

 Sukender
 PVLE - Lightweight cross-platform game engine -
 http://pvle.sourceforge.net/


 Le Wed, 26 Nov 2008 16:01:29 +0100, Ümit Uzun [EMAIL PROTECTED] a
 écrit:

  Hi Sukender,
 
  I have searched about Normal Map and I see that to create normal map we
 need
  2 models( high detailed polygon and low detailed polygon ) and then we
 can
  create normal map using ray casting to find high detailed models normals
 at
  intersected areas and then save this normal as a texture which name is
  NormalMap.
 
  But my question is, I want to create NormalMap the ocean waves. But I
  haven't any models. Can I use Ocean wave texture to create bumpmapping? I
  mean Can I create NormalMap from related wave texture?
 
  If I send the my oceanwave texture to the createNormalMap function, then
 I
  think. take back bluish normal map Sukender?
 
  2008/11/26 Sukender [EMAIL PROTECTED]
 
  This is not related to GLSL, but if someone needs it, I quickly wrote a
  function that transforms a gray-scale bump map into a normal map:
  http://pvle.sourceforge.net/Doc/Html/Utility3D_8cpp-source.html#l00115
  Hope this may be useful to someone, even if the function is not that
 clean.
 
  Sukender
  PVLE - Lightweight cross-platform game engine -
  http://pvle.sourceforge.net/
 
 
  Le Wed, 26 Nov 2008 13:29:33 +0100, Morné Pistorius 
  [EMAIL PROTECTED] a écrit:
 
   Thanks,
   I managed to implement a standard bump mapping shader in OSG.  Below
 is a
   code snippet that does it if it might help someone else.  Shaders are
   attached.
  
   Cheers,
   Morne
  
   osg::Node * VOSGFloorGrid::CreateBumpMappedFloor()
   {
 const int BASE_TEX_UNIT = 0;
 const int BUMP_TEX_UNIT = 1;
 const int TANGENT_ATR_UNIT = 6;
 const int

Re: [osg-users] osgAudio / osgAL

Hi Robert,

 I was to develop osgAudio I would use osgAL/OpenAL as a template,
 much in the same way as you seem to be look at the topic.  I'd also
 see how SDL audio might map as this has cross platform audio support
 that might be reasonable implementation for non spaitialized sound.

And maybe we should have a look to some other libs too, such as SFML ( 
http://www.sfml-dev.org )?

 I would also try to keep things decoupled so items like a Manager
 would be something that is implementation dependent, rather that
 something that end user need worry about.

Sorry I don't understand. Do you mean you're in favor of my second idea (having 
a kind of priorirty for sounds that the plugin would use to automatically turn 
on/off sounds to fit the limitation of the number of sources)?

 I would have thought that
 one might be able to capture the camera position relative to
 listener/sound sources by using the existing cull traversal as the way
 to extract the required info to pass on to OpenAL.   Threading and
 multiple camera traversals might throw this a bit though...  so
 perhaps a standard alone audio traversal would be appropriate as one
 would only have one audio context.  Perhaps the ideal would be to
 allow the viewer to run an audio thread that runs in parallel with the
 cull/draw traversal threads.

Having a separate thread sounds fine to me. CPU is not used enough for audio! 
Maybe a good occlusion computation would add immersion; so I think a separate 
thread is better. Should there be audio update and cull/render traverals for 
the viewer then?

 I am overloaded with my existing work so I can't take on any of this
 work myself, I'll happy cheer on from the side lines though.  I
 certainly want to see an osgAudio merged into the core OSG.  Perhaps a
 feature for OSG-2.10.

 Robert.

I'm also too busy to work on osgAudio, but I'd like to help as much as I can.


Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/



 On Thu, Nov 27, 2008 at 1:37 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert, hi everyone,

 I totally agree that we need an abstraction layer and plugins. So let's say 
 osgAudio is that abstraction layer, and that osgAL is a future plugin 
 based on the current osgAL work.
 - What would be in the osgAudio then?
 - Should we (and how could we do to) leave a degree of freedom to plugins so 
 that users can access specific features (= not handled in osgAudio)?

 I guess osgAudio has to be very simple. Here are some of my ideas:
 - As LightSources, there should be AudioSources nodes that we can position 
 somewhere.
 - AudioSource may be absolute (= heard everywhere = no distance attenuation 
 = no culling).
 - AudioSource should be attached to a Sound (= AudioData = buffer or stream 
 + some parameters like doppler factor, gain, velocity...)
 - Sound should be able to read many formats/codecs (PCM, Vorbis...)
 - There should be a cache for sounds (for buffers but not for streams I 
 guess!)
 - The user may update the Sounds parameters on update traversal (mainly for 
 the velocity - For me, the physics will drive this value)
 - There should be Listeners, and the main Listener should be by default 
 linked with the main camera (Is that easy to do?)
 - Sounds may be occuled, but I wonder if it's better to add occulder 
 geometries in the world, or set a specific flag on existing geometries to 
 say they occult sounds.
 Well this looks much like osgAL, but that's normal! However, I'd like to 
 remove the presence of the osgAL manager if possible.

 About allocation/deallocation of internal sound buffers, I have two ideas:
 1. As for lights, the user is limited to a given number and he has to 
 manually switch on/off those (s)he wants.
 2. This not be the matter of the user. Eventually (s)he could set their 
 number, but not much more. The sources are given a base priority, which can 
 be lowered if the sound is attenuated (= if listener is far). The 'n' most 
 important AudioSources would then be active and the other inactive. 
 Eventually, a parameter would have to say if AudioSources may or may not be 
 stopped suring playing to leave another one play (= a more imporant one).

 Which one do you prefer? The second idea looks a little bit like the 
 LightSourcesManager I wrote (that switch on the 8 most important lights), 
 and that can easily be generalized. The advantage is simplicity for the 
 user, and the drawback is that we then cannot remove the osgAL manager I 
 told before.

 I hope this will help to see an osgAudio soon!

 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 27 Nov 2008 11:17:01 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 Hi Sukender,

 Previously I have looked at merging osgAL into svn/trunk, but on
 review of the code decided that a straight merge was inappropriate.
 For end user build simplicity OpenAL++ and osgAL would be best merged.

 The structure of an audio library for

Re: [osg-users] Packaging granularity + platform specific scripts

Hi Robert and J-S,

 One couldn't have a totally open system for uploading. Only
 maintainers would be able to upload.  We could include a number of
 maintainers for each platform.  Testing would need to happen of
 course, and perhaps a holding area for proposed packages would suit
 this phase.  Once a package is tested and approved only then would
 link to it from the download pages/move it to general public downloads
 area.

 I agree, that sounds like a good way to manage that. It all hinges on
 getting maintainers to sign up though.


Here is a sum up/proposal. This is just a draft, and I think that it could be 
useful to improve/augment/correct this. Maybe this also could be on a wiki 
page? Well, as you (OSG gurus) wish!

1. Roles
- Maintainer (builds packages for a specific toolset, tests the built packages, 
moves to public area when tested)
- Tester (Helps the maintainer testing deployed binaries = has access to non 
public built packages)
- Admin (Manages permissions of maintainers, writes test cases)

2. Infrastructure:
- A public download area.
- A private (= currently in test) download area.
- A wiki/tracker/shared spreadsheet/something to list ToDo's and bugs.
- A wiki/tracker/shared spreadsheet/something to sum up the packages, toolsets, 
and their state (not done, building, built, testing, ok).
- A wiki/something to keep useful documentation and notes about building.
Maintainers have write access to everything. Testers have write access to bugs 
report (read access for other things).

What do you think about it?

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] VPB: osgdem ignoring vertical multiplier

2008-11-27 Thread Alejandro Aguilar Sierra

Hello:

I created a geotiff file with all necesary data. The resulting
terrain, using osgdem, is correct.

Now I'd like to exagerate the vertical scale in another model. I tried
to force the vertical scale assigning a vertical multiplier -v 10.0
but osgdem ignores it.

Any hint?

Thanks in advance.

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

[osg-users] Determine texture memory allocation size

Hi,

does anybody of you know if it is possible to determine the size of allocated 
bytes of texture in the memory (VRAM or just RAM if swapped). One can compute 
it by the internal texture format and data type, however I would be interested 
if there exists some opengl routine which do gives me texture memory size 
directly.

Cheers,
art




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

Re: [osg-users] Determine texture memory allocation size

2008-11-27 Thread Gordon Tomlinson

Sorry Opengl does not provide any such function or capability, you have to
track this on your own I'm afraid



__

Capture the magic of Christmas this year see http://www.capturethemagic.com

__

Gordon Tomlinson 

[EMAIL PROTECTED]
IM: [EMAIL PROTECTED]
www.vis-sim.com www.gordontomlinson.com 

__

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Art Tevs
Sent: Thursday, November 27, 2008 6:15 PM
To: OpenSceneGraph Users
Subject: [osg-users] Determine texture memory allocation size

Hi,

does anybody of you know if it is possible to determine the size of
allocated bytes of texture in the memory (VRAM or just RAM if swapped). One
can compute it by the internal texture format and data type, however I would
be interested if there exists some opengl routine which do gives me texture
memory size directly.

Cheers,
art




  
___
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] Determine texture memory allocation size


Hi Art, Gordon,


Sorry Opengl does not provide any such function or capability, you have to
track this on your own I'm afraid


OpenGL doesn't, but if you install nVidia's instrumented drivers, there 
are a large number of counters you can query for low-level things like this.


I'm not sure there's a counter for the memory used by a single texture, 
it might just be total texture memory used by a context. But you can 
always load the texture using osgviewer --image and then the total 
texture memory used by the context *is* the texture memory used by your 
texture! :-)


But other than using these instrumented drivers (and I think they're 
only for Windows, but I'm not sure, so see their site to be sure) I 
don't know another way.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to compile OSG with Dev-C++ and 3rdParty source in Cmake!

2008-11-27 Thread Wang Rui

Hi YangXiao

Maybe you should try to build required 3rd dependence with mingw (which is
the default compiler of Dev-Cpp) first, and then build OSG with CMake.

Wang Rui
2008/11/28 YangXiao [EMAIL PROTECTED]

   Hi Everyone:
  I already  setup  QT and   Dev-C++  on my computer and integrate in
 Eclipse,But when i compile osg and  3rdParty ,I found only a Visual c++ 8
 sp1 binary lib.

 How to compile OSG with Dev-C++ and 3rdParty source in Cmake?

 Someone can give me  advices!
 Best regards.

 YangXiao



 --
 好玩贺卡等你发，邮箱贺卡全新上线！http://cn.rd.yahoo.com/mail_cn/tagline/card/*http://card.mail.cn.yahoo.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] Linux Dev. Env. Poll