Re: [osg-users] Multiple GPU

[ufuk gun]

Hi,
Thank you so much for your answers. :)
i will research and try your advices. I wanted to learn where to start.
i will let you know what i have done about this.

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

Re: [osg-users] LWO loading problem

[Simon Hammett]

Works ok in 2.7.1.

2009/2/5 Csaba Halász :
> Hi everybody.
>
> I have gotten a report that the LWO loader doesn't seem to work.
> Investigating, I grabbed the sample LWO file posted by Marco Jez back
> in november last year (attached for convenience).
> Loading into osgviewer, I get an empty view. Trying osgconv, I get an
> osg file full of zeroes and nans (also attached).
> With SIGFPE enabled, gdb shows:
>
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread 0x7f9b6be43730 (LWP 10599)]
> 0x7f9b6756e456 in lwosg::Block::setup_texture_point
> (this=0xaee3c8, p...@0x7fff73fdcca0) at
> OpenSceneGraph/src/osgPlugins/lwo/Block.cpp:141
> 141 Q.x() *= 1/imap_.mapping.size_.x();
> Current language:  auto; currently c++
> (gdb) p imap_.mapping
> $1 = {center_ = {_v = {0, 0, 0}}, size_ = {_v = {0, 0, 0}}, rotation_
> = {_v = {0, 0, 0}},
>  csys_ = lwosg::Texture_mapping::OBJECT}
>
> That's clearly the source of the nans but maybe not the root of the problem.
> I haven't tried to find the exact svn rev this got broken yet, maybe
> somebody has a quick solution right away.
>
> --
> Thanks,
> Csaba
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Render to Texture and per vertex colors

[Joseba]

Thanks, I will take a look!!

J.

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=5923#5923





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

Re: [osg-users] "Works with 2.8" campaign :-)

[Can T. Oguz]

Sure!

Can

2009/2/4 Robert Osfield 

> Hi All,
>
> I would like to see the OSG-2.8 branch tested out across as many
> platforms and 3rd party applications as we can this week, as this will
> be the best way for us to shake down the release and make sure it's
> really ready to go 2.8.0 thank we can all rely upon for months to
> come.
>
> It occurred to me that we might be able to entice end users to come
> forward and give a public thumbs up that OSG-2.8 works well with their
> applications, it'll give some focus on the tasks of actually testing
> OSG-2.8 against their own applications, and it might give the
> community a bit of buzz knowing what applications/libraries that are
> out their that are using the OSG.  Perhaps we could even coordinate
> this into a wiki page with links to those projects, with screenshots
> if you are up to it.  Does this sound like a good idea?
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Ümit Uzun]

Hi Jean;

Thanks for quick explanations, I am holding building directory separated
from source directory and before building always I delete all files in
building directory, but I get same result after 3 try :( I don't understand
as you. But I will checkout the 2.8 and try this branch in different
directory.

And after osg web site get alive I will look at the cdash and try to
scheduled nightly build. I hope it is simple to get understand quickly,
because I haven't tried cdash yet :)

Thanks so much again,
Best Regards.

2009/2/4 Jean-Sébastien Guay 

> Hi Umit,
>
>  System : VisualStudio2003, Cmake2.6, OSGLastSvnTrunk, XP SP3
>>
>
> You're getting a lot of warnings in the standard headers, and the only time
> I've seen these was back when the aggressive warnings flags were set to /W4
> /Wall... Now /Wall has been removed, but maybe it's still in your
> CMakeCache.txt for some reason. Can you try deleting your cache and starting
> fresh? That will at least eliminate one possible cause.
>
> If you can, you should schedule a task to do a nightly build since I think
> all the nightly builds right now are VS 2005 and 2008. It would be good to
> get 2003 in there so we can check it routinely. See the wiki for
> instructions on how to make a nightly build (type "CDash" in the search
> field at the top, the site is down right now so I can't give you the exact
> URL). See the reports here for where your nightly build would end up:
>
> http://www.cdash.org/CDashPublic/index.php?project=OpenSceneGraph
>
> Oh, and if you do decide to schedule a nightly build, check out the 2.8
> branch and use that for your nightly builds for now, until 2.8 ships. That
> way you're testing the build for the release. When 2.8 is released you can
> switch to using the trunk for the nightly build. This is the URL of the 2.8
> branch to check out with SVN, but of course you can only do that once the
> site is back up :-)
>
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/
>
> Thanks,
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   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
>



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

Re: [osg-users] exporting from OSG to OpenFlight

[Paul Martz]

When you said "node" in your original post, I thought you were referring to
OSG Nodes, not OpenFlight records. :-)
 
The flt plugin options are documented here:
http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFl
ight
(the wiki seems to be down at the moment, so I was unable to verify this
bookmark.)
 
I think you want to have "version=15.6" in your Options string. This will
export a 15.6 model without the Mesh record.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael
Kelley
Sent: Wednesday, February 04, 2009 6:57 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] exporting from OSG to OpenFlight



Mesh nodes were added to the OpenFlight spec in version 15.7, and it seems
to me that the intention was to provide a replacement for the inefficient
face nodes.  However, in our experience it seems like a lot of companies
aren't using mesh nodes, so I wanted to test data that contains the old
style object->face nodes.

 

From: "Paul Martz" http://groups.google.com/groups/unlock?_done=/group/osg-users/msg/02fc8318d
f6e0ace&msg=02fc8318df6e0ace> @skew-matrix.com>

Date: Wed, 4 Feb 2009 17:28:37 -0700

Local: Wed, Feb 4 2009 4:28 pm 

Subject: Re: [osg-users] exporting from OSG to OpenFlight

Reply
  |
Reply to author
  |
Forward
  | Print

| View thread
  | Show original

| Report this message
  | Find messages by
this author
  

Can you be more specific about what you are trying to do? 

Paul Martz 
Skew Matrix Software LLC 
http://www.skew-matrix.com  
+1 303 859 9466 

  _   

From: osg-users-boun...
 @lists.openscenegraph.org 
[mailto:osg-users-boun...
 @lists.openscenegraph.org] On Behalf Of
Michael 
Kelley 
Sent: Wednesday, February 04, 2009 5:17 PM 
To: osg-us...
 @lists.openscenegraph.org 
Subject: [osg-users] exporting from OSG to OpenFlight 

Is there a way to export Object nodes instead of Mesh nodes when converting 
from OpenSceneGraph to OpenFlight? 

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





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

Re: [osg-users] Triangular mesh with OSG

[Paul Martz]

Yes, you can put all of them in a single Geometry and use a single
PrimitiveSet such as DrawElementsUByte to draw them. Take a look at the
osggeometry example, or load the cow.osg in an editor and see how it draws
several triangles with few Geometry objects.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ruqin Zhang
Sent: Wednesday, February 04, 2009 9:32 PM
To: OpenSceneGraph Users
Subject: [osg-users] Triangular mesh with OSG


Hi there,

Here, I got a question about drawing 3D mesh with OSG.

I have the following information available:
(1) number of vertices
(2) position of each vertex
(3) number of triangular faces
(4) indexes for vertices involved in each triangular face

I can draw each single triangular face as an osg::Geometry and then add all
of them as children into a huge osg::Geode. While, I don't want to do that. 
So, here I am just wondering if there is a way to put all these triangles
into one
osg::Geometry.

BTW, do you guys have any information about some internet resources for 3D
mesh parameterization, mapping or morphing sort of stuff? Thanks a lot!

Ruqin

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi Umit,


System : VisualStudio2003, Cmake2.6, OSGLastSvnTrunk, XP SP3


You're getting a lot of warnings in the standard headers, and the only 
time I've seen these was back when the aggressive warnings flags were 
set to /W4 /Wall... Now /Wall has been removed, but maybe it's still in 
your CMakeCache.txt for some reason. Can you try deleting your cache and 
starting fresh? That will at least eliminate one possible cause.


If you can, you should schedule a task to do a nightly build since I 
think all the nightly builds right now are VS 2005 and 2008. It would be 
good to get 2003 in there so we can check it routinely. See the wiki for 
instructions on how to make a nightly build (type "CDash" in the search 
field at the top, the site is down right now so I can't give you the 
exact URL). See the reports here for where your nightly build would end up:


http://www.cdash.org/CDashPublic/index.php?project=OpenSceneGraph

Oh, and if you do decide to schedule a nightly build, check out the 2.8 
branch and use that for your nightly builds for now, until 2.8 ships. 
That way you're testing the build for the release. When 2.8 is released 
you can switch to using the trunk for the nightly build. This is the URL 
of the 2.8 branch to check out with SVN, but of course you can only do 
that once the site is back up :-)


http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Triangular mesh with OSG

[Ruqin Zhang]

Hi there,

Here, I got a question about drawing 3D mesh with OSG.

I have the following information available:
(1) number of vertices
(2) position of each vertex
(3) number of triangular faces
(4) indexes for vertices involved in each triangular face

I can draw each single triangular face as an osg::Geometry and then add all
of them as children into a huge osg::Geode. While, I don't want to do that.
So, here I am just wondering if there is a way to put all these triangles
into one
osg::Geometry.

BTW, do you guys have any information about some internet resources for 3D
mesh parameterization, mapping or morphing sort of stuff? Thanks a lot!

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Terry Welsh]

Fedora 7, gcc 4.1.2.  When compiling I get endless warnings like the
ones following this message.  But I've tested with a couple very
demanding apps and can't see any runtime problems.
--
Terry Welsh  /  mogumbo 'at' gmail.com
www.reallyslick.com  /  www.mogumbo.com


/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/i386-redhat-linux/bits/c++locale.h:
In function 'int std::__convert_from_v(char*, int, const char*, _Tv,
__locale_struct* const&, int) [with _Tv = double]':
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/locale_facets.tcc:1099:
  instantiated from '_OutIter std::num_put<_CharT,
_OutIter>::_M_insert_float(_OutIter, std::ios_base&, _CharT, char,
_ValueT) const [with _ValueT = double, _CharT = char, _OutIter =
std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/locale_facets.tcc:1259:
  instantiated from '_OutIter std::num_put<_CharT,
_OutIter>::do_put(_OutIter, std::ios_base&, _CharT, double) const
[with _CharT = char, _OutIter = std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/locale_facets.h:2365:
  instantiated from '_OutIter std::num_put<_CharT,
_OutIter>::put(_OutIter, std::ios_base&, _CharT, double) const [with
_CharT = char, _OutIter = std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/ostream.tcc:370:
  instantiated from 'std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT =
char, _Traits = std::char_traits]'
/usr/local/src/OpenSceneGraph-2.8.0-rc1/src/osg/CullSettings.cpp:116:
 instantiated from here
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/i386-redhat-linux/bits/c++locale.h:86:
warning: format not a string literal, argument types not checked
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/i386-redhat-linux/bits/c++locale.h:86:
warning: format not a string literal, argument types not checked
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] how to get video card's maximum sampling rate?

[forest37]

hi all,
   I have a problem with antialiasing. when I set the sampling rate with 16 
,the window in which I draw the three-dimension scene will expand to full 
screen if the video cards don't support the sampling rate.
So I have to get every machine's maximum sampling rate,how can I achieve this?  
 
  Thanks in advance.
  best regards.
forest
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] exporting from OSG to OpenFlight

[Michael Kelley]

Mesh nodes were added to the OpenFlight spec in version 15.7, and it seems
to me that the intention was to provide a replacement for the inefficient
face nodes.  However, in our experience it seems like a lot of companies
aren't using mesh nodes, so I wanted to test data that contains the old
style object->face nodes.

 

From: "Paul Martz" http://groups.google.com/groups/unlock?_done=/group/osg-users/msg/02fc8318d
f6e0ace&msg=02fc8318df6e0ace> @skew-matrix.com>

Date: Wed, 4 Feb 2009 17:28:37 -0700

Local: Wed, Feb 4 2009 4:28 pm 

Subject: Re: [osg-users] exporting from OSG to OpenFlight

Reply
  |
Reply to author
  |
Forward
  | Print

| View thread
  | Show original

| Report this message
  | Find messages by
this author
  

Can you be more specific about what you are trying to do? 

Paul Martz 
Skew Matrix Software LLC 
http://www.skew-matrix.com  
+1 303 859 9466 

  _   

From: osg-users-boun...
 @lists.openscenegraph.org 
[mailto:osg-users-boun...
 @lists.openscenegraph.org] On Behalf Of
Michael 
Kelley 
Sent: Wednesday, February 04, 2009 5:17 PM 
To: osg-us...
 @lists.openscenegraph.org 
Subject: [osg-users] exporting from OSG to OpenFlight 

Is there a way to export Object nodes instead of Mesh nodes when converting 
from OpenSceneGraph to OpenFlight? 

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





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

Re: [osg-users] osgPango (Stop Worrying & Love The Bomb)

[Ümit Uzun]

Thanks for your effort Jeremy. These all awesome :)

2009/2/4 Sukender 

> Well, I only need basic text features for now, but that really sounds
> interesting. Maybe in the future?
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
>
> Le Wed, 04 Feb 2009 21:15:16 +0100, Jeremy Moles 
> a écrit:
>
> > Hello all. Before I start hacking on osgWidget again full force (in
> > preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my
> > wares here and generating interest in a different (BUT RELATED) project
> > of mine called osgPango.
> >
> > Basically, I'm writing osgPango to achieve the following (in order):
> >
> >   1. TOP quality 2D fonts in OSG on all supported platforms.
> >   2. A sophisticated layout/markup system for complicated text.
> >   3. An extensible rendering backend that lets users create
> >  callbacks for the actual "rendering" of the font character.
> >   4. Speed, speed, and more speed.
> >   5. Clean and intuitive API that exposes all elements of a body
> >  of text (the position of each character, etc.)
> >
> > Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get
> > started with some obligatory screenshots:
> >
> >   http://cubicool.plopbyte.net/osgPango-normal.png
> >
> > Here is some undecorated text (no shadows or outlines) showing one of
> > Robert's posts from earlier this week. Notice how the text is justified
> > to a certain width, and that it is no problem for osgPango to change
> > font style or color midway through a sentence or word! Also notice the
> > font quality, where no character is missing a pixel on any side and
> > straight vertical lines are sharp and not "smudged" along two pixels.
> >
> >   http://cubicool.plopbyte.net/osgPango-shadow.png
> >
> > Same as the above screenshot, except that the paragraph width is
> > shortened and there are now +1, +1 drop shadows (their offset is
> > configurable).
> >
> >   http://cubicool.plopbyte.net/osgPango-outline.png
> >
> > Here we change our alignment to RIGHT and add 1px black outlines to the
> > fonts.
> >
> > I'd like to get other people who need high-quality 2D fonts to start
> > keeping an eye on osgPango so I can start seeing how folks want to use
> > and extend it's feature set (where possible). I've tested it personally
> > on Linux and Vista 64, but I'd need someone else to try it on Mac.
> >
> > (As an aside, it should use the ATSUI backend on Mac, giving some pretty
> > nice font quality! It uses FreeType on Linux and ClearType on Windows;
> > to get it compile on Windows I simply used the binaries from the GTK
> > project)
> >
> > The main osgPango website is here:
> >
> >   http://osgpango.googlecode.com
> >
> > It won't be long before I consider it done (for me) and move back to
> > osgWidget and start helping more with osgAnimation, so let me know soon
> > if you're interested and need it to do something it doesn't. :)
> >
> > With time I hope to be able to get osgPango in the core and replace
> > osgText, but we'll have to see. :) The advanced layout powers and
> > pluggable rendering backends are two things it would be VERY hard to add
> > to osgText.
> >
> > As far as speed is concerned, osgPango is currently just as fast as
> > osgText for most normal usage, though obviously every time you change
> > font families or color or size you introduce a state change. :)
> > Placeholder code is also in place for someone to add a GLSL shader to do
> > the multitexturing instead of the complicated osg::TexEnvCombine()
> > object I currently use, and I'm sure we'd see some significant speed
> > increases there as well (when effects are used or desired).
> >
> > ___
> > 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
>



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

[osg-users] LWO loading problem

[Csaba Halász]

Hi everybody.

I have gotten a report that the LWO loader doesn't seem to work.
Investigating, I grabbed the sample LWO file posted by Marco Jez back
in november last year (attached for convenience).
Loading into osgviewer, I get an empty view. Trying osgconv, I get an
osg file full of zeroes and nans (also attached).
With SIGFPE enabled, gdb shows:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7f9b6be43730 (LWP 10599)]
0x7f9b6756e456 in lwosg::Block::setup_texture_point
(this=0xaee3c8, p...@0x7fff73fdcca0) at
OpenSceneGraph/src/osgPlugins/lwo/Block.cpp:141
141 Q.x() *= 1/imap_.mapping.size_.x();
Current language:  auto; currently c++
(gdb) p imap_.mapping
$1 = {center_ = {_v = {0, 0, 0}}, size_ = {_v = {0, 0, 0}}, rotation_
= {_v = {0, 0, 0}},
  csys_ = lwosg::Texture_mapping::OBJECT}

That's clearly the source of the nans but maybe not the root of the problem.
I haven't tried to find the exact svn rev this got broken yet, maybe
somebody has a quick solution right away.

-- 
Thanks,
Csaba


multitextured_cube.lwo
Description: Binary data


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

Re: [osg-users] Render to Texture and per vertex colors

[Art Tevs]

Hi, Joseba

ok, there is now a new example called glow in the osgPPU svn. I have 
implemented the first version of the glow. Hence just created a slave camera 
and render only the thing, which I want to glow by the second camera. Then 
apply gaussian blur on the output of the second camera and combine it with the 
main camera. Then write results to the frame buffer.

Take a look. I choosed the version with the slave camera, because then you 
doesn't need to change any object shaders. You just render the object as it is 
, with its complete subgraph by the slave camera and blur the result.

The example isn't perfect. One should also apply some kind of stencil masking, 
to render only the silhuette of the glowed object (if you need so). Also a 
depth buffer check has to be made, because the slave camera doesn't have the 
depth information form the main camera. If I would find some time, I  will also 
implement this. However just to understand how a glow effect  works with 
osgPPU, this example should be enough ;)


Best regards,
art



Shaitan wrote:
> Hi Art,
> It would be great to see this demo!!!
> Another good idea is to use another camera for the 'glow objects', this match 
> perfectly with my pipeline, with minor changes on the shaders. 
> Although i propossed to use OsgPPU on the app we are doing, at this time we 
> use another postprocessing effects, so at this moment we need a quite big 
> change on it to use osgPPU (im sure that when osgPPU gets inside osg core, we 
> will use it).
> Ill try to send you the small app using osgPPU that crahses.
> 
> Thanx
> 
> J.


--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=5908#5908





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

Re: [osg-users] 3.0 or 2.10?

[Jean-Sébastien Guay]

Hi Paul,

Hi all -- I've seen a couple of posts now implying that the next stable 
release after 2.8 will be called "3.0". I wanted to open a discussion on 
this so that we can get some clarification.


I don't think this is the case. Robert has only referred to 3.0 when 
talking about introducing an OpenGL 3.0-only pipeline, i.e. not relying 
on the fixed pipeline at all. This will probably not happen in the next 
stable release after 2.8, thus there will surely be a 2.10, 2.12, etc. 
before we see 3.0.


At least that's how I understood it. The fact that Robert and Art have 
started discussions on "the road to OSG 3.0" does not automatically 
imply that 3.0 will be the next stable version of OSG.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] About OpenGL materials

[Jean-Sébastien Guay]

Hi Shayne,


This may be a naive comment but couldn't you leverage something similar to
glColorMaterial() to accomplish the task? 


I think glColorMaterial is the opposite, i.e. it will place whatever 
glColor is set as (i.e. vertex colors for example) into the current 
material. What I (thought I) wanted was to set the material color into 
the vertex colors.


Anyways, the problem was solved in another (more direct) way, see my 
previous post.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] About OpenGL materials

[Jean-Sébastien Guay]

Hi Roger,

Here is a probably worthless suggestion written without a proper review 
of the thread. I you want a material that looks the same as the unlit 
colour just set the materials emissive colour to the same as the vertex 
colour and set all the other material colours to black.


Well, reviewing the osgFX::Scribe code, this is exactly what it does. 
The problem was that our own Outline effect (based on Scribe, but only 
renders the outside edges of the object) disabled lighting in the 
outline pass. Thus, it was using the raw vertex color of the object for 
its outline color, which is why I didn't want to use vertex colors.


Re-enabling lighting for the outline pass made it use the emissive 
material color, and made it so that I could disable lighting on my model 
and use vertex colors for its own colors without affecting the color of 
the outline.


So, I would say problem solved. Thanks also to Paul Melis who pointed me 
to the osgscribe example, in which I saw the same thing was being done 
and led me to check the lighting setting on my outline pass...


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] About OpenGL materials

[Jean-Sébastien Guay]

Hi Bryan,


Couldn't you just disable color arrays when you want the scribe/outline effect 
(see osg::State::disableColorPointer(); would require a DrawCallback, though)?


Interesting, I didn't know you could do that, I'll look into it.

Thanks for the suggestion,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] exporting from OSG to OpenFlight

[Paul Martz]

Can you be more specific about what you are trying to do?
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael
Kelley
Sent: Wednesday, February 04, 2009 5:17 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] exporting from OSG to OpenFlight



Is there a way to export Object nodes instead of Mesh nodes when converting
from OpenSceneGraph to OpenFlight?

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

Re: [osg-users] About OpenGL materials

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

This may be a naive comment but couldn't you leverage something similar to
glColorMaterial() to accomplish the task? 

Just a thought...

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Wednesday, February 04, 2009 3:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] About OpenGL materials

Hi Gordon,

(sorry, sent before I had finished typing...)

> No Lighting = No Material 

Hmmm, and any way to make it so that lighting has no effect (even though 
it's on) for a given object? I thought about putting a 1x1 texture with 
in GL_DECAL mode, but then I would need a texture for each color I want 
in my models (since it would even override the material color) right?

What I'm getting at is I'm very flexible as to how I get the color onto 
my model, as long as it isn't through the vertex colors since that 
overrides the scribe/outline effect's color.

> You probably could do this with in a shader but you would have to
replicate the full fixed pipeline calculation of lighting,materials,
textures , fogs etc ( which you have to do anyway  )

I already have shaders for most of the fixed pipeline (what I need) but 
these can be disabled by the user, and whatever I'm trying to display 
would need to look the same both with shaders on and off... So I need a 
solution that works for the fixed pipeline too.

I'll try to think about another way...

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] exporting from OSG to OpenFlight

[Michael Kelley]

Is there a way to export Object nodes instead of Mesh nodes when converting
from OpenSceneGraph to OpenFlight?

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

Re: [osg-users] About OpenGL materials

[Roger James]

Jean-Sébastien Guay wrote:
Hi
Gordon,
  
  
(sorry, sent before I had finished typing...)
  
  
  No Lighting = No Material 

Hi J-S,

Here is a probably worthless suggestion written without a proper review
of the thread. I you want a material that looks the same as the unlit
colour just set the materials emissive colour to the same as the vertex
colour and set all the other material colours to black.

Roger


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

Re: [osg-users] 3.0 or 2.10?

[Art Tevs]

HI,

I agree on that the next version will still be 2.x. Only if we really go for a 
completly different API (with almost no backward compatibility), then we should 
go to 3.x

The previous thread just collected some ideas about how to manage future 
releases of osg 3.x The idea was to go away from current nodekit thing and to 
separate the real main core part. Then with the help of something like 
NodeKitSuite one could add additional node kits. The main core would only have 
the real main core of a scene graph. All other suites will just provide 
functionality like ViewerSuite (whcih will include osgViewer), then 
InteractionSuite (here one could include osgWidget, osgGA, ...), then 
EffectSuite (here osgParticle, ...) and so on.

Cheers,
art

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=5901#5901





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

Re: [osg-users] 3.0 or 2.10?

[Sukender]

Hi Paul,

This needs to be confirmed, but I think Robert's mind is to go to 3.0 to allow 
the whole community to introduce things that "break backwards compatibility", 
as you say. You even posted a thing on the thread "Ideas for OSG v3.0", where 
Art Tevs told about reorganizing nodekits/plugins ( 
http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 ).
Of course if nothing special breaks the compatibility, or if there is not a 
huge pile of new features, I think going to 2.10 should be okay.

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


Le Thu, 05 Feb 2009 00:11:04 +0100, Paul Martz  a écrit:

> Hi all -- I've seen a couple of posts now implying that the next stable
> release after 2.8 will be called "3.0". I wanted to open a discussion on
> this so that we can get some clarification.
> 
> Unless the next stable release will break lots of backwards compatibility,
> I'd opt for calling it "2.10", then "2.12", etc. No need to change the major
> revision number unless we break backwards compatibility, and although there
> has been some discussion of that, nothing definite yet at this point as far
> as I know.
> 
> Robert, comments?
> 
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com 
> +1 303 859 9466

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

Re: [osg-users] About OpenGL materials

[Thrall, Bryan]

Jean-Sébastien Guay wrote on Wednesday, February 04, 2009 4:43 PM:
> What I'm getting at is I'm very flexible as to how I get the color onto
> my model, as long as it isn't through the vertex colors since that
> overrides the scribe/outline effect's color.

Couldn't you just disable color arrays when you want the scribe/outline effect 
(see osg::State::disableColorPointer(); would require a DrawCallback, though)?

-- 
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 3.0 or 2.10?

[Cedric Pinson]

I am agree with this notation.

Paul Martz wrote:
Hi all -- I've seen a couple of posts now implying that the next 
stable release after 2.8 will be called "3.0". I wanted to open a 
discussion on this so that we can get some clarification.
 
Unless the next stable release will break lots of backwards 
compatibility, I'd opt for calling it "2.10", then "2.12", etc. No 
need to change the major revision number unless we break backwards 
compatibility, and although there has been some discussion of that, 
nothing definite yet at this point as far as I know.
 
Robert, comments?
 
Paul Martz

*Skew Matrix Software LLC*
http://www.skew-matrix.com 
+1 303 859 9466
 



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


--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:morni...@plopbyte.net 
http://www.plopbyte.net


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

[osg-users] 3.0 or 2.10?

[Paul Martz]

Hi all -- I've seen a couple of posts now implying that the next stable
release after 2.8 will be called "3.0". I wanted to open a discussion on
this so that we can get some clarification.
 
Unless the next stable release will break lots of backwards compatibility,
I'd opt for calling it "2.10", then "2.12", etc. No need to change the major
revision number unless we break backwards compatibility, and although there
has been some discussion of that, nothing definite yet at this point as far
as I know.
 
Robert, comments?
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] About OpenGL materials

[Jean-Sébastien Guay]

Hi Gordon,

(sorry, sent before I had finished typing...)

No Lighting = No Material 


Hmmm, and any way to make it so that lighting has no effect (even though 
it's on) for a given object? I thought about putting a 1x1 texture with 
in GL_DECAL mode, but then I would need a texture for each color I want 
in my models (since it would even override the material color) right?


What I'm getting at is I'm very flexible as to how I get the color onto 
my model, as long as it isn't through the vertex colors since that 
overrides the scribe/outline effect's color.



You probably could do this with in a shader but you would have to replicate the 
full fixed pipeline calculation of lighting,materials, textures , fogs etc ( 
which you have to do anyway  )


I already have shaders for most of the fixed pipeline (what I need) but 
these can be disabled by the user, and whatever I'm trying to display 
would need to look the same both with shaders on and off... So I need a 
solution that works for the fixed pipeline too.


I'll try to think about another way...

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] When is right time to update text on the screen

[Pecoraro, Alexander N]

Ok I figured out by looking closer at the stats handler that a better
way to do it is to implement a draw callback for the text object that
uses a mutex to prevent multiple threads from accessing the text string
simultaneously.

 

Alex



From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Pecoraro, Alexander N
Sent: Tuesday, February 03, 2009 5:17 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] When is right time to update text on the screen

 

I seem to have fixed the problem by setting the data variance on my
osgText object to DYNAMIC. I'm wondering if this is the proper way to
handle this situation though - because when I look at the StatsHandler
for an example it appears to be modifying it's osgText nodes, but it
does not set the data variance to DYNAMIC. Why does it work for the
StatsHandler, but not for my code? Is it because the StatsHandler
modifies its text during the event traversal and I modify my text during
the update traversal? Should I be modifying it during event traversal
only?

 

Thanks.

 

Alex

 



From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Pecoraro, Alexander N
Sent: Tuesday, February 03, 2009 4:26 PM
To: OpenSceneGraph Users
Subject: [osg-users] When is right time to update text on the screen

 

Is there a proper time to make changes to an osgText object's text? I
seem to be having a problem where if I update some text in an update
callback function it causes a segfault when I'm running the viewer in
multi-threaded mode, but not in single threaded mode. I'm guessing
because the text object is modified while is it being used by the render
thread. Is there something wrong with how I am doing it?

 

Thanks.

 

Alex

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

Re: [osg-users] osgPango (Stop Worrying & Love The Bomb)

[Sukender]

Well, I only need basic text features for now, but that really sounds 
interesting. Maybe in the future?

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


Le Wed, 04 Feb 2009 21:15:16 +0100, Jeremy Moles  a 
écrit:

> Hello all. Before I start hacking on osgWidget again full force (in
> preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my
> wares here and generating interest in a different (BUT RELATED) project
> of mine called osgPango.
>
> Basically, I'm writing osgPango to achieve the following (in order):
>
>   1. TOP quality 2D fonts in OSG on all supported platforms.
>   2. A sophisticated layout/markup system for complicated text.
>   3. An extensible rendering backend that lets users create
>  callbacks for the actual "rendering" of the font character.
>   4. Speed, speed, and more speed.
>   5. Clean and intuitive API that exposes all elements of a body
>  of text (the position of each character, etc.)
>
> Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get
> started with some obligatory screenshots:
>
>   http://cubicool.plopbyte.net/osgPango-normal.png
>
> Here is some undecorated text (no shadows or outlines) showing one of
> Robert's posts from earlier this week. Notice how the text is justified
> to a certain width, and that it is no problem for osgPango to change
> font style or color midway through a sentence or word! Also notice the
> font quality, where no character is missing a pixel on any side and
> straight vertical lines are sharp and not "smudged" along two pixels.
>
>   http://cubicool.plopbyte.net/osgPango-shadow.png
>
> Same as the above screenshot, except that the paragraph width is
> shortened and there are now +1, +1 drop shadows (their offset is
> configurable).
>
>   http://cubicool.plopbyte.net/osgPango-outline.png
>
> Here we change our alignment to RIGHT and add 1px black outlines to the
> fonts.
>
> I'd like to get other people who need high-quality 2D fonts to start
> keeping an eye on osgPango so I can start seeing how folks want to use
> and extend it's feature set (where possible). I've tested it personally
> on Linux and Vista 64, but I'd need someone else to try it on Mac.
>
> (As an aside, it should use the ATSUI backend on Mac, giving some pretty
> nice font quality! It uses FreeType on Linux and ClearType on Windows;
> to get it compile on Windows I simply used the binaries from the GTK
> project)
>
> The main osgPango website is here:
>
>   http://osgpango.googlecode.com
>
> It won't be long before I consider it done (for me) and move back to
> osgWidget and start helping more with osgAnimation, so let me know soon
> if you're interested and need it to do something it doesn't. :)
>
> With time I hope to be able to get osgPango in the core and replace
> osgText, but we'll have to see. :) The advanced layout powers and
> pluggable rendering backends are two things it would be VERY hard to add
> to osgText.
>
> As far as speed is concerned, osgPango is currently just as fast as
> osgText for most normal usage, though obviously every time you change
> font families or color or size you introduce a state change. :)
> Placeholder code is also in place for someone to add a GLSL shader to do
> the multitexturing instead of the complicated osg::TexEnvCombine()
> object I currently use, and I'm sure we'd see some significant speed
> increases there as well (when effects are used or desired).
>
> ___
> 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] "Works with 2.8" campaign :-)

[Sukender]

Le Wed, 04 Feb 2009 18:36:36 +0100, Jean-Sébastien Guay 
 a écrit:

> Hi Robert,
>
>> Does this sound like a good idea?
>
> Definitely! :-)
>
> (when did you turn into a marketing mogul?)
>
> J-S


+1 :)

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Sukender]

Hi JS,

Yes, they're mostly in the wrappers. As I told before, I'm a bit in a hurry, so 
I won't be able fix them now.

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


Le Wed, 04 Feb 2009 21:57:54 +0100, Jean-Sébastien Guay 
 a écrit:

> Hi Sukender,
>
>>> Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1
>>> express, all inclusive, CMake cache cleared, full release rebuild.
>>> See the dashboard for details. Unfortunately, it has >50 warnings.
>>
>> I guess most are in the wrappers? I don't build the wrappers at all...
>> You'll need to go through and try to fix the warnings and then submit
>> the fixes to Robert, though the wrappers are less used so I guess it's
>> less critical if there are warnings there?
>
> I just checked the CDash page for your build. The first three should be
> fixed as soon as Robert can commit the changes I sent earlier (as soon
> as the server allows him to :-) ). The rest seem to be all in the wrappers.
>
> J-S

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Paul Melis]

Robert Osfield wrote:
> But still we can't rest if we want to make 2.8.0 the best we can... so
> please download/check out the OpenSceneGraph-2.8 branch or the
> 2.8.0-rc1 and do compile and runtime checks on as wide range of
> platforms as you have to hand.  I would also greatly value feedback on
> how you own applications are performing with 2.8, if there are issues
> please just report them on osg-users and we can together have a bash
> at resolve them.
>   
DCMTK, installed locally, was also not found completely by CMake,
specifically some of the include paths where missing. I slightly changed
the relevant module to reuse the DCMTK_ROOT_INCLUDE_DIR variable, which
is the first one searched for.

I also get the following warning:

/home/melis/c/osg/svn/branches-2.8/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:
In member function 'virtual osgDB::ReaderWriter::ReadResult
ReaderWriterDICOM::readImage(const std::string&, const
osgDB::ReaderWriter::Options*) const':
/home/melis/c/osg/svn/branches-2.8/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:421:
warning: 'pixelRep' may be used uninitialized in this function

But I'm having a hard time figuring out if it is valid or not.

Paul
# - find DCMTK libraries
#

#  DCMTK_INCLUDE_DIRS  - Directories to include to use DCMTK
#  DCMTK_LIBRARIES - Files to link against to use DCMTK
#  DCMTK_FOUND - If false, don't try to use DCMTK
#  DCMTK_DIR   - (optional) Source directory for DCMTK
#
# DCMTK_DIR can be used to make it simpler to find the various include
# directories and compiled libraries if you've just compiled it in the
# source tree. Just set it to the root of the tree where you extracted
# the source.
#
# Written for VXL by Amitha Perera.
# Modified by Robert Osfied to enable support for install placements of DCMTK 
3.5.4 versions onwards

FIND_PATH( DCMTK_ROOT_INCLUDE_DIR dcmtk/config/osconfig.h
${DCMTK_DIR}/config/include 
${DCMTK_DIR}/include
/usr/local/include/
/usr/include/
/usr/local/dicom/include/
)

FIND_PATH( DCMTK_config_INCLUDE_DIR osconfig.h
${DCMTK_DIR}/config/include 
${DCMTK_DIR}/include
/usr/local/include/dcmtk/config
/usr/include/dcmtk/config
/usr/local/dicom/include/dcmtk/config
)

FIND_PATH( DCMTK_ofstd_INCLUDE_DIR ofstdinc.h
${DCMTK_DIR}/ofstd/include 
${DCMTK_DIR}/include/ofstd
/usr/local/include/dcmtk/ofstd
/usr/include/dcmtk/ofstd
/usr/local/dicom/include/dcmtk/ofstd
)

FIND_LIBRARY( DCMTK_ofstd_LIBRARY ofstd
${DCMTK_DIR}/ofstd/libsrc
${DCMTK_DIR}/ofstd/libsrc/Release
${DCMTK_DIR}/ofstd/libsrc/Debug
${DCMTK_DIR}/ofstd/Release
${DCMTK_DIR}/ofstd/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmdata_INCLUDE_DIR dctypes.h
${DCMTK_DIR}/dcmdata/include
${DCMTK_DIR}/include/dcmdata
/usr/local/include/dcmtk/dcmdata
/usr/include/dcmtk/dcmdata
/usr/local/dicom/include/dcmtk/dcmdata
)

FIND_LIBRARY( DCMTK_dcmdata_LIBRARY dcmdata
${DCMTK_DIR}/dcmdata/libsrc
${DCMTK_DIR}/dcmdata/libsrc/Release
${DCMTK_DIR}/dcmdata/libsrc/Debug
${DCMTK_DIR}/dcmdata/Release
${DCMTK_DIR}/dcmdata/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmimgle_INCLUDE_DIR dcmimage.h
${DCMTK_DIR}/dcmimgle/include
${DCMTK_DIR}/include/dcmimgle
/usr/local/include/dcmtk/dcmimgle
/usr/include/dcmtk/dcmimgle
/usr/local/dicom/include/dcmtk/dcmimgle
)

FIND_LIBRARY( DCMTK_dcmimgle_LIBRARY dcmimgle
${DCMTK_DIR}/dcmimgle/libsrc
${DCMTK_DIR}/dcmimgle/libsrc/Release
${DCMTK_DIR}/dcmimgle/libsrc/Debug
${DCMTK_DIR}/dcmimgle/Release
${DCMTK_DIR}/dcmimgle/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_imagedb_LIBRARY imagedb 
${DCMTK_DIR}/imagectn/libsrc/Release
${DCMTK_DIR}/imagectn/libsrc/
${DCMTK_DIR}/imagectn/libsrc/Debug
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_dcmnet_LIBRARY dcmnet 
${DCMTK_DIR}/dcmnet/libsrc/Release
${DCMTK_DIR}/dcmnet/libsrc/Debug
${DCMTK_DIR}/dcmnet/libsrc/
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


IF( DCMTK_config_INCLUDE_DIR 
AND DCMTK_ofstd_INCLUDE_DIR 
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )

  SET( DCMTK_FOUND "YES" )
  SET( DCMTK_INCLUDE_DIRS
${DCMTK_config_INCLUDE_DIR}
${DCMTK_ofstd_INCLUDE_DIR}
${DCMTK_dcmdata_INCLUDE_DIR}
${DCMTK_dcmimgle_INCLUDE_DIR}
  )

  SET( DCMTK_LIBRARIES
${DCMTK_dcmimgle_LIBRARY}
${DCMTK_dcmdata_LIBRARY}
${DCMTK_ofstd_LIBRARY}
${DCMTK_config_LIBRARY}
  )

  IF(DCMTK_imagedb_LIBRARY

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[christophe loustaunau]

Hi,

build with no warnings on OpenSuse 11.1, gcc 4.3.2 and cmake 2.6.2
I have tested some examples and everything works fine.

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi Sukender,

Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 
express, all inclusive, CMake cache cleared, full release rebuild.

See the dashboard for details. Unfortunately, it has >50 warnings.


I guess most are in the wrappers? I don't build the wrappers at all... 
You'll need to go through and try to fix the warnings and then submit 
the fixes to Robert, though the wrappers are less used so I guess it's 
less critical if there are warnings there?


I just checked the CDash page for your build. The first three should be 
fixed as soon as Robert can commit the changes I sent earlier (as soon 
as the server allows him to :-) ). The rest seem to be all in the wrappers.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi Sukender,


Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, 
all inclusive, CMake cache cleared, full release rebuild.
See the dashboard for details. Unfortunately, it has >50 warnings.


I guess most are in the wrappers? I don't build the wrappers at all... 
You'll need to go through and try to fix the warnings and then submit 
the fixes to Robert, though the wrappers are less used so I guess it's 
less critical if there are warnings there?


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] osgPango (Stop Worrying & Love The Bomb)

[Tomlinson, Gordon]

Looks cool. 


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jeremy
Moles
Sent: Wednesday, February 04, 2009 3:15 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgPango (Stop Worrying & Love The Bomb)

Hello all. Before I start hacking on osgWidget again full force (in
preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my
wares here and generating interest in a different (BUT RELATED) project
of mine called osgPango.

Basically, I'm writing osgPango to achieve the following (in order):

1. TOP quality 2D fonts in OSG on all supported platforms.
2. A sophisticated layout/markup system for complicated text.
3. An extensible rendering backend that lets users create
   callbacks for the actual "rendering" of the font character.
4. Speed, speed, and more speed.
5. Clean and intuitive API that exposes all elements of a body
   of text (the position of each character, etc.)

Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get
started with some obligatory screenshots:

http://cubicool.plopbyte.net/osgPango-normal.png

Here is some undecorated text (no shadows or outlines) showing one of
Robert's posts from earlier this week. Notice how the text is justified
to a certain width, and that it is no problem for osgPango to change
font style or color midway through a sentence or word! Also notice the
font quality, where no character is missing a pixel on any side and
straight vertical lines are sharp and not "smudged" along two pixels.

http://cubicool.plopbyte.net/osgPango-shadow.png

Same as the above screenshot, except that the paragraph width is
shortened and there are now +1, +1 drop shadows (their offset is
configurable).

http://cubicool.plopbyte.net/osgPango-outline.png

Here we change our alignment to RIGHT and add 1px black outlines to the
fonts.

I'd like to get other people who need high-quality 2D fonts to start
keeping an eye on osgPango so I can start seeing how folks want to use
and extend it's feature set (where possible). I've tested it personally
on Linux and Vista 64, but I'd need someone else to try it on Mac.

(As an aside, it should use the ATSUI backend on Mac, giving some pretty
nice font quality! It uses FreeType on Linux and ClearType on Windows;
to get it compile on Windows I simply used the binaries from the GTK
project)

The main osgPango website is here:

http://osgpango.googlecode.com

It won't be long before I consider it done (for me) and move back to
osgWidget and start helping more with osgAnimation, so let me know soon
if you're interested and need it to do something it doesn't. :)

With time I hope to be able to get osgPango in the core and replace
osgText, but we'll have to see. :) The advanced layout powers and
pluggable rendering backends are two things it would be VERY hard to add
to osgText.

As far as speed is concerned, osgPango is currently just as fast as
osgText for most normal usage, though obviously every time you change
font families or color or size you introduce a state change. :)
Placeholder code is also in place for someone to add a GLSL shader to do
the multitexturing instead of the complicated osg::TexEnvCombine()
object I currently use, and I'm sure we'd see some significant speed
increases there as well (when effects are used or desired).

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Cory Riddell]

Sorry for the false alarm. I rebuilt everything and and it seems to be
working.

Cory

On Wed, Feb 4, 2009 at 2:45 PM, Cory Riddell  wrote:

> Yeah, I started wondering if I built the wrong source tree. I started the
> whole process over again and should know pretty soon. Even on a 4-core
> machine, it takes a while to build everything (but at least the build
> process can mostly run in parallel).
>
> Cory
>
>
> On Wed, Feb 4, 2009 at 2:21 PM, Jean-Sébastien Guay <
> jean-sebastien.g...@cm-labs.com> wrote:
>
>> Hi again Cory,
>>
>>  I always use a different CMAKE_INSTALL_PREFIX than the default, and it
>>> works well for me, which is why I suggest you re-check the setting... If
>>> it's really set to what you say, then there might be some other problem.
>>>
>>
>> Just out of curiosity I checked myself and here's what I got:
>>
>> 1>-- Build started: Project: INSTALL, Configuration: Debug Win32
>> --
>> 1>
>> 1>Performing Post-Build Event...
>> 1>-- Install configuration: "Debug"
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs/osg32-32.png
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs/osg32-32.png
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openscenegraph.pc
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openthreads.pc
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/OpenThreadsd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/ot11-OpenThreadsd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/OpenThreads/Config
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osg/Config
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgDBd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgDBd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgUtild.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgUtild.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgGAd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgGAd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTextd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTextd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgViewerd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgViewerd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/GraphicsWindowWin32
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/PixelBufferWin32
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgAnimationd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgAnimationd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgFXd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgFXd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgManipulatord.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgManipulatord.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgParticled.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgParticled.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgShadowd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgShadowd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgSimd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgSimd.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTerraind.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTerraind.dll
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgWidgetd.lib
>> 1>-- Installing:
>> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgWidgetd.dll
>> 1>-- Installing:
>> C:/Dev/Open

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi Cory,

Yeah, I started wondering if I built the wrong source tree. I started 
the whole process over again and should know pretty soon.


You could have just re-run the CMake GUI to see the value 
CMAKE_INSTALL_PREFIX was set to...


Even on a 
4-core machine, it takes a while to build everything (but at least the 
build process can mostly run in parallel).


Yes, it's about 20 minutes on my Quad-core Windows machine (if you don't 
enable wrappers...). On Linux it's quicker (much quicker for those lucky 
owners of Core i7 machines, eh Robert?).


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Cory Riddell]

Yeah, I started wondering if I built the wrong source tree. I started the
whole process over again and should know pretty soon. Even on a 4-core
machine, it takes a while to build everything (but at least the build
process can mostly run in parallel).

Cory

On Wed, Feb 4, 2009 at 2:21 PM, Jean-Sébastien Guay <
jean-sebastien.g...@cm-labs.com> wrote:

> Hi again Cory,
>
>  I always use a different CMAKE_INSTALL_PREFIX than the default, and it
>> works well for me, which is why I suggest you re-check the setting... If
>> it's really set to what you say, then there might be some other problem.
>>
>
> Just out of curiosity I checked myself and here's what I got:
>
> 1>-- Build started: Project: INSTALL, Configuration: Debug Win32 --
> 1>
> 1>Performing Post-Build Event...
> 1>-- Install configuration: "Debug"
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs/osg32-32.png
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs/osg32-32.png
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openscenegraph.pc
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openthreads.pc
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/OpenThreadsd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/ot11-OpenThreadsd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/OpenThreads/Config
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osg/Config
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgDBd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgDBd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgUtild.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgUtild.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgGAd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgGAd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTextd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTextd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgViewerd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgViewerd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/GraphicsWindowWin32
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/PixelBufferWin32
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgAnimationd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgAnimationd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgFXd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgFXd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgManipulatord.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgManipulatord.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgParticled.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgParticled.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgShadowd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgShadowd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgSimd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgSimd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTerraind.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTerraind.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgWidgetd.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgWidgetd.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgVolumed.lib
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgVolumed.dll
> 1>-- Installing:
> C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jeremy Moles]

On Wed, 2009-02-04 at 14:40 +, Robert Osfield wrote:
> Hi All,
> 
> We're finally one the home straight now - OpenSceneGraph-2.8 branch
> has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created
> off this.
> 
> News page:
> http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8
> 
> Download page:
> http://www.openscenegraph.org/projects/osg/wiki/Downloads
> 
> OpenSceneGraph-2.8.0-rc1 source code:
> 
> source package:
> http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip
> svn tag: svn co
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1
> OpenSceneGraph
> 
> OpenSceneGraph-2.8 branch:
> 
> svn tag: svn co
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8
> OpenSceneGraph
> 
> 
> Updates (since 2.6.1) include: ¶
> 
> * New osgVolume library for volume rendering, with support for:
>   o High quality GPU based Ray tracing
>   o Transfer functions
>   o Per pixel lighting
>   o Iso surface rendering
>   o Maximum Intensity rendering
>   o non power of two 3d texture and 3d texture compression
>   o DICOM loader for reading dicom medical data
> * New osgAnimation library for character and scene animation.
> * New plugin for reading Biovision hierarchical files (.BVH) to
> generate character motion animations.
> * New osgShadow support for Light Space Perspective Shadow Maps.
> * Three new scene graph widgets for placing traditional 2D
> capability into fully interactive 3D scenes:
>   o PDF widget support (based on libPoppler)
>   o VNC client widget support (based on libVNCServer)
>   o Internet browser client widget support (based on Gecko/UBrowser)
> * New plugins for loading Half-Life 2 maps and models.
> * New plugin for loaded exr, high dynamic range imagery
> * Improvements to DatabasePager tailored for low latency paging.
> * Improved runtime stats collection and on screen reporting.
> * Performance improvements through optimization of matrix operations.
> * Support for the OpenGL draw instanced extension.
> * Improvements to COLLADA support.
> * Build reporting using CDash
> * New packing support using CPack
> * A wide range of build and bug fixes
> 
> Many many thanks to all those who've put in time on testing out 2.7.9
> and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for
> release snapshot we've ever done ;-)
> 
> But still we can't rest if we want to make 2.8.0 the best we can... so
> please download/check out the OpenSceneGraph-2.8 branch or the
> 2.8.0-rc1 and do compile and runtime checks on as wide range of
> platforms as you have to hand.  I would also greatly value feedback on
> how you own applications are performing with 2.8, if there are issues
> please just report them on osg-users and we can together have a bash
> at resolve them.
> 
> For uploading of packages I have requested ftp access to the server
> for uploading, I let you know of the details if we can get this set
> up.

The warning is gone! :) Wee! (The one from
ViewerEventHandlers::InteractiveImageHandler)

Happy day...

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

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi again Cory,

I always use a different CMAKE_INSTALL_PREFIX than the default, and it 
works well for me, which is why I suggest you re-check the setting... If 
it's really set to what you say, then there might be some other problem.


Just out of curiosity I checked myself and here's what I got:

1>-- Build started: Project: INSTALL, Configuration: Debug Win32 --
1>
1>Performing Post-Build Event...
1>-- Install configuration: "Debug"
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs/osg32-32.png
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs/osg32-32.png
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openscenegraph.pc
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openthreads.pc
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/OpenThreadsd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/ot11-OpenThreadsd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/OpenThreads/Config
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osg/Config
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgDBd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgDBd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgUtild.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgUtild.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgGAd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgGAd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTextd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTextd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgViewerd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgViewerd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/GraphicsWindowWin32
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/PixelBufferWin32
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgAnimationd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgAnimationd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgFXd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgFXd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgManipulatord.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgManipulatord.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgParticled.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgParticled.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgShadowd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgShadowd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgSimd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgSimd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTerraind.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTerraind.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgWidgetd.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgWidgetd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgVolumed.lib
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgVolumed.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osganimationd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osgfxd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osgparticled.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osgsimd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osgtextd.dll
1>-- Installing: 
C:/Dev/OpenSceneGraph-SVN/Ope

Re: [osg-users] osgPango (Stop Worrying & Love The Bomb)

[Cedric Pinson]

Just awesome 

Jeremy Moles wrote:

Hello all. Before I start hacking on osgWidget again full force (in
preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my
wares here and generating interest in a different (BUT RELATED) project
of mine called osgPango.

Basically, I'm writing osgPango to achieve the following (in order):

1. TOP quality 2D fonts in OSG on all supported platforms.
2. A sophisticated layout/markup system for complicated text.
3. An extensible rendering backend that lets users create
   callbacks for the actual "rendering" of the font character.
4. Speed, speed, and more speed.
5. Clean and intuitive API that exposes all elements of a body
   of text (the position of each character, etc.)

Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get
started with some obligatory screenshots:

http://cubicool.plopbyte.net/osgPango-normal.png

Here is some undecorated text (no shadows or outlines) showing one of
Robert's posts from earlier this week. Notice how the text is justified
to a certain width, and that it is no problem for osgPango to change
font style or color midway through a sentence or word! Also notice the
font quality, where no character is missing a pixel on any side and
straight vertical lines are sharp and not "smudged" along two pixels.

http://cubicool.plopbyte.net/osgPango-shadow.png

Same as the above screenshot, except that the paragraph width is
shortened and there are now +1, +1 drop shadows (their offset is
configurable).

http://cubicool.plopbyte.net/osgPango-outline.png

Here we change our alignment to RIGHT and add 1px black outlines to the
fonts.

I'd like to get other people who need high-quality 2D fonts to start
keeping an eye on osgPango so I can start seeing how folks want to use
and extend it's feature set (where possible). I've tested it personally
on Linux and Vista 64, but I'd need someone else to try it on Mac.

(As an aside, it should use the ATSUI backend on Mac, giving some pretty
nice font quality! It uses FreeType on Linux and ClearType on Windows;
to get it compile on Windows I simply used the binaries from the GTK
project)

The main osgPango website is here:

http://osgpango.googlecode.com

It won't be long before I consider it done (for me) and move back to
osgWidget and start helping more with osgAnimation, so let me know soon
if you're interested and need it to do something it doesn't. :)

With time I hope to be able to get osgPango in the core and replace
osgText, but we'll have to see. :) The advanced layout powers and
pluggable rendering backends are two things it would be VERY hard to add
to osgText.

As far as speed is concerned, osgPango is currently just as fast as
osgText for most normal usage, though obviously every time you change
font families or color or size you introduce a state change. :)
Placeholder code is also in place for someone to add a GLSL shader to do
the multitexturing instead of the complicated osg::TexEnvCombine()
object I currently use, and I'm sure we'd see some significant speed
increases there as well (when effects are used or desired).

___
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:morni...@plopbyte.net 
http://www.plopbyte.net


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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jean-Sébastien Guay]

Hi Cory,

I built everything with Visual Studio 2005 on XP with no build problems. 
One minor glitch that may be my fault- when I ran the built the INSTALL 
target, it copied the executables to C:\Program Files\OpenSceneGraph 
rather than C:\Program Files\OpenSceneGraph-2.8 (I specified this in CMake).


Are you sure you changed CMAKE_INSTALL_PREFIX to C:\Program 
Files\OpenSceneGraph-2.8 ? If you checked out the 2.8 branch to a new 
empty directory, the cache would have been empty so you would have had 
to change it again.


I always use a different CMAKE_INSTALL_PREFIX than the default, and it 
works well for me, which is why I suggest you re-check the setting... If 
it's really set to what you say, then there might be some other problem.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] osgPango (Stop Worrying & Love The Bomb)

[Jeremy Moles]

Hello all. Before I start hacking on osgWidget again full force (in
preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my
wares here and generating interest in a different (BUT RELATED) project
of mine called osgPango.

Basically, I'm writing osgPango to achieve the following (in order):

1. TOP quality 2D fonts in OSG on all supported platforms.
2. A sophisticated layout/markup system for complicated text.
3. An extensible rendering backend that lets users create
   callbacks for the actual "rendering" of the font character.
4. Speed, speed, and more speed.
5. Clean and intuitive API that exposes all elements of a body
   of text (the position of each character, etc.)

Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get
started with some obligatory screenshots:

http://cubicool.plopbyte.net/osgPango-normal.png

Here is some undecorated text (no shadows or outlines) showing one of
Robert's posts from earlier this week. Notice how the text is justified
to a certain width, and that it is no problem for osgPango to change
font style or color midway through a sentence or word! Also notice the
font quality, where no character is missing a pixel on any side and
straight vertical lines are sharp and not "smudged" along two pixels.

http://cubicool.plopbyte.net/osgPango-shadow.png

Same as the above screenshot, except that the paragraph width is
shortened and there are now +1, +1 drop shadows (their offset is
configurable).

http://cubicool.plopbyte.net/osgPango-outline.png

Here we change our alignment to RIGHT and add 1px black outlines to the
fonts.

I'd like to get other people who need high-quality 2D fonts to start
keeping an eye on osgPango so I can start seeing how folks want to use
and extend it's feature set (where possible). I've tested it personally
on Linux and Vista 64, but I'd need someone else to try it on Mac.

(As an aside, it should use the ATSUI backend on Mac, giving some pretty
nice font quality! It uses FreeType on Linux and ClearType on Windows;
to get it compile on Windows I simply used the binaries from the GTK
project)

The main osgPango website is here:

http://osgpango.googlecode.com

It won't be long before I consider it done (for me) and move back to
osgWidget and start helping more with osgAnimation, so let me know soon
if you're interested and need it to do something it doesn't. :)

With time I hope to be able to get osgPango in the core and replace
osgText, but we'll have to see. :) The advanced layout powers and
pluggable rendering backends are two things it would be VERY hard to add
to osgText.

As far as speed is concerned, osgPango is currently just as fast as
osgText for most normal usage, though obviously every time you change
font families or color or size you introduce a state change. :)
Placeholder code is also in place for someone to add a GLSL shader to do
the multitexturing instead of the complicated osg::TexEnvCombine()
object I currently use, and I'm sure we'd see some significant speed
increases there as well (when effects are used or desired).

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

Re: [osg-users] 2.8: XUL not completely found

[Paul Melis]

Hi Robert,

Here's an updated FindXUL.cmake that works for me. It uses pkg-config to
discover some extra paths.
Now osgbrowser google.com works for me!

Two remarks:
- It doesn't do any version checks, although the pkg-config CMake macros
are capable of this (but I don't know if there are any version reqs)
- The paths discovered with pkg-config are put in the front of the
existing lists

Paul

Robert Osfield wrote:
> HI Paul,
>
> There is pkg-config support in CMake, but I don't know how flexible it is.
>
> BTW, what happens on your Gentoo system?  Does the half found XUL
> cause a build failure or does the gecko plugin simply not compile?
>   
> Robert.
>
> On Wed, Feb 4, 2009 at 6:22 PM, Paul Melis
>  wrote:
>   
>> I just noticed (on a Gentoo system) that not all of the parts of XUL are
>> found by CMake.
>> Some of the include directories and libraries are not among the ones in
>> FindXUL.cmake.
>> There does seem to be pkg-config support for it though:
>>
>> # nsEmbedAPI.h
>> pkg-config libxul-embedding --cflags
>> # jsapi.h
>> pkg-config xulrunner-js --cflags
>> # prtypes.h
>> pkg-config xulrunner-nspr --cflags
>>
>> Does CMake have support for parsing the output of pkg-config?
>>
>> 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
>
>   

# Locate gdal
# This module defines
# XUL_LIBRARIES
# XUL_FOUND, if false, do not try to link to gdal 
# XUL_INCLUDE_DIR, where to find the headers
#
# $XUL_DIR is an environment variable that would
# correspond to the ./configure --prefix=$XUL_DIR
#
# Created by Robert Osfield. 

FIND_PATH(XUL_INCLUDE_DIR nsEmbedAPI.h
$ENV{OSG_DIR}/include/xulrunner
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/xulrunner
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/xulrunner
$ENV{OSGDIR}/include
$ENV{OSGDIR}/xulrunner
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/xulrunner
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/xulrunner
/usr/local/include
/usr/include/xulrunner
/usr/include
/sw/include/xulrunner # Fink
/sw/include # Fink
/opt/local/include/xulrunner # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/xulrunner # Blastwave
/opt/csw/include # Blastwave
/opt/include/xulrunner
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include/xulrunner
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/xulrunner
/usr/freeware/include
)

FIND_PATH(NSPR_INCLUDE_DIR prtypes.h
$ENV{OSG_DIR}/include/nspr
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/nspr
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/nspr
$ENV{OSGDIR}/include
$ENV{OSGDIR}/nspr
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/nspr
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/nspr
/usr/local/include
/usr/include/nspr
/usr/include
/sw/include/nspr # Fink
/sw/include # Fink
/opt/local/include/nspr # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/nspr # Blastwave
/opt/csw/include # Blastwave
/opt/include/nspr
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include/nspr
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/nspr
/usr/freeware/include
)

FIND_PATH(MOZJS_INCLUDE_DIR jsapi.h
$ENV{OSG_DIR}/include/mozjs
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/mozjs
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/mozjs
$ENV{OSGDIR}/include
$ENV{OSGDIR}/mozjs
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/mozjs
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/mozjs
/usr/local/include
/usr/include/mozjs
/usr/include
/sw/include/mozjs # Fink
/sw/include # Fink
/opt/local/include/mozjs # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/mozjs # Blastwave
/opt/csw/include # Blastwave
/opt/include/mozjs
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include/mozjs
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/mozjs
/usr/freeware/include
)

FIND_PATH(XUL_DIR 
NAMES components/appshell.xpt
PATHS
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROO

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Sukender]

Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, 
all inclusive, CMake cache cleared, full release rebuild.
See the dashboard for details. Unfortunately, it has >50 warnings.

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

Le Wed, 04 Feb 2009 15:40:21 +0100, Robert Osfield  a 
écrit:

> Hi All,
>
> We're finally one the home straight now - OpenSceneGraph-2.8 branch
> has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created
> off this.
>
> News page:
> http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8
>
> Download page:
> http://www.openscenegraph.org/projects/osg/wiki/Downloads
>
> OpenSceneGraph-2.8.0-rc1 source code:
>
> source package:
> http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip
> svn tag: svn co
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1
> OpenSceneGraph
>
> OpenSceneGraph-2.8 branch:
>
> svn tag: svn co
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8
> OpenSceneGraph
>
>
> Updates (since 2.6.1) include: ¶
>
> * New osgVolume library for volume rendering, with support for:
>   o High quality GPU based Ray tracing
>   o Transfer functions
>   o Per pixel lighting
>   o Iso surface rendering
>   o Maximum Intensity rendering
>   o non power of two 3d texture and 3d texture compression
>   o DICOM loader for reading dicom medical data
> * New osgAnimation library for character and scene animation.
> * New plugin for reading Biovision hierarchical files (.BVH) to
> generate character motion animations.
> * New osgShadow support for Light Space Perspective Shadow Maps.
> * Three new scene graph widgets for placing traditional 2D
> capability into fully interactive 3D scenes:
>   o PDF widget support (based on libPoppler)
>   o VNC client widget support (based on libVNCServer)
>   o Internet browser client widget support (based on Gecko/UBrowser)
> * New plugins for loading Half-Life 2 maps and models.
> * New plugin for loaded exr, high dynamic range imagery
> * Improvements to DatabasePager tailored for low latency paging.
> * Improved runtime stats collection and on screen reporting.
> * Performance improvements through optimization of matrix operations.
> * Support for the OpenGL draw instanced extension.
> * Improvements to COLLADA support.
> * Build reporting using CDash
> * New packing support using CPack
> * A wide range of build and bug fixes
>
> Many many thanks to all those who've put in time on testing out 2.7.9
> and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for
> release snapshot we've ever done ;-)
>
> But still we can't rest if we want to make 2.8.0 the best we can... so
> please download/check out the OpenSceneGraph-2.8 branch or the
> 2.8.0-rc1 and do compile and runtime checks on as wide range of
> platforms as you have to hand.  I would also greatly value feedback on
> how you own applications are performing with 2.8, if there are issues
> please just report them on osg-users and we can together have a bash
> at resolve them.
>
> For uploading of packages I have requested ftp access to the server
> for uploading, I let you know of the details if we can get this set
> up.
>
> Have fun!
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Cory Riddell]

I built everything with Visual Studio 2005 on XP with no build problems. One
minor glitch that may be my fault- when I ran the built the INSTALL target,
it copied the executables to C:\Program Files\OpenSceneGraph rather than
C:\Program Files\OpenSceneGraph-2.8 (I specified this in CMake).

Cory

On Wed, Feb 4, 2009 at 12:50 PM, Jason Daly  wrote:

> Robert Osfield wrote:
>
>> But still we can't rest if we want to make 2.8.0 the best we can... so
>> please download/check out the OpenSceneGraph-2.8 branch or the
>> 2.8.0-rc1 and do compile and runtime checks on as wide range of
>> platforms as you have to hand.  I would also greatly value feedback on
>> how you own applications are performing with 2.8, if there are issues
>> please just report them on osg-users and we can together have a bash
>> at resolve them.
>>
>>
>
> Builds with zero warnings on Red Hat Enterprise 5.3, even with our tired
> old CMake 2.4.5  ;-)
>
> Only minor glitch with the build is that I have to pass -march=i686 in
> CXXFLAGS for OpenThreads to configure properly to use GCC_BUILTINS.  I think
> this was covered in another thread a few months back.  Even if I don't do
> this, it works fine running with mutexes.
>
>
> --"J"
>
>
> ___
> 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Robert Osfield]

Hi JS,

Thanks for the warning fixes, I've merged about 2/3rds of them, but
will record some of the other ones.   The server isn't accessible
right now so I'm not able to check in right now.  I'll have  bash
tomorrow morning.  These last warning fixes won't affect runtime at
all so the 2.8.0-rc1 as it stands right now should be good enough for
testing.

Robert.

On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay
 wrote:
> Hi Robert,
>
>> As I said on my other post, I don't seem to get any warnings (other than
>> "can't open build log for writing", which is weird but benign - the warnings
>> if any would still go to stdout and thus get reported in the CDash warnings
>> page for the build). I'll try another full rebuild and see for sure. Then if
>> I get any I'll see what needs to be done.
>
> OK, I've had a go at fixing the warnings. I've attached a zip containing the
> build output before the fixes for you to see, as well as the changed files.
>
> The PDB warnings (which come from the fact that a given 3rd party library
> was compiled with debug information split into a separate file instead of
> embedded into the library) we can just ignore. They only happen at link time
> for the given plugin. Same thing for the "default library MSVCRT
> conflicts..." warning, though that might indicate a bigger problem. The next
> time someone makes a 3rd party package, those things should be taken care
> of.
>
> Other than that, here are the warnings I fixed:
>
> ___
>
> osgUtil.lib and osglauncher example
>
> 4>C:\Tools\msvs8\VC\include\list(42) : warning C4510:
> 'std::_List_nod<_Ty,_Alloc>::_Node' : default constructor could not be
> generated
>
> (and other similar and related warnings)
>
> Simply adding an empty default constructor to the arc class in
> TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this
>
> You could see that std::list was not the problem, but the class used as a
> template argument, because lower in the warning message there was mention of
>
> 4>
> c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109)
> : see reference to class template instantiation 'std::list<_Ty>' being
> compiled
> 4>with
> 4>[
> 4>
> _Ty=triangle_stripper::common_structures::graph_array::arc
> 4>]
>
> which pointed to the type to which a default constructor needed to be added.
> It comes down to deciphering VS's messages... :-)
> ___
>
> osga plugin
>
> 198>..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(727) : warning C4512:
> 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be
> generated
> 198>..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(719) : see
> declaration of 'OSGA_Archive::WriteObjectFunctor'
>
> (and so on for the other Write*Functors)
>
> I didn't find any way to fix this other than locally suppressing it, since
> creating a default constructor would imply constructing a default
> osg::Object, which is abstract so I can't do that. So I suppressed it around
> those 4 classes.
> ___
>
> cfg plugin and osgviewerGLUT example
>
> You had tried suppressing warnings in these two cases, protected by
>
> #if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS)
>
> but you needed to include  before that, so that
> OSG_DISABLE_MSVC_WARNINGS was defined...
> ___
>
> osgviewerQT example
>
> 26>c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(97)
> : warning C4512: 'QtConcurrent::BlockSizeManager' : assignment operator
> could not be generated
> 26>
> c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(79)
> : see declaration of 'QtConcurrent::BlockSizeManager'
>
> Since this is in Qt's headers, I just suppressed this locally (for both Qt 4
> and Qt 3 - I'm using Qt 4 and I have no way of knowing if this appears for
> Qt 3).
> ___
>
> I'm doing a full rebuild now (and as you all know now thanks to the
> dashboard reports, this takes 20 minutes on my machine if nothing else is
> happening) so I'll tell you when this is done if any fixable warnings
> remain, but I think it should look good.
>
> Of course as we can see from osgviewerQT, there are perhaps warnings lurking
> in other examples/plugins which I don't compile... Others will have to pitch
> in for fixing those.
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   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 maili

Re: [osg-users] About OpenGL materials

[Paul Melis]

Jean-Sébastien Guay wrote:
> The reason I can't just specify the colors in the color array is that
> then, if I use scribe or outline effects (using osgFX::Effect), the
> wireframe overlay or outline takes on the vertex colors too instead of
> being white (or the color I specify). If there's a way to force the
> scribe to be white (i.e. not use the object's vertex colors) that
> would work too even though it's the reverse of what I'm asking...
The osgscribe example seems to include code that specifies the color of
the wireframe (but in the else branch of an #if 1 ...). Is that what
you're looking for?

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

Re: [osg-users] About OpenGL materials

[Tomlinson, Gordon]

No in straight OSG/OGL

No Lighting = No Material 

You probably could do this with in a shader but you would have to replicate the 
full fixed pipeline calculation of lighting,materials, textures , fogs etc ( 
which you have to do anyway  )


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien 
Guay
Sent: Wednesday, February 04, 2009 2:14 PM
To: OpenSceneGraph Users
Subject: [osg-users] About OpenGL materials

Hi all,

I have a question about OpenGL materials. From what I can see, if I disable 
GL_LIGHTING in the stateset of an object, then that object is rendered with the 
colors specified in its color array only, i.e. the material has no effect. Is 
there a way to change that?

The effect I want is that the object be unaffected by lighting but still has 
colors according to its material, i.e. even if no light is present in the 
scene, or if there is only a spotlight but it is not pointing toward the 
object, its color is defined by its material.

The reason I can't just specify the colors in the color array is that then, if 
I use scribe or outline effects (using osgFX::Effect), the wireframe overlay or 
outline takes on the vertex colors too instead of being white (or the color I 
specify). If there's a way to force the scribe to be white (i.e. not use the 
object's vertex colors) that would work too even though it's the reverse of 
what I'm asking...

Any suggestions would be appreciated. I've never quite understood the 
intricacies of how OpenGL handles vertex colors, materials, shading and even 
textures (when one takes precedence over the other, etc.) so I'd like the 
advice of someone who knows more than me in this respect.

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] About OpenGL materials

[Robert Osfield]

Hi JS,

The OSG is designed around separating geometry data (in Drawables)
from state data (in StateSets), the usage model you are suggesting
mixing this, and this would struggle in anything other than models
that don't have any colour arrays assigned to them, otherwise the
local geometry colour array would just override that you provide by
the StateSet.  Consider that the OSG by default display lists geometry
and you can see that the problem isn't one that you can fix easily.

However if you carefully manage your scene graph so that the subgraph
you are decorating contains no colour arrays then you could define a
custom StateAttribute that sets the vertex colour.

Robert.

On Wed, Feb 4, 2009 at 7:13 PM, Jean-Sébastien Guay
 wrote:
> Hi all,
>
> I have a question about OpenGL materials. From what I can see, if I disable
> GL_LIGHTING in the stateset of an object, then that object is rendered with
> the colors specified in its color array only, i.e. the material has no
> effect. Is there a way to change that?
>
> The effect I want is that the object be unaffected by lighting but still has
> colors according to its material, i.e. even if no light is present in the
> scene, or if there is only a spotlight but it is not pointing toward the
> object, its color is defined by its material.
>
> The reason I can't just specify the colors in the color array is that then,
> if I use scribe or outline effects (using osgFX::Effect), the wireframe
> overlay or outline takes on the vertex colors too instead of being white (or
> the color I specify). If there's a way to force the scribe to be white (i.e.
> not use the object's vertex colors) that would work too even though it's the
> reverse of what I'm asking...
>
> Any suggestions would be appreciated. I've never quite understood the
> intricacies of how OpenGL handles vertex colors, materials, shading and even
> textures (when one takes precedence over the other, etc.) so I'd like the
> advice of someone who knows more than me in this respect.
>
> Thanks,
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] About OpenGL materials

[Jean-Sébastien Guay]

Hi all,

I have a question about OpenGL materials. From what I can see, if I 
disable GL_LIGHTING in the stateset of an object, then that object is 
rendered with the colors specified in its color array only, i.e. the 
material has no effect. Is there a way to change that?


The effect I want is that the object be unaffected by lighting but still 
has colors according to its material, i.e. even if no light is present 
in the scene, or if there is only a spotlight but it is not pointing 
toward the object, its color is defined by its material.


The reason I can't just specify the colors in the color array is that 
then, if I use scribe or outline effects (using osgFX::Effect), the 
wireframe overlay or outline takes on the vertex colors too instead of 
being white (or the color I specify). If there's a way to force the 
scribe to be white (i.e. not use the object's vertex colors) that would 
work too even though it's the reverse of what I'm asking...


Any suggestions would be appreciated. I've never quite understood the 
intricacies of how OpenGL handles vertex colors, materials, shading and 
even textures (when one takes precedence over the other, etc.) so I'd 
like the advice of someone who knows more than me in this respect.


Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] 2.8: XUL not completely found

[Robert Osfield]

HI Paul,

There is pkg-config support in CMake, but I don't know how flexible it is.

BTW, what happens on your Gentoo system?  Does the half found XUL
cause a build failure or does the gecko plugin simply not compile?

Robert.

On Wed, Feb 4, 2009 at 6:22 PM, Paul Melis
 wrote:
> I just noticed (on a Gentoo system) that not all of the parts of XUL are
> found by CMake.
> Some of the include directories and libraries are not among the ones in
> FindXUL.cmake.
> There does seem to be pkg-config support for it though:
>
> # nsEmbedAPI.h
> pkg-config libxul-embedding --cflags
> # jsapi.h
> pkg-config xulrunner-js --cflags
> # prtypes.h
> pkg-config xulrunner-nspr --cflags
>
> Does CMake have support for parsing the output of pkg-config?
>
> 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] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Jason Daly]

Robert Osfield wrote:

But still we can't rest if we want to make 2.8.0 the best we can... so
please download/check out the OpenSceneGraph-2.8 branch or the
2.8.0-rc1 and do compile and runtime checks on as wide range of
platforms as you have to hand.  I would also greatly value feedback on
how you own applications are performing with 2.8, if there are issues
please just report them on osg-users and we can together have a bash
at resolve them.
  


Builds with zero warnings on Red Hat Enterprise 5.3, even with our tired 
old CMake 2.4.5  ;-)


Only minor glitch with the build is that I have to pass -march=i686 in 
CXXFLAGS for OpenThreads to configure properly to use GCC_BUILTINS.  I 
think this was covered in another thread a few months back.  Even if I 
don't do this, it works fine running with mutexes.



--"J"

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

[osg-users] 2.8: XUL not completely found

[Paul Melis]

I just noticed (on a Gentoo system) that not all of the parts of XUL are
found by CMake.
Some of the include directories and libraries are not among the ones in
FindXUL.cmake.
There does seem to be pkg-config support for it though:

# nsEmbedAPI.h
pkg-config libxul-embedding --cflags
# jsapi.h
pkg-config xulrunner-js --cflags
# prtypes.h
pkg-config xulrunner-nspr --cflags

Does CMake have support for parsing the output of pkg-config?

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

Re: [osg-users] Multiple GPU

[Ümit Uzun]

Hi Ufuk,

You can look at Distributed-OSG-Thesis.pdf in
http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/OSG_Tutorial_Ball.zipIt
would help you.

Kolay Gelsin :)
Saygilar.

2009/2/4 Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW <
kenneth.sew...@wpafb.af.mil>

> Just to offer an alternative setup... We have OSG running a system of 6
> screens representing a single view.  The solution we chose was to use a
> single 8800 GTX and two of the matrox triple-head-to-go devices.
> Nvidia's twinview lets us treat it as one big screen of resolution
> 3840x2048, which makes for a very simple setup in OSG.  By adding
> another card you could easily get the number of screens you require.
>
> - Ken.
>
> >   I have to do a simulation project which needs 8 screens. This
> > system likes a dome.
> >
> >   so i want to ask few questions about this:
> >
> >   1) i want to use multiple gpu's. So is there a limit on number
> of
> > gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can
> i
> > render 8 screen with viewer?
> >
> >   2) how can i set which gpu render which screen. is there an auto
> > management system in viewer? if i have screens which have resolutions
> > like 8x1280x1024 or 4x2560x1024 or any other combination of this,
> > should i do an extra thing for this?
> >
> >   3) do you think i will have a critical frame rate problem if i
> > render 8 screens.
> >
> >
> >   ___
> >   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
>



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

Re: [osg-users] Using cpack to create debian packages

[Mattias Helsing]

Hi Robert,

On 2/4/09, Robert Osfield  wrote:
> Hi All,
>
> Now that I've tagged 2.8.0-rc1 my focus has now moved on to helping
> out on the packaging front.  The packaging that I'd like to contribute
> is the debian packages, so I've started down this journey by enable
> cpack support in the OSG, then doing:
>
> cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D
> CPACK_PACKAGE_CONTACT="rob...@openscenegraph.com"

very cool. To bad I haven't had the time to dig out the debian
generator features yet. I will eventually get to improving these but
as I realized that I wouldn't make it to 2-8 and that we have a man on
making debian packages I dropped it for now. See

http://packages.qa.debian.org/o/openscenegraph.html

for status of the openscenegraph debs. It seems that he has requested
help to get packages delivered and that Alberto Luaces and some others
have agreed to help him.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392266

For ubuntu it the ubuntu-MOTU developers are responsible for the
openscenegreph package(s) so we might need to poke them.

>
> Which generates a OpenSceneGraph-2.8.0.deb, which is but... if I then
> do create a package libopenscenegraph-dev pacakge I also get an
> OpenSceneGraph-2.8.0.deb.
>
> Looking at the CPackConfig-libopenscenegraph.cmake I note the
> CPACK_PACKAGE_FILE_NAME is OpenSceneGraph-2.8.0 which goes a long way
> to explain why the name is what it is.  I have been able to override
> it using:
>
> cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D
> CPACK_PACKAGE_CONTACT="rob...@openscenegraph.com" -D
> CPACK_PACKAGE_FILE_NAME="libopenscenegraph-2.8.0.deb"

All this is due to the workaround I had to do to make the tar archives
look like we wanted them with a top folder OpenSceneGraph-2.8.0 and
all the different packages would sort themselves in under that. My
first submission had debian-like packages names. I (or someone) will
have to fix this before we can make proper debs. What you have already
done (-DCPACK_PACKAGE_NAME=...) is probably a good solution that one
could put in an add_custom_target.

>
> I don't yet have the right architecture info in the debian name, and
> no doubt other items aren't yet set which I'll need to add.  I found
> the following page on the CMake/CPack wiki:
>
>   http://www.vtk.org/Wiki/CMake:CPackPackageGenerators
>
> I do wonder whether there isn't some more we could be doing on the
> generation of the CPackConfig-* files such as setting the base name a
> bit more appropriately.  I'm rather new to cpack and debian packaging
> so I'm rather floundering around a bit clueless, but that's how we
> start learning is it not...  Feel free to point me in the right
> direction.

There are some other cmake vars that are/will be used to create the
control file that must be part of every deb package. I think the only
one that we don't have in the CPackConfig-xxx scripts is the
CPACK_DEBIAN_PACKAGE_DEPENDS
...which I have fiddled with but not enough to dare a submission.
Perhaps someone more exerienced with debian cuold fill this out
properly. I will need to get some information from a real package
maintainer to fix this.

>
> In particular I'm keen to QA the packages I create, is there such a
> tool for debian?

Can't help here I'm afraid. I see that this mail didn't help much at
all but telling you things you already know :-( So to try and help I
mailed some questions to the ubuntu-motu developers mailing list
asking how we can help getting osg-2.8 into ubuntu packages adn will
persue that. For debian perhaps Alberto Luaces or someone else can
fill us in on how the debian package is doing and if any further help
is needed.

cheers
Mattias

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

Re: [osg-users] "Works with 2.8" campaign :-)

[Jean-Sébastien Guay]

Hi Robert,


Does this sound like a good idea?


Definitely! :-)

(when did you turn into a marketing mogul?)

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] modelling geodes with children?

[Cory Riddell]

On Wed, Feb 4, 2009 at 10:48 AM, Paul Martz  wrote:

> If your HandlebarNode will be used in many apps to render handlebars (I
> don't know, maybe you intend to make a series of bicycle simulators), then
> yes, maybe it is best to encapsulate it in its own class. But if you are
> just using it as an example of some general hierarchical structure, then I
> doubt you want to create a new class for each unique piece of hierarchical
> geometry. Perhaps I'm not fully understanding your use case.
>

My use case was just a fabricated example (and a poor one at that). I'm
working on software for mechanical equipment and I was afraid using an
example from the actual domain would have been mired down in domain specific
terminology.

We don't have a particular arrangement of components that would be repeated,
but the equipment in general does have a natural hierarchical order to it (A
is connected to B is connected to C etc...). I confessed to Jean-Sebastien
that the source of this notion of all-in-one nodes was HOOPS - the first
scene graph tool I investigated. I'm starting to come around to the OSG
viewpoint though. Not that I dislike HOOPS- it's a fantastic piece of
software. It's just a little overkill for what we need.

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

[osg-users] "Works with 2.8" campaign :-)

[Robert Osfield]

Hi All,

I would like to see the OSG-2.8 branch tested out across as many
platforms and 3rd party applications as we can this week, as this will
be the best way for us to shake down the release and make sure it's
really ready to go 2.8.0 thank we can all rely upon for months to
come.

It occurred to me that we might be able to entice end users to come
forward and give a public thumbs up that OSG-2.8 works well with their
applications, it'll give some focus on the tasks of actually testing
OSG-2.8 against their own applications, and it might give the
community a bit of buzz knowing what applications/libraries that are
out their that are using the OSG.  Perhaps we could even coordinate
this into a wiki page with links to those projects, with screenshots
if you are up to it.  Does this sound like a good idea?

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

Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Serge Lages]

Hi Robert,

Built and tested with WinXP VS8 SP1, everything work as espected.
Thanks for all this good work !

On Wed, Feb 4, 2009 at 3:40 PM, Robert Osfield wrote:

> Hi All,
>
> We're finally one the home straight now - OpenSceneGraph-2.8 branch
> has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created
> off this.
>
> News page:
> http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8
>
> Download page:
> http://www.openscenegraph.org/projects/osg/wiki/Downloads
>
> OpenSceneGraph-2.8.0-rc1 source code:
>
>source package:
>
> http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip
>svn tag: svn co
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1
> OpenSceneGraph
>
> OpenSceneGraph-2.8 branch:
>
>svn tag: svn co
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8
> OpenSceneGraph
>
>
> Updates (since 2.6.1) include: ¶
>
>* New osgVolume library for volume rendering, with support for:
>  o High quality GPU based Ray tracing
>  o Transfer functions
>  o Per pixel lighting
>  o Iso surface rendering
>  o Maximum Intensity rendering
>  o non power of two 3d texture and 3d texture compression
>  o DICOM loader for reading dicom medical data
>* New osgAnimation library for character and scene animation.
>* New plugin for reading Biovision hierarchical files (.BVH) to
> generate character motion animations.
>* New osgShadow support for Light Space Perspective Shadow Maps.
>* Three new scene graph widgets for placing traditional 2D
> capability into fully interactive 3D scenes:
>  o PDF widget support (based on libPoppler)
>  o VNC client widget support (based on libVNCServer)
>  o Internet browser client widget support (based on Gecko/UBrowser)
>* New plugins for loading Half-Life 2 maps and models.
>* New plugin for loaded exr, high dynamic range imagery
>* Improvements to DatabasePager tailored for low latency paging.
>* Improved runtime stats collection and on screen reporting.
>* Performance improvements through optimization of matrix operations.
>* Support for the OpenGL draw instanced extension.
>* Improvements to COLLADA support.
>* Build reporting using CDash
>* New packing support using CPack
>* A wide range of build and bug fixes
>
> Many many thanks to all those who've put in time on testing out 2.7.9
> and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for
> release snapshot we've ever done ;-)
>
> But still we can't rest if we want to make 2.8.0 the best we can... so
> please download/check out the OpenSceneGraph-2.8 branch or the
> 2.8.0-rc1 and do compile and runtime checks on as wide range of
> platforms as you have to hand.  I would also greatly value feedback on
> how you own applications are performing with 2.8, if there are issues
> please just report them on osg-users and we can together have a bash
> at resolve them.
>
> For uploading of packages I have requested ftp access to the server
> for uploading, I let you know of the details if we can get this set
> up.
>
> Have fun!
> Robert.
> ___
> 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] modelling geodes with children?

[Paul Martz]

Are you suggesting that my root would be a group node and under that would
be all the leaf nodes? I don't like that idea because it loses the
hierarchy: streamer is attached to grip, grip is attached to handlebar. If I
delete the grip node, the streamer should go away as well.

Well, I didn't really mean to forego the hierarchy and have a flat scene
graph. If you really need the functionality of having the streamers
disappear when you remove the grip, then by all means you should use
hierarchy to achieve that. 
 
I could've implemented my HandNode using existing core functionality, but my
client specifically wanted a Hand Node that they could reuse in many
applications specifically for rendering a hand. If your HandlebarNode will
be used in many apps to render handlebars (I don't know, maybe you intend to
make a series of bicycle simulators), then yes, maybe it is best to
encapsulate it in its own class. But if you are just using it as an example
of some general hierarchical structure, then I doubt you want to create a
new class for each unique piece of hierarchical geometry. Perhaps I'm not
fully understanding your use case.
   -Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Using cpack to create debian packages

[Robert Osfield]

Hi All,

Now that I've tagged 2.8.0-rc1 my focus has now moved on to helping
out on the packaging front.  The packaging that I'd like to contribute
is the debian packages, so I've started down this journey by enable
cpack support in the OSG, then doing:

cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D
CPACK_PACKAGE_CONTACT="rob...@openscenegraph.com"

Which generates a OpenSceneGraph-2.8.0.deb, which is but... if I then
do create a package libopenscenegraph-dev pacakge I also get an
OpenSceneGraph-2.8.0.deb.

Looking at the CPackConfig-libopenscenegraph.cmake I note the
CPACK_PACKAGE_FILE_NAME is OpenSceneGraph-2.8.0 which goes a long way
to explain why the name is what it is.  I have been able to override
it using:

cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D
CPACK_PACKAGE_CONTACT="rob...@openscenegraph.com" -D
CPACK_PACKAGE_FILE_NAME="libopenscenegraph-2.8.0.deb"

I don't yet have the right architecture info in the debian name, and
no doubt other items aren't yet set which I'll need to add.  I found
the following page on the CMake/CPack wiki:

  http://www.vtk.org/Wiki/CMake:CPackPackageGenerators

I do wonder whether there isn't some more we could be doing on the
generation of the CPackConfig-* files such as setting the base name a
bit more appropriately.  I'm rather new to cpack and debian packaging
so I'm rather floundering around a bit clueless, but that's how we
start learning is it not...  Feel free to point me in the right
direction.

In particular I'm keen to QA the packages I create, is there such a
tool for debian?

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

Re: [osg-users] Multiple GPU

[Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW]

Just to offer an alternative setup... We have OSG running a system of 6
screens representing a single view.  The solution we chose was to use a
single 8800 GTX and two of the matrox triple-head-to-go devices.
Nvidia's twinview lets us treat it as one big screen of resolution
3840x2048, which makes for a very simple setup in OSG.  By adding
another card you could easily get the number of screens you require.

- Ken.

>   I have to do a simulation project which needs 8 screens. This
> system likes a dome.
> 
>   so i want to ask few questions about this:
> 
>   1) i want to use multiple gpu's. So is there a limit on number
of
> gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can
i
> render 8 screen with viewer?
> 
>   2) how can i set which gpu render which screen. is there an auto
> management system in viewer? if i have screens which have resolutions
> like 8x1280x1024 or 4x2560x1024 or any other combination of this,
> should i do an extra thing for this?
> 
>   3) do you think i will have a critical frame rate problem if i
> render 8 screens.
> 
> 
>   ___
>   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] Multiple GPU

[yann le paih]

Hi,

Recent post of Stefan Eilemann on "Equalizer blog" talk about Openscenegraph
and Equalizer :
 http://pogl.wordpress.com/2009/01/24/openscenegraph-and-equalizer/

Maybe, you could use the subversion of Equalizer and Openscengraph 2.8

Yann,



On Wed, Feb 4, 2009 at 4:25 PM, Adrian Egli OpenSceneGraph (3D) <
3dh...@gmail.com> wrote:

> Hi UFUK ?
>
> it would be greate to get see working osg with such high-end technology.
> may you should use equalizer and openscenegraph doing this.
>
> adrian
>
> 2009/2/4 ufuk gun 
>
>> Hi,
>> I have to do a simulation project which needs 8 screens. This system likes
>> a dome.
>>
>> so i want to ask few questions about this:
>>
>> 1) i want to use multiple gpu's. So is there a limit on number of gpu's on
>> a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8
>> screen with viewer?
>>
>> 2) how can i set which gpu render which screen. is there an auto
>> management system in viewer? if i have screens which have resolutions like
>> 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an
>> extra thing for this?
>>
>> 3) do you think i will have a critical frame rate problem if i render 8
>> screens.
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> 
> Adrian Egli
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Yann Le Paih
Keraudrono
56150 BAUD
Portable: +33(0)610524356
lepaih.y...@gmail.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Multiple GPU

[Robert Osfield]

Hi Ufuk? Gun? (Could you please sign with your first name so we can
adddress you correctly)

On Wed, Feb 4, 2009 at 2:54 PM, ufuk gun  wrote:
> Hi,
> I have to do a simulation project which needs 8 screens. This system likes a
> dome.
>
> so i want to ask few questions about this:
>
> 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a
> pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen
> with viewer?

Yes, osgViewer support novel camera/display combinations, including
support for multi-threading.  There is a video on youtube of
FlightGear running on an 8 screen powerwall all driven from a single
PC.  I'm afriad I don't have the refernece off hand.

I've personally driven four outputs from a single PC using two cards.
Scaling up much higher will hit PC hardware/driver bottlenecks.

If you are doing a dome, then could also do the distortion correction
using the OSG - see the osgViewer::setUpViewFor3DSphericalDisplay(),
this uses 6 RTT cameras rendering to a cube map, and a single
Camera/subgraph that does the distortion correction.  This setup only
generates a single output for a fish eye lens, so not an exact match
for your requirements but it might give up an idea of how to set up
the various slave cameras to do combinations of distortion correction.

> 2) how can i set which gpu render which screen. is there an auto management
> system in viewer? if i have screens which have resolutions like 8x1280x1024
> or 4x2560x1024 or any other combination of this, should i do an extra thing
> for this?

You just assign the screen number to the GraphicsContext::Traits when
setting up the various GraphicsContexts. See the osgcamera example for
an example of use Traits to describe your window setup.

FYI, Windows is less well suited for this type of multi-screen output,
as the drivers try to a bit bit too clever for their own good,
duplicating OpenGL calls across contexts.  Unices (including Linux)
that use X11 work great on complex multi-screen setups as you get
exactly what you ask for in terms of screen to GPU mapping.

> 3) do you think i will have a critical frame rate problem if i render 8
> screens.

That all depends upon your scene, and your hardware, and your
frame-rate needs.  It's doable but.. to get the performance you might
need to use a cluster rather than a single machine.

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

Re: [osg-users] Spam: Re: MSVC v9

[Tanguy Fautre]

Hi J-S,

The bug is apparently triggered by a very specific set of conditions. Most 
common programming patterns will actually result in the compiler generating the 
correct code. If you search the thread, you'll find more detailed explanations 
as well as an example program. 

I do not expect many people to be affected by it. For all I know, it's been 
lurking around for years.

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien 
Guay
Sent: Wednesday 04 February 2009 15:21
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9

Hi Tanguy,

I wonder, why have I not seen this problem with my OSG builds? Is it 
that the default optimization options are lower than what generates this 
bug? (sorry I've been speed-reading this thread and may have missed 
mention of this)

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Multiple GPU

[Adrian Egli OpenSceneGraph (3D)]

Hi UFUK ?

it would be greate to get see working osg with such high-end technology. may
you should use equalizer and openscenegraph doing this.

adrian

2009/2/4 ufuk gun 

> Hi,
> I have to do a simulation project which needs 8 screens. This system likes
> a dome.
>
> so i want to ask few questions about this:
>
> 1) i want to use multiple gpu's. So is there a limit on number of gpu's on
> a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8
> screen with viewer?
>
> 2) how can i set which gpu render which screen. is there an auto management
> system in viewer? if i have screens which have resolutions like 8x1280x1024
> or 4x2560x1024 or any other combination of this, should i do an extra thing
> for this?
>
> 3) do you think i will have a critical frame rate problem if i render 8
> screens.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 

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

Re: [osg-users] Getting Started with OpenSceneGraph on Ubuntu

[Trịnh Thành Trung GMail]

Ok, thanks for your suggestion.

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

Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Jean-Sébastien Guay]

Hi Robert,


I've tried really hard to fix all these Windows warnings, while most
seem now fixed/workaround/suppressed some have resisted my attempts to
remotely fix them, we me doing several unsuccessful attempts at this
last persistent warnings.


As I said on my other post, I don't seem to get any warnings (other than 
"can't open build log for writing", which is weird but benign - the 
warnings if any would still go to stdout and thus get reported in the 
CDash warnings page for the build). I'll try another full rebuild and 
see for sure. Then if I get any I'll see what needs to be done.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] MSVC v9

[Jean-Sébastien Guay]

Hi Tanguy,

I wonder, why have I not seen this problem with my OSG builds? Is it 
that the default optimization options are lower than what generates this 
bug? (sorry I've been speed-reading this thread and may have missed 
mention of this)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Jean-Sébastien Guay]

Hi Robert,


Yes, move across to making the builds from the 2.8 banch till 2.8.0 is
out.  


OK, I've disabled the nightly build of the branch for now.


Even after 2.8.0 is out, there is some value in having periodic
builds of the 2.8 branch as there may well be a 2.8.1+ later released,
although we could probably just make a request for new tests of the
2.8 if we actually need to make a 2.8.1+


We could perhaps have the same thing as for 2.6 - a Nightly-2.8 target, 
so that the build would end up in a different category and not overwrite 
the build of the trunk on the dashboard page?



I've started a build of the 2.8 branch, since it's the first it will be a
complete build and the results should be there in about 20 minutes.


Which is now done (20.2 minutes), and it seems that the only warnings 
were "could not open build log for writing"... Good job on the warnings 
fixes.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Sukender]

Hi Robert,

I'm terribly sorry, but I don't have the time right now. I just hope someone 
else will do it.
PS: I launched an experimental build. I'll tell you about the results.

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


Le Wed, 04 Feb 2009 15:57:45 +0100, Robert Osfield  a 
écrit:

> Hi Window's users,
>
> I've tried really hard to fix all these Windows warnings, while most
> seem now fixed/workaround/suppressed some have resisted my attempts to
> remotely fix them, we me doing several unsuccessful attempts at this
> last persistent warnings.  A fundamental problem is that I can't make
> a change and see whether the problem is fixed or not, this makes it
> really inefficient...
>
> So could a windows hack take over the attempt at fixing these
> warnings.  Suppressing these warnings is fair game at this stage,
> especially if simple code changes aren't possible, suppressing a
> warning for a single .cpp is also note such a bad thing, especially if
> you use the convention set up in the include/osg/Export that allows
> you to switch off the disabling of the MSVC warnings.   The
> src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't
> seem to work... if the latest build results are correct).
>
> #if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS)
> // disable '=' : conversion from 'int' to 'char', possible loss of
> data style warnings
> #pragma warning( disable : 4244)
> #endif
>
> Just send me the code changes that resolve these final warnings.
>
> Thanks,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] MSVC v9

[Tanguy Fautre]

Hi Robert,

I agree such changes would be too risky to be done for the current
release. But I don't think a compiler flag change would help much at
this point (especially that the bug was reported on this mailing list as
part of the user code, not OSG code).

Neil has expressed that he is willing to implement those changes
himself, which would be introduced post-2.8.0 obviously.


Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday 04 February 2009 14:48
To: OpenSceneGraph Users
Subject: Re: [osg-users] MSVC v9

HI Tanguy,

OK, since the changes are intrusive and widespread there certainly are
candidates for inclusion into 2.8.0, it's just too much of risk.

Changing the compile options should be less intrusive so I'd suggest
looking into adding this option to the VS compile options in
OpenSceneGraph/CMakeLists.txt.  One could make these extra build
options, optionally so that you can toggle them on/off from with
ccmake/CMakeSetup.

Robert.

On Wed, Feb 4, 2009 at 2:37 PM, Tanguy Fautre
 wrote:
> Hi Robert,
>
> It's not a small set of changes. It's actually quite tedious (but not
complex to do). Unfortunately, we cannot be sure it avoids the invalid
code generation bug in all cases.
>
>
> Basically, changing the operator (in this case, it's operator -) from:
>
>
>/** Binary vector subtract. */
>inline const Vec3f operator - (const Vec3f& rhs) const
>{
>return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1],
_v[2]-rhs._v[2]);
>}
>
>/** Unary vector subtract. */
>inline Vec3f& operator -= (const Vec3f& rhs)
>{
>_v[0]-=rhs._v[0];
>_v[1]-=rhs._v[1];
>_v[2]-=rhs._v[2];
>return *this;
>}
>
>
> To:
>
>inline Vec3f & operator -= (const Vec3f& rhs)
>{
>_v[0] -= rhs._v[0];
>_v[1] -= rhs._v[1];
>_v[2] -= rhs._v[2];
>return *this;
>}
>
>inline friend Vec3f operator - (const Vec3f& lhs, const Vec3f& rhs)
>{
>return Vec3f(lhs) -= rhs;
>}
>
>
> Seems to work around the problem with VS2005 and VS2008 without
requiring changes in the user code. Also, someone's pointed out the
latter is more correct in some cases (e.g. argument dependent lookup,
see below).
>
> But changing all the operators of classes like Vec3f, Vec3d (and I
suppose others such as Matrix classes) would be quite tedious. I guess
it really depends on how many people are really by this problem.
>
> One a broader note, I've noticed Boost has a very nice library for
dealing with this
(http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm). Too
bad OSG probably cannot use it because of the dependencies it would
introduce. But it's still worth a read, as they explain several issues
that may not be obvious at first sight.
>
>
> Cheers,
>
> Tanguy
>
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
> Sent: Wednesday 04 February 2009 12:40
> To: OpenSceneGraph Users
> Subject: Spam: Re: [osg-users] MSVC v9
>
> Hi Tanguy,
>
> On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
>  wrote:
>> Robert, do you thing the problem may be serious enough to possibly
motivate
>> a code change for all operators of Vec3f and co as a workaround?
>
> We could change code, it would all depend on how intrusive the changes
> are, without code changes in front of me I can't make this judgement
> call.  Could you send me a modified Vec* files so I could do a review?
>
> The other approach is to change the compile flags of the OSG to avoid
> this bug.  This wouldn't help 3rd party apps though.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Robert Osfield]

Hi Window's users,

I've tried really hard to fix all these Windows warnings, while most
seem now fixed/workaround/suppressed some have resisted my attempts to
remotely fix them, we me doing several unsuccessful attempts at this
last persistent warnings.  A fundamental problem is that I can't make
a change and see whether the problem is fixed or not, this makes it
really inefficient...

So could a windows hack take over the attempt at fixing these
warnings.  Suppressing these warnings is fair game at this stage,
especially if simple code changes aren't possible, suppressing a
warning for a single .cpp is also note such a bad thing, especially if
you use the convention set up in the include/osg/Export that allows
you to switch off the disabling of the MSVC warnings.   The
src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't
seem to work... if the latest build results are correct).

#if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS)
// disable '=' : conversion from 'int' to 'char', possible loss of
data style warnings
#pragma warning( disable : 4244)
#endif

Just send me the code changes that resolve these final warnings.

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

[osg-users] Multiple GPU

[ufuk gun]

Hi,
I have to do a simulation project which needs 8 screens. This system likes a
dome.

so i want to ask few questions about this:

1) i want to use multiple gpu's. So is there a limit on number of gpu's on a
pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen
with viewer?

2) how can i set which gpu render which screen. is there an auto management
system in viewer? if i have screens which have resolutions like 8x1280x1024
or 4x2560x1024 or any other combination of this, should i do an extra thing
for this?

3) do you think i will have a critical frame rate problem if i render 8
screens.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MSVC v9

[Robert Osfield]

HI Tanguy,

OK, since the changes are intrusive and widespread there certainly are
candidates for inclusion into 2.8.0, it's just too much of risk.

Changing the compile options should be less intrusive so I'd suggest
looking into adding this option to the VS compile options in
OpenSceneGraph/CMakeLists.txt.  One could make these extra build
options, optionally so that you can toggle them on/off from with
ccmake/CMakeSetup.

Robert.

On Wed, Feb 4, 2009 at 2:37 PM, Tanguy Fautre
 wrote:
> Hi Robert,
>
> It's not a small set of changes. It's actually quite tedious (but not complex 
> to do). Unfortunately, we cannot be sure it avoids the invalid code 
> generation bug in all cases.
>
>
> Basically, changing the operator (in this case, it's operator -) from:
>
>
>/** Binary vector subtract. */
>inline const Vec3f operator - (const Vec3f& rhs) const
>{
>return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1], _v[2]-rhs._v[2]);
>}
>
>/** Unary vector subtract. */
>inline Vec3f& operator -= (const Vec3f& rhs)
>{
>_v[0]-=rhs._v[0];
>_v[1]-=rhs._v[1];
>_v[2]-=rhs._v[2];
>return *this;
>}
>
>
> To:
>
>inline Vec3f & operator -= (const Vec3f& rhs)
>{
>_v[0] -= rhs._v[0];
>_v[1] -= rhs._v[1];
>_v[2] -= rhs._v[2];
>return *this;
>}
>
>inline friend Vec3f operator - (const Vec3f& lhs, const Vec3f& rhs)
>{
>return Vec3f(lhs) -= rhs;
>}
>
>
> Seems to work around the problem with VS2005 and VS2008 without requiring 
> changes in the user code. Also, someone's pointed out the latter is more 
> correct in some cases (e.g. argument dependent lookup, see below).
>
> But changing all the operators of classes like Vec3f, Vec3d (and I suppose 
> others such as Matrix classes) would be quite tedious. I guess it really 
> depends on how many people are really by this problem.
>
> One a broader note, I've noticed Boost has a very nice library for dealing 
> with this (http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm). 
> Too bad OSG probably cannot use it because of the dependencies it would 
> introduce. But it's still worth a read, as they explain several issues that 
> may not be obvious at first sight.
>
>
> Cheers,
>
> Tanguy
>
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org 
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert 
> Osfield
> Sent: Wednesday 04 February 2009 12:40
> To: OpenSceneGraph Users
> Subject: Spam: Re: [osg-users] MSVC v9
>
> Hi Tanguy,
>
> On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
>  wrote:
>> Robert, do you thing the problem may be serious enough to possibly motivate
>> a code change for all operators of Vec3f and co as a workaround?
>
> We could change code, it would all depend on how intrusive the changes
> are, without code changes in front of me I can't make this judgement
> call.  Could you send me a modified Vec* files so I could do a review?
>
> The other approach is to change the compile flags of the OSG to avoid
> this bug.  This wouldn't help 3rd party apps though.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Robert Osfield]

Hi JS,

On Wed, Feb 4, 2009 at 2:32 PM, Jean-Sébastien Guay
 wrote:
> Quick question about this: Since the Nightly build is still called "Nightly"
> in the 2.8 branch, it will replace any result of a nightly build of the
> trunk right? So I don't have to schedule a nightly build of both, just the
> 2.8 branch, until 2.8 is out. Am I right?

Yes, move across to making the builds from the 2.8 banch till 2.8.0 is
out.  Even after 2.8.0 is out, there is some value in having periodic
builds of the 2.8 branch as there may well be a 2.8.1+ later released,
although we could probably just make a request for new tests of the
2.8 if we actually need to make a 2.8.1+

> I've started a build of the 2.8 branch, since it's the first it will be a
> complete build and the results should be there in about 20 minutes.

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

[osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test

[Robert Osfield]

Hi All,

We're finally one the home straight now - OpenSceneGraph-2.8 branch
has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created
off this.

News page:
http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8

Download page:
http://www.openscenegraph.org/projects/osg/wiki/Downloads

OpenSceneGraph-2.8.0-rc1 source code:

source package:
http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip
svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1
OpenSceneGraph

OpenSceneGraph-2.8 branch:

svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8
OpenSceneGraph


Updates (since 2.6.1) include: ¶

* New osgVolume library for volume rendering, with support for:
  o High quality GPU based Ray tracing
  o Transfer functions
  o Per pixel lighting
  o Iso surface rendering
  o Maximum Intensity rendering
  o non power of two 3d texture and 3d texture compression
  o DICOM loader for reading dicom medical data
* New osgAnimation library for character and scene animation.
* New plugin for reading Biovision hierarchical files (.BVH) to
generate character motion animations.
* New osgShadow support for Light Space Perspective Shadow Maps.
* Three new scene graph widgets for placing traditional 2D
capability into fully interactive 3D scenes:
  o PDF widget support (based on libPoppler)
  o VNC client widget support (based on libVNCServer)
  o Internet browser client widget support (based on Gecko/UBrowser)
* New plugins for loading Half-Life 2 maps and models.
* New plugin for loaded exr, high dynamic range imagery
* Improvements to DatabasePager tailored for low latency paging.
* Improved runtime stats collection and on screen reporting.
* Performance improvements through optimization of matrix operations.
* Support for the OpenGL draw instanced extension.
* Improvements to COLLADA support.
* Build reporting using CDash
* New packing support using CPack
* A wide range of build and bug fixes

Many many thanks to all those who've put in time on testing out 2.7.9
and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for
release snapshot we've ever done ;-)

But still we can't rest if we want to make 2.8.0 the best we can... so
please download/check out the OpenSceneGraph-2.8 branch or the
2.8.0-rc1 and do compile and runtime checks on as wide range of
platforms as you have to hand.  I would also greatly value feedback on
how you own applications are performing with 2.8, if there are issues
please just report them on osg-users and we can together have a bash
at resolve them.

For uploading of packages I have requested ftp access to the server
for uploading, I let you know of the details if we can get this set
up.

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

Re: [osg-users] MSVC v9

[Tanguy Fautre]

Hi Robert,

It's not a small set of changes. It's actually quite tedious (but not complex 
to do). Unfortunately, we cannot be sure it avoids the invalid code generation 
bug in all cases.


Basically, changing the operator (in this case, it's operator -) from:


/** Binary vector subtract. */
inline const Vec3f operator - (const Vec3f& rhs) const
{
return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1], _v[2]-rhs._v[2]);
}

/** Unary vector subtract. */
inline Vec3f& operator -= (const Vec3f& rhs)
{
_v[0]-=rhs._v[0];
_v[1]-=rhs._v[1];
_v[2]-=rhs._v[2];
return *this;
}


To:

inline Vec3f & operator -= (const Vec3f& rhs)
{
_v[0] -= rhs._v[0];
_v[1] -= rhs._v[1];
_v[2] -= rhs._v[2];
return *this;
}

inline friend Vec3f operator - (const Vec3f& lhs, const Vec3f& rhs)
{
return Vec3f(lhs) -= rhs;
}


Seems to work around the problem with VS2005 and VS2008 without requiring 
changes in the user code. Also, someone's pointed out the latter is more 
correct in some cases (e.g. argument dependent lookup, see below).

But changing all the operators of classes like Vec3f, Vec3d (and I suppose 
others such as Matrix classes) would be quite tedious. I guess it really 
depends on how many people are really by this problem.

One a broader note, I've noticed Boost has a very nice library for dealing with 
this (http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm). Too bad 
OSG probably cannot use it because of the dependencies it would introduce. But 
it's still worth a read, as they explain several issues that may not be obvious 
at first sight.


Cheers,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday 04 February 2009 12:40
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9

Hi Tanguy,

On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
 wrote:
> Robert, do you thing the problem may be serious enough to possibly motivate
> a code change for all operators of Vec3f and co as a workaround?

We could change code, it would all depend on how intrusive the changes
are, without code changes in front of me I can't make this judgement
call.  Could you send me a modified Vec* files so I could do a review?

The other approach is to change the compile flags of the OSG to avoid
this bug.  This wouldn't help 3rd party apps though.

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

Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Morné Pistorius]

Hi Robert,

Just built a clean checkout of the 2.8 branch on Windows Vista, Visual
Studio 8 SP1.  Apart from the std::list warning that we can't do much
about, there were 4 left in OSGA_Archive.cpp (below).  I tested the
build in our app and everything worked as expected.

Cheers,
Morne

warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment
operator could not be
generated   
c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp   
727
warning C4512: 'OSGA_Archive::WriteImageFunctor' : assignment operator
could not be generated  
c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp   
737
warning C4512: 'OSGA_Archive::WriteHeightFieldFunctor' : assignment
operator could not be
generated   
c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp   
747
warning C4512: 'OSGA_Archive::WriteNodeFunctor' : assignment operator
could not be generated  
c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp   
757


On Wed, Feb 4, 2009 at 1:02 PM, Robert Osfield  wrote:
> Hi All,
>
> I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is:
>
>   
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/
>
> If those don't CDash builds (as well as everyone else) move across to
> using this branch as the base for testing the OSG-2.8 release series.
> I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh
> build on the 2.8 branch and see how I get on.  It'd be useful to have
> feedback from others as well on how the OSG-2.8 is fairing.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in 2.7.9 with collada

[Patrice Bouvier]

Hi Robert & Roger,

I've tried with another collada file with texture, and it works, so
it's probably a problem with mine. Unfortunately i can't send a sample
of this file because of property rights, so i will continue to look
around it.

Thanks anyway for your answers.
Patrice

Roger James a écrit :

  
  
Patrice Bouvier wrote:
  Hi
All, 

I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9
version. Unfortunately i've a problem with a collada scene, no textures
are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0
version. 

Could someone give me a fix for that problem ? 

Thanks 
Patrice 
  
Without any information a fix will be difficult :-) Can you at least
supply a copy of your osg notify log. If your model is a large one it
would be good if you could cut it down to a single geometry node which
fails to show a texture and post that. Collada files are xml and quite
easy to hand edit.
  
Roger
  

___
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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Jean-Sébastien Guay]

Hi Robert,


If those don't CDash builds (as well as everyone else) move across to
using this branch as the base for testing the OSG-2.8 release series.


Quick question about this: Since the Nightly build is still called 
"Nightly" in the 2.8 branch, it will replace any result of a nightly 
build of the trunk right? So I don't have to schedule a nightly build of 
both, just the 2.8 branch, until 2.8 is out. Am I right?


BTW, I've got a build from last night on the CDash dashboard (WHITESTAR) 
and it looks like it built fine, though with 13 warnings from compiling 
the 29 changed files.


I've started a build of the 2.8 branch, since it's the first it will be 
a complete build and the results should be there in about 20 minutes.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Mattias Helsing]

Hi Robert,

I checked out a fresh 2.8 source tree (rev 9648) and it built fine on
vs 2005 xp! But I still see a few warnings and they are attached.

cheers
Mattias

On 2/4/09, Robert Osfield  wrote:
> Hi All,
>
> I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is:
>
>
> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/
>
> If those don't CDash builds (as well as everyone else) move across to
> using this branch as the base for testing the OSG-2.8 release series.
> I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh
> build on the 2.8 branch and see how I get on.  It'd be useful to have
> feedback from others as well on how the OSG-2.8 is fairing.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_nod<_Ty,_Alloc>::_Node' : default constructor could not be generated
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see 
declaration of 'std::_List_nod<_Ty,_Alloc>::_Node'
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : 
see reference to class template instantiation 
'std::_List_nod<_Ty,_Alloc>::_Node' being compiled
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(110) : 
while compiling class template member function 
'std::_List_nod<_Ty,_Alloc>::_Node 
*&std::list<_Ty>::_Nextnode(std::_List_nod<_Ty,_Alloc>::_Node *)'
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>c:\public\openscenegraph-2.8\src\osgutil\TriStrip_graph_array.h(109) 
: see reference to class template instantiation 'std::list<_Ty>' being compiled
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc
15>]
15>
c:\public\openscenegraph-2.8\src\osgutil\TriStrip_tri_stripper.h(257) : see 
reference to class template instantiation 
'triangle_stripper::common_structures::graph_array' being 
compiled
15>with
15>[
15>nodetype=triangle_stripper::triangle,
15>arctype=char
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning 
C4610: struct 'std::_List_nod<_Ty,_Alloc>::_Node' can never be instantiated - 
user defined constructor required
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
16>Registry.cpp
15>TriStrip_tri_stripper.cpp
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning 
C4510: 'std::_List_nod<_Ty,_Alloc>::_Node' : default constructor could not be 
generated
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see 
declaration of 'std::_List_nod<_Ty,_Alloc>::_Node'
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : 
see reference to class template instantiation 
'std::_List_nod<_Ty,_Alloc>::_Node' being compiled
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>C:\Program Files\Microsoft Visual Studio 8\VC\include\list(110) : 
while compiling class template member function 
'std::_List_nod<_Ty,_Alloc>::_Node 
*&std::list<_Ty>::_Nextnode(std::_List_nod<_Ty,_Alloc>::_Node *)'
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc,
15>
_Alloc=std::allocator::arc>
15>]
15>c:\public\openscenegraph-2.8\src\osgutil\TriStrip_graph_array.h(109) 
: see reference to class template instantiation 'std::list<_Ty>' being compiled
15>with
15>[
15>
_Ty=triangle_stripper::common_structures::graph_array::arc
15>]
15>
c:\public\openscenegraph-2.8\src\osgutil\TriStrip_tri_stripper.h(257) : see 
reference to class template instantiation 
'triangle_stripper::common_structures::graph_array' being 
co

Re: [osg-users] SVN (2.8) bugs in osgviewerQt

[Jean-Sébastien Guay]

Hi Morné,


Thanks again for your help!!  You saved me a lot of debugging headache :)


You're welcome, we have to stick together when we're doing similar 
projects so we all move forward much faster!



PS. Do you want me to submit a modified osgviewerQt example with these
fixes/workarounds?


It would be nice to get others' comments on these changes, so I would 
say yes. Plus it would allow us to test these same features in the 
future when other things change.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Different behavior between Linux and Windows when using OpenThreads::Mutex

[J.P. Delport]

Hi,

see also this thread here:

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

I've run into this as well.

Also have a look at OpenThreads/Barrier.

jp

Laurence Muller wrote:

Hi,

It seems that there is a difference in behavior when using the 
OpenThreads::Mutex class in Linux and Windows.


For our (crossplatform) application it is required to synchronize data 
between two different threads. In order to prevent a race condition, we 
used the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
To test the behavior of the mutex lock, I created a small application 
(attached below).


Our Linux machine produces the following output:
[laure...@fedora mutex_test]$ ./main
test 1 (trylock): ok
-- application blocked --

Using the same application under windows (compiled with mingw):
main.exe
test 1 (trylock): ok
test 2 (lock): ok
test 3 (lock again): ok
test 4 (unlock): ok
-- application finished --

The Linux version shows the correct behavior, the Windows version seems 
to ignore the lock calls and does not block at all.


Questions:
1. Are additional settings required to use the OpenThreads mutex lock 
under windows?
2. What alternatives are available for the OpenThreads mutex lock? 
(Manually implement calls using pthread?)


Kind Regards,
- Laurence

-
// main.cpp
// g++ main.cpp -o main -I /home/userx/osg/include -L 
/home/userx/osg/lib -lOpenThreads


#include 
#include 
#include 
using namespace std;

OpenThreads::Mutex *mt_sync;

int main(int argc, char **argv)
{
   mt_sync = new OpenThreads::Mutex();

   printf("test 1 (trylock): ");
   if(mt_sync->trylock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 2 (lock): ");
   if(mt_sync->lock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 3 (lock again): ");
   if(mt_sync->lock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 4 (unlock): ");
   if(mt_sync->unlock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   delete mt_sync;

   return 0;
}


___
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] modelling geodes with children?

[Jean-Sébastien Guay]

Hi Cory,

In my mind, I'm equating the "thing" with the thing's geometry. And so 
if something is attached to the thing, I want the data structure to 
mimic that. 


I can understand where you're coming from, but I think keeping things 
separate (at least conceptually) makes them more flexible. It's a matter 
of opinion, of course, as most design decisions are. :-)


Think of the Transform node as being just a change in coordinate 
systems. I tend to picture the graph upside down, or at least read it 
going from the leaves to the root (instead of the opposite). The 
geometry itself is modeled in its local coordinate system (that's just 
the Geode), then it's transformed to place it where it should be 
relative to some other thing (that's just the Transform). And so on.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Different behavior between Linux and Windows when using OpenThreads::Mutex

[Robert Osfield]

Hi Luarance,

I believe the difference is down to pthreads not allowing two locks on
the same mutex from a single thread, while the windows equivilant
allows this - this means the standard Windows mutex is re-entrant,
whereas the pthread one isn't.   To get the same behaviour as windows
under linux you have to use the OpenThreads::ReentrantMutex.  You'd
use this in code that sets a lock and the recurses, such a case would
be an osgPlugin that uses a RenentrantMutex to serialize access to it,
but the mutex doesn't prevent it calling itself - a conventional Mutex
under pthreads would lock in this situation.

The Windows mutex does prevent locks from different threads being
acquired multiple times, so if you modified your code to test this it
should work the same under Windows and Pthreads/unix.

Robert.





On Wed, Feb 4, 2009 at 1:53 PM, Laurence Muller  wrote:
> Hi,
>
> It seems that there is a difference in behavior when using the
> OpenThreads::Mutex class in Linux and Windows.
>
> For our (crossplatform) application it is required to synchronize data
> between two different threads. In order to prevent a race condition, we used
> the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
> To test the behavior of the mutex lock, I created a small application
> (attached below).
>
> Our Linux machine produces the following output:
> [laure...@fedora mutex_test]$ ./main
> test 1 (trylock): ok
> -- application blocked --
>
> Using the same application under windows (compiled with mingw):
> main.exe
> test 1 (trylock): ok
> test 2 (lock): ok
> test 3 (lock again): ok
> test 4 (unlock): ok
> -- application finished --
>
> The Linux version shows the correct behavior, the Windows version seems to
> ignore the lock calls and does not block at all.
>
> Questions:
> 1. Are additional settings required to use the OpenThreads mutex lock under
> windows?
> 2. What alternatives are available for the OpenThreads mutex lock? (Manually
> implement calls using pthread?)
>
> Kind Regards,
> - Laurence
>
> -
> // main.cpp
> // g++ main.cpp -o main -I /home/userx/osg/include -L /home/userx/osg/lib
> -lOpenThreads
>
> #include 
> #include 
> #include 
> using namespace std;
>
> OpenThreads::Mutex *mt_sync;
>
> int main(int argc, char **argv)
> {
>   mt_sync = new OpenThreads::Mutex();
>
>   printf("test 1 (trylock): ");
>   if(mt_sync->trylock() == 0)
>   printf("ok\n");
>   else
>   printf("fail\n");
>
>   printf("test 2 (lock): ");
>   if(mt_sync->lock() == 0)
>   printf("ok\n");
>   else
>   printf("fail\n");
>
>   printf("test 3 (lock again): ");
>   if(mt_sync->lock() == 0)
>   printf("ok\n");
>   else
>   printf("fail\n");
>
>   printf("test 4 (unlock): ");
>   if(mt_sync->unlock() == 0)
>   printf("ok\n");
>   else
>   printf("fail\n");
>
>   delete mt_sync;
>
>   return 0;
> }
>
>
> ___
> 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] Different behavior between Linux and Windows when using OpenThreads::Mutex

[Laurence Muller]

Hi,

It seems that there is a difference in behavior when using the 
OpenThreads::Mutex class in Linux and Windows.


For our (crossplatform) application it is required to synchronize data 
between two different threads. In order to prevent a race condition, we 
used the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
To test the behavior of the mutex lock, I created a small application 
(attached below).


Our Linux machine produces the following output:
[laure...@fedora mutex_test]$ ./main
test 1 (trylock): ok
-- application blocked --

Using the same application under windows (compiled with mingw):
main.exe
test 1 (trylock): ok
test 2 (lock): ok
test 3 (lock again): ok
test 4 (unlock): ok
-- application finished --

The Linux version shows the correct behavior, the Windows version seems 
to ignore the lock calls and does not block at all.


Questions:
1. Are additional settings required to use the OpenThreads mutex lock 
under windows?
2. What alternatives are available for the OpenThreads mutex lock? 
(Manually implement calls using pthread?)


Kind Regards,
- Laurence

-
// main.cpp
// g++ main.cpp -o main -I /home/userx/osg/include -L 
/home/userx/osg/lib -lOpenThreads


#include 
#include 
#include 
using namespace std;

OpenThreads::Mutex *mt_sync;

int main(int argc, char **argv)
{
   mt_sync = new OpenThreads::Mutex();

   printf("test 1 (trylock): ");
   if(mt_sync->trylock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 2 (lock): ");
   if(mt_sync->lock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 3 (lock again): ");
   if(mt_sync->lock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   printf("test 4 (unlock): ");
   if(mt_sync->unlock() == 0)
   printf("ok\n");
   else
   printf("fail\n");

   delete mt_sync;

   return 0;
}


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

Re: [osg-users] OSGEarth precision

[Glenn Waldron]

David,

I'll just chime in for the record to echo Robert's correct assessment --
osgEarth uses osgTerrain under the hood, and osgTerrain solves the precision
issue by localizing each tile at each level of detail with a
double-precision matrix.


Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
+1.703.652.4791


On Wed, Feb 4, 2009 at 4:14 AM, Robert Osfield wrote:

> Hi David,
>
> I haven't dived into the source code of osgEarth, but I do know that
> it utilises osgTerrain, and osgTerrain internally uses double to
> locate tiles in their geocentric position (the class that does this is
> the osgTerrain::Locator).  When the geometry for rendering is
> generated on demand it's created with a local origin and then
> decorated with a MatrixTransform that places the tile into it's final
> position.
>
> Since the OSG defaults to use double Matrix for MatrixTransform and
> doubles for all osg::Camera management, and the cull traversal
> accumulates the camera + transforms in the scene using doubles, it's
> possible to position the tiles very accurately and maintain precision
> for as long as possible before passing to OpenGL.
>
> When you are close to a tile, such as driving along it the relative
> translations of the camera and the tile's MatrixTransform largely
> cancel out  with little numerical errors thank's to the use of
> doubles, so you get the best precision where you need it most, while
> far away tiles have larger translations left in them so the error is
> higher, but this is not an issue as vertices and divide by their
> distance during the transformation from object to clip space so the
> errors seen on screen remain subpixel so you don't see them.
>
> Thanks to this system it's possible to use pre-built
> VirtualPlanetBuilder or dynamically generated osgEarth databases in
> geocentric coords without complex additional coding, it just works out
> of the box.
>
> Whether you'd want to use a dynamically generated database from remote
> data for a simulator is a different matter, one would have to look
> closely at the latency and consistency of download and generating
> tiles.
>
> Robert.
>
> On Wed, Feb 4, 2009 at 7:10 AM, David Karlsson 
> wrote:
> > Hi,
> >
> > Is OSGEarth suitable to use, as a part of a terrain simulator, together
> with objects that needs to be positioned with about cm precision - or will I
> run into problems with precision? I found this page about  how they handled
> it in NASA's World Wind:
> http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-precision.html
> >
> > How is this handled in OSGEarth?
> >
> > Thanks,
> > David
> > ___
> > 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)

[Robert Osfield]

Hi All,

I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is:

   
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/

If those don't CDash builds (as well as everyone else) move across to
using this branch as the base for testing the OSG-2.8 release series.
I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh
build on the 2.8 branch and see how I get on.  It'd be useful to have
feedback from others as well on how the OSG-2.8 is fairing.

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

Re: [osg-users] MSVC v9

[Robert Osfield]

Hi Tanguy,

On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
 wrote:
> Robert, do you thing the problem may be serious enough to possibly motivate
> a code change for all operators of Vec3f and co as a workaround?

We could change code, it would all depend on how intrusive the changes
are, without code changes in front of me I can't make this judgement
call.  Could you send me a modified Vec* files so I could do a review?

The other approach is to change the compile flags of the OSG to avoid
this bug.  This wouldn't help 3rd party apps though.

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

Re: [osg-users] Getting Started with OpenSceneGraph on Ubuntu

[Robert Osfield]

Hi ?

On Wed, Feb 4, 2009 at 12:13 PM, Trịnh Thành Trung GMail
 wrote:
> Uhm, one thing I don't understand is, as you said, "Could sign with the name
> you wish to be addressed as please, to prevent others form making mistakes".

When I mean sign your posts I mean, just sign your first name or a
pseudonym at the bottom of each post so that we keep track of who's
who - this might seem a little formal, but it makes for a much
pleasanter online exchanges. Mailing lists such as this one are
fundamentally a social activity, it's just a community of like minded
individuals trying to scramble through their daily tasks, helping and
receiving help.  Small little things like being a bit more personal
can help this along.

> Actually I've just had to subscribe to osg-users, again, to be able to post
> in the group, although I still have recieved osg disgest mails for months.
> Does it has anything to do with what you said? :-S

You can post from a digest enabled mail subscription, it's only the
mail dispatch that is different.  Contributing to threads using non
digest form is much easier though, as you can reply directly to posts,
without having to jump through hoops to get the subject line to do
some sensible.

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

Re: [osg-users] MSVC v9

[Tanguy Fautre]

I’ve submitted the bug to Microsoft.

Hopefully they will be able to further enlighten us on the issue.

 

Robert, do you thing the problem may be serious enough to possibly motivate a 
code change for all operators of Vec3f and co as a workaround?

 

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=411031

 

 

Tanguy

 

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Guy Wallis
Sent: Monday 02 February 2009 00:04
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9

 

Hi Tanguy,

I tried your code on an SGI (IRIX 6.5.22) using the GNU C++ compiler (version 
2.4.3) and level 3 optimisation.

 

No errors using either form of the subtraction operator.

 

Cheers,

 

Guy

 

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

Re: [osg-users] Getting Started with OpenSceneGraph on Ubuntu

[Trịnh Thành Trung GMail]

Wow! I thank you so much for your detailed support. I was able to compile my
OSG program with OpenSceneGraph 2.4 with kind help of Alberto Luaces. I will
try your instruction soon to get the newest version of OpenSceneGraph, well,
as soon as OSG 2.8 becomes available.
Uhm, one thing I don't understand is, as you said, "Could sign with the name
you wish to be addressed as please, to prevent others form making mistakes".
Actually I've just had to subscribe to osg-users, again, to be able to post
in the group, although I still have recieved osg disgest mails for months.
Does it has anything to do with what you said? :-S

-- 
TnTonly Corporation
===
Home: http://www.tntonly.co.cc
Mail: http://mail.tntonly.co.cc
Forum: http://www.tntonly.co.cc/forum
Blog: http://www.tntonly.co.cc/blog
OS: http://www.tntonly.co.cc/os (Limited Service)
===
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] about Drawable::ComputeBoundingBoxCallback struct

[Mojtaba Fathi]

Hi all

osg::Drawable class declares 5 structs which can be used to implement callback 
functions for different purposes. Except 'ComputeBoundingBoxCallback' struct, 
other 4 structs inherit virtually from osg::Object class.
Is there any particular reason for 'ComputeBoundingBoxCallback' struct to not 
inherit virtually from osg::Object or this is simply a bug?

Regards
Moji the Great


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

Re: [osg-users] SVN (2.8) bugs in osgviewerQt

[Morné Pistorius]

Hi Robert, J-S,

Thanks for the suggestions!  I removed the Qt event relay methods and
added a dummy view with a zero sized viewport to my viewer.  The
single context, multiple view tiled viewer now works as expected,
adding/removing views and clearing the window as it should.

Thanks again for your help!!  You saved me a lot of debugging headache :)

Regards,
Morné

PS. Do you want me to submit a modified osgviewerQt example with these
fixes/workarounds?


On Tue, Feb 3, 2009 at 7:57 PM, Jean-Sébastien Guay
 wrote:
> Hi Morné,
>
>> The other approach might be to create an empty View that does nothing,
>> has no scene, but at least has a Camera with the GraphicsWindow
>> assigned to it.  It's viewport could be zero sized so would be litte
>> more than a non op, and you have have the GraphicsWindow do the clear
>> each frame for you.  This approach why a bit inelegant would probably
>> prevent the problems you are seeing, and would just require an
>> additionally couple of lines of set up code at the creation time,
>> thereafter you'd just ignore this extra View.
>
> Yep, in my testing what Robert suggests would work since as long as you have
> at least one view there is no problem. It's removing that last view and then
> adding others that brings up the problem.
>
> Sorry I couldn't find anything more definitive on my end.
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg::Image::copySubImage

[Robert Osfield]

HI Valery? (could you sign with the name you wish to be addressed as
please to avoid confusion ;-)

The osg::Image* source parameter should be const, clearly this was
just an oversight in the original implementation, I've fixed this and
checked into svn/trunk.  So this change will make it into 2.8.

Cheers,
Robert.

On Wed, Feb 4, 2009 at 8:11 AM, Валерий Быков  wrote:
>
> Hi.
>
> Tell me please why
> void osg::Image::copySubImage(int s_offset,int t_offset,int
> r_offset,osg::Image* source);
> has non-const parameter source?
>
>
> ___
> 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