Re: [osg-users] FBX Plugin: animation speed not as expected...
Great, I've bumped my submission so hopefully it'll be in osg trunk soon. Re: poses, they have been a complete nightmare to get working so far, and yet there are still a few cases that don't work. If you can find what's going on with humanoid.fbx then you'll be my hero! I may be able to help more if you can get a much simpler example that demonstrates the problem e.g. only one or two joints. On 18 January 2011 15:27, Alessandro Terenzi wrote: > Thank you very much Michael, > your fix solved the timing issue. > > Any idea/suggestion about the wrong initial-pose problem? (it happen with > the humanoid.fbx model available with the FBX SDK). > > Regards. > Alessandro > > > On Tue, Jan 18, 2011 at 11:12 AM, Michael Platings wrote: > >> Hi Alessandro, >> I posted a fix a while back that may solve the issue you're referring to. >> If it works for you then maybe with more prodding Cedric might accept it ;) >> Here it is again, attached >> >> >> On 17 January 2011 15:43, Alessandro Terenzi wrote: >> >>> Hi, >>> no one else is experiencing the same problems with osgAnimation and the >>> FBX plugin? I mean the 'initial-pose' issue (described in this thread) and >>> the timing issue described in another post of mine. >>> >>> Cheers, >>> Alessandro >>> >>> -- >>> Read this topic online here: >>> http://forum.openscenegraph.org/viewtopic.php?p=35708#35708 >>> >>> >>> >>> >>> >>> ___ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using MVPW in a Resizeable Window.
Skylark wrote: > Hi David, > > > > You don't recall by chance any fixes that were made after the OSG 2.8.1 > > release based on resizing issues? > > > > Not off the top of my head, no. It might be interesting to set a > breakpoint in the resize event handler and see if it ever gets there > when it should. But anyways, if you've got it working the way you want, > that's fine too. :-) > > J-S > -- > __ > Jean-Sebastien Guay > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum Oh yea, the resize event handler is being called. I actually have two points where resizing is used: One is the resizing event routine that is called every time the Whole Window is resized, and the Second is where a tab slider is at where you can make the controls disappear - to get the most maximum view. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35752#35752 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
Hi Jason, Has anybody tried a build with the NDK r5 yet? It's supposed to have an optional STL that supports RTTI, exceptions, etc. It'd be nice to not require a 3rd-party NDK to compile OSG. I haven't tried it yet. It was in my plans but Android development is not part of my normal job, just after-work-hobby-type-stuff, so I haven't gotten to it yet. 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] Texture Buffer Objects status?
Hi Fred,
I have never used TBOs before. How do you use your new class?
Is the following correct?
Code:
// Creation
osg::TextureBuffer *tb = new osg::TextureBuffer();
// This will create a buffer of 300 * 4 bytes = 1200 bytes
osg::Image *image = new osg::Image();
image->allocateImage(300 /*width*/, 1 /*height is ALWAYS 1, right?*/, 1,
GL_RGBA, GL_FLOAT, 1); // GL_RGBA + GL_FLOAT = 4 floating point components for my
color
// here, feed buffer with data
tb->setImage(image);
I don't see anything wrong here.
Code:
#version 150 compatibility
#extension GL_EXT_gpu_shader4 : enable
For me (NVIDIA 280GTX graphics card in linux), it works just to declare:
#version 130
uniform sampler1D tex; // shall I use sampler1D here, or sampler2D?
This has to be:
uniform samplerBuffer tex;
void main(void)
{
vec4 color = texelFetch(tex, 0); // I get a compile error here, texelFetch
is not a recognized function name (?!). I use a Fermi card with the latest
drivers. Confused with the different function names I found on the web
(texelFetch, texelFetch1D/2D, texelFetchBuffer which, I understand, are
deprecated).
[...]
}
I use texelFetchBuffer but if you solved it I guess you use the same.
Cheers,
Juan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
On 01/17/2011 09:27 AM, Jean-Sébastien Guay wrote: I compiled OSG with the NDK, it was pretty easy. You'll need the modified NDK that has support for RTTI, exceptions and a more complete standard library, which you can find here: http://smartctl.net/android/ndk-r4.php Just curious, Has anybody tried a build with the NDK r5 yet? It's supposed to have an optional STL that supports RTTI, exceptions, etc. It'd be nice to not require a 3rd-party NDK to compile OSG. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
I figured out why texelFetch wasn't being compiled successfully. 1) I forgot the last argument 2) I last tried on AMD/ATI hardware, and the GLSL compiler on this platform doesn't seem to actually recognize 'texelFetch'... Now moving on with my tests. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35746#35746 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgmovie and stereo
Hi, Thanks Robert. I also saw a 'osgmovie' sample along with other examples built on OSG 2.9.10. When I hit a 'osgmovie --help', I found an option '--stereo'. Will this be any simpler than using 'osgstereoimage' ? Thank you! Cheers, Vijay -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35745#35745 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan,
I managed to make some progress.
- I replaced osg::BufferObject::Extensions with GLEW
- I changed the other offending expression:
generateTextureObject(contextID, GL_TEXTURE_BUFFER_EXT);
to
generateTextureObject(this, contextID, GL_TEXTURE_BUFFER_EXT);
Things compile fine.
I have never used TBOs before. How do you use your new class?
Is the following correct?
Code:
// Creation
osg::TextureBuffer *tb = new osg::TextureBuffer();
// This will create a buffer of 300 * 4 bytes = 1200 bytes
osg::Image *image = new osg::Image();
image->allocateImage(300 /*width*/, 1 /*height is ALWAYS 1, right?*/, 1,
GL_RGBA, GL_FLOAT, 1); // GL_RGBA + GL_FLOAT = 4 floating point components for
my color
// here, feed buffer with data
tb->setImage(image);
Fragment shader:
Code:
#version 150 compatibility
#extension GL_EXT_gpu_shader4 : enable
uniform sampler1D tex; // shall I use sampler1D here, or sampler2D?
void main(void)
{
vec4 color = texelFetch(tex, 0); // I get a compile error here, texelFetch
is not a recognized function name (?!). I use a Fermi card with the latest
drivers. Confused with the different function names I found on the web
(texelFetch, texelFetch1D/2D, texelFetchBuffer which, I understand, are
deprecated).
[...]
}
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35742#35742
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX Plugin: animation speed not as expected...
Thank you very much Michael, your fix solved the timing issue. Any idea/suggestion about the wrong initial-pose problem? (it happen with the humanoid.fbx model available with the FBX SDK). Regards. Alessandro On Tue, Jan 18, 2011 at 11:12 AM, Michael Platings wrote: > Hi Alessandro, > I posted a fix a while back that may solve the issue you're referring to. > If it works for you then maybe with more prodding Cedric might accept it ;) > Here it is again, attached > > > On 17 January 2011 15:43, Alessandro Terenzi wrote: > >> Hi, >> no one else is experiencing the same problems with osgAnimation and the >> FBX plugin? I mean the 'initial-pose' issue (described in this thread) and >> the timing issue described in another post of mine. >> >> Cheers, >> Alessandro >> >> -- >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=35708#35708 >> >> >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi, Sorry for not answering before but I've been away from the computer. Regarding osg::BufferObject, in my OSG version (2.8.3) there is an Extensions class declared inside osg::BufferObject. Of course you can replace it with GLEW, but probably the other compile error is also related to the use of a different version. Regards, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM & cascaded shadow maps
So far I've tried osg 2.8.3 and 2.9.10 and have not been able to get any results using the parallel split shadow map technique. Is anyone using PSSM currently and have any suggestions? I am presently using LiSPSM, it works pretty well but I since I am rendering a large outdoor scene I find that need to set a far clip plane in order to get acceptable resolution for the shadowed volume, as a result shadows "pop" at the far plane. Cascaded shadow map techniques like PSSM are supposed to address this problem. Ideally, osg should have a generalized cascaded shadow map class which would allow specializations for the various methods of partitioning the shadowed scene. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows in OSG
I suggest looking at StandardShadowMap, MinimalShadowMap and the various LiSPSM variations; based on my experience with osg 2.8.3 they offer the most robust implementation of shadows. There is also a debugging mode that you can enable that renders the depth map which is extremely useful. As Wojtek said, dynamic shadows are a pretty advanced topic, you will need a good theoretical understanding before diving into the particulars of how osg manages it. On 1/17/2011 8:42 AM, Linda Lee wrote: > Hi, > > How about learning the way OSG structures the shadow code. I found it > difficult understanding how OSG manage shadow. Could anyone briefly explain > the shadow codes in OSG or is there any way I could learn more on them? > > Thank you! > > Cheers, > Linda > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=35694#35694 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Another autobuild failure
Hi JS, Caught this one already, fix checked in this morning ;-) Robert. On Tue, Jan 18, 2011 at 1:57 PM, Jean-Sébastien Guay wrote: > Hi Robert, > > Another day, another autobuild failure :-) > > I'm kidding you of course. > > http://cdash.openscenegraph.org/viewBuildError.php?buildid=3185 > > .\..\..\src\osgDB\DatabasePager.cpp(895) : error C2664: 'void > osgUtil::IncrementalCompileOperation::add(osg::Group *,osg::Node *)' : > cannot convert parameter 1 from 'osg::ref_ptr' to 'osg::Group *' > > Seems you tested your changes with a build where the > REF_PTR_IMPLICIT_CONVERSION (paraphrasing) was enabled. > > J-S > -- > __ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Another autobuild failure
Hi Robert, Another day, another autobuild failure :-) I'm kidding you of course. http://cdash.openscenegraph.org/viewBuildError.php?buildid=3185 .\..\..\src\osgDB\DatabasePager.cpp(895) : error C2664: 'void osgUtil::IncrementalCompileOperation::add(osg::Group *,osg::Node *)' : cannot convert parameter 1 from 'osg::ref_ptr' to 'osg::Group *' Seems you tested your changes with a build where the REF_PTR_IMPLICIT_CONVERSION (paraphrasing) was enabled. 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] Shadows in OSG
Hi Linda, Its large and advanced topic. Various techniques work in different way. I simply do not have the time to explain it. Besides, I follow the rule to not respond in much more words than question asked (hint). If you are interested in Shadow Mapping I may recomend starting from osgShadow::ShadowMap implementation. See ShadowMap::cull method. Its the place where all the relevant code is located. However be warned, that to fully understand it one needs to understand how OSG culling and rendering backend works so its really stuff for advanced developers. Wojtek -Oryginalna wiadomość- From: Linda Lee Sent: Monday, January 17, 2011 2:42 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Shadows in OSG Hi, How about learning the way OSG structures the shadow code. I found it difficult understanding how OSG manage shadow. Could anyone briefly explain the shadow codes in OSG or is there any way I could learn more on them? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35694#35694 ___ 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] Texture Buffer Objects status?
Hi,
OK, I temporarily replaced Extensions with GLEW, things moved forward, but I'm
stuck with the following compilation error now:
Code:
} else if (_image.valid() && _image->data()) {
/* Temporary copy */
osg::ref_ptr image = _image;
/* Creating the texture object */
_textureObjectBuffer[contextID] = to =
generateTextureObject(contextID,
GL_TEXTURE_BUFFER_EXT); // compilation error here:
error C2661: 'osg::Texture::generateTextureObject' : no overloaded function
takes 2 arguments
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35730#35730
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
Hi, I'm working with Jorge trying to get a native osg on Android. The main problem that we found was the migration of OpenThreads, it's not really complicated but there are some missing api in pthreads (pthread_cancel as mentioned before) and some changes (sleep returns void :O). We made the changes on CMake and OpenThreads to support this changes but when we tried to build against a desktop environment again then things didn't work :(. We wanted to send the modified files once things get working, but maybe is time that other eyes get a look to this. Jorge, could you attach to this thread a bundle with all the changes we made to get things compiling and working on android? I'm attaching a simple (and little ugly) example of a viewer for android, all made in native (except the minimal parts required in Java). Currently we got things building against crystax-ndk-r4. This example "worked" for my Samsung Galaxy S (android 2.1update1). The viewer starts, and shows the nice blue osg screen! :) but I wasn't be able to get draw any geometry (I built osg with gles2 support). To compile it, you need the crystax ndk r4, and osg compiled against this version. Then you need to modify the osgviewerandroid/jni/Android.mk file to change the path of required osg libraries for your system. To get the apk for android I do this things. android update project -p . -t 1 # -t is the target defined (android list devices to get the list) ndk-build ant debug If things work inside bin/ you will get the .apk Greets, Rafa. 2011/1/18 Robert Osfield : > Hi Jorge, > > I know little about the issues of Android platform, so read with > interest in the various developments that yourself and others are > working on, it does mean I can't yet contribute too pro-actively > though. I'll will try and chip in where I can. > > On Mon, Jan 17, 2011 at 10:37 PM, Jorge Izquierdo Ciges > wrote: >> Pthreads. The Set functions are trivial and i don't think that could cause a >> very big damage. But pthread_cancel is something different, because i've >> seen that it's widely used. And we would need a suitable replacement to >> don't let the thread go on. > > With the OSG usage of threads I have implemented co-operative exit of > the thread loops using done flags, instead of relying upon > Thread::cancel(). Given this, not having cancel() working as before > may well not be that critical. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es http://gvsig3d.blogspot.com Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia osgviewerandroid.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
That are some great news. I was planning to do some test to know if it was used, but if it's not used then for the moment it's one thing that i don't have to worry right now. 2011/1/18 Robert Osfield > Hi Jorge, > > I know little about the issues of Android platform, so read with > interest in the various developments that yourself and others are > working on, it does mean I can't yet contribute too pro-actively > though. I'll will try and chip in where I can. > > On Mon, Jan 17, 2011 at 10:37 PM, Jorge Izquierdo Ciges > wrote: > > Pthreads. The Set functions are trivial and i don't think that could > cause a > > very big damage. But pthread_cancel is something different, because i've > > seen that it's widely used. And we would need a suitable replacement to > > don't let the thread go on. > > With the OSG usage of threads I have implemented co-operative exit of > the thread loops using done flags, instead of relying upon > Thread::cancel(). Given this, not having cancel() working as before > may well not be that critical. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi, When I compile your code I get the following errors: Code: error C2065: 'GL_TEXTURE_BUFFER_EXT' : undeclared identifier error C2039: 'Extensions' : is not a member of 'osg::BufferObject' error C2039: 'getExtensions' : is not a member of 'osg::BufferObject' [...] I don't see any osg::BufferObject::Extensions class in OSG's source code. Do you? Didn't you mean osg::Texture::Extensions instead? Regarding GL_TEXTURE_BUFFER_EXT, I'm usually working with and plan to include GLEW, so I should be fine. Regards Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35728#35728 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Object picking with multiple Instances
Hello everyone,
I'm new here so hi all and thanks in advance to everyone willing to take a look
on my issue. :)
I'm currently working on object selection in my scene, so I made something up
based on the picking example from osgpick.cpp .
Code:
if (myview->computeIntersections(x, y, intersections))
{
// *** for each intersection we found ***
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr =
intersections.begin();
hitr != intersections.end();
++hitr)
{
// choose foremost selection in FoV
if(hitr == intersections.begin()) {
if (!hitr->nodePath.empty())
{
osg::NodePath nodePath = hitr->nodePath;
node = (nodePath.size() >= 1) ? nodePath[nodePath.size()-1] : 0;
pickedObjects.push_back(node);
return true;
}
}
}
}
If this function returns true, a callback on another class responsible for for
further processing the object selection (adding it to list of selected objects,
changing display mode to wireframe etc) is triggered.
That other class traverses the objects in my scene and checks whether the
picked node is part of the currently scanned object:
Code:
// scan for objects to potentially add
for(nodeit = selectednodes.begin(); nodeit != selectednodes.end(); ++nodeit)
{
// and try to verify their existance as drawobject
for(drawit = drawObjects.begin(); drawit != drawObjects.end(); ++drawit)
{
/* In case we find the corresponding drawobject, we have to
* add them to the list of selected objects. */
if((*drawit)->getObject()->containsNode((*nodeit))) {
(*drawit)->setSelected(true);
selectedobjects.push_back((*drawit));
That piece of code works well, as long as the selected object is the only
instance of itself. As soon as I have the picked object instanced multiple
times in my scene, trying to pick any of these will result in always the same
object being selected (the first match in the list, obviously).
So, when performing the pick itself (code snippet #1) I need to gather
additional info like the position of the selected object in order to be able to
make the correct match when trying to mark the object as selected. However,
when I have the same mesh with, say, 30 instances and therefore 31 parental
nodes, how would I find out which one is the node corresponding to the instance
I click on in the scene?
Best regards,
-Alex
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35625#35625
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX Plugin: animation speed not as expected...
Hi Alessandro,
I posted a fix a while back that may solve the issue you're referring to. If
it works for you then maybe with more prodding Cedric might accept it ;)
Here it is again, attached
On 17 January 2011 15:43, Alessandro Terenzi wrote:
> Hi,
> no one else is experiencing the same problems with osgAnimation and the FBX
> plugin? I mean the 'initial-pose' issue (described in this thread) and the
> timing issue described in another post of mine.
>
> Cheers,
> Alessandro
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=35708#35708
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
/* -*-c++-*-
* Copyright (C) 2008 Cedric Pinson
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include
using namespace osgAnimation;
Animation::Animation(const osgAnimation::Animation& anim, const osg::CopyOp& copyop): osg::Object(anim, copyop),
_duration(anim._duration),
_originalDuration(anim._originalDuration),
_weight(anim._weight),
_startTime(anim._startTime),
_playmode(anim._playmode)
{
const ChannelList& cl = anim.getChannels();
for (ChannelList::const_iterator it = cl.begin(); it != cl.end(); ++it)
{
addChannel(it->get()->clone());
}
}
void Animation::addChannel(Channel* pChannel)
{
_channels.push_back(pChannel);
if (_duration == _originalDuration)
computeDuration();
else
_originalDuration = computeDurationFromChannels();
}
double Animation::computeDurationFromChannels() const
{
double tmin = 1e5;
double tmax = -1e5;
ChannelList::const_iterator chan;
for( chan=_channels.begin(); chan!=_channels.end(); chan++ )
{
float min = (*chan)->getStartTime();
if (min < tmin)
tmin = min;
float max = (*chan)->getEndTime();
if (max > tmax)
tmax = max;
}
return tmax-tmin;
}
void Animation::computeDuration()
{
_duration = computeDurationFromChannels();
_originalDuration = _duration;
}
osgAnimation::ChannelList& Animation::getChannels()
{
return _channels;
}
const osgAnimation::ChannelList& Animation::getChannels() const
{
return _channels;
}
void Animation::setDuration(double duration)
{
_originalDuration = computeDurationFromChannels();
_duration = duration;
}
double Animation::getDuration() const
{
return _duration;
}
float Animation::getWeight () const
{
return _weight;
}
void Animation::setWeight (float weight)
{
_weight = weight;
}
bool Animation::update (double time, int priority)
{
if (!_duration) // if not initialized then do it
computeDuration();
double ratio = _originalDuration / _duration;
double t = (time - _startTime) * ratio;
switch (_playmode)
{
case ONCE:
if (t > _originalDuration)
return false;
break;
case STAY:
if (t > _originalDuration)
t = _originalDuration;
break;
case LOOP:
if (!_originalDuration)
t = _startTime;
else if (t > _originalDuration)
t = fmod(t, _originalDuration);
// std::cout << "t " << t << " duration " << _duration << std::endl;
break;
case PPONG:
if (!_originalDuration)
t = _startTime;
else
{
int tt = (int) (t / _originalDuration);
t = fmod(t, _originalDuration);
if (tt%2)
t = _originalDuration - t;
}
break;
}
ChannelList::const_iterator chan;
for( chan=_channels.begin(); chan!=_channels.end(); ++chan)
{
(*chan)->update(t, _weight, priority);
}
return true;
}
void Animation::resetTargets()
{
ChannelList::const_iterator chan;
for( chan=_channels.begin(); chan!=_channels.end(); ++chan)
(*chan)->reset();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Skybox (horizon and ground) in GLSL?
Hi, Not sure if this or its been superseded, you might want to take a look at OSGTDS. http://andesengineering.com/Projects/TDS/ This is for deforming terrain for the placement of objects. I have never used it, but it might be worth a shot? Cheers Martin. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christian Buchner Sent: 17 January 2011 09:58 To: OpenSceneGraph Users Subject: [osg-users] Skybox (horizon and ground) in GLSL? Hi, I managed to load some 20 buildings from a freely available GIS database from the city of Winston-Salem and I render them with OSG. Buildings floating in space look kind of funny though and I need a ground, a horizon and some sky. I do not want to use a flat ground geometry or sky dome - that's too old-fashioned. I was thinking to use a screen aligned quad (coordinates forced to screen dimensions in a vertex shader) and a pixel shader to set ground and sky zbuffer values and to render the ground and sky color. The ground zbuffer values for sure depend on the camera height over ground. And how the horizon is oriented would depend on the camera orientation (view matrix) Unfortunately having little prior experience with GLSL, I think I might need some input from the community how to pull this off. Christian ___ 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] Visibility of point array
Hi Oliver, On 18/01/11 20:23 , Oliver Neumann wrote: > I need the information on vertix level, not bounding volumn level. How does > the Render > Engine know which vertices to draw. Is it all done in GPU using the Z Buffer > (overwriting what is nearer)? OSG does not check each vertex for visibility, that would be way too expensive. Instead it's checking the Drawable against the view frustum for potential visibility. OpenGL then does finer-grained checking of the vertices against the view frustum, discarding vertices outside. Finally the Z-buffer determines if the pixels are occluded or not. But there's no way to easily get to the information which vertices actually get drawn. > OcclusionQueryNode but I cannot find any occlusion information in it. How do > I get the > visibility information stuff here? You don't, at least not on a per-vertex level. If I remember correctly OC could tell you how many pixels are visible, but not which ones. If you really need that information you have to check each pixel individually yourself. This can be made a lot faster by properly balancing the scenegraph, ie rather than putting all points into one Drawable you'd oct-tree them so that they can be more easily discarded based on the bsphere/bbox of the drawable. Again, what do you want to achieve? There might be easier ways to do that. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visibility of point array
Hi Ulrich, I need the information on vertix level, not bounding volumn level. How does the Render Engine know which vertices to draw. Is it all done in GPU using the Z Buffer (overwriting what is nearer)? I found the OcclusionQuery example that uses OcclusionQueryNode, but I can't quite make out how to use it. Its very confusing, I add the previous root node as a child of a new OcclusionQueryNode but I cannot find any occlusion information in it. How do I get the visibility information stuff here? Thank you! Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35723#35723 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
Hi Jorge, I know little about the issues of Android platform, so read with interest in the various developments that yourself and others are working on, it does mean I can't yet contribute too pro-actively though. I'll will try and chip in where I can. On Mon, Jan 17, 2011 at 10:37 PM, Jorge Izquierdo Ciges wrote: > Pthreads. The Set functions are trivial and i don't think that could cause a > very big damage. But pthread_cancel is something different, because i've > seen that it's widely used. And we would need a suitable replacement to > don't let the thread go on. With the OSG usage of threads I have implemented co-operative exit of the thread loops using done flags, instead of relying upon Thread::cancel(). Given this, not having cancel() working as before may well not be that critical. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
