[osg-users] How to construct an instance of osgviewer::viewer from osgviewer::view?
Hi, How to construct an instance of osgviewer::viewer from osgviewer::view? I know osgviewer::compositeViewer has an interface compositeviewer::addView(), which can be used to assign view instance to compositeViewer. However, i don't find any similar interface in osgviewer::viewer. Rogerz 2010-04-13 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multicard memory allocation?
Hi robert,
Thanks for ur clarification. In our setup, all powerwall displays
are of 1280*1024. I m rendering a texture of 1280*1024 with the cameras
viewport set in such a way it will be projected on big screen as 1280*1024.
That means, as 512*1024 I m creating 3 textures(last one is 256*1024). Each
texture is set to one context/card and camera. The offset of each texture is
0, 512, 1024 respectively(viewport setup). But I get display on screen as 3
textures more space between them as seen in my powerwall display. I understand
dat as I set texture to different context, my offset setting goes wrong. But I
want to make use of all cards available in my system. What needs to be done to
get merged single display out of my powerwall display? I attach my code as well
for the reference.
Code:
#define NSCREEN 3
#define SCREEN_HEIGHT 1024
//OSG related var
osg::Texture2D* texture[NSCREEN];
osg::ref_ptrosgText::Text latLonDisp;
osg::Image* image[NSCREEN];
osg::MatrixTransform* mt;
osg::Matrix rotate;
double rot_angle=180.f;
//
//
// Function Defn: Create tecture to the specified view and width
//
osg::Camera* createTex(int nView, int width)
{
double right = 0.5 * width;
double top = 0.5 * SCREEN_HEIGHT;
osg::Camera* camera = new osg::Camera;
camera-setProjectionMatrix(osg::Matrix::ortho2D(-right, right, -top,
top));
//camera-setViewMatrixAsLookAt(osg::Vec3(0.0,0.0,0.0),osg::Vec3(0.0,1.0,0.0),osg::Vec3(0.0,0.0,1.0));
camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
camera-setRenderOrder(osg::Camera::POST_RENDER);
camera-setAllowEventFocus(false);
{
osg::Geode* geode = new osg::Geode();
std::string timesFont(fonts/arial.ttf);
osg::StateSet* stateset = geode-getOrCreateStateSet();
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
{
osg::Geometry* geom = new osg::Geometry;
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-right, top,0.f));
vertices-push_back(osg::Vec3(-right, -top,0.f));
vertices-push_back(osg::Vec3(right, -top, 0.f));
vertices-push_back(osg::Vec3(right, top, 0.f));
geom-setVertexArray(vertices);
osg::Vec2Array* texcoords = new osg::Vec2Array(4);
(*texcoords)[0].set(0.0f,1.0f);
(*texcoords)[1].set(0.0f,0.0f);
(*texcoords)[2].set(1.0f,0.0f);
(*texcoords)[3].set(1.0f,1.0f);
geom-setTexCoordArray(0,texcoords);
osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0.0f,0.0f,1.0f));
geom-setNormalArray(normals);
geom-setNormalBinding(osg::Geometry::BIND_OVERALL);
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0f,1.0,1.0f,1.0f));
geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
geom-addPrimitiveSet(new osg::DrawArrays(GL_QUADS,0,4));
texture[nView] = new osg::Texture2D;
texture[nView]-setName(TEXTURE);
texture[nView]-setDataVariance(osg::Object::DYNAMIC); // protect
from being optimized away as static state.
texture[nView]-setResizeNonPowerOfTwoHint(false);
// Setting buffer
image[nView] = new osg::Image;
image[nView]-setName(BUFFER);
image[nView]-setOrigin(osg::Image::BOTTOM_LEFT);
image[nView]-setImage(width, SCREEN_HEIGHT, 1, GL_LUMINANCE,
GL_LUMINANCE, GL_UNSIGNED_BYTE,buf[nView], osg::Image::NO_DELETE);
texture[nView]-setImage(image[nView]);
osg::StateSet* stateset = geom-getOrCreateStateSet();
stateset-setTextureAttributeAndModes(0,texture[nView],osg::StateAttribute::ON);
stateset-setMode(GL_BLEND,osg::StateAttribute::ON);
stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
// Rotate the texture to 180 degree
mt = new osg::MatrixTransform;
//rotate.makeRotate(osg::inDegrees(0.0), 1.0, 0.0, 0.0);
mt-setMatrix(osg::Matrix::rotate(osg::inDegrees(rot_angle), 1.0,
0.0, 0.0));
mt-addChild(geode);
geode-addDrawable(geom);
}
camera-addChild(mt);
}
return camera;
}
void main()
{
{
// construct the viewer.
osgViewer::CompositeViewer viewer;
// create the main
Re: [osg-users] Camera Manipulator initial camera pos/orientation
Ted Morris writes: Hi, I need to set an initial viewpoint of my camera manipulators with respect to the local coordinate system of the object. What is the best way to go about that? Hi Ted, I think that osg::Node::getWorldMatrices and osgGA::MatrixManipulator::setHomePosition can help you to do what you are looking for. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] fatal error on simple programm
Hi, finally I found the bug. The build framework was using the /MTd libc parameter per default. Adding OSG (which seems to force the use of /MDd libc) caused the heap corruption. Cheers, lexar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26701#26701 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX plugin with FBX SDK 2011.2
The FBX plugin is written for version 2010.2 of the SDK. That version is still available in the SDK Archives page on Autodesk's website. I'll look into getting 2011.2 working, cheers. On 12 April 2010 20:03, Doug McCorkle mc...@iastate.edu wrote: Hello, Has anyone gotten the FBX plugin to build with the FBX SDK version 2011.2? If so what version of OSG are you using? http://usa.autodesk.com/adsk/servlet/pc/mform_proc Thanks. Doug ___ 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] osgIntrospection serialization
Hi Paul, In OpenSceneGraph svn/trunk and the 2.9.x there is a dedicated serializer support now located in osgDB, and would recommend using this over osgIntrospection. The new native .osgt (ascii text), osgb (binary) and .osgx (xml) file formats all use this serializer support, and it's possible to write you own custom streams for handling the data. This has already been used by a user to serializer data over a cluster. Robert. On Mon, Apr 12, 2010 at 6:44 PM, Paul Gotzel paul.got...@us.cd-adapco.com wrote: Hello, osgIntrospection namespace documentation and the osgintrospection.cpp example gives some hints about automatic serialization. Is there any more information about this? I'm interested in possibly using this to serialize some or all of the scene graph to an in memory (compressed?) structure that could then be rehydrated later. Ultimately, I want to use this for cross process synchronization. Thoughts? Am I looking in the wrong area? Could I use the osgDB in a similar way? -- Paul Gotzel ___ 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] Solaris build errors
Hi Chris, I've just looked at the lines of the error being reported and compared to Qt lines and it seems to be the problem in reverse - our code is converting a GLchar* to a std::string via an assignment. This would suggest the case would need to be to the std::string char type or using a templated copy. I don't have Solaris to compile against so I'll have to defer to you to find a workable solution. Robert. On Tue, Apr 13, 2010 at 6:07 AM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: From a client trying to build 2.9.7 on Solaris 10, 64-bit: OpenSceneGraph/src/osg/GL2Extensions.cpp, line 2161: Error: Cannot assign unsigned char* to std::string without std::string::operator=(const std::string );. OpenSceneGraph/src/osg/GL2Extensions.cpp, line 2178: Error: Cannot assign unsigned char* to std::string without std::string::operator=(const std::string );. OpenSceneGraph/src/osg/GL2Extensions.cpp, line 2197: Error: Formal argument name of type const unsigned char* in call to osg::GL2Extensions::glGetAttribLocation(unsigned, const unsigned char*) const is being passed const char*. OpenSceneGraph/src/osg/GL2Extensions.cpp, line 2220: Error: Formal argument name of type const unsigned char* in call to osg::GL2Extensions::glGetFragDataLocation(unsigned, const unsigned char*) const is being passed const char*. This is apparently a known problem in Solaris' OpenGL, as shown by the Qt patch cited below: http://qt.gitorious.org/~nordellj/qt/qt-chloride/commit/6b628fb9754629cc8cdd5718edec296b02ab3b0e?diffmode=sidebyside I'm afraid a specific cast is probably the only way to fix it (which is what the Qt folks did). I don't think there's any way to disable compiling of this code through CMake configuration. I can try to make a fix for this, but I'm not at the Solaris box myself, and I wanted to check with the opinions of the rest of the group first. Anyone else experienced this? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to construct an instance of osgviewer::viewer from osgviewer::view?
Hi Rogerz, osgViewer::Viewer is a subclassed from View, and while there isn't a direct assignment operator from a view to a viewer, you can take the settings from one View to a Viewer using the viewer.take(*viewPointer); Robert. On Tue, Apr 13, 2010 at 7:51 AM, myth0904 myth0...@gmail.com wrote: Hi, How to construct an instance of osgviewer::viewer from osgviewer::view? I know osgviewer::compositeViewer has an interface compositeviewer::addView(), which can be used to assign view instance to compositeViewer. However, i don't find any similar interface in osgviewer::viewer. Rogerz 2010-04-13 ___ 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] Multicard memory allocation?
Hi Akilan,
I'm afraid I can't really easily parse your paragraph in form that
easily sense to me. What you are trying to do is almost certainly
straight forward - the OSG has been used for many years on powerwalls
and more complex setups, including by myself. I can point you in
roughly the right direction but I can't code things for you.
Robert.
On Tue, Apr 13, 2010 at 8:03 AM, Akilan Thangamani
akilan.thangam...@gmail.com wrote:
Hi robert,
Thanks for ur clarification. In our setup, all powerwall
displays are of 1280*1024. I m rendering a texture of 1280*1024 with the
cameras viewport set in such a way it will be projected on big screen as
1280*1024. That means, as 512*1024 I m creating 3 textures(last one is
256*1024). Each texture is set to one context/card and camera. The offset of
each texture is 0, 512, 1024 respectively(viewport setup). But I get
display on screen as 3 textures more space between them as seen in my
powerwall display. I understand dat as I set texture to different context,
my offset setting goes wrong. But I want to make use of all cards available
in my system. What needs to be done to get merged single display out of my
powerwall display? I attach my code as well for the reference.
Code:
#define NSCREEN 3
#define SCREEN_HEIGHT 1024
//OSG related var
osg::Texture2D* texture[NSCREEN];
osg::ref_ptrosgText::Text latLonDisp;
osg::Image* image[NSCREEN];
osg::MatrixTransform* mt;
osg::Matrix rotate;
double rot_angle=180.f;
//
//
// Function Defn: Create tecture to the specified view and width
//
osg::Camera* createTex(int nView, int width)
{
double right = 0.5 * width;
double top = 0.5 * SCREEN_HEIGHT;
osg::Camera* camera = new osg::Camera;
camera-setProjectionMatrix(osg::Matrix::ortho2D(-right, right, -top,
top));
//camera-setViewMatrixAsLookAt(osg::Vec3(0.0,0.0,0.0),osg::Vec3(0.0,1.0,0.0),osg::Vec3(0.0,0.0,1.0));
camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
camera-setRenderOrder(osg::Camera::POST_RENDER);
camera-setAllowEventFocus(false);
{
osg::Geode* geode = new osg::Geode();
std::string timesFont(fonts/arial.ttf);
osg::StateSet* stateset = geode-getOrCreateStateSet();
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
{
osg::Geometry* geom = new osg::Geometry;
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-right, top,0.f));
vertices-push_back(osg::Vec3(-right, -top,0.f));
vertices-push_back(osg::Vec3(right, -top, 0.f));
vertices-push_back(osg::Vec3(right, top, 0.f));
geom-setVertexArray(vertices);
osg::Vec2Array* texcoords = new osg::Vec2Array(4);
(*texcoords)[0].set(0.0f,1.0f);
(*texcoords)[1].set(0.0f,0.0f);
(*texcoords)[2].set(1.0f,0.0f);
(*texcoords)[3].set(1.0f,1.0f);
geom-setTexCoordArray(0,texcoords);
osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0.0f,0.0f,1.0f));
geom-setNormalArray(normals);
geom-setNormalBinding(osg::Geometry::BIND_OVERALL);
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0f,1.0,1.0f,1.0f));
geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
geom-addPrimitiveSet(new osg::DrawArrays(GL_QUADS,0,4));
texture[nView] = new osg::Texture2D;
texture[nView]-setName(TEXTURE);
texture[nView]-setDataVariance(osg::Object::DYNAMIC); // protect
from being optimized away as static state.
texture[nView]-setResizeNonPowerOfTwoHint(false);
// Setting buffer
image[nView] = new osg::Image;
image[nView]-setName(BUFFER);
image[nView]-setOrigin(osg::Image::BOTTOM_LEFT);
image[nView]-setImage(width, SCREEN_HEIGHT, 1, GL_LUMINANCE,
GL_LUMINANCE, GL_UNSIGNED_BYTE,buf[nView], osg::Image::NO_DELETE);
texture[nView]-setImage(image[nView]);
osg::StateSet* stateset = geom-getOrCreateStateSet();
stateset-setTextureAttributeAndModes(0,texture[nView],osg::StateAttribute::ON);
stateset-setMode(GL_BLEND,osg::StateAttribute::ON);
stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
// Rotate the texture to 180 degree
mt = new osg::MatrixTransform;
//rotate.makeRotate(osg::inDegrees(0.0), 1.0, 0.0, 0.0);
mt-setMatrix(osg::Matrix::rotate(osg::inDegrees(rot_angle), 1.0,
0.0, 0.0));
mt-addChild(geode);
geode-addDrawable(geom);
}
camera-addChild(mt);
Re: [osg-users] osgIntrospection serialization
Hi, yepp ;) contact me on further questions Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26710#26710 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render to VBO?
Dear All, Does OSG support rendering to a Vertex Buffer Object? I'm happy with regular texture RTT, but is rendering to VBO as simple as this: camera-setRenderTargetImplementation(osg::CameraNode::FRAME_BUFFER_OBJECT); camera-attach(osg::CameraNode::COLOR_BUFFER, m_texture); where m_texture's image is pointing to a vertex buffer? e.g. something like m_vertex = (osg::Vec4f*) new osg::Vec4f[m_nx * m_ny]; m_vertexArray = new osg::Array(m_nx * m_ny, m_vertex); m_texture-setImage(m_vertex) ? Does this (apparently simple) operation ensure that the VBO stays entirely on the GPU, and doesn't do a round trip via the driver/CPU? Thanks all, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to improve lighting - headlight brighter
Hi, here is a screenshot of my scene, iam using the standard headlight how can i improve the brightness ive already implemented a light source too... light-setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f)); light-setDiffuse(osg::Vec4(1.0f,1.0f,1.0f,1.0f)); light-setSpecular(osg::Vec4(1.0f,1.0f,1.0f,1.0f)); can anybody help? Thank you! Cheers, Matthias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26713#26713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to VBO?
Hi David, On Tue, Apr 13, 2010 at 12:08 PM, David Spilling david.spill...@gmail.com wrote: Does OSG support rendering to a Vertex Buffer Object? Not yet... I'm happy with regular texture RTT, but is rendering to VBO as simple as this: camera-setRenderTargetImplementation(osg::CameraNode::FRAME_BUFFER_OBJECT); camera-attach(osg::CameraNode::COLOR_BUFFER, m_texture); We might be able to engineer the osg::Camera interface to take an osg::Array as input rather than a osg::Image or osg::Texture, but... it would require quite a bit of work on the backend to support it. I haven't tried rendering to VBO before but it's my understanding that the technique used to render to FBO, then copy the appropriate buffer to PBO, then re-assign this PBO as a VBO. You might be able to implement this right now using a post draw callback attached to an osg::Camera set up as at RTT to FRAME_BUFFER_OBJECT. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and XVideo
Hi all, Anyone knows how to use the XVideo extension under Linux : http://en.wikipedia.org/wiki/X_video_extension It says it can be used with an OpenGL pbuffer, does it mean we can use it to accelerate the rendering of a video on a classic texture ? Thanks in advance for any help on this subject. Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Error with osgOcean-VBO Example!
Hi Nick, Sorry chap, I'm afraid not. I haven't had the time to sit down with it for a while. Kim. On 12 April 2010 18:10, Trajce (Nick) Nikolov nikolov.tra...@gmail.com wrote: Hi Kim, any progress on this? -Nick On Tue, Apr 6, 2010 at 10:09 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Kim, Just got round to looking at this stack trace and I can't find any references to osg::GLBufferObject in the 2.8.2 code. What version of OSG were you running when you got the crash? I'll see if I can reproduce it. I was running it on SVN trunk (2.9.8 right now). That would seem to indicate that the new buffer object pools are tripping up osgOcean... 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX plugin with FBX SDK 2011.2
Hello Michael, On Apr 13, 2010, at 3:45 AM, Michael Platings wrote: The FBX plugin is written for version 2010.2 of the SDK. OK. That version is still available in the SDK Archives page on Autodesk's website. Right, I have been grabbing these but wanted to check and see if it was supported on a new version of OSG. I'll look into getting 2011.2 working, cheers. Wow! Thanks. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to VBO?
Hi Robert I haven't tried rendering to VBO before but it's my understanding that the technique used to render to FBO, then copy the appropriate buffer to PBO, then re-assign this PBO as a VBO. You might be able to implement this right now using a post draw callback attached to an osg::Camera set up as at RTT to FRAME_BUFFER_OBJECT. Thanks, I will try this. I was really wondering if anything had been done since the conversation between you and Art Tevs from osg-submissions, 28/11/08 (thread entitled General PBO implementation for GPU only memory handling (usefull for CUDA interoperability)), in which Art said: This shouldn't be a big problem. The good thing with PBOs is that just changing its target will change its functionality. Hence I think, it shouldn't be a big issue to just bind the PBO as VBO before one does need it (assuming there is correct data in the PBO). I'll let you know how I get on, if I get anywhere at all. Best regards, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to VBO?
One other thought - is this render to FBO/copy to PBO/assign as VBO method likely to be any faster than rendering to texture and then using vertex texture fetch? I guess the answer will be just to try it and see... Regards, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to VBO?
Hi David, On 13/04/10 15:03, David Spilling wrote: Hi Robert I haven't tried rendering to VBO before but it's my understanding that the technique used to render to FBO, then copy the appropriate buffer to PBO, then re-assign this PBO as a VBO. You might be able to implement this right now using a post draw callback attached to an osg::Camera set up as at RTT to FRAME_BUFFER_OBJECT. Thanks, I will try this. I was really wondering if anything had been done since the conversation between you and Art Tevs from osg-submissions, 28/11/08 (thread entitled General PBO implementation for GPU only memory handling (usefull for CUDA interoperability)), in which Art said: This shouldn't be a big problem. The good thing with PBOs is that just changing its target will change its functionality. Hence I think, it shouldn't be a big issue to just bind the PBO as VBO before one does need it (assuming there is correct data in the PBO). I'll let you know how I get on, if I get anywhere at all. you can also maybe look at this thread for some examples of PBO use in a callback: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp Best regards, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgIntrospection serialization
Hi Paul,
I intended to use osgIntrospection to provide scripting functionality to my
software. As I dived in deeper into osgIntrospection, I recognized that this
framework is quite complicated. After lots of reading forum posts and
discussions, I learned that this part of osg was once contributed to osg by a
third party. This person is any longer active in the osg community, so Robert
is thinking about removing osgIntrospection from the core project, as soon as
any other technique is available.
As far as I know, the wrapper definitions of osgIntrospection are created semi
automatically. This seem to cause lots of trouble. Robert assumed that manual
wrapper definition and maintenance would be easier.
Now osgDB::Serializer enters the game: Wang wrote it to allow file formats
which can grow with the project. The old .osg and .ive format was hard coded,
so later added node classes could not be saved to file/stream.
In the new format, all classes have the usual class definition with members and
attributes. For the serializer, all classes provide now additionally set/get
functions for all members with a well defined signature AND they contain a
macro call which connects all members and there set/get functions.
To serialize nodes is now easy: Using predefined osg nodes you can serialize in
one step, because all get/set functions and the MACRO call is implemented
already. (you have to use at least 2.9.7)
If you use one transportcontainsers, you have to define you transport
container, the getters/setter and the serializer macro.
Please note that my transport container node holds other customs nodes, so they
are build in that serializer compatible way too. (not listed below)
Regarding namespace: osgDB::serializer requires namespace usage! My application
did not use namespace before, but I added it for the serializer and it works )
In detail, why do you want to use osgIntrospection? For serializing nodes or
for scripting abilities? I would recommend you to try solving your issue with
the “new” technique, because this will give your software a guaranteed future
(at least more the using osgIntrospection, I assume)
I myself would be happy if the serializer functionality would get a
corresponding wrapper functionality.
Maybe this could be realized by specifying the function signatures via calling
them with a Macro. (only a fiorst simple approach of myself to that topic)
Well , I hope I could help you, don’t hesitate to ask.
I will post this email additionally in our thread in the forum to participate
other persons in that discussion.
Best regards from Salzburg,
Torben
My example dataIO_transportContainer.cpp:
#include dataIO_transportContainer.h
#include osgDB/ObjectWrapper
#include osgDB/InputStream
#include osgDB/OutputStream
REGISTER_OBJECT_WRAPPER( dataIO_transportContainer, // The
unique wrapper name
new osgVisual::dataIO_transportContainer,
// The proto
osgVisual::dataIO_transportContainer,
// The class typename
osg::Object
osgVisual::dataIO_transportContainer ) // The inheritance relations
{
ADD_INT_SERIALIZER( FrameID, 0 );
ADD_MATRIXD_SERIALIZER( ViewMatrix, osg::Matrixd() );
ADD_LIST_SERIALIZER( Executer,
osgVisual::dataIO_transportContainer::executerList );
ADD_LIST_SERIALIZER( IOSlots,
osgVisual::dataIO_transportContainer::slotList );
}
My example dataIO_transportContainer.h:
#pragma once
/* -*-c++-*- osgVisual - Copyright (C) 2009-2010 Torben Dannhauer
*
* This library is based on OpenSceneGraph, 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.
*
* osgVisual requires for some proprietary modules a license from the
correspondig manufacturer.
* You have to aquire licenses for all used proprietary modules.
*
* 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 osg/Object
#include osg/Matrixd
#include dataIO_executer.h
#include dataIO_slot.h
#include vector
namespace osgVisual {
class dataIO_transportContainer : public osg::Object
{
public:
META_Object(osgVisual,dataIO_transportContainer);// Required for
serializer
dataIO_transportContainer(const osgVisual::dataIO_transportContainer
tC_, const osg::CopyOp copyop=osg::CopyOp::SHALLOW_COPY): // Required for
serializer
Object(tC_,copyop),
frameID(tC_.frameID),
viewMatrix(tC_.viewMatrix),
executer(tC_.executer),
Re: [osg-users] Render to VBO?
David,
I think this just a simple matter of doing the following:
class VBO : public osg::NodeVisitor {
public:
virtual void apply(osg::Geode geode) {
for (osg::Geode::DrawableList::const_iterator itr =
geode.getDrawableList().begin();
itr != geode.getDrawableList().end();
++itr) {
(*itr)-setUseVertexBufferObjects(true);
}
}
};
VBO vboMode;
root-traverse(vboMode);
This will convert your scene graph to use vbo's if the card supports
it.
Cheers,
Paul
David Spilling wrote:
Dear All,
Does OSG support rendering to a Vertex Buffer Object?
I'm happy with regular texture RTT, but is rendering to VBO as simple
as this:
camera-setRenderTargetImplementation(osg::CameraNode::FRAME_BUFFER_OBJECT);
camera-attach(osg::CameraNode::COLOR_BUFFER, m_texture);
where m_texture's "image" is pointing to a vertex buffer? e.g.
something like
m_vertex = (osg::Vec4f*) new osg::Vec4f[m_nx * m_ny];
m_vertexArray = new osg::Array(m_nx * m_ny, m_vertex);
m_texture-setImage(m_vertex)
?
Does this (apparently simple) operation ensure that the VBO stays
entirely on the GPU, and doesn't do a round trip via the driver/CPU?
Thanks all,
David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Problems with resizing
Hi,
I'm looking for a solution to this problem as well. I built a pipeline (a very
simple one) like so:
Code:
osg::Group* ogrpDoNotBlurTheScene(osg::Camera* camera, osg::Node* glowedScene,
unsigned tex_width, unsigned tex_height, unsigned windowWidth,
unsigned windowHeight, osg::Camera::RenderTargetImplementation
renderImplementation,
osg::ref_ptrosgPPU::Processor p_ppuProcessor,
osg::ref_ptrosgPPU::UnitOut noBlurOutUnit)
{
// this group will house the osgPPU pipeline units
osg::Group* group = new osg::Group;
group-setName(NoBlurringEffect);
// create the texture which will hold the usual view or scene
osg::Texture* textureView = createRenderTextureWrks(windowWidth,
windowHeight);
// setup the camera, which will render the usual scene into the above
// allocated texture
camera-setViewport(new osg::Viewport(0,0,windowWidth,windowHeight));
camera-attach(osg::Camera::COLOR_BUFFER0, textureView);
camera-setRenderTargetImplementation(renderImplementation);
// setup osgPPU pipeline processor, which will use the main camera
// this code allows teh processor to have access to the main camera's
// texture output but it does NOT actually get that texture and put
// it into the pipeline. It only makes that texture output from the
// camera available for retrieval.
osg::ref_ptrosgPPU::Processor processor = new osgPPU::Processor();
processor-setName(ProcessorForNormalScene);
processor-setCamera(camera);
p_ppuProcessor = processor;
// setup unit which will bring the output of the camera into the scene
// UnitCameraAttachmentBypass is the unit that actually gets the output
// texture of a camera and brings it into the pipeline so that that
// texture may be further manipulated. It must be a direct child of the
// processor unit to accomplish feat.
osgPPU::UnitCameraAttachmentBypass* ucaByPass = new
osgPPU::UnitCameraAttachmentBypass();
ucaByPass-setBufferComponent(osg::Camera::COLOR_BUFFER0);
ucaByPass-setName(mainCamOutputTexUCAB);
processor-addChild(ucaByPass);
// This unit of type UnitOut is required so that any data passed to it is
// output to the frame buffer object. It must be the LAST unit of the
// pipeline.
// A key point is the glsl (openGL Shader Language) line:
// gl_FragColor=texture2D(textureNameInShader,gl_TexCoord[0].st);\n
// this ine takes the incoming texture and causes it to be the the
// output texture without modifying that texture. It construsts a
// simple pass-through.
// Notice that the output viewport is the SAME SIZE AS the viewport
// of the camera's viewport.
osgPPU::UnitOut* unitOut2= new osgPPU::UnitOut();
osgPPU::ShaderAttribute* shaderAttribute= new osgPPU::ShaderAttribute();
{
osg::Shader* shader= new osg::Shader(osg::Shader::FRAGMENT);
const char* shaderSource=
uniform sampler2D textureNameInShader;\n
void main()\n
{\n
gl_FragColor=texture2D(textureNameInShader,gl_TexCoord[0].st);\n
};
shader-setShaderSource(shaderSource);
shaderAttribute-addShader(shader);
shaderAttribute-setName(nomShaderAttribute);
shaderAttribute-add(textureNameInShader, osg::Uniform::SAMPLER_2D);
shaderAttribute-set(textureNameInShader, 0);
unitOut2-setName(finalOutputUnit);
unitOut2-setViewport(new osg::Viewport(0,0, windowWidth, windowHeight) );
unitOut2-getOrCreateStateSet()-setAttributeAndModes(shaderAttribute);
}
noBlurOutUnit = unitOut2;
// this line sends the output of ucaByPass into unitOut2, the final
// destination frame buffer object
ucaByPass-addChild(unitOut2);
// return osgPPU pipeline as a group and put the processor in that group
// as a child.
group-addChild(processor);
return group;
}
and in another section of code, after the pipeline is built and the viewer is
running, I call a routine to handle the resize event of my window like so:
Code:
class CMyWindowSizeHandler : public osgViewer::WindowSizeHandler
{
public:
osgViewer::Viewer *viewer; // not needed
osgPPU::UnitOut *unitOut2NoBlur;
osg::ref_ptrosg::Switch m_oswBlur;
osg::ref_ptrosg::Switch m_oswNoBlur;
osg::ref_ptrosgPPU::Processor processor;
CMyWindowSizeHandler(osgViewer::Viewer *v, osgPPU::UnitOut
*p_unitOut2NoBlur,
osg::ref_ptrosgPPU::Processor p_ppuProcessor) :
viewer(v) , unitOut2NoBlur(p_unitOut2NoBlur), processor(p_ppuProcessor)
{
std::cout ctored win sz hdl\n;
} // ctor
bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapteraa)
{
extern osg::Texture* createRenderTextureWrks(int tex_width, int
tex_height);
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::RESIZE):
{
std::cout window resized std::endl;
[osg-users] Incorrect Producer link in wiki
Hi, I've found the link to OpenProducer on the Integration with GUI Toolkits (http://www.openscenegraph.org/projects/osg/wiki/Community/WindowingToolkits) wiki page is incorrect. I believe the corrected link should be: http://www.andesengineering.com/Producer/index.php?main=download.php Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26730#26730 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Incorrect Producer link in wiki
Thanks Curtis, link now updated. On Tue, Apr 13, 2010 at 3:24 PM, Curtis Schroeder c.schroe...@ieee.org wrote: Hi, I've found the link to OpenProducer on the Integration with GUI Toolkits (http://www.openscenegraph.org/projects/osg/wiki/Community/WindowingToolkits) wiki page is incorrect. I believe the corrected link should be: http://www.andesengineering.com/Producer/index.php?main=download.php Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26730#26730 ___ 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] Optimizer improvements
Hi everyone, Recently I've noticed some issues with the optimizer which I'd like to fix. However, I'd like to request some feedback on what the best course would be. I have a file like this Code: Group Transform Group (UniqueID 1) Geode 1 StateSet (UniqueID 2) Geometry 1 Geode 2 StateSet (UniqueID 2) Geometry 2 Geode 3 StateSet (UniqueID 2) Geometry 3 Transform Group (UniqueID 1) I would like to optimize this to: Code: Group Geode StateSet Geometry It is not possible to do this in a single pass with the optimizer. Using optimizer settings FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS MERGE_GEODES MERGE_GEOMETRY REMOVE_REDUNDANT_NODES COPY_SHARED_NODES gets me quite far: Code: Group Geode StateSet Geometry 1 Geometry 2 Geometry 3 Geometry 4 Geometry 5 Geometry 6 , but the final geometry nodes aren't merged because the Geometry is still sharing the same vertex arrays (1 and 4, 2 and 5, 3 and 6). The COPY_SHARED_NODES setting helps to reduce the different nodes (because they are then merged), but it doesn't do anything to the data inside Geode nodes. Note that if I save the last file to disk, and then reconvert with the same optimizer settings, then the contents of the geometries is fully written to file, and on the second conversion OSG doesn't know that the geometries were linked, so happily merges them. The 'correct' solution I think is to add a function to CopySharedSubgraphsVisitor that also duplicates the contents of a Geode node. After that the MERGE_GEOMETRY setting should kick in and merge the resulting geometries into a single geometry. I hope someone can give me some input on the best way to handle this issue. If I wasn't clear enough about the problem, please let me know and I can post a complete osg file. Thank you! Cheers, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26734#26734 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] OSG Training This Year?
Hi Lee, where are you located? Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26735#26735 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to VBO?
Paul, Thanks for your input, but I think you've misunderstood me. I already use VBOs quite happily. The question is whether you can use a pre-render pixel stage to render directly into the vertex buffer (the technique is sometimes abbreviated RTVB); i.e. to use a fragment/pixel shader to populate vertex array data. Anyway, I've got plenty to go on now, thanks to all for your help. Best regards, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Use namespace...
Hi, Just curious, I noticed that in a lot of the code, we use stuff like osg::someFunctio() and etc... Could we use a namespace using namespace osg; to avoid having to write osg:: every single time? THANKS!! -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use namespace...
Yes you can, however OSG uses simple names that will likely also be used in other projects (e.g. Array, Node, Group etc.) so it's quite likely you'll get name conflicts if you use another library which uses the same class names. I've had developers making similar complaints to me, so as a compromise we do using somenamespace::SomeClass; using somenamespace::SomeFunction; etc. for things that are used very frequently. That way it will be less of a big deal to change the code if we start using a library that uses the same class names. On 13 April 2010 17:12, mas oug mas...@gmail.com wrote: Hi, Just curious, I noticed that in a lot of the code, we use stuff like osg::someFunctio() and etc... Could we use a namespace using namespace osg; to avoid having to write osg:: every single time? THANKS!! -Masoug ___ 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] Use namespace...
I have found it much safer/easier (in the long run) to not collapse the namespaces. It's a lot of trouble to go back and correct the problem when you start integrating other toolkits. Just my 2 cents worth. On 13 April 2010 17:12, mas oug mas...@gmail.com wrote: Hi, Just curious, I noticed that in a lot of the code, we use stuff like osg::someFunctio() and etc... Could we use a namespace using namespace osg; to avoid having to write osg:: every single time? THANKS!! -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nvidia Quadro Cards, and Nice Touch Pannals!
David Glenn wrote: I also went by the Microsoft booth and saw a Touch Panel that was designed for Windows 7 that was fun to play with. I talked to the maker about interfacing it to an OSG app. He said it was a neat idea, but I would have problems using Linux due to fact (what he claims) is that only Windows 7 can do up to 8 touch events at the same time - Linux, XP and Vista can only handle one. As he explained it: It's like tracking up to 8 mouse cursors all at the same time. Anyway, it would be cool if we could use it in some kind of Minority Report type display using OSG. I've read that X.org 7.5 supports MPX, the multi-pointer extension (though I haven't tried it myself, so I don't know how good/stable it is). The MS guy might be correct for now, but he won't be for long. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nvidia Quadro Cards, and Nice Touch Pannals!
Jason Daly wrote: I've read that X.org 7.5 supports MPX, the multi-pointer extension (though I haven't tried it myself, so I don't know how good/stable it is). The MS guy might be correct for now, but he won't be for long. --J Yea! At our lab: We been debating how to approach the problem, even though I don't think that we could develop any interest in using it! I'm sure the solution would be a driver of some kind that we would link to an OSG app that would run full screen. We would have to develop some controls that can be controlled via the panel - X would be bypassed for now. Right now we are just kicking the idea around in our heads! 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=26744#26744 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] run-on-demand
Hello, Something I've noticed since I started using osg is that the viewer uses all of one cpu even when the view is not changing. I've tried passing the --run-on-demand option to osgviewer and doing viewer.setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); in code and there is no difference. What gives? Thanks, -- Paul Gotzel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text Entents
Shortly after my last post, I got moved away from working on a HUD, before I had actually solved the above problem. I've spent the better part of today working on this again, and have been unable to get a valid BoundingBox from my osgText object. Here's the code chunk in question: Code: // create a transform and geode to hold the text drawable m_pTransform = new osg::MatrixTransform; m_pGeode = new osg::Geode; m_pText = new osgText::Text; // link them all together UIManager::I()-GetUISubRoot()-addChild( m_pTransform ); m_pTransform-addChild( m_pGeode ); m_pGeode-addDrawable( m_pText ); // create text from string m_pText-setCharacterSize( aiSize ); m_pText-setFont( C:/WINDOWS/Fonts/impact.ttf ); m_pText-setText( asText.c_str() ); m_pText-setAxisAlignment( osgText::Text::SCREEN ); m_pText-setColor( osg::Vec4( aiR, aiG, aiB, aiA ) ); m_pText-setPosition( osg::Vec3( 0, 0, 0 ) ); m_pText-setCharacterSizeMode( osgText::Text::OBJECT_COORDS ); if ( m_bRightJustified ) m_pText-setAlignment( osgText::TextBase::RIGHT_BASE_LINE ); else m_pText-setAlignment( osgText::TextBase::LEFT_BASE_LINE ); // determine size extents of the text osg::BoundingBox box = m_pText-computeBound(); int w = box.xMax() - box.xMin(); int h = box.yMax() - box.yMin(); w and h are not correct at this point. The text does display correctly, but I need to adjust its placement based on its height and width. I've tried far more that just this, running through quite a number of functions both in Text and TextBase. I've looked through some example apps for this. I've searched the forums and the web at large for examples. I'm stuck. ~ Chris Innanen ~ Nonsanity -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26746#26746 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text Entents
have a look at osgWidget::Input. There is a code snippet that calculates the text bounds -Nick On Wed, Apr 14, 2010 at 1:03 AM, Chris Innanen f...@nonsanity.com wrote: Shortly after my last post, I got moved away from working on a HUD, before I had actually solved the above problem. I've spent the better part of today working on this again, and have been unable to get a valid BoundingBox from my osgText object. Here's the code chunk in question: Code: // create a transform and geode to hold the text drawable m_pTransform = new osg::MatrixTransform; m_pGeode = new osg::Geode; m_pText = new osgText::Text; // link them all together UIManager::I()-GetUISubRoot()-addChild( m_pTransform ); m_pTransform-addChild( m_pGeode ); m_pGeode-addDrawable( m_pText ); // create text from string m_pText-setCharacterSize( aiSize ); m_pText-setFont( C:/WINDOWS/Fonts/impact.ttf ); m_pText-setText( asText.c_str() ); m_pText-setAxisAlignment( osgText::Text::SCREEN ); m_pText-setColor( osg::Vec4( aiR, aiG, aiB, aiA ) ); m_pText-setPosition( osg::Vec3( 0, 0, 0 ) ); m_pText-setCharacterSizeMode( osgText::Text::OBJECT_COORDS ); if ( m_bRightJustified ) m_pText-setAlignment( osgText::TextBase::RIGHT_BASE_LINE ); else m_pText-setAlignment( osgText::TextBase::LEFT_BASE_LINE ); // determine size extents of the text osg::BoundingBox box = m_pText-computeBound(); int w = box.xMax() - box.xMin(); int h = box.yMax() - box.yMin(); w and h are not correct at this point. The text does display correctly, but I need to adjust its placement based on its height and width. I've tried far more that just this, running through quite a number of functions both in Text and TextBase. I've looked through some example apps for this. I've searched the forums and the web at large for examples. I'm stuck. ~ Chris Innanen ~ Nonsanity -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26746#26746 ___ 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] Byte sizes of various objects
A discussion came up this week about the overhead and memory consumption of various OSG objects, relating to the possible indiscriminate use of them. It turned out not to be an issue, but in the process of investigating, I quickly measured the in-memory byte sizes of a few common OSG objects. These are simply measured with sizeof(osg::Node) or the like. Obviously, in practical use, the containers and ref_ptrs involved increase the actual memory consumption, but this gives you a baseline idea. Compiler is MSVC++ 2005, Win32: Release Node: 160 Group: 176 Switch: 200 LOD: 216 PagedLOD: 276 Geode: 200 Geometry: 308 Drawable: 172 StateSet: 192 Debug Node: 172 Group: 192 Switch: 224 LOD: 236 PagedLOD: 304 Geode: 216 Geometry: 332 Drawable: 184 StateSet: 260 Thought it might be informative to someone else, so here it is. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use namespace...
Hi, On 13/04/10 9:12 , mas oug wrote: Just curious, I noticed that in a lot of the code, we use stuff like osg::someFunctio() and etc... Could we use a namespace using namespace osg; to avoid having to write osg:: every single time? Of course you can use a 'using namespace osg' in the implementation files on your own project if that makes it more comfortable for you. Just don't put them in a header file as this is a no-no, it defeats the purpose of namespaces in the first place. Like Ben Cain I tend to not do that since it makes the code easier to read since it's obvious where a class/function comes from. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
