Re: [osg-users] Need help about Night Vision Effect
I did a IR scene by making my own cull visitor. In order to make this efficient
I had to put a virtual in front off osgUtil::CullVisitor::pushStateSet().
My cull visitor look like this
class SpectrumCullVisitor : public osgUtil::CullVisitor
{
public:
SpectrumCullVisitor()
{};
SpectrumCullVisitor(MapCullSpectrumCallBack* spectrumCallBack)
{
_Callback = spectrumCallBack;
};
virtual ~SpectrumCullVisitor()
{};
//! Get Cull Map Callback
MapCullSpectrumCallBack* Callback() const { return _Callback.get(); }
//! Set Cull Map Callback
void Callback(MapCullSpectrumCallBack* val) { _Callback = val; }
protected:
//! Try to find alternative stat set if this fails push the stat set
delivered from the graph
void pushStateSet(const osg::StateSet* ss)
{
const osg::StateSet* pushSS = NULL;
if (_Callback.get())
{
//Look if there is a alternative stat set
pushSS = _Callback-GetMapedStateSet(ss);
if (pushSS)
{
//Alternative found using it in base function
CullVisitor::pushStateSet(pushSS);
}
else
{
//No alternative found cal bas function without
switching
CullVisitor::pushStateSet(ss);
}
}
else
{
//No Callback cal base without switching
CullVisitor::pushStateSet(ss);
}
};
private:
osg::ref_ptrMapCullSpectrumCallBack _Callback;
};
And the callback like this:
class MapCullSpectrumCallBack : public osg::Referenced
{
public:
MapCullSpectrumCallBack(const std::string spectrum):
_spectrum(spectrum)
{};
virtual ~MapCullSpectrumCallBack(){};
const osg::StateSet* GetMapedStateSet( const osg::StateSet* ss ) const;
bool InsertModifiedStatsetIfChanged(const osg::StateSet* ss);
int CleanUp();
protected:
osg::ref_ptrosg::StateSet CreateStatsetAlternative(const
osg::StateSet* ss);
std::string _spectrum;
bool SwitchToSpectrumTextures( osg::StateSet* ss );
bool SwitchToSpectrumShader( osg::StateSet* ss );
std::string getFileSpectrumName( std::string name );
typedef std::maposg::ref_ptrconst
osg::StateSet,osg::ref_ptrosg::StateSet StateMap;
StateMap _StateMap;
};
You then have to populate the map in the callback with statset with alternative
textures(IR).
Regars Ragnar
-Ursprungligt meddelande-
Från: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] För Steven Powers
Skickat: den 2 december 2010 21:12
Till: osg-users@lists.openscenegraph.org
Ämne: Re: [osg-users] Need help about Night Vision Effect
The easy/cheating way is to calculate the luminance of each pixel, amplify it,
(color it green to fit the stereotype) then add electric noise.
This is easiest to do on a fragment shader.
Cheers,
Steven
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34458#34458
___
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] IVE referenced textures...
Hi All, Sorry to bother you but I have an FLT file that references a number of textures via relative paths, and I wish to save this scenegraph as an IVE file, maintaining the relative path references to the textures so that the IVE doesn't become too large. When I save the scene graph as an IVE all my textures disappear. Could anyone suggest what I might be doing wrong please ? Thanks for any help. Kind regards Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] uniform value to shader
Hi Sajjadul,
Have a look at the osg::Uniform class (include/osg/Uniform), is
supports arrays of uniforms, see the Uniform::setElement(..) method
for passing in the data. Uniforms are assigned to osg::StateSet, so
have a look at include/osg/StateSet, and also the shader related
examples. Just do a search for Uniform in example/*.
Robert.
On Sun, Dec 5, 2010 at 11:41 AM, Sajjadul Islam dosto.wa...@gmail.com wrote:
Hi,
In the main application i need to send texture coordinate offset as a one
dimensional array
float tc_off[18];
I initialize the above array with the offset value and then need to pass
it as uniform variable. How do i accomplish it within osg.
It can be done in OpenGL as follows:
//get a uniform location for the characer string
uniformLoc = glGetUniformLocation(progObj[shaderNum], tc_offset);
if (uniformLoc != -1)
{
glUniform2fv(uniformLoc, 9, tc_off);
}
So the value inside tc_off is sent to the shader and on the shader side i
have it as follows:
uniform vec2 tc_offset[9];
From the application in OpenGL we are sending 3 parameters , but how do we
send an array in OSG?
Please correct me if i m wrong in conception
Thank you!
Cheers,
Sajjadul
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34530#34530
___
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] Is caching in osg::Drawable and osg::Node getBound() methods error free?
Hi Hartwig,
I believe the current implementation is correct. If the bounding box
has be computed then _boundingBoxComputed should be false, regardless
of whether it's valid or note, otherwise you'd get repeated attempts
to compute an invalid box which is pointless. Please note that it's
not _boundingBoxValid flag.
If a bounding box needs to be recomputed then the dirtyBound() needs
to be called.
Robert.
On Sun, Dec 5, 2010 at 1:10 PM, Hartwig Wiesmann
hartwig.wiesm...@wanadoo.nl wrote:
Hi,
The current code for the getBound() methods are like this
Code:
inline const BoundingBox getBound() const
{
if(!_boundingBoxComputed)
{
_boundingBox = _initialBound;
if (_computeBoundCallback.valid())
_boundingBox.expandBy(_computeBoundCallback-computeBound(*this));
else
_boundingBox.expandBy(computeBound());
_boundingBoxComputed = true;
}
return _boundingBox;
}
Assume that you call getBound() (for a text object) before it has been drawn
for the first time it will return an invalid bounding box. And as the
bounding box is cached it will always be invalid.
I suggest to patch it like
Code:
inline const BoundingBox getBound() const
{
if(!_boundingBoxComputed)
{
_boundingBox = _initialBound;
if (_computeBoundCallback.valid())
_boundingBox.expandBy(_computeBoundCallback-computeBound(*this));
else
_boundingBox.expandBy(computeBound());
_boundingBoxComputed = _boundingBox.valid();
}
return _boundingBox;
}
Any comments?
Cheers,
Hartwig
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34533#34533
___
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] Confused with pixel buffer objects in OSG
Hi Fred, The PBO support built into osg::Texture/osg::Image for passing image data from the osg::Image to the texture, and does not presently support reading the result back. When doing read back using PBO's the situation is a little more convoluted than when passing data from main memory to the GPU, it's less of an API issue and more of performance issue. PBO's enable async data transfer to the GPU, which is where the performance benefit comes from. Copying data back from the GPU is different though, it still has to be synchronous unless you double buffer the PBO's and get the result not in the current frame, but the following frame. This double buffering and handling of a frame latency requires a high level management of the operations. Without the double buffering and retrieving the results in the next frame PBO's don't offer any performance benefit or straight glReadPixels. If osgscreencapture examples has code paths to using PBO's and double buffering so go have a look at how it does things. I'm afraid it's a lot more complicated than just adding a PBO to an osg::Image, and it won't be possible ever to implement in such a straight forward maner. Robert. On Sat, Dec 4, 2010 at 6:42 PM, Fred Smith osgfo...@tevs.eu wrote: Hi, I am confused about how to use PBOs in OSG. I browsed the forum quite a bit but still can't make my code work. 1) GPU - CPU pixel transfers As I understand it, an osg::Image with an osg::PixelBufferObject cannot be used (yet) to read FBO contents. I have actually checked that and could see that glReadPixels() still uses a client-side memory pointer. I believe this scenario is not supported yet. Not a big deal. I understand it is possible to do this manually and follow for instance what is done in the osgscreencapture sample. This sample doesn't make use of osg::PixelBufferObject, and instead manually creates a GL PBO, manually calls glReadBuffer with a bound pixel buffer object. 2) CPU - GPU pixel transfers I gave this a go but cannot make it work yet. To see if the PBO is effectively used this time in my GL tracer I look at a current bound PBO and the last parameter of glTexImage2D, which would reflect an offset and not a client side pointer. My code to create my texture, image and PBO is the following: Code: Image *image = osgDB:readImageFile(filePath); // PBO image binding method 1 - this line has no effect for me PixelBufferObject *pbo = new PixelBufferObject(image); // PBO image binding method 2 - I get a crash in BufferObject::computeRequiredBufferSize here image-setPixelBufferObject(new PixelBufferObject()); Texture2D *texture = new Texture2D(image); geode-getOrCreateStateSet()-setTextureAttributeAndMode(0, texture, StateSet::ON); I don't see any PBO created in the GL trace, and glTexImage2D still reads image data off a client side pointer. What I am doing wrong? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34527#34527 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release
Hi Tom,
I'll have a look at the enum and rename it to something less likely to
overlap with other libs over zealous using of #define.
Robert.
On Sat, Dec 4, 2010 at 2:51 PM, Thomas Hogarth thomas.hoga...@gmail.com wrote:
Hi Robert
Nice one on the fix for the subload it's much appreciated.
Thomas could you test out svn/trunk and let me know how you get on.
Quick test on windows went fine, but now I've moved over to IOS I'm getting
an unrelated compile error. I Optimizer.h there exists an enum
enum FitsIn
{
NO,
YES,
IN_NEXT_ROW
};
I think objective c has #defined YES and NO in objc.h as
#define NO (BOOL)0
as I'm getting compile error
../OpenSceneGraph-IOS-GLES2/include/osgUtil/Optimizer:763:0
../OpenSceneGraph-IOS-GLES2/include/osgUtil/Optimizer:763: error: expected
identifier before '(' token
What I don't get is why objc.h is included in the first place, it must be
some global include thing. Does anyone know of a setting in xcode that might
disable it.
Cheers
Tom
___
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] osgAnimation : feeding MorphGeometry into RigGeometry
Hi Peter, Do you have some sample data in order I test it and debug ? In theory piece are here to make it work but I have not been able to use this path. I would need to experiment with an example if you have one Cheers, Cedric On Sun, 2010-12-05 at 15:54 +0100, Peter Wrobrl wrote: Hi, I'm feeding a MorphGeometry into RigGeometry, to achieve Character Animation with Facial Morphing. The system works, but it is unclear where to attach the osgAnimation::UpdateMorph. Two cases ( Source Attached ) : 1.) Animation for UpdateMorph does not work GroupRoot ( with BasicAnimtionManager and an animation ) --Skeleton Geode ( with UpdateMorph ) --RigGeometry MorphGeometry ( Morph Base ) --Geometry ( Morph Target ) 2.) Animation Works, but skinned and unskinned ( both morphing ) is Visible GroupRoot ( with BasicAnimtionManager and an animation ) --Skeleton GeodeRig --RigGeometry MorphGeometry ( Instanced bellow ) --GeodeMorph ( with UpdateMorph ) MorphGeometry ( Morph Base ) --Geometry ( Morph Target ) I cannot turn off the NodeMask for the GeodeMorph, as then the UpdateMorph does not calculate. So how can I attach the UpdateMorph so that the skin gets morphed ( before Bone Influence ) and only one geometry been visible ? Btw, Cedric, should a FloatLinearChannel not be rather named morph than 0 ? Moreover, I'm writing out the file, there are issues in reading it back with the osganimationviewer. I'm using SVN Version 2.9.10 Thank you! Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34536#34536 Attachments: http://forum.openscenegraph.org//files/osgmorphskin_102.zip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawable and OpenGL,
Hi Gabriel,
First up strongly I'd recommend that you don't use glBegin()/glEnd()
in OpenGL. This path was supported in OpenGL 1.0, but not longer
after was replaced by much more efficient vertex array and primitive
classes. glBegin()/glEnd() support is also deprecated in OpenGL and
the OSG. Also OpenGL ES and most recent GL versions do not support
glBegin()/glEnd().
Second up I'd suggest rather than subclass your own Drawable you just
use osg::Geometry as it provides all the vertex and primitive data
support you'll need for your mesh. It'll be simpler and more
efficient than any of your current implementation and open the door to
use vertex buffer objects.
Finally when dynamically updating data switch off display lists, as
they are very expensive to recompute, and offer now performance
advantage for dynamic data. Switch off display lists via
drawable-setUseDisplayLists(false).
Robert.
2010/12/5 Gabriel Nützi gnue...@gmx.ch:
Hello
I am a newbie, and need some help regarding the drawable class:
I have a project to simulate aerodynamics on a mesh:
I have implemented a drawable class which should visualize the mesh
The mesh gets updated every rendering loop
but
Code:
void IMeshDrawable::drawImplementation (osg::RenderInfo renderInfo) const
{
// Create a 'StateSet' with a blue diffuse color attribute.
osg::ref_ptrosg::Material blue (new osg::Material);
blue-setDiffuse (osg::Material::FRONT_AND_BACK, osg::Vec4(1.0, 0.0, 1.0,
1.0));
renderInfo.getState()-applyAttribute(blue.get());
renderInfo.getState()-apply(texSS.get());
// Here IS MY CODE:
OpenGLVertexDrawVisitor mOpenGLVertexDrawVisitor;
mSimMesh-visitFaces(mOpenGLVertexDrawVisitor);
renderInfo.getState()-apply();
}
my visitFace (Visitor pattern) goes over each face in the mesh, and
executes the opengl commands as follows...
Code:
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glBegin(GL_TRIANGLES);
glVertex3d((*it)-vertexData.position.x,(*it)-vertexData.position.y,(*it)-vertexData.position.z);
glNormal3d(v.faceData.normal.x,v.faceData.normal.y,v.faceData.normal.z);
it++;
glVertex3d((*it)-vertexData.position.x,(*it)-vertexData.position.y,(*it)-vertexData.position.z);
glNormal3d(v.faceData.normal.x,v.faceData.normal.y,v.faceData.normal.z);
it++;
glVertex3d((*it)-vertexData.position.x,(*it)-vertexData.position.y,(*it)-vertexData.position.z);
glNormal3d(v.faceData.normal.x,v.faceData.normal.y,v.faceData.normal.z);
glEnd();
glPopMatrix();
My problem is, that this function drawImplementation gets executed once, and
then no more... and the mesh is plotted in OSG but it is not animated because
drawImplementation does not execute again...
Did I miss something?
A Callback or so??
Thanks very much for all helps!!
Thanks Gabriel
[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34531#34531
___
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] IVE referenced textures...
Hi Neil, Are you rendering your scene before writing it out to disk? If so then the Optiimizer is enable the osg::Texture::UnRefImageAfterApply() option that is used to cut data usage of the application. Robert. On Mon, Dec 6, 2010 at 9:37 AM, neil.hug...@tesco.net wrote: Hi All, Sorry to bother you but I have an FLT file that references a number of textures via relative paths, and I wish to save this scenegraph as an IVE file, maintaining the relative path references to the textures so that the IVE doesn't become too large. When I save the scene graph as an IVE all my textures disappear. Could anyone suggest what I might be doing wrong please ? Thanks for any help. Kind regards Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release
Hi Tom, On Mon, Dec 6, 2010 at 10:16 AM, Robert Osfield robert.osfi...@gmail.com wrote: I'll have a look at the enum and rename it to something less likely to overlap with other libs over zealous using of #define. I've checked in the renaming of NO to DOES_NOT_FIT_IN_ANY_ROW and YES to FITS_IN_CURRENT_ROW, which are both better descriptions and won't overlap your #defines. An update to svn/trunk will get this change. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation : feeding MorphGeometry into RigGeometry
Arf sorry, I have not seen the link about the attachment :) I will dig into Cedric On Sun, 2010-12-05 at 15:54 +0100, Peter Wrobrl wrote: Hi, I'm feeding a MorphGeometry into RigGeometry, to achieve Character Animation with Facial Morphing. The system works, but it is unclear where to attach the osgAnimation::UpdateMorph. Two cases ( Source Attached ) : 1.) Animation for UpdateMorph does not work GroupRoot ( with BasicAnimtionManager and an animation ) --Skeleton Geode ( with UpdateMorph ) --RigGeometry MorphGeometry ( Morph Base ) --Geometry ( Morph Target ) 2.) Animation Works, but skinned and unskinned ( both morphing ) is Visible GroupRoot ( with BasicAnimtionManager and an animation ) --Skeleton GeodeRig --RigGeometry MorphGeometry ( Instanced bellow ) --GeodeMorph ( with UpdateMorph ) MorphGeometry ( Morph Base ) --Geometry ( Morph Target ) I cannot turn off the NodeMask for the GeodeMorph, as then the UpdateMorph does not calculate. So how can I attach the UpdateMorph so that the skin gets morphed ( before Bone Influence ) and only one geometry been visible ? Btw, Cedric, should a FloatLinearChannel not be rather named morph than 0 ? Moreover, I'm writing out the file, there are issues in reading it back with the osganimationviewer. I'm using SVN Version 2.9.10 Thank you! Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34536#34536 Attachments: http://forum.openscenegraph.org//files/osgmorphskin_102.zip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation : feeding MorphGeometry into RigGeometry
Hi Peter,
I have a fix, but it's not the ideal solution. The idea is to cull the
morph geometry but to update it. In order to do that you can add a cull
callback that does not traverse child.
I have updated your sample to demonstrate the technique. Note you have
to add group in your hierarchy in order the cull callback works, it's
because the cull visitor iterate on drawable geode even if there is a
cull callback that does not traverse. You can see why with more detail
in osgUtil/CullVisitor.cpp:712 but doing it for a group will do the
things and will filter the subgraph only on rednering part.
Another way would be to setup the cull mask traversal but I dont
remember where it must be set.
About the channel '0' it's because the channel is associated to the
index of shape, it has been done like that in the past, it can be a
problem if you have more than one morphGeometry instance on a subgraph
driven by an animation manager. For skinning bones are named so I guess
we would need the same things for morph geometry.
Cheers,
Cedric
On Sun, 2010-12-05 at 15:54 +0100, Peter Wrobrl wrote:
Hi,
I'm feeding a MorphGeometry into RigGeometry, to achieve Character Animation
with Facial Morphing. The system works, but it is unclear where to attach the
osgAnimation::UpdateMorph.
Two cases ( Source Attached ) :
1.) Animation for UpdateMorph does not work
GroupRoot ( with BasicAnimtionManager and an animation )
--Skeleton
Geode ( with UpdateMorph )
--RigGeometry
MorphGeometry ( Morph Base )
--Geometry ( Morph Target )
2.) Animation Works, but skinned and unskinned ( both morphing ) is Visible
GroupRoot ( with BasicAnimtionManager and an animation )
--Skeleton
GeodeRig
--RigGeometry
MorphGeometry ( Instanced bellow )
--GeodeMorph ( with UpdateMorph )
MorphGeometry ( Morph Base )
--Geometry ( Morph Target )
I cannot turn off the NodeMask for the GeodeMorph, as then the UpdateMorph
does not calculate.
So how can I attach the UpdateMorph so that the skin gets morphed ( before
Bone Influence ) and only one geometry been visible ?
Btw, Cedric, should a FloatLinearChannel not be rather named morph than 0
?
Moreover, I'm writing out the file, there are issues in reading it back with
the osganimationviewer.
I'm using SVN Version 2.9.10
Thank you!
Cheers,
ParticlePeter
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34536#34536
Attachments:
http://forum.openscenegraph.org//files/osgmorphskin_102.zip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Provide OpenGL, WebGL and OpenSceneGraph services
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
/* -*-c++-*-
* Copyright (C) 2008 Cedric Pinson morni...@plopbyte.net
*
* 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 iostream
#include osg/Geometry
#include osg/MatrixTransform
#include osg/Geode
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/StateSetManipulator
#include osgUtil/SmoothingVisitor
#include osg/io_utils
#include osgAnimation/RigGeometry
#include osgAnimation/MorphGeometry
#include osgAnimation/BasicAnimationManager
#include osgDB/ReadFile
#include osgDB/WriteFile
struct FilterCullCallback : osg::NodeCallback
{
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
// do nothing and stop traverse
}
};
bool validPointer( osg::Object * pointer , std::string error ) {
if ( pointer ) return true ;
else std::cout error std::endl std::endl ;
return false ;
}
class RigGeometryFinder : public osg::NodeVisitor
{
public :
RigGeometryFinder() : osg::NodeVisitor( osg::NodeVisitor::TRAVERSE_ALL_CHILDREN ) {}
void apply( osg::Geode geode ) {
if ( _rigGeometry.valid() )
return ;
for( unsigned int i = 0 ; i geode.getNumDrawables() ; ++i ) {
osgAnimation::RigGeometry * rigGeometry = dynamic_cast osgAnimation::RigGeometry * ( geode.getDrawable( i ) ) ;
if ( rigGeometry ) {
_rigGeometry = rigGeometry ;
return ;
}
}
}
osgAnimation::RigGeometry * getRigGeometry() {
Re: [osg-users] Cygwin compile
Hi J-S, Jean-Sébastien Guay writes: Hi all, I've got this thing, I like to find and fix build problems. I guess I'll have to get checked by a psychologist sometime. :-) Just for the fun of it, I tried to build OSG on Cygwin today. Has anyone tried that lately, or is anyone using a Cygwin build of OSG regularly? I was until a year ago. Nevertheless, I believe nothing has changed enormously. I was wondering if the goal of a Cygwin build was to act like Windows or act like Linux. I would have thought the latter, but that's not what I saw. Here are the two problems I had. 1. By default, the OpenGL (GL and GLU) libraries that are picked up by cmake are the Windows ones (from the Platform SDK in my install of Visual Studio). That was easily changed by setting them to /usr/lib/libGL.dll.a and /usr/lib/libGLU.dll.a which are the Cygwin ones, but I was wondering if there was something we could do to get the right ones picked up right away, or if it's a cmake thing. 2. The way the CMakeLists.txt in src/osgViewer is written results in CMake picking the GraphicsWindowWin32 implementation, whereas it should pick the X11 one I guess. This was easily fixed too by adding AND NOT CYGWIN to the IF(WIN32) test. Then I also needed it to link to the X11 lib, easily fixed too. I'll submit the changed files once I've got a complete and running build (it's building the plugins now, everything else built fine). Essentially I just wanted to get feedback on this and see if anyone has done this lately or if I'm treading new ground. There are some cygwin ifdefs in the code so I thought this had been done before, but perhaps it's just not been tested recently. Cygwin is aimed to be a UNIX layer to wich you can throw unmodified UNIX source code, compile it, and run it on Windows. All the programs are linked to the cygwin dll, which implements the UNIX API in terms of the Win32 one as faithfully as possible. Certainly you can use the win32 OpenGL library and have working executables, that is what I did in the past until I volunteered to package OSG for cygwin. I was told -- and it makes sense -- that for this library to be included into the cygwin distribution, it would have to behave as a UNIX one, that is, use the X server. I did nothing at that time because the X server was unaccelerated, so there was no sense on having a crippled OSG version out there. A few months ago I saw in the cygwin mailing list that there was an accelerated branch of the X server, so it was on my to do list to check its performance although with a low priority. Another difficult point is CMake behaviour. As you tested, CMake treats cygwin as win32 and UNIX, something that is incorrect for the cygwin developers, and in fact makes more difficult to build mainstream software like KDE or Qt, which have UNIX and Windows targets. To address this, a cygwin developer has modified CMake to treat cygwin as UNIX. The point is not having to consider cygwin as a special case anymore. Unfortunately, CMake developers are reluctant to include all those patches and have only accepted several ones so far. They say they would break old code, including some Kitware's own products, that relied in cygwin being win32+UNIX. IIRC, this is the CMake you will find in the repositories. The modified one is available at cygwin ports. So, to summarise, I think the best strategy for the OSG with respect to cygwin would be to drop all special CYGWIN remarks in the code an let it behave as a UNIX platform. Using that modified cygwin's CMake, it should already possible. After all, for building native win32 OpenGL binaries we already have Mingw available. Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
Hi Robert, Let's leave GPU - CPU transfers aside. I don't mind if they are slow. You usually have to use 2 PBOs. If I use a single PBO to upload texture data to the GPU, performance will be very low. It seems to me I have two ways to do CPU - GPU transfers efficiently. 1) Use 2 differents PBOs. Let glTexImage2D do its job with the first PBO, while I'm loading up new data into the second PBO with the CPU. 2) Use 1 PBO and the method below (feedback?) Code: // Bind PBO glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pbo); Label1: // Request new buffer data (third parameter = NULL) // This call will return immediately. **The GPU will complete any transfer in progress with the previous buffer data**. // As far as the client side is concerned, the new buffer data is immediately available. glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, NULL, GL_STREAM_DRAW_ARB); // Load up new pixels into the same pbo, but into its new buffer data (requested above), not the previous one glMapBuffer // returns immediately, because the GPU isn't doing anything with the new buffer updatePixels glUnmapBuffer // Issue asynchronous transfer to texture glTexImage2D(.., 0); goto Label1; This method above which should work (I think!) will most likely not be supported by OSG at all. I'll have to do things manually. However perhaps I can resort to method 1 and do something by fiddling with two osg::PixelBufferObject objects, two osg::Image objects, creating as many osg::Textures as I want, alternating osg::Texture::setImage(image1) and osg::Texture::setImage(image2), to be sure I am doing CPU and GPU work in parrallel. Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34554#34554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
Hi Fred, I have too much other work on right now to go chasing supports threads at a low level, I have time to point users in roughly the right direction, but then have to get back to work - I have 3.0 to get out the door. Robert. On Mon, Dec 6, 2010 at 1:16 PM, Fred Smith osgfo...@tevs.eu wrote: Hi Robert, Let's leave GPU - CPU transfers aside. I don't mind if they are slow. You usually have to use 2 PBOs. If I use a single PBO to upload texture data to the GPU, performance will be very low. It seems to me I have two ways to do CPU - GPU transfers efficiently. 1) Use 2 differents PBOs. Let glTexImage2D do its job with the first PBO, while I'm loading up new data into the second PBO with the CPU. 2) Use 1 PBO and the method below (feedback?) Code: // Bind PBO glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pbo); Label1: // Request new buffer data (third parameter = NULL) // This call will return immediately. **The GPU will complete any transfer in progress with the previous buffer data**. // As far as the client side is concerned, the new buffer data is immediately available. glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, NULL, GL_STREAM_DRAW_ARB); // Load up new pixels into the same pbo, but into its new buffer data (requested above), not the previous one glMapBuffer // returns immediately, because the GPU isn't doing anything with the new buffer updatePixels glUnmapBuffer // Issue asynchronous transfer to texture glTexImage2D(.., 0); goto Label1; This method above which should work (I think!) will most likely not be supported by OSG at all. I'll have to do things manually. However perhaps I can resort to method 1 and do something by fiddling with two osg::PixelBufferObject objects, two osg::Image objects, creating as many osg::Textures as I want, alternating osg::Texture::setImage(image1) and osg::Texture::setImage(image2), to be sure I am doing CPU and GPU work in parrallel. Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34554#34554 ___ 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] plugin source code
I was looking at submitting a fix for the osg plugin. We use shared arrays (see osgsharedarray example) in the last stable release of OSG. We had a problem writing osg files of our scene because of a static cast in the osg plugin. It assumed it knew what the array was (FloatArray, for example) and cast to it. Our arrays weren't implemented with that, and we crashed. We had a fix where we get the actual array memory out and use that, so it worked with either kind of array. I was going to submit that, but I don't see the problem in the trunk. (I added writing a file to the osgsharedarray example.) So I went to check out Geometry.cpp in the osg plugin, and it isn't there. Seems the plugins have been refactored. Could someone point me to the code equivalent to the Array_writeLocalData function that was in Geometry.cpp in src/osgPlugins/osg before? Is the new code set up to handle shared arrays without assuming what they are? I want to make sure I didn't get lucky with the shared array example. Seems unlikely that the memory would just happen to work, but I figure someone will be familiar with the plugins and can reassure me. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] plugin source code
Hi Andy, The deprecated DotOsgWrappers can now be found in src/osgWrappers/deprecated-dotosg/*/*. Robert. On Mon, Dec 6, 2010 at 2:34 PM, Andy Skinner andy.skin...@mathworks.com wrote: I was looking at submitting a fix for the osg plugin. We use shared arrays (see osgsharedarray example) in the last stable release of OSG. We had a problem writing osg files of our scene because of a static cast in the osg plugin. It assumed it knew what the array was (FloatArray, for example) and cast to it. Our arrays weren’t implemented with that, and we crashed. We had a fix where we get the actual array memory out and use that, so it worked with either kind of array. I was going to submit that, but I don’t see the problem in the trunk. (I added writing a file to the osgsharedarray example.) So I went to check out Geometry.cpp in the osg plugin, and it isn’t there. Seems the plugins have been refactored. Could someone point me to the code equivalent to the Array_writeLocalData function that was in Geometry.cpp in src/osgPlugins/osg before? Is the new code set up to handle shared arrays without assuming what they are? I want to make sure I didn’t get lucky with the shared array example. Seems unlikely that the memory would just happen to work, but I figure someone will be familiar with the plugins and can reassure me. thanks andy ___ 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] osgAnimation : feeding MorphGeometry into RigGeometry
Thanks for your help, this will do for now. However, I would be very interested that this functionality becomes part of osgAnimation, as I am writing on a maya osg exporter. I'll try to look deeper into osgAnimation functionality. The opossite case, morphing two RigGeometries with different Skelettons, is also very usefull. So just for my understanding, a MorphCallback gets attached to a Geode which holds MorphGeometry. Which function searches the Drawables, to link them with the MorphCallback ? Could it be extend it, so that it would also look inside children of RigGeometry ? Got your point with the MorphChannelNames. Thank you! Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34558#34558 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin compile
Hello Alberto, Cygwin is aimed to be a UNIX layer to wich you can throw unmodified UNIX source code, compile it, and run it on Windows. All the programs are linked to the cygwin dll, which implements the UNIX API in terms of the Win32 one as faithfully as possible. That was my impression too. Certainly you can use the win32 OpenGL library and have working executables, that is what I did in the past until I volunteered to package OSG for cygwin. I was told -- and it makes sense -- that for this library to be included into the cygwin distribution, it would have to behave as a UNIX one, that is, use the X server. I did nothing at that time because the X server was unaccelerated, so there was no sense on having a crippled OSG version out there. A few months ago I saw in the cygwin mailing list that there was an accelerated branch of the X server, so it was on my to do list to check its performance although with a low priority. My build finished this weekend, building with the two changes I noted in my first post to make it run on the X server, and it worked well, though it is still running in software OpenGL. I don't know if there is some special thing I need to do to use the accelerated X server, I have found conflicting information on the web, some which said there was nothing special to do which doesn't seem to be true. It's hard from the discussions on online mailing lists/forums to find out if the accelerated X server is done or not at this date. Anyways, my goal in doing this was not to get a fast running app on Windows. I want to get an environment similar to what is used when building Android apps (eventually I'd like to run OSG on Android). The Android NDK uses cygwin with a cross-compiler to build native libraries and JNI interfaces, so my first step was making sure OSG still compiled on Cygwin. Eventually I'll want to build OSG with the NDK's cross-compiler, using the NDK's OpenGL ES 2.0 libraries, and run that on the actual device. The Android emulator doesn't even emulate OpenGL ES 2.0, so I will be forced to use different code paths when testing on my desktop (before deploying), compared to the actual device. So I just wanted to see if it was remotely possible to get OSG on there at all. Another difficult point is CMake behaviour. As you tested, CMake treats cygwin as win32 and UNIX, something that is incorrect for the cygwin developers, and in fact makes more difficult to build mainstream software like KDE or Qt, which have UNIX and Windows targets. To address this, a cygwin developer has modified CMake to treat cygwin as UNIX. The point is not having to consider cygwin as a special case anymore. Unfortunately, CMake developers are reluctant to include all those patches and have only accepted several ones so far. They say they would break old code, including some Kitware's own products, that relied in cygwin being win32+UNIX. IIRC, this is the CMake you will find in the repositories. The modified one is available at cygwin ports. I was using cmake from cygwin, and it still seemed to behave as Win32 (it went into the IF(WIN32) in stc/osgViewer/CMakeLists.txt as I noted in my first post). So, to summarise, I think the best strategy for the OSG with respect to cygwin would be to drop all special CYGWIN remarks in the code an let it behave as a UNIX platform. Using that modified cygwin's CMake, it should already possible. Not sure I want to embark on something like that... This is a hobby project for me (give a programmer any device with a processor, and they'll want to tinker with it to get their programs on it, right? :-) ) Plus, we have no idea if the modified cygwin CMake will ever become the mainstream version... Perhaps it won't if the disagreement stays the way it is. I think a good first step would be to make sure that using the default cmake we get a usable cygwin build that uses the X server. Whether this is accelerated or not doesn't depend on us, and when it becomes accelerated then it'll be even better. After all, for building native win32 OpenGL binaries we already have Mingw available. True. Cygwin fills a different niche, being even closer to Unix on Win32. And I tested the MinGW build of OSG a little while ago so there's no challenge there ;-) Thanks a lot for your input. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Placing an object on VPB (flat) Terrain
Hi, I used osgdem to build a terrain using VPB. I now want to place an object on it whose coordinates would be a random latitude-longitude. I browsed the source and found the ObjectPlacer class. I assume that I will need to use this. But I do not know how to correctly use its place() method objectPlacer.place(vpb::DestinationTile, osg::Node) (do I need to give one of the subtiles .ive as the destinationTile and my object's Node) I looked at the other interface files in the vpb source as well such as DataSet, SourceData, etc but am still confused how to achieve this. Hoping to get some pointers so that I can head in the right direction. Thanks in advance Sincerely, Sanat. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34560#34560 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] plugin source code
Thank you. That also shows me where the new code is--the serializers directory next to the deprecated-dotosg, right? Looks like the equivalent writing code uses a operator on the data. Following that code around to OutputStream.cpp, it looks like the writeArray() method does a static cast of the arrays to ByteArray, FloatArray, etc. I think that's the same problem we had before. But writeArrayImplementation() takes a pointer to the array of actual data. That would work for us. So I _think_ it depends on the particular cast between things like FloatArray and float*. While I look into this, could you tell me if I'm in the correct code? thanks, andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, December 06, 2010 9:46 AM To: OpenSceneGraph Users Subject: Re: [osg-users] plugin source code Hi Andy, The deprecated DotOsgWrappers can now be found in src/osgWrappers/deprecated-dotosg/*/*. Robert. On Mon, Dec 6, 2010 at 2:34 PM, Andy Skinner andy.skin...@mathworks.com wrote: I was looking at submitting a fix for the osg plugin. We use shared arrays (see osgsharedarray example) in the last stable release of OSG. We had a problem writing osg files of our scene because of a static cast in the osg plugin. It assumed it knew what the array was (FloatArray, for example) and cast to it. Our arrays weren't implemented with that, and we crashed. We had a fix where we get the actual array memory out and use that, so it worked with either kind of array. I was going to submit that, but I don't see the problem in the trunk. (I added writing a file to the osgsharedarray example.) So I went to check out Geometry.cpp in the osg plugin, and it isn't there. Seems the plugins have been refactored. Could someone point me to the code equivalent to the Array_writeLocalData function that was in Geometry.cpp in src/osgPlugins/osg before? Is the new code set up to handle shared arrays without assuming what they are? I want to make sure I didn't get lucky with the shared array example. Seems unlikely that the memory would just happen to work, but I figure someone will be familiar with the plugins and can reassure me. thanks andy ___ 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] how do I modify textures of an .IVE
So no one else has ever had to work with a .IVE file and modify the images/textures??? A little help is all I am seeking. I don't know enough about the software to easily modify the textures I am hoping some one here can help. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34562#34562 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how do I modify textures of an .IVE
Hi John, So no one else has ever had to work with a .IVE file and modify the images/textures??? A little help is all I am seeking. I don't know enough about the software to easily modify the textures I am hoping some one here can help. Of course others have had to do this in the past, but Jason's reply was pretty complete and you replied I will try the suggestions you provided and see how that goes. So how did it go? What Jason suggested should lead you to convert the .ive file to .osg (a text format which does not embed textures) with separate referenced texture files. You can then load up those textures in an image editing software and modify them as you like. You can load up the .osg file in osgviewer to check out your modifications as you go. Then once you're happy with the result you would convert the .osg file back to .ive (re-embedding the modified texture files in the .ive file in the process). If this doesn't work for you then you'll have to explain what else you want, because going from the information you gave us this process should work for you. 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] How do I get the most accurate heightfield readingout of an OsgTerrain paged database
Agreed... The terrain is only as accurate as the original source data. -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Glenn Sent: Friday, December 03, 2010 12:30 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] How do I get the most accurate heightfield readingout of an OsgTerrain paged database Greetings! A Word of Caution: that no matter how accurate the HAT is that the reading may be only as accurate as the Terrain used. In my experience making and using terrain, I have found that even some of these high priced terrain builders have their flaws compounded by the fact that most data in the public realm has only a certain level of accuracy. So you’re only going to get a certain level of confidence in relation to the real world figures or even some other forms of map data I have used. Terrain can be such a fickle beast! ... D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34511#34511 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I get the most accurate heightfield reading out of an OsgTerrain paged database
rogerjames99 wrote: Hi Robert, Chris, David Thanks for the quick reply. I have been playing with putting osgTerrain support into VTP. Ben has probably written me off as a heretic! I just wanted to get my placement of procedurally generated buildings a bit more accurate. So performance at that point is not too much of a problem. Gee, if all you want to do is place buildings on terrain, you might want to look into osgTDS (if it's still supported). this is a script language methodology you can use to place buildings, roads and other cultural data on a terrain is OSG. I think you still have to calculate the elevation you want, but it adjusts the terrain so building and stuff appear on the ground. I've never tried it, so I can't say how effective it is, but that’s my shot in the dark on that! D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34566#34566 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] rain/snow accumulation on the screen
robertosfield wrote: Hi Nick, On Wed, Dec 1, 2010 at 10:15 AM, Trajce (Nick) Nikolov wrote: any ideas/hints how to implement rain/snow accumulation on the screen (like for a driving sim)? Bring a laptop to Scotland and sit outside. Right now you'll get an accumulation of snow on the screen. Waiting another week and we might be able to provide an accumulation of rain, although it's likely to ruin the laptop. Still you'd have achieved your mission :-) Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum I spent a winter in Edinburgh as a young boy! Don't care to relive that winter again if I can help it! B, it defined cold for me! Thanks but no Thanks Robert! I guess that I have had all the Scotsman bred out of me in Sothern California, because I’d rather spend my winter near the Med if I got to live in that part of the world! Of course I also had issues with the schooling I got back then also - they maid you learn! D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34567#34567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rotate osg precipitationEffect effect
Hi, ... I need to snow coming form horizontal direction not from vertical direction. But so far didnt succeed. I tried to rotate but it is not rotating. I try to change the wind thts not working as well. How can i do it? Thank you! Cheers, Aruna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34568#34568 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release
Hi Robert I've checked in the renaming of NO to DOES_NOT_FIT_IN_ANY_ROW and YES to FITS_IN_CURRENT_ROW, which are both better descriptions and won't overlap your #defines. An update to svn/trunk will get this change. Thanks, that did the trick, clean builds on Windows and IOS now. This release must put you well on track for the version 3.0 release. Good luck. Cheers Tom ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
Hi Fred, what bandwidth are you trying to achieve? We've had no issues with updating multiple osg Images from camera input with just a PBO attached as per e.g.: osg_image_buffer[i]-setPixelBufferObject(new osg::PixelBufferObject(osg_image_buffer[i].get())); where osg_image_buffer[i] is a ref_ptr to osg::Image. jp On 06/12/10 15:16, Fred Smith wrote: Hi Robert, Let's leave GPU - CPU transfers aside. I don't mind if they are slow. You usually have to use 2 PBOs. If I use a single PBO to upload texture data to the GPU, performance will be very low. It seems to me I have two ways to do CPU - GPU transfers efficiently. 1) Use 2 differents PBOs. Let glTexImage2D do its job with the first PBO, while I'm loading up new data into the second PBO with the CPU. 2) Use 1 PBO and the method below (feedback?) Code: // Bind PBO glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pbo); Label1: // Request new buffer data (third parameter = NULL) // This call will return immediately. **The GPU will complete any transfer in progress with the previous buffer data**. // As far as the client side is concerned, the new buffer data is immediately available. glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, NULL, GL_STREAM_DRAW_ARB); // Load up new pixels into the same pbo, but into its new buffer data (requested above), not the previous one glMapBuffer // returns immediately, because the GPU isn't doing anything with the new buffer updatePixels glUnmapBuffer // Issue asynchronous transfer to texture glTexImage2D(.., 0); goto Label1; This method above which should work (I think!) will most likely not be supported by OSG at all. I'll have to do things manually. However perhaps I can resort to method 1 and do something by fiddling with two osg::PixelBufferObject objects, two osg::Image objects, creating as many osg::Textures as I want, alternating osg::Texture::setImage(image1) and osg::Texture::setImage(image2), to be sure I am doing CPU and GPU work in parrallel. Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34554#34554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
