Re: [osg-users] Inserting a Switch node into the SG

[Paul Martz]

> > How are you determining that you are getting the wrong results? What 
> > you show as the result seems impossible for the code you've posted, as 
> > 'parent'
> > only adds one child: the switch.
> 
> I saved the scenegraph to a file and looked at it.

When are you doing the file write? I'm concerned that some other code might
be operating on your scene graph between when you load it and when you write
it out. If I were you, I'd write it out twice, first at the top of the code
you originally posted, and second at the bottom, so you get an unambiguous
"before and after" shot of exactly what that one function is changing.
   -Paul

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

[osg-users] UserData

[Guy Volckaert]

Hi,

What's the best way to pass user data to all nodes and drawables. For example, 
lets assumes I have 2 cameras (left & right). Each camera points to the same 
scene. When rendering the left camera, I want the the nodes and drawables to 
use userdata1, and when rendering the right camera I want the nodes and 
drawables to use userdata2. 

The goal is to pass thread safe data during the rendering of each camera 
without having to use a mutext or a critical section to access the data. Since 
each camera has its own user data "copy" it should be thread safe.

I know that the RenderInfo contains a userdata ptr, but I don't know how to use 
it as decribed above.

Any suggestions are appreciated. 

Thank you!

Cheers,
Guy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13202#13202





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

Re: [osg-users] FirstPersonManipulator

[Christian Sam]

Hi,

i included the following lines in my applicationcode:
#include "../include/FirstPersonManipulator.h"
viewer.setCameraManipulator(new osgGA::FirstPersonManipulator);

and got:
1>   Creating library D:\workspace\test-osg\sln\graz\Debug\graz.lib and object 
D:\workspace\test-osg\sln\graz\Debug\graz.exp
1>graz5.obj : warning LNK4217: locally defined symbol 
??0firstpersonmanipula...@osgga@@q...@_n@Z (public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)) imported in 
function _main
1>graz5.obj : warning LNK4217: locally defined symbol 
?classn...@firstpersonmanipulator@osgGA@@UBEPBDXZ (public: virtual char const * 
__thiscall osgGA::FirstPersonManipulator::className(void)const ) imported in 
function "[thunk]:public: virtual char const * __thiscall 
osgGA::FirstPersonManipulator::className`vtordisp{4294967292,0}' (void)const " 
(?classn...@firstpersonmanipulator@osgGA@@$4p...@a@BEPBDXZ)
1>graz5.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
protected: void __thiscall osgGA::FirstPersonManipulator::`vbase 
destructor'(void)" (__imp_??_dfirstpersonmanipula...@osgga@@IAEXXZ) referenced 
in function "protected: virtual void * __thiscall 
osgGA::FirstPersonManipulator::`scalar deleting destructor'(unsigned int)" 
(??_gfirstpersonmanipula...@osgga@@maep...@z)
1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for 
`osg::Object'}" (__imp_??_7firstpersonmanipula...@osgga@@6bobj...@osg@@@) 
referenced in function "public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)" 
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for 
`osg::Drawable::EventCallback'}" 
(__imp_??_7firstpersonmanipula...@osgga@@6beventcallb...@drawable@osg@@@) 
referenced in function "public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)" 
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for 
`osg::NodeCallback'}" 
(__imp_??_7firstpersonmanipula...@osgga@@6bnodecallb...@osg@@@) referenced in 
function "public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)" 
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for 
`osg::Drawable::EventCallback'}" 
(__imp_??_8firstpersonmanipula...@osgga@@7beventcallb...@drawable@osg@@@) 
referenced in function "public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)" 
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for 
`osg::NodeCallback'}" 
(__imp_??_8firstpersonmanipula...@osgga@@7bnodecallb...@osg@@@) referenced in 
function "public: __thiscall 
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)" 
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1>D:\workspace\test-osg\sln\graz\Debug\graz.exe : fatal error LNK1120: 6 
unresolved externals


is it possible to try this manipulator without building a new osgViewer?


Thank you!

Cheers,
Christian

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13200#13200





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

Re: [osg-users] Inserting a Switch node into the SG

[Jim Vaughan]

Hi Paul,

Thanks for the reply,

 
> What you have looks basically right, except I don't 
> understand why you have:
>   ref_ptr group = new Group;
>   switchnode->addChild(group.get());
> That seems unnecessary to the task at hand.

Yes, I had tried a few semi-random things to try to understand
what was happening and inadvertantly included one of them
in my posting.  What I should have posted is this:

ref_ptr switchnode = new Switch;
string name = node->getName();
switchnode->setName(name);
switchnode->addChild(node);
Group* parent = node->getParent(0);
parent->addChild(switchnode.get());
parent->removeChild(node);

> 
> How are you determining that you are getting the wrong 
> results? What you
> show as the result seems impossible for the code you've 
> posted, as 'parent'
> only adds one child: the switch.

I saved the scenegraph to a file and looked at it.

This is the scene graph before:

  Group {
name "mviewConeGroup"
nodeMask 0x
cullingActive TRUE
num_children 1
Group {
  name "multiviewCone1"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  ...


  Switch {
name "mviewConeGroup"
nodeMask 0x
cullingActive TRUE
NewChildDefaultValue 0
ValueList {
  0
}
num_children 1
Group {
  name "mviewConeGroup_old"
  nodeMask 0x
  cullingActive TRUE
}
  }

The children of mviewConeGroup (Group2 in the example in my earlier post)
are not under mviewConeGroup_old, as I expected they would be.


Thanks

Jim

> 
> Inserting a node above another node is a common task and one that is
> somewhat error-prone to implement. I've often wondered if it 
> would make
> sense to have Node methods for insertAbove() and 
> insertBelow(). This was a
> feature in PEI VisKit and we made frequent use of it at my 
> old employer.
> 
> 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-opensce
> negraph.org
> 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Jason Daly]

Christian Buchner wrote:

I think I will try  my luck with an ARB fragment and vertex shader
extension that implements
parallax occlusion mapping with offset limiting. Link follows.

http://web.archive.org/web/20060207121301/http://www.infiscape.com/doc/parallax_mapping.pdf

The advantage is that I might get this to work on Intel integrated
graphics even.
  


Suit yourself  :-)

If I remember correctly, it's only about six lines of GLSL code in the 
fragment shader.


Actually, looking at the link, it should be pretty easy to translate 
that asm code into GLSL code as well.


--"J"

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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Paul Martz]

Hi Chris -- What do you know, another opportunity to discuss BRDF textures.
(I mentioned this to Christian in a separate thread when he was looking for
ways to draw realistic coins with relief detail.)

The good news about BRDFs is that they were covered in the orange book, so
GLSL source should be available at the book's web site:
http://www.3dshaders.com/home/ (I know it was in the first edition, not sure
about the second). Also, BRDFs handle your low angle-of-incidence issue
cleanly.

The bad news is that generating the BRDF texture images is no easy task.
About the time I left HP, I believe they were working on patenting a machine
for snapping BRDF texture images from actual small-ish 3D objects. The
machine was a small dome about a meter in diameter. Of course, you could
capture the images using screen shots of a virtual object and thereby avoid
the need for any such physical hardware.

Feel free to pick my (or Mike Weiblen's) brain on this, as we both have some
familiarity with the algorithm. (Go Colorado OSG Users!)

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] Can I change the plugin directory structure?

[Paul Martz]

> I am not finding this to be the case.  When running with F5 or Ctrl-F5, 
> VS runs the example from where it compiled to, NOT where the INSTALL 
> project sends it.  In my case, "bin\Release\". 

I'm not able to reproduce this problem, Rick. To test, I blew away my
installed OSG (deleted C:\Program Files\OpenSceneGraph), went into VS, set
osganimate as the active project, brought up Properties and specified
OSG_NOTIFY_LEVEL=DEBUG_FP in the environment, then I hit ctrl-f5 to run. The
program ran fine and displayed the models. I exited and examined the console
output. There, I saw osgDB looking for the .osg plugin, and it found and
used "\bin\osgPlugins-2.9.5\osgdb_osg.dll".

You say your examples are in bin\Release. This is not the case for me; there
is no bin\Release in my build dir. The release build of my osganimate.exe
file is in "\bin". Not sure why yours would be elsewhere, but
this appears to be the source of your problem. What CMake variables did you
change from their default?
 
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] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension "bug"

[Andrew Cunningham]

Hi,
I have just been bitten by  and wasted hours on with this 'issue' with VC++ 
2005 . As noted you cannot mix vectors across "Release Mode" libraries that 
uses STL  compiled with _SECURE_SCL=0 (mine) and "Release Mode" 
libraries e.g OSG ) compiled _SECURE_SCL=1 ( the default).
It causes all sorts of mysterious crashes...

Arrrgh!

Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13196#13196





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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

Thanks for the help guys, and the reminder to check the previous posts and
the web-site.  UNFORTUNATELY:

> Being able to run an example directly from Visual Studio (using Set As
Active Project and pressing F5) is another issue. You need to first run at
least the ALL_BUILD target, so that all plugins will be built. That's
because none of the OSG DLLs or examples have the plugins as dependencies,
as it should be - the plugins are dynamically loaded, and as such no
executable can know /a/ /priori/ which plugins it will need, it all depends
on what is loaded either from the command line or the code.
> Once you've run the ALL_BUILD target (or INSTALL, which depends on
ALL_BUILD) then the examples will find the plugins just fine, you can run
them with F5 no problem.

I am not finding this to be the case.  When running with F5 or Ctrl-F5, VS
runs the example from where it compiled to, NOT where the INSTALL project
sends it.  In my case, "bin\Release\".  I have built all the plugins, and
the go to "bin\Release\..\osgPlugins-2.x.x\", which appears to be in the
wrong relative place (one directory too high) for osgDB to find it.  I am
not sure where the extra "..\" is coming from, does any one know?  Something
else that I thought would be nice is if the examples knew where the sample
data is.  That way it could set the working directory for debugging to where
the samples are, and it should just run when you hit F5 (or Ctrl-F5).

> Just set your CMAKE_INSTALL_PREFIX to some directory where you want the
latest OSG binaries+libs+headers to be placed ...

Unfortunately this does not do it either, it creates the osgPlugins-2.x.x
whether I want it or not.


> Then just copy the right version of the OSG DLLs into your app's bin
> directory (with its executable) and the osgPlugins-VERSION directory
> there too (with the plugins inside the directory).

> ...somepath/bin/myapp.exe
> ...somepath/bin/osg.dll
> ...somepath/bin/
> ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
> ...somepath/bin/osgPlugins-x.y.z/

Well, there is the rub.  To keep from having to do all this manually, I
created a bat file to do the copying for me.  Whenever either one of us
upgrades OSG, we have to remember to go and change that bat file to include
the new version number.  Just one more thing to forget to do.

Thanks, and sorry for the whining.  I love OSG and all this community does.
If it is just a matter of changing something somewhere on my end, please let
me know.
-- Rick



On Fri, May 29, 2009 at 6:46 AM, James Killian wrote:

>
> Sorry about that... I did fix, and then I had to forward an email to Rick
> about the osgParticle (as I had to use html to preserve the diagram's
> spacing)  I have now switched it back to plain text.
> Thanks for letting me know. (there are too few of us in the "dark side" for
> microsoft to do something about it)  : (
>
> I have recopied email in plain text below:
>
> James Killian
> - Original Message - From: "James Killian" <
> james_kill...@hotmail.com>
> To: "OpenSceneGraph Users" 
> Cc: "Rick Pingry" 
> Sent: Thursday, May 28, 2009 10:25 PM
>
> Subject: Re: [osg-users] Can I change the plugin directory structure?
>
>
> "
> Then just copy the right version of the OSG DLLs into your app's bin
> directory (with its executable) and the osgPlugins-VERSION directory
> there too (with the plugins inside the directory).
>
> .somepath/bin/myapp.exe
> .somepath/bin/osg.dll
> .somepath/bin/
> .somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
> .somepath/bin/osgPlugins-x.y.z/
> "
>
> I should review the code as I suspect it uses relative paths to retrieve
> the plugins.  If so, there should be a clause that client code must not
> dominate the CWD as ours currently does.  One thing I know for sure is that
> this path setup does not work right with our game in its current state.
>  Thanks for taking the time out to explain.  Hopefully we may find a better
> solution.
>
>
>
> James Killian
>  - Original Message -  From: Jean-Sébastien Guay
>  To: OpenSceneGraph Users
>  Sent: Thursday, May 28, 2009 8:07 PM
>  Subject: Re: [osg-users] Can I change the plugin directory structure?
>
>
>  Hello Rick,
>
>  > I have noticed that for the past little while the plugins are compiled
>  > to their own directory with the version number.  I am not quite sure why
>  > this is beneficial, it seems like you would always want the plugins
>  > compiled with the version of OSG you have compiled, and it seems that
>  > having them in the same folder with the other binaries ensures that the
>  > proper dll's will be found.
>
>  Well, copying the plugins into the same directory as your application
>  ensures that *some* *version* of the plugin will be found, not
>  necessarily the right one (unless you're extra careful).
>
>  There have been enough cases in the past of people only updating the
>  main OSG DLLs, omitting to also update the plugins, and then running
>  into an application crash (because of ABI changes between 

Re: [osg-users] osgGlut does not build

[Jean-Sébastien Guay]

Hi Bruce,


For some odd reason I am getting links error from gz and ive plug-ins for 
various methods that are in the zlib123 libraries.  I have tried both 
zlibstat.lib and zlibwapi.lib and get the same errors both ways.  If I open the 
libraries in the debugger I can see the strings (i.e inflate, inflateEnd 
inflateinit2 etc).  I have checked the path to the libraries several times and 
I am not getting a library not found error.

Is there a different ZLIB library that I should be using?


Perhaps you still have the old dependencies from OSG pre-1.9 days? The 
dependencies have been updated a few times since then, so perhaps 
they're using functions that were not in previous versions. See


  http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies

for how to get up to date prebuilt dependencies for your compiler.

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] osgGlut does not build

[Clay, Bruce]

Thanks Robert.  I updated my source tree and found the program you mentioned.

For some odd reason I am getting links error from gz and ive plug-ins for 
various methods that are in the zlib123 libraries.  I have tried both 
zlibstat.lib and zlibwapi.lib and get the same errors both ways.  If I open the 
libraries in the debugger I can see the strings (i.e inflate, inflateEnd 
inflateinit2 etc).  I have checked the path to the libraries several times and 
I am not getting a library not found error.

Is there a different ZLIB library that I should be using?

Bruce


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Friday, May 29, 2009 3:29 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgGlut does not build

Hi Bruce,

OpenSceneGraph now has a osgviewerGLUT example.  The ancient osgGLUT
library really isn't worth looking at as it dates back to a time
before time forgot.

Robert.

On Thu, May 28, 2009 at 6:51 PM, Clay, Bruce  wrote:
> I can not get the osgGlut viewer to build either.  The error list is
> attached below.  I am using Visual Studio 2005 and compiling against OSG
> 2.8.1, OpenThreads and Producer both pulled with svn today.
>
>
>
> Several of the errors in this list come from STL
>
>
>
>
>
> Any thoughts?
>
>
>
> Bruce
>
>
>
>
>
>
>
> Error 1  error C2039: 'getPrims' : is not a member of
> 'osgUtil::RenderStage'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    626
>
> Error 2  error C2039: 'getPrims' : is not a member of
> 'osgUtil::RenderStage'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    647
>
> Error 3  error C2039: 'setTextureModeToInherit' : is not a
> member of 'osg::StateSet'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1122
>
> Error 4  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::LineSegment::vec_type' (or there is
> no acceptable conversion)
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1271
>
> Error 5  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable
> conversion)
>
>
>
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1294
>
> Error 6  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable
> conversion)   f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1301
>
> Error 7  error C2248:
> 'osg::AnimationPath::ControlPoint::_position' : cannot access protected
> member declared in class 'osg::AnimationPath::ControlPoint'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 8  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'const osg::Vec3d' (or there is no
> acceptable conversion)
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 9  error C2248:
> 'osg::AnimationPath::ControlPoint::_rotation' : cannot access protected
> member declared in class 'osg::AnimationPath::ControlPoint'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 10 error C3083: 'PrimtiveValueMap': the symbol to the left
> of a '::' must be a type
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 11 error C2039: 'iterator' : is not a member of
> 'osgUtil::Statistics'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 12 error C2133: 'pItr' : unknown size
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 13 error C2512: 'std::iterator' : no appropriate default
> constructor available
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 14 error C2582: 'operator =' function is unavailable in
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1770
>
> Error 15 error C2678: binary '!=' : no operator found which
> takes a left-hand operand of type 'std::iterator' (or there is no acceptable
> conversion)   f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1771
>
> Error 16 error C2675: unary '++' : 'std::iterator' does not
> define this operator or a conversion to a type acceptable to the predefined
> operator f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1772
>
> Error 17 error C2819: type 'std::iterator' does not have an
> overloaded member 'operator ->'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Error 18 error C2039: 'second' : is not a member of
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Error 19 error C2228: left of '.first' must have
> class/struct/union
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Er

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Christian Buchner]

>>  Yes, but I don't think that's the New and Improved version -- Parallax
>> Occlusion
>> Mapping.
>
> No, it's not.  I was replying to Christian's message for his coin rendering
> application.

I think I will try  my luck with an ARB fragment and vertex shader
extension that implements
parallax occlusion mapping with offset limiting. Link follows.

http://web.archive.org/web/20060207121301/http://www.infiscape.com/doc/parallax_mapping.pdf

The advantage is that I might get this to work on Intel integrated
graphics even.

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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Chris 'Xenon' Hanson]

Jason Daly wrote:
> Indeed.  Was the gamedev.net article I sent any use?  I still think
> you'll find that translating HLSL to GLSL isn't as hard as it sounds. 
> The only issues I can think of will be the extra functionality that the
> .fx files provide (multiple passes/techniques, etc), but OSG should let
> you handle these pretty easily if you're just writing an application.

  I haven't tried yet. I am still getting the confidence up to try to tackle 
the conversion.

> --"J"

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] smooth angle on normal calculation

[Paul Martz]

There is the osgUtil SmoothingVisitor, which will compute a normal per
vertex by averaging the facet normals of shared polygons. Will that do what
you want?

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

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Matthias
Asselborn
Sent: Friday, May 29, 2009 10:40 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] smooth angle on normal calculation

Hi,

iam looking for a function
that calculates normals by given smooth angle or is it already implemented?

Thank you!

Cheers,
Matthias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13188#13188





___
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] smooth angle on normal calculation

[Matthias Asselborn]

Hi,

iam looking for a function 
that calculates normals by given smooth angle 
or is it already implemented?

Thank you!

Cheers,
Matthias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13188#13188





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

Re: [osg-users] Inserting a Switch node into the SG

[Paul Martz]

What you have looks basically right, except I don't understand why you have:
ref_ptr group = new Group;
switchnode->addChild(group.get());
That seems unnecessary to the task at hand.

How are you determining that you are getting the wrong results? What you
show as the result seems impossible for the code you've posted, as 'parent'
only adds one child: the switch.

Inserting a node above another node is a common task and one that is
somewhat error-prone to implement. I've often wondered if it would make
sense to have Node methods for insertAbove() and insertBelow(). This was a
feature in PEI VisKit and we made frequent use of it at my old employer.

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

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

[osg-users] Inserting a Switch node into the SG

[Jim Vaughan]

Hi Fellow OSG Users,

I'm trying to dynamically insert a Swtich into my scene graph and I'm a little
confused by what is happening.

The graph is like this:

Group1
   Group2
  Child1
  ...
  ChildN

I am trying to make it like this (Group2 and its children moved to under the 
newly inserted switch):

Group1
Switch
   Group2
  Child1
  ...
  ChildN


But what I end up with is this (Group2 has moved as expected, but its children 
are now under Group1):


Group1
   Switch
  Group2

   Child1
   ...
   ChildN

Could someone please tell me if I am doing something stupid, or missing 
something fundamental.

Here is the code in question.  The parameter node Group2.  

void makeLayer(Node* node)
{
if (strcmp(node->className(), "Switch") == 0) {
return;
}
ref_ptr switchnode = new Switch;
string name = node->getName();
switchnode->setName(name);
switchnode->addChild(node);
Group* parent = node->getParent(0);
parent->addChild(switchnode.get());
ref_ptr group = new Group;
switchnode->addChild(group.get());
parent->removeChild(node);
node->setName(name + "_old");
}


Many thanks in advance,

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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Jason Daly]

Chris 'Xenon' Hanson wrote:


  Yes, but I don't think that's the New and Improved version -- Parallax 
Occlusion
Mapping. 


No, it's not.  I was replying to Christian's message for his coin 
rendering application.




There are several Parallax Mapping sources out there, but basic PM falls apart
visually at low view angles, whereas POM does much better.
  


Indeed.  Was the gamedev.net article I sent any use?  I still think 
you'll find that translating HLSL to GLSL isn't as hard as it sounds.  
The only issues I can think of will be the extra functionality that the 
.fx files provide (multiple passes/techniques, etc), but OSG should let 
you handle these pretty easily if you're just writing an application.


--"J"

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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Chris 'Xenon' Hanson]

Jason Daly wrote:
> Christian Buchner wrote:
>> Strangely that preview for Parallax Bump Mapping demo says "Source
>> Code: [YES]"
>> but when you go to the detail page and download the demo (
>> ParallaxMapping_Demo.zip )
>> there is no source code to be seen.
>>
>> I am also looking for this rendering technique to make some realistic
>> rendering of coins with an embossed imprint.
> Here is a link to NVidia's bump mapping demo, which also includes the
> simple parallax mapping technique (I don't know why folks have such a
> hard time finding this, it took me about five seconds).  This demo uses
> GLSL, so it should be easy to integrate into whatever you're trying to
> do.   There are a lot of other examples on this page as well.
> http://developer.download.nvidia.com/SDK/9.5/Samples/samples.html#glsl_bump_mapping

  Yes, but I don't think that's the New and Improved version -- Parallax 
Occlusion
Mapping. There are several Parallax Mapping sources out there, but basic PM 
falls apart
visually at low view angles, whereas POM does much better.

> --"J"

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Access vertices and faces after load the model

[Xin Chen]

Hello Guys,

  To my original problem. I found a website which is quite useful and 
works. Just in case others may need it. 

http://delta3d.wiki.sourceforge.net/Accessing+Underlying+OpenSceneGraph+Geometry

Thank you!

Cheers,
Xin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13184#13184





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

Re: [osg-users] Access vertices and faces after load the model

[Thrall, Bryan]

Paul Melis wrote on Friday, May 29, 2009 9:55 AM:

> Thrall, Bryan wrote:
>> Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
>> 
>>> You use a NodeVisitor to walk your scene graph and look for Geodes,
>>> then iterate over the Drawables that are attached to the Geodes,
using
>>> dynamic_cast to access the Drawable as a Geometry.
>>> 
>> 
>> Even better, I notice osg::Drawable has asGeometry(), which is
cheaper than
>> dynamic_cast<> :) 
>> 
> Wow, I wasn't expecting the difference to be this large, as virtual
> function calls aren't completely free either:
...
> 16:52|p...@tabu:~> ./t
> 1
> asGeometry(): 1.181 ms
> dynamic_cast<>(): 3.945 ms
> 16:52|p...@tabu:~> g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L
> ~/osg2.8/lib/ -losg -losgDB
> 16:52|p...@tabu:~> ./t
> 1
> asGeometry(): 0.839 ms
> dynamic_cast<>(): 3.611 ms
> 16:52|p...@tabu:~>

That's even more impressive than I was expecting!

-- 
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] Accessing Texture Indices

[Xin Chen]

omaralvi wrote:
> Hello guys,
> 
> I am new to osg. I have loaded an obj file using osgDB but I don't know how 
> to access vertex and texture indices. I can get the vertex array from the 
> geometry using
> pGeo.get()->getVertexArray()  method but pGeo.get()->getVertexIndices() 
> returns null.  I cant figure out how the indices are stored for the vertices 
> and the texture. The model is loaded and displayed fine so there 
> is definitely a problem in the way I am accessing the data. Would really 
> appreciate any help. 
> 
> 
> 
> 
> Thanks
> 
> Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it 
> out.
> 
>  --
> Post generated by Mail2Forum



Hi 

I'm new to OSG and having the same problem. check this website, it may helpful.

http://delta3d.wiki.sourceforge.net/Accessing+Underlying+OpenSceneGraph+Geometry

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13183#13183





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

Re: [osg-users] osg::ref_ptr<> used anymore

[Paul Martz]

I used to tell people "once you become familiar with ref_ptrs, you'll learn
where you need them and where you don't, and you can get away with using
regular C/C++ pointers in some cases." I've stopped telling people this,
because I have caught myself multiple times using regular C/C++ pointers,
then later changing the code and assuming it was ref counted, and therefore
introducing a leak.

Yes, it's best to always use ref_ptr.

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

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Rabbi
Robinson
Sent: Friday, May 29, 2009 8:38 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] osg::ref_ptr<> used anymore

Hi,

Thanks for the replies. They really clarified a lot. Looks like for small
pointer, it's all or none deal, e.g. it's best to use them every time a
reference to the pointed object is needed. 

Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13175#13175





___
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] Access vertices and faces after load the model

[Paul Martz]

Touché! :-)

Cheers,

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

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Thrall,
Bryan

Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
> You use a NodeVisitor to walk your scene graph and look for Geodes, 
> then iterate over the Drawables that are attached to the Geodes, using 
> dynamic_cast to access the Drawable as a Geometry.

Even better, I notice osg::Drawable has asGeometry(), which is cheaper than
dynamic_cast<> :)

--
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] add/remove camera crash

[Robert Osfield]

Hi Mathias,

2009/5/29 Mathias Fröhlich :
> There is a race between asking the observer_ptr if it is valid and the object
> you have no counted reference on being deleted before accessing it.
> And there is no atomic way to get a ref_ptr from an observed_ptr without that
> race.

I went for a lightweight observer implementation, rather than go the
route of requiring ref_ptr<> construction for access like
std::weak_ptr requires.  The later is more robust in the presence of
threading, but slower.

To make a thread safe implementation we'd need to add a mutex into the
observer to protect access to _ptr and add a ref_ptr<> as the
accessors.

Right now one should obviously take care of what contexts you use
observer_ptr<>.  Using the Observer interface doesn't have this
problem though, as one could easily manage the thread safe on the
observer side.

For this particular problem observer_ptr<> isn't appropriate - it's
the Camera that owns the RenderStage that needs to be managed
correctly.

>> The problem is that you can't delete an object whilest another thread
>> is still using it.  The easiest way to address this is to stop the
>> threading.  The more complex way is to synchronize the threads in some
>> fasion.
> So, I wonder how is this solved for models that are being deleted by a Paged
> model?
> Should this already work?
> Just wondering if I can safely use pre/post Cameras in paged models?
> What am I missing here in the thread picture?

Interesting issue.  Normally nodes don't make it into the rendering
backend, but in scene graph Camera's are the exception, the StateSet
and Drawable are all reference counted in the rendering backend so
that aren't effected by the possibility of scene graph elements being
deleted which the draw traversal is running.   So potentially one
could have a Camera node removed during update such as pageing that
overlaps with the draw traversal when running in DrawThreadPerContext
and CullDrawThreadPerContext.   The CullDrawThreadPerContext and
SingleThreaded models won't be affected as the draw traversals won't
be affected.


> Also I thought that in the concrete problem. The event stage (as well as the
> update stage) is something that is serialized enough to modify the scenegraph
> (may be also throwing away a Camera)?

Removing a Camera that is being used in a rendering thread will be
unsafe no matter when it's done.  Right now the way to avoid problems
is use CullDrawThreadPerContext/SingleThreaded or stop threading when
removing Cameras.

To allow us to remove Camera's from the scene graph whilst the draw
thread is still running will require the draw thread to take a
reference to Camera while it's being used.   It might be possible to
tweak the osgViewer::Renderer so that it keeps tabs on what
RenderStage and associated Camera's are in action and to take a
reference where appropriate.  Perhaps RenderStage itself could be
tweaked to allow on to increment/decrement the ref count of all
associated Camera's under the control of the Renderer.

Perhaps another tweak might be to have the whole Rendering backend
manage the reference counts for StateSet and Drawables as well as
Camera in a high level way, as then we could toggle on/off the
reference counting when we need it rather than have it on even when it
isn't neccessary - such as in SingleThreaded and
CullDrawThreadPerContext threading models.

Robert.

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

Re: [osg-users] Transparency and hdr texture

[Jason Daly]

josselin.pe...@lcpc.fr wrote:

Hi,

Does anyone know an image format storing high dynamic range values (32  
bits per pixel) and transparency ?
  


I believe OSG supports OpenEXR, which was designed by Industrial Light 
and Magic for this purpose.  I think it supports both half-float and 
float formats, and it's probably the highest-quality format for HDR 
pictures.  There is also the HDR format, but I think it only does RGBE, 
not float.


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

Re: [osg-users] Access vertices and faces after load the model

[Paul Melis]

Thrall, Bryan wrote:

Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
  

You use a NodeVisitor to walk your scene graph and look for Geodes,
then iterate over the Drawables that are attached to the Geodes, using
dynamic_cast to access the Drawable as a Geometry.



Even better, I notice osg::Drawable has asGeometry(), which is cheaper
than dynamic_cast<> :)
  
Wow, I wasn't expecting the difference to be this large, as virtual 
function calls aren't completely free either:


16:51|p...@tabu:~> cat t.cpp
// g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB
#include 
#include 

float
timediff(struct timeval t0, struct timeval t1)
{
   return 1000 * (t1.tv_sec - t0.tv_sec) + (t1.tv_usec - t0.tv_usec) / 
1000.0;

}

int main()
{
   osg::Group* cow = (osg::Group*)osgDB::readNodeFile("cow.osg");
   osg::Geode* geode = (osg::Geode*)cow->getChild(0);
   osg::Drawable *draw = geode->getDrawable(0);

   boolisgeom = true;
   int i;
   struct timeval  t0, t1, t2;
   const int   N = 10;

   gettimeofday(&t0, NULL);
   for (i = 0; i < N; i++)
   isgeom = isgeom && (draw->asGeometry() != NULL);

   gettimeofday(&t1, NULL);
   for (i = 0; i < N; i++)
   isgeom = isgeom && (dynamic_cast(draw) != NULL);

   gettimeofday(&t2, NULL);

   printf("%d\n", isgeom);  // need to use isgeom, as otherwise it 
might be optimized away

   printf("asGeometry(): %.3f ms\n", timediff(t0, t1));
   printf("dynamic_cast<>(): %.3f ms\n", timediff(t1, t2));
}
16:52|p...@tabu:~> g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ 
-losg -losgDB

16:52|p...@tabu:~> ./t
1
asGeometry(): 1.181 ms
dynamic_cast<>(): 3.945 ms
16:52|p...@tabu:~> g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L 
~/osg2.8/lib/ -losg -losgDB

16:52|p...@tabu:~> ./t
1
asGeometry(): 0.839 ms
dynamic_cast<>(): 3.611 ms
16:52|p...@tabu:~>




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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Jason Daly]

Christian Buchner wrote:

Strangely that preview for Parallax Bump Mapping demo says "Source Code: [YES]"
but when you go to the detail page and download the demo (
ParallaxMapping_Demo.zip )
there is no source code to be seen.

I am also looking for this rendering technique to make some realistic
rendering of coins with an embossed imprint.
  


Here is a link to NVidia's bump mapping demo, which also includes the 
simple parallax mapping technique (I don't know why folks have such a 
hard time finding this, it took me about five seconds).  This demo uses 
GLSL, so it should be easy to integrate into whatever you're trying to 
do.   There are a lot of other examples on this page as well.


http://developer.download.nvidia.com/SDK/9.5/Samples/samples.html#glsl_bump_mapping

--"J"

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

Re: [osg-users] osg::ref_ptr<> used anymore

[Rabbi Robinson]

Hi,

Thanks for the replies. They really clarified a lot. Looks like for small 
pointer, it's all or none deal, e.g. it's best to use them every time a 
reference to the pointed object is needed. 

Thank you!

Cheers,
Rabbi

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13175#13175





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

Re: [osg-users] Access vertices and faces after load the model

[Thrall, Bryan]

Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
> You use a NodeVisitor to walk your scene graph and look for Geodes,
> then iterate over the Drawables that are attached to the Geodes, using
> dynamic_cast to access the Drawable as a Geometry.

Even better, I notice osg::Drawable has asGeometry(), which is cheaper
than dynamic_cast<> :)

-- 
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] Dragger snap to grid / raster

[Matthias Asselborn]

20 pixel is only a value..

i want to implement a snapping grid 
for a dragger

how can i set the snapping to dragger?

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13173#13173





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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Pierre Bourdin (gmail)]

I think I got it with the sources when I tried...

You should probably contact the webmaster of the ozone web site.

Pierre.
Le vendredi 29 mai 2009 à 11:28 +0200, Christian Buchner a écrit :
> > For a parallax sample using GLSL there are probably a lot of samples on
> > ATI or Nvidia developper site, but maybe you'll find some interesting
> > demo on ozone3d:
> > n
> 
> Strangely that preview for Parallax Bump Mapping demo says "Source Code: 
> [YES]"
> but when you go to the detail page and download the demo (
> ParallaxMapping_Demo.zip )
> there is no source code to be seen.
> 
> I am also looking for this rendering technique to make some realistic
> rendering of coins with an embossed imprint.
> 
> Christian

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com


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

[osg-users] Transparency and hdr texture

[josselin . petit]

Hi,

Does anyone know an image format storing high dynamic range values (32  
bits per pixel) and transparency ?


Thanks,
Josselin


This message was sent using IMP, the Internet Messaging Program.

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

Re: [osg-users] Can I change the plugin directory structure?

[James Killian]

Sorry about that... I did fix, and then I had to forward an email to Rick 
about the osgParticle (as I had to use html to preserve the diagram's 
spacing)  I have now switched it back to plain text.
Thanks for letting me know. (there are too few of us in the "dark side" for 
microsoft to do something about it)  : (


I have recopied email in plain text below:

James Killian
- Original Message - 
From: "James Killian" 

To: "OpenSceneGraph Users" 
Cc: "Rick Pingry" 
Sent: Thursday, May 28, 2009 10:25 PM
Subject: Re: [osg-users] Can I change the plugin directory structure?


"
Then just copy the right version of the OSG DLLs into your app's bin
directory (with its executable) and the osgPlugins-VERSION directory
there too (with the plugins inside the directory).

.somepath/bin/myapp.exe
.somepath/bin/osg.dll
.somepath/bin/
.somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
.somepath/bin/osgPlugins-x.y.z/
"

I should review the code as I suspect it uses relative paths to retrieve the 
plugins.  If so, there should be a clause that client code must not dominate 
the CWD as ours currently does.  One thing I know for sure is that this path 
setup does not work right with our game in its current state.  Thanks for 
taking the time out to explain.  Hopefully we may find a better solution.




James Killian
 - Original Message - 
 From: Jean-Sébastien Guay

 To: OpenSceneGraph Users
 Sent: Thursday, May 28, 2009 8:07 PM
 Subject: Re: [osg-users] Can I change the plugin directory structure?


 Hello Rick,

 > I have noticed that for the past little while the plugins are compiled
 > to their own directory with the version number.  I am not quite sure why
 > this is beneficial, it seems like you would always want the plugins
 > compiled with the version of OSG you have compiled, and it seems that
 > having them in the same folder with the other binaries ensures that the
 > proper dll's will be found.

 Well, copying the plugins into the same directory as your application
 ensures that *some* *version* of the plugin will be found, not
 necessarily the right one (unless you're extra careful).

 There have been enough cases in the past of people only updating the
 main OSG DLLs, omitting to also update the plugins, and then running
 into an application crash (because of ABI changes between versions) that
 motivated Robert to do something better. Using the osgPlugins-VERSION
 subdirectory ensures that OSG will find the *right* *version* of the
 plugins. Since OSG (specifically osgDB::Registry) knows its own version,
 it can look in the right directory for the plugins.

  > I know when I try to run any of the example
 > projects from Visual Studio, that it always complains about the plugins
 > not being there until I copy them all over to the bin directory where
 > the other binaries are.  Perhaps I am doing something wrong and I am
 > missing some really cool feature related to having them in their own
 > version labeld directory?

 Yep, they're not meant to be in the same directory as the main OSG DLLs,
 they're meant to be in the osgPlugins-VERSION directory under that.
 Running the INSTALL target from Visual Studio will give you that
 automatically.

 Being able to run an example directly from Visual Studio (using Set As
 Active Project and pressing F5) is another issue. You need to first run
 at least the ALL_BUILD target, so that all plugins will be built. That's
 because none of the OSG DLLs or examples have the plugins as
 dependencies, as it should be - the plugins are dynamically loaded, and
 as such no executable can know /a/ /priori/ which plugins it will need,
 it all depends on what is loaded either from the command line or the code.

 Once you've run the ALL_BUILD target (or INSTALL, which depends on
 ALL_BUILD) then the examples will find the plugins just fine, you can
 run them with F5 no problem.

 > I have several versions of OSG on my machine, for different projects,
 > and I want to avoid the DLL hell that might arise from having an
 > environment variable or whatever telling me where they go.

 Then just copy the right version of the OSG DLLs into your app's bin
 directory (with its executable) and the osgPlugins-VERSION directory
 there too (with the plugins inside the directory).

 ...somepath/bin/myapp.exe
 ...somepath/bin/osg.dll
 ...somepath/bin/
 ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
 ...somepath/bin/osgPlugins-x.y.z/

 > Is there a way to tell CMake to just put
 > all the binaries in the same directory?

 Yes, it's called the INSTALL target. Just set your CMAKE_INSTALL_PREFIX
 to some directory where you want the latest OSG binaries+libs+headers to
 be placed, generate the project files, and run the INSTALL target from
 the Visual Studio solution. Same goes for Unix - set
 CMAKE_INSTALL_PREFIX, generate the makefiles, and run 'make install'.

 Incidentally, this has been discussed a lot in the past, so searching
 the archives would have turned up all this info, bu

Re: [osg-users] set type of atomic operations via CMake?

[Alberto Luaces]

Hi,

El Viernes 29 Mayo 2009ES 13:18:07 Mathias Fröhlich escribió:
> > So is there a way to force this setting via CMake? Or use the chosen SDK
> > when compiling the atomic-test? I tried some stuff, but didn't succeed.
>
> Currently not.

I was struggling with a simliar issue this week 
(http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg27737.html) 
so I wrote a little patch in order to have the possibility of at least 
deactivating the use of those instructions manually.

The patch respects current behaviour by default, but creates a new boolean 
switch in order to deactivate manually those operations if it's needed.

I can post it in case it's useful to you.

Regards,

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

Re: [osg-users] set type of atomic operations via CMake?

[Mathias Fröhlich]

Hi,

On Friday 29 May 2009, Stephan Maximilian Huber wrote:
> I am facing a problem with atomic operations and CMake and OS X. If I
> configure CMake to compile against the 10.4 SDK I'll get compile errors
> in OpenThreads/Atomic.cpp, because CMake decided to use
> _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC which is only valid when compiling
> against the 10.5 SDK. The cmake-test succeeds because I am on a
> 10.5-system, but I want to compile osg against 10.4 so the libs are
> usable there too.
That means that the test for the BSD features is not complete!
At the time I did that initial patch, the configure test included all 
functions we really need. At a later time there were some additional 
functions added, but the test was not extended as far as I see.
So we might change the cmake test code to something that really tests what is 
required. Then you would get the mutex fallback.

Anyway, is there any chance to back port the current code that to the 10.4 
sdk, so that you get that atomic stuff?
With the atomic operations osg is noticable faster.

> To rephrase: This is only a problem, when I am on a 10.5 system, and I
> want to compile against the 10.4 sdk. On a 10.4 system, the CMake-test
> will fail.
>
> So is there a way to force this setting via CMake? Or use the chosen SDK
> when compiling the atomic-test? I tried some stuff, but didn't succeed.
Currently not.

> (I can edit Openthreads/Config per hand, but it seems errorprone)
Then you need to make sure that cmake does not rewrite that file.

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

[osg-users] set type of atomic operations via CMake?

[Stephan Maximilian Huber]

Hi,


I am facing a problem with atomic operations and CMake and OS X. If I
configure CMake to compile against the 10.4 SDK I'll get compile errors
in OpenThreads/Atomic.cpp, because CMake decided to use
_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC which is only valid when compiling
against the 10.5 SDK. The cmake-test succeeds because I am on a
10.5-system, but I want to compile osg against 10.4 so the libs are
usable there too.

To rephrase: This is only a problem, when I am on a 10.5 system, and I
want to compile against the 10.4 sdk. On a 10.4 system, the CMake-test
will fail.

So is there a way to force this setting via CMake? Or use the chosen SDK
when compiling the atomic-test? I tried some stuff, but didn't succeed.

(I can edit Openthreads/Config per hand, but it seems errorprone)


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

Re: [osg-users] memory leak problem

[Paul Melis]

Andoni Mujika wrote:

Hi Robert,

Sorry for not being very precise. I also tried osg::ref_ptr<>. Now, 
the code looks like this:


osg::ref_ptr m_geom;
/m_geom = (osg::Vec3Array*) ((dynamic_cast// 
(m_NewGeom)->clone(osg::CopyOp::DEEP_COPY_ARRAYS)));



the memory grows and grows...
/
Are you developing on Linux? If so, you might want to give valgrind a 
try and specifically its 'massif' tool. This allows you to track memory 
usage during a programs run and can (in principle) provide you with 
information where all the memory you're seeing was allocated.


Regards,
Paul

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

[osg-users] memory leak problem

[Andoni Mujika]

Hi Robert,

Sorry for not being very precise. I also tried osg::ref_ptr<>. Now, the code
looks like this:

osg::ref_ptr m_geom;

*m_geom = (osg::Vec3Array*) ((dynamic_cast**
(m_NewGeom)->clone(osg::CopyOp::DEEP_COPY_ARRAYS)));


the memory grows and grows...

Thank you,

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

Re: [osg-users] memory leak problem

[Robert Osfield]

Hi Amujika,

There really is nothing anybody can say to help given the scant
details of what you are doing.

Robert.

On Fri, May 29, 2009 at 11:04 AM, Andoni Mujika  wrote:
> Hi Robert,
>
> Sorry for not being very precise. I also tried osg::ref_ptr<>. Now, the code
> looks like this:
>
> osg::ref_ptr m_geom;
>
> m_geom = (osg::Vec3Array*) ((dynamic_cast
> (m_NewGeom)->clone(osg::CopyOp::DEEP_COPY_ARRAYS)));
>
>
>
> the memory grows and grows...
>
> Thank you,
>
> Amujika
>
>
> ___
> 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] add/remove camera crash

[Mathias Fröhlich]

On Friday 29 May 2009, Robert Osfield wrote:
> Hi Mathias,
>
> 2009/5/29 Mathias Fröhlich :
> > Should the Render Stage have a reference to the camera instead of just a
> > pointer? Since the RenderStage relies on the Camera being present, this
> > appears to be the /right/ way to get that.
>
> Um not quite as you provide the  answer why not...
>
> > ... but then we have a cylclic reference count loop:
> > Camera->RenderCache->RenderStage->back to Camera.
> > So, should we cache the render stages for the cameras somewhere
> > different. May be also in the cull visitor? That would probably break the
> > reference cycle?!
> >
> > Does this sound reasonable?
> > Other thoughts?
>
> Use a observer_ptr instead of a Camera*, or register the
> RenderStage as an Observer of the Camera parent so RenderStage gets
> called when Camera gets deleted.
The observer_ptr is not thread safe!

There is a race between asking the observer_ptr if it is valid and the object 
you have no counted reference on being deleted before accessing it.
And there is no atomic way to get a ref_ptr from an observed_ptr without that 
race.

The std::weak_ptr concept where you can get a ref_ptr by the weak_ptr.lock() 
method in an atomic way would provide a thread safe way to use that.
Not yet thought about how and if the existing observed_ptr could be changed to 
make that safe.
My implementation of such a referenced/weak pointer thing is completely 
different than what is currently in osg.

> Eitherway this is all a bit moot as if the Camera is being deleted the
> RenderStage will be deleted along with... so you really are just
> hiding the problem.
>
> The problem is that you can't delete an object whilest another thread
> is still using it.  The easiest way to address this is to stop the
> threading.  The more complex way is to synchronize the threads in some
> fasion.
So, I wonder how is this solved for models that are being deleted by a Paged 
model?
Should this already work?
Just wondering if I can safely use pre/post Cameras in paged models?
What am I missing here in the thread picture?

Also I thought that in the concrete problem. The event stage (as well as the 
update stage) is something that is serialized enough to modify the scenegraph 
(may be also throwing away a Camera)?

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Christian Buchner]

> For a parallax sample using GLSL there are probably a lot of samples on
> ATI or Nvidia developper site, but maybe you'll find some interesting
> demo on ozone3d:
> n

Strangely that preview for Parallax Bump Mapping demo says "Source Code: [YES]"
but when you go to the detail page and download the demo (
ParallaxMapping_Demo.zip )
there is no source code to be seen.

I am also looking for this rendering technique to make some realistic
rendering of coins with an embossed imprint.

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

Re: [osg-users] add/remove camera crash

[Robert Osfield]

Hi Mathias,

2009/5/29 Mathias Fröhlich :
> Should the Render Stage have a reference to the camera instead of just a
> pointer? Since the RenderStage relies on the Camera being present, this
> appears to be the /right/ way to get that.

Um not quite as you provide the  answer why not...

> ... but then we have a cylclic reference count loop:
> Camera->RenderCache->RenderStage->back to Camera.
> So, should we cache the render stages for the cameras somewhere different. May
> be also in the cull visitor? That would probably break the reference cycle?!
>
> Does this sound reasonable?
> Other thoughts?

Use a observer_ptr instead of a Camera*, or register the
RenderStage as an Observer of the Camera parent so RenderStage gets
called when Camera gets deleted.

Eitherway this is all a bit moot as if the Camera is being deleted the
RenderStage will be deleted along with... so you really are just
hiding the problem.

The problem is that you can't delete an object whilest another thread
is still using it.  The easiest way to address this is to stop the
threading.  The more complex way is to synchronize the threads in some
fasion.


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

Re: [osg-users] memory leak problem

[Robert Osfield]

Hi Amujika,

There is what reference counting is for - to automatically manage
memory like this.  You don't really provide enough information about
how you are defining and using this m_geom pointer so we can only
guess at what the problem might be.  If you aren't using ref_ptr<> for
m_geom you certainly should be.

Robert.

On Fri, May 29, 2009 at 9:43 AM, Andoni Mujika  wrote:
> Hi,
>
> In my programm I have this line inside the viewer's loop:
>
> m_geom = (osg::Vec3Array*) ((dynamic_cast
> (m_NewGeom)->clone(osg::CopyOp::DEEP_COPY_ARRAYS)));
>
> The memory used increases untill the programm fails. I tried delete m_geom,
> m_geom->clear() and m_geom->erase but it didn't work.
>
> How can I release this memory?
>
> Thanks,
>
> Amujika
>
> ___
> 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] add/remove camera crash

[Mathias Fröhlich]

Hi Robert,

I have played with that thing a bit. But without success so far.

The first thought is:
Should the Render Stage have a reference to the camera instead of just a 
pointer? Since the RenderStage relies on the Camera being present, this 
appears to be the /right/ way to get that.

... but then we have a cylclic reference count loop:
Camera->RenderCache->RenderStage->back to Camera.
So, should we cache the render stages for the cameras somewhere different. May 
be also in the cull visitor? That would probably break the reference cycle?!

Does this sound reasonable?
Other thoughts?

Beside that, I have also observed that caching Render stages by the Camera 
itself is probably not sufficient. We may have two post render Cameras with 
relative transforms referenced through more than one node path. But these 
will end up rendered with the same render stage instance. True? If so you 
will not see every such Camera rendered correctly. Only the last one 
traversed by the cull visitor will render correctly. True?

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

[osg-users] memory leak problem

[Andoni Mujika]

Hi,

In my programm I have this line inside the viewer's loop:

m_geom = (osg::Vec3Array*) ((dynamic_cast
(m_NewGeom)->clone(osg::CopyOp::DEEP_COPY_ARRAYS)));

The memory used increases untill the programm fails. I tried delete m_geom,
m_geom->clear() and m_geom->erase but it didn't work.

How can I release this memory?

Thanks,

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

Re: [osg-users] Drawing a point

[Mojtaba Fathi]

Hi Robert

Thanks, it works fine.

Regards, Moji


HI Moji,

You are falling foul of small feature culling as your bounding volume
has zero size.  You can disable small feature culling by doing:

   viewer.getCamera()->setCullingMode(
            viewer.getCamera()->getCullingMode() &
~osg::CullSettings::SMALL_FEATURE_CULLING);

Robert.




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

Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping

[Pierre Bourdin (gmail)]

Hi Chris,
you could be interested by the work of Kevin Boulanger
http://www.kevinboulanger.net/grass.html

For a parallax sample using GLSL there are probably a lot of samples on
ATI or Nvidia developper site, but maybe you'll find some interesting
demo on ozone3d:
http://www.ozone3d.net/demos_projects/index.php?lang=2

Pierre.

Le jeudi 28 mai 2009 à 13:54 -0600, Chris 'Xenon' Hanson a écrit :
> I've tried posting this a couple of times, and it disappears. It went through 
> yesterday as
> a reply to a test post, so I'm going to try again with the proper subject.
> 
> 
> I'm looking to add extra visual realism to surfaces using shaders. Grass, 
> gravel and
> dirt are some of the obvious candidates, but there could be others. I am 
> hoping to use a
> type of Parallax Mapping. I have a few algorithms of basic Parallax Mapping, 
> but they fall
> apart at glancing angles close to the ground (where the user viewpoint will 
> frequently be).
> 
>   Tatarchuk's Parallax Occlusion Mapping:
> 
> http://ati.amd.com/developer/SIGGRAPH05/Tatarchuk-ParallaxOcclusionMapping-Sketch-print.pdf
> http://ati.amd.com/developer/gdc/Tatarchuk-ParallaxOcclusionMapping-FINAL_Print.pdf
> http://ati.amd.com/developer/gdc/2006/GDC06-Tatarchuk-Parallax_Occlusion_Mapping.pdf
> 
>   Seems to solve many of the issues.
> 
>   The GDC 06 paper with the allegedly improved algorithm only talks about 
> HLSL and
> DirectX. I'm interested in checking this algorithm out to see how it performs 
> (I'm
> designing shaders in RenderMonkey) but I've had a hard time finding working 
> GLSL source
> for anything newer than the original Parallax Shader from 04 and earlier.
> 
>   I don't want to write and debug an implementation from scratch just to find 
> out it
> doesn't do the job, so I was hoping to find a working implementation 
> somewhere, but am not
> finding one. Anyone seen one? It looks like a heck of a technique and could 
> really be used
> to great purpose in landscapes, and well, just about anything with surface 
> detail.
> 
>   Anyone know where to find something like this?
> 
>   Also, I'm interested in other sources of canned shaders. I'm not trying to 
> do
> cutting-edge research, I'm just trying to apply the best available technology 
> to a
> visualization problem to give the best results without reinventing the wheel.
> 

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com


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

Re: [osg-users] Drawing a point

[Robert Osfield]

HI Moji,

You are falling foul of small feature culling as your bounding volume
has zero size.  You can disable small feature culling by doing:

   viewer.getCamera()->setCullingMode(
viewer.getCamera()->getCullingMode() &
~osg::CullSettings::SMALL_FEATURE_CULLING);

Robert.

On Thu, May 28, 2009 at 11:04 PM, Mojtaba Fathi  wrote:
>
> Hi all
> Accept my apology for such a simple question. I want to display two
> coincident points at (0,0,0). I use code like this:
>
> int main()
> {
>     osgViewer::Viewer viewer;
>
>     osg::ref_ptr root (new osg::Group);
>     osg::ref_ptr geode (new osg::Geode());
>     osg::ref_ptr geometry (new osg::Geometry());
>
>     osg::ref_ptr vertices (new osg::Vec3Array());
>
>     vertices->push_back (osg::Vec3 ( 0.0, 0.0, 0.0));
>     vertices->push_back (osg::Vec3 ( 0.0, 0.0, 0.0));
>
>     geometry->setVertexArray (vertices.get());
>
>     geometry->addPrimitiveSet(new
> osg::DrawArrays(osg::PrimitiveSet::POINTS,0,vertices->size()));
>
>     osg::Point *point=new osg::Point;
>     point->setSize(4);
>     root->getOrCreateStateSet()->setAttribute(point);
>
>     geode->addDrawable (geometry.get());
>     root->addChild(geode.get());
>     viewer.setSceneData( root.get() );
>
>     return (viewer.run());
> }
>
> But it displays nothing. I think it relates to BoundingBox and culling, so
> what should I do to display two coincident points at (0,0,0)? And how to do
> it for just one point?
>
> Regards, Moji
>
>
>
> ___
> 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] Hope this is the right way to post this (osgEphemeris problem with simple example)

[Robert Osfield]

Hi Don,

Last month I had a quick trial of adding Cmake support to osgEmpheris.
 This version I worked I've put into svn up on openscenegraph.org,
this builds with the latest OSG.

svn co http://www.openscenegraph.org/svn/osgEphemeris/trunk/ osgEphemeris

I did the port to CMake by am not the original author, nor have used
osgEphemeris in projects before so I'm afraid I can't provide my
assistance with it's usage.

Robert.

On Thu, May 28, 2009 at 7:18 PM, Don Dakin
 wrote:
> Hi Richard,
>
> I have not yet come to compiling any example/sample code to check these 
> features out.
>
> I stopped at trying with the simple example when it did not work. I could try 
> it with codeing it up but that would require more time. If there is no quick 
> answer to this working using osgviewer then I will put this on the back 
> burner and try an example with some code when I have the time to look into 
> that.
>
> Thanks again
>
> Don.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13120#13120
>
>
>
>
>
> ___
> 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] osgGlut does not build

[Robert Osfield]

Hi Bruce,

OpenSceneGraph now has a osgviewerGLUT example.  The ancient osgGLUT
library really isn't worth looking at as it dates back to a time
before time forgot.

Robert.

On Thu, May 28, 2009 at 6:51 PM, Clay, Bruce  wrote:
> I can not get the osgGlut viewer to build either.  The error list is
> attached below.  I am using Visual Studio 2005 and compiling against OSG
> 2.8.1, OpenThreads and Producer both pulled with svn today.
>
>
>
> Several of the errors in this list come from STL
>
>
>
>
>
> Any thoughts?
>
>
>
> Bruce
>
>
>
>
>
>
>
> Error 1  error C2039: 'getPrims' : is not a member of
> 'osgUtil::RenderStage'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    626
>
> Error 2  error C2039: 'getPrims' : is not a member of
> 'osgUtil::RenderStage'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    647
>
> Error 3  error C2039: 'setTextureModeToInherit' : is not a
> member of 'osg::StateSet'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1122
>
> Error 4  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::LineSegment::vec_type' (or there is
> no acceptable conversion)
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1271
>
> Error 5  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable
> conversion)
>
>
>
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1294
>
> Error 6  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable
> conversion)   f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1301
>
> Error 7  error C2248:
> 'osg::AnimationPath::ControlPoint::_position' : cannot access protected
> member declared in class 'osg::AnimationPath::ControlPoint'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 8  error C2679: binary '<<' : no operator found which
> takes a right-hand operand of type 'const osg::Vec3d' (or there is no
> acceptable conversion)
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 9  error C2248:
> 'osg::AnimationPath::ControlPoint::_rotation' : cannot access protected
> member declared in class 'osg::AnimationPath::ControlPoint'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1370
>
> Error 10 error C3083: 'PrimtiveValueMap': the symbol to the left
> of a '::' must be a type
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 11 error C2039: 'iterator' : is not a member of
> 'osgUtil::Statistics'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 12 error C2133: 'pItr' : unknown size
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 13 error C2512: 'std::iterator' : no appropriate default
> constructor available
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1769
>
> Error 14 error C2582: 'operator =' function is unavailable in
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1770
>
> Error 15 error C2678: binary '!=' : no operator found which
> takes a left-hand operand of type 'std::iterator' (or there is no acceptable
> conversion)   f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1771
>
> Error 16 error C2675: unary '++' : 'std::iterator' does not
> define this operator or a conversion to a type acceptable to the predefined
> operator f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp
> 1772
>
> Error 17 error C2819: type 'std::iterator' does not have an
> overloaded member 'operator ->'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Error 18 error C2039: 'second' : is not a member of
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Error 19 error C2228: left of '.first' must have
> class/struct/union
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1774
>
> Error 20 error C2819: type 'std::iterator' does not have an
> overloaded member 'operator ->'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1775
>
> Error 21 error C2039: 'second' : is not a member of
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1775
>
> Error 22 error C2228: left of '.second' must have
> class/struct/union
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1775
>
> Error 23 error C2819: type 'std::iterator' does not have an
> overloaded member 'operator ->'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1776
>
> Error 24 error C2039: 'first' : is not a member of
> 'std::iterator'
> f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp    1776
>
> Error 25 error C2582: '