[osg-users] osgGA::AnimationPathManipulator animate twice

[Seppel Andrio]

Hey guys,

I have a problem with an osgGA::AnimationPathManipulator.

Basically my situation is:
When user clicks an item I calculate an AnimationPath and set it to the the 
viewer with:


Code:
viewer->setCameraManipulator(new 
osgGA::AnimationPathManipulator(calculateAnimationPath(params)))



The first time setting the cameraManipulator works like charm and the camera 
does the wished animation, but the second time I set the cameraManipulator the 
camera switches immediately to the end of the set AnimationPath without 
animating.

 What do I have to change that the second animation is displayed too?

Thank you!

Cheers,
Seppel

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





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

Re: [osg-users] Drawable getBoundingBox() question

[Rick Irons]

Hi Robert,



Thank you for the response.



I am still a little puzzled...shouldn't the code you refer to below set 
'_boundingBoxComputed' to true in addition to the current behavior of setting 
‘_boundingSphereComputed’ to true?  When I compare the OSG 3.0.1 version of the 
method to the 3.4.0 version the setting of ‘_boundingBoxComputed’ to true has 
been removed while the setting of ‘_boundingSphereComputed’ to true has been 
added.  It seems that both are necessary.



Thanks,

Rick





-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Saturday, June 11, 2016 3:07 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] Drawable getBoundingBox() question



On 10 June 2016 at 23:02, Rick Irons 
mailto:rick.ir...@mathworks.com>> wrote:

> Shouldn’t the inlined getBoundingBox() method in include/osg/Drawable

> set _boundingBoxComputed to ‘true’ or am I missing something?



The later :-)



From git master:



/** Get BoundingBox of Drawable.

  * If the BoundingBox is not up to date then its updated via an 
internal call to computeBond().

  */

inline const BoundingBox& getBoundingBox() const

{

if(!_boundingSphereComputed)

{

_boundingBox = _initialBound;



if (_computeBoundCallback.valid())



_boundingBox.expandBy(_computeBoundCallback->computeBound(*this));

else

_boundingBox.expandBy(computeBoundingBox());



if(_boundingBox.valid()){

_boundingSphere.set(_boundingBox.center(),

_boundingBox.radius());

} else {

_boundingSphere.init();

}



_boundingSphereComputed = true;

}



return _boundingBox;

}

___

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] Building OSG on Mac OS X 10.11.5

[François Bérard]

Wietse,

  I'm only using clang and its libc++ library. If you are using 
gcc/libstdc++, that may well explain the difference. But gcc/libstdc++ 
is the standard on linux, and ref_ptr compiles fine there.


  Do you *have to* use gcc? Otherwise, it may be easier to go with 
clang; which, I think, is the native toolchain on Mac OS. By the way, a 
simple unzip, cmake, should select a clang build. Did you force gcc? One 
thing that I noticed is that when I create new Xcode projects/targets, 
xcode insists on overriding the default clang/libc++ by gcc/libstdc++ in 
the new project or target, so I have to remove the override by hand. Did 
you use cmake's xcode generator? This may explain why you had a gcc build.





On 13/06/16 12:50, Wietse Jacobs wrote:

Hello François,

On Mon, Jun 13, 2016 at 11:31 AM François Bérard
mailto:francois.ber...@imag.fr>> wrote:

I just built the same OSG (same git rev-parse HEAD).

OS X 10.11.5
CMake 3.5.2
Xcode 7.3 (i.e. the only apparent difference with your setup).

I get the same cmake warning about MACOSX_RPATH, which is expected, cf
bottom of the following post.

http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/89981



The build displays a few warnings, but no error. See attached build log
(the line ordering is a bit messed up due to the parallel build).

I think that the normal unix way to point to shared libraries that are
not in "system" locations is using "DYLD_LIBRARY_PATH", I was not aware
of the "DYLD_FALLBACK_LIBRARY_PATH" variable.


I mainly work on windows, so I had to look that up when I was trying to
solve the "image not loaded" error when running osgviewer. I came across
a post *somewhere* that for development purposes it's wiser to us
"DYLD_FALLBACK_LIBRARY_PATH" and not interfere with "DYLD_LIBRARY_PATH".
It's supposed to do what the name implies: "use this if all else
fails...". But I know it's a hack.

...so, I don't understand your "implicit instantiation" errors. Is this
related to the Xcode 7.3.1 update? Did you play with your c++ library
somehow?


:) I did not play with my c++ library!
Seriously, no. But searching around for this problem gave many results
that point to a transition from using gcc to clang in Xcode and the
difference between using libstdc++ and libc++ as the standard library
(for example: https://github.com/qpdf/qpdf/issues/19). Does that mean
anything to you? On the other hand, that transition was made a few
releases ago so I would expect you to get the same error if that were
the reason.
But anyway, since "ref_ptr" doesn't #include  it was apparently
relying on an implicit #include *somewhere else*, so it must be that
with my setup that no longer happens. Sadly I haven't got the time right
now to track it down further...

Wietse

___
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] Render to Texture without clamping values

[Philipp Meyer]

Hi,

for my current project I need to do some computations in the fragment shader 
and retrieve the values within my application. For that I am using the render 
to texture feature together with a float texture.

I'm having some trouble reading values > 1.0 though. It seems like the values 
are getting clamped to 0..1, even though I followed the osgprerender HDR setup. 
Besides the code below, I have also tried GL_RGBA32F (ARB and not ARB) for the 
internal texture format, tried double for the image and source type and tried 
using osg::ClampColor to disable clamping for the RTT camera, all without 
success.

When reading the texture, It returns (0.123,0.5,1,1) for every texel.

Code for texture setup:


Code:
radarTexture = new osg::Texture2D;
radarTexture->setInternalFormat(GL_RGBA16F_ARB);
radarTexture->setSourceFormat(GL_RGBA);
radarTexture->setSourceType(GL_FLOAT);

auto textureImage = osgHelper::make_osgref();
textureImage->allocateImage(16,16,1,GL_RGBA, GL_FLOAT);
//  textureImage->setImage(128, 128, 1, GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE,
//  nullptr, osg::Image::AllocationMode::NO_DELETE);
radarTexture->setImage(textureImage);
radarTexture->setMaxAnisotropy(0);
radarTexture->setWrap(osg::Texture::WRAP_S, 
osg::Texture::CLAMP_TO_EDGE);
radarTexture->setWrap(osg::Texture::WRAP_T, 
osg::Texture::CLAMP_TO_EDGE);
radarTexture->setFilter(osg::Texture::FilterParameter::MIN_FILTER,
osg::Texture::FilterMode::NEAREST);
radarTexture->setFilter(osg::Texture::FilterParameter::MAG_FILTER,
osg::Texture::FilterMode::NEAREST);
radarTexture->setDataVariance(osg::Object::DYNAMIC);



RTT Camera setup (some)

Code:

// set the camera to render before the main camera.
this->setRenderOrder(osg::Camera::PRE_RENDER);

// tell the camera to use OpenGL frame buffer object where supported.
this->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);

// attach the texture and use it as the color buffer.
this->attach(osg::Camera::COLOR_BUFFER0, dest->getImage());



GLSL Fragment Shader Code (simplified):


Code:
void main()
{
gl_FragColor = vec4(0.123,0.5,3,4);
}





Thank you!

Cheers,
Philipp

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





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

Re: [osg-users] osgsimplegl3 example, is it possible to run on some combination of OSG and OSX?

[Curtis Rubel]

Hi Robert,

Thank you for your quick response, I will keep posted.

... 

Cheers,
Curtis

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





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

Re: [osg-users] osgsimplegl3 example, is it possible to run on some combination of OSG and OSX?

[Robert Osfield]

Hi Curtis,

GL3 under OSX is currently not working as Apple require the Vertex
Array Objects to be used, unlike other GL3 implementations...

There is some discussion about VAO support on osg-usbmissions so we
will hopefully have a solution checked in soon.

Robert.

On 13 June 2016 at 14:01, Curtis Rubel  wrote:
> Hi,
>
> I am hoping there may be some OSG & MacOSX
> guru's out there that could tell if me there is
> a combination of Mac OSX release and OpenSceneGraph
> release that allows the provided osgsimplegl3 example run as it
> is without modification.
>
> The mac is running El Capitan and we currently have OSG
> 3.4.0 compiled and installed on it as we had read someplace that
> 3.4.0 was already patched to allow for later GL support of
> some kind.  Unfortunately, it was not able to successfully run the
> osgsimplegl3 example either without getting a couple of
> #version 140 glcompiler messages output after enabling
> debug output messages.
>
> We used macports to satisfy most of the required
> OSG dependencies.
>
> We are not GL experts, nor OSX experts here as you probably already
> deduced...hopefully the answer is not one that will take very
> much time to answer.
>
> If you need more information just let me know and I will do my best
> to get the information for you.
>
> ...
>
> Thank you!
>
> Cheers,
> Curtis
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67589#67589
>
>
>
>
>
> ___
> 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] osgsimplegl3 example, is it possible to run on some combination of OSG and OSX?

[Curtis Rubel]

Hi,

I am hoping there may be some OSG & MacOSX
guru's out there that could tell if me there is
a combination of Mac OSX release and OpenSceneGraph
release that allows the provided osgsimplegl3 example run as it
is without modification.

The mac is running El Capitan and we currently have OSG
3.4.0 compiled and installed on it as we had read someplace that
3.4.0 was already patched to allow for later GL support of
some kind.  Unfortunately, it was not able to successfully run the 
osgsimplegl3 example either without getting a couple of
#version 140 glcompiler messages output after enabling
debug output messages.  

We used macports to satisfy most of the required 
OSG dependencies.

We are not GL experts, nor OSX experts here as you probably already
deduced...hopefully the answer is not one that will take very
much time to answer.  

If you need more information just let me know and I will do my best
to get the information for you.

... 

Thank you!

Cheers,
Curtis

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





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

Re: [osg-users] [build] Openscene Graph API

[Robert Osfield]

Hi Dave,

I don't have any idea what is going wrong in your case, but recently
during the last few weeks I've checked fixes to the cmake/Doxygen
build into the git master of the OSG to handle more modern versions of
Doxygen.

So if you aren't already using git master you could try this.

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

Re: [osg-users] Building OSG on Mac OS X 10.11.5

[Wietse Jacobs]

Hello François,

On Mon, Jun 13, 2016 at 11:31 AM François Bérard 
wrote:

>I just built the same OSG (same git rev-parse HEAD).
>
> OS X 10.11.5
> CMake 3.5.2
> Xcode 7.3 (i.e. the only apparent difference with your setup).
>
> I get the same cmake warning about MACOSX_RPATH, which is expected, cf
> bottom of the following post.
>
> http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/89981


>
> The build displays a few warnings, but no error. See attached build log
> (the line ordering is a bit messed up due to the parallel build).
>
> I think that the normal unix way to point to shared libraries that are
> not in "system" locations is using "DYLD_LIBRARY_PATH", I was not aware
> of the "DYLD_FALLBACK_LIBRARY_PATH" variable.
>

I mainly work on windows, so I had to look that up when I was trying to
solve the "image not loaded" error when running osgviewer. I came across a
post *somewhere* that for development purposes it's wiser to us
"DYLD_FALLBACK_LIBRARY_PATH"
and not interfere with "DYLD_LIBRARY_PATH". It's supposed to do what the
name implies: "use this if all else fails...". But I know it's a hack.

...so, I don't understand your "implicit instantiation" errors. Is this
> related to the Xcode 7.3.1 update? Did you play with your c++ library
> somehow?
>

:) I did not play with my c++ library!
Seriously, no. But searching around for this problem gave many results that
point to a transition from using gcc to clang in Xcode and the difference
between using libstdc++ and libc++ as the standard library (for example:
https://github.com/qpdf/qpdf/issues/19). Does that mean anything to you? On
the other hand, that transition was made a few releases ago so I would
expect you to get the same error if that were the reason.
But anyway, since "ref_ptr" doesn't #include  it was apparently
relying on an implicit #include *somewhere else*, so it must be that with
my setup that no longer happens. Sadly I haven't got the time right now to
track it down further...

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

Re: [osg-users] [build] Openscene Graph API

[Dave Sargrad]

Hi,

I've got graphviz installed now, and recognized by cmake. I also now see a 
partial set of documentation in build/docs/OpenscenegraphReferenceDocs.

Perhaps I need to rebuild the entire system again to get a complete set.

The partial set seems to have just the File list. The per-class API that one 
would typically expect in such doxygen documentation is completely missing.

I'll kick off a clean build from scratch and see if that gives me something 
more reasonable.

Cheers,
Dave

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





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

Re: [osg-users] Building OSG on Mac OS X 10.11.5

[François Bérard]

Hi Wietse,

  I just built the same OSG (same git rev-parse HEAD).

OS X 10.11.5
CMake 3.5.2
Xcode 7.3 (i.e. the only apparent difference with your setup).

I get the same cmake warning about MACOSX_RPATH, which is expected, cf 
bottom of the following post.


http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/89981

The build displays a few warnings, but no error. See attached build log 
(the line ordering is a bit messed up due to the parallel build).


I think that the normal unix way to point to shared libraries that are 
not in "system" locations is using "DYLD_LIBRARY_PATH", I was not aware 
of the "DYLD_FALLBACK_LIBRARY_PATH" variable.


...so, I don't understand your "implicit instantiation" errors. Is this 
related to the Xcode 7.3.1 update? Did you play with your c++ library 
somehow?





On 12/06/16 23:27, Wietse Jacobs wrote:

Hello,

I'm new to OSG and to this list, so I'm not sure how appropriate this
post is, but I'm hoping somebody will find it useful. Following are some
notes about the process I went through to build OSG on my new Macbook Pro.

Mac OS X 10.11.5
CMake 3.5.2
Xcode 7.3.1
OSG git clone, "git rev-parse HEAD" returns
157ee3dd7d080e7b16b133dabab9f8dce2f83941

When configuring with cmake I get the following warning:
-
CMake Warning (dev):
   Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run
"cmake
   --help-policy CMP0042" for policy details.  Use the cmake_policy
command to
   set the policy and suppress this warning.

   MACOSX_RPATH is not specified for the following targets:

OpenThreads
osg
osgAnimation
osgDB
osgFX
osgGA
osgManipulator
osgParticle
osgPresentation
osgShadow
osgSim
osgTerrain
osgText
osgUI
osgUtil
osgViewer
osgVolume
osgWidget
-
(I'm not installing to a default path)

When running make I get the following errors:
-
Scanning dependencies of target osg
[  0%] Building CXX object src/osg/CMakeFiles/osg.dir/AlphaFunc.cpp.o
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/src/osg/AlphaFunc.cpp:14
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/AlphaFunc:17
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/StateAttribute:18
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/Object:19
:
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/ref_ptr:99:42
: error:
implicit instantiation of
   undefined template 'std::__1::basic_string,
   std::__1::allocator >'
 throw std::runtime_error(std::string("could not
dereference invalid osg pointer ") ...
  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33:
note:
   template is declared here
 class _LIBCPP_TYPE_VIS_ONLY basic_string;
 ^
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/src/osg/AlphaFunc.cpp:14
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/AlphaFunc:17
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/StateAttribute:18
:
In file included from
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/Object:19
:
/Users/wja/projects/gitbub.com/OpenSceneGraph/include/osg/ref_ptr:109:42
: error:
implicit instantiation of
   undefined template 'std::__1::basic_string,
   std::__1::allocator >'
 throw std::runtime_error(std::string("could not call
invalid osg pointer ") + std::s...
  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:193:33:
note:
   template is declared here
 class _LIBCPP_TYPE_VIS_ONLY basic_string;
 ^
2 errors generated.
make[2]: *** [src/osg/CMakeFiles/osg.dir/AlphaFunc.cpp.o] Error 1
make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2
make: *** [all] Error 2
-

Changing