Re: [osg-users] Render to Texture and per vertex colors
Anyone has experience something similar?
J.
Hi all,
I want to do an RTT of the current camera to do some PostProcesses on it
(using shaders). When the geometry is textured, everything works ok, but
when i use non-textured objects, the objects renders in black. I tryed
the code in osgprerender example in my app and it does the same thing,
but the osgprerender example works correctly (with the cessna model for
ex.). I Attach an image of the result.
Here is the code i use:
/// Texture for RTT ///
{
sourceSceneTexture = new osg::Texture2D;
sourceSceneTexture-setTextureSize(textureWidth, textureHeight);
sourceSceneTexture-setInternalFormat(GL_RGBA);
sourceSceneTexture-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
sourceSceneTexture-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
}
// Geode without ilumination for attaching the RTT
rttPlaneGroup = new osg::Group;
osg::ref_ptrosg::Geode geo = new osg::Geode;
geo-setName(PlanoGeode);
osg::StateSet* ss = geo-getOrCreateStateSet();
ss-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
finalPlaneGeometry = new osg::Geometry();
finalPlaneGeometry-setName(PlanoGeometry);
geo-addDrawable(finalPlaneGeometry.get());
osg::Vec3Array* vertex = new osg::Vec3Array;
vertex-push_back( osg::Vec3 (0,0,0) ); // down left
vertex-push_back( osg::Vec3 (1,0,0) ); // down right
vertex-push_back( osg::Vec3 (1,1,0) ); // up right
vertex-push_back( osg::Vec3 (0,1,0) ); // up left
finalPlaneGeometry-setVertexArray(vertex);
GLuint vertplane[4] = {3,2,1,0};
finalPlaneGeometry-addPrimitiveSet(new
osg::DrawElementsUInt(osg::PrimitiveSet::QUADS, 4, vertplane));
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
finalPlaneGeometry-setColorArray(colors);
finalPlaneGeometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
osg::Vec2Array* tcoords = new osg::Vec2Array(4);
(*tcoords)[0].set(0.0f, 0.0f);
(*tcoords)[1].set(1.0f, 0.0f);
(*tcoords)[2].set(1.0f, 1.0f);
(*tcoords)[3].set(0.0f, 1.0f);
finalPlaneGeometry-setTexCoordArray(0, tcoords);
geo-addDrawable(finalPlaneGeometry);
rttPlaneGroup-addChild(geo.get());
/FBO -
Scene
// then create the camera node to do the render to texture
{
camShot = new osg::Camera;
camShot-setName(CamShot);
camShot-setClearColor(osg::Vec4(0.7,0.1,0.3,1));
camShot-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
camShot-setProjectionMatrix(osg::Matrix::identity());
camShot-setViewMatrix(osg::Matrix::identity());
camShot-setReferenceFrame(osg::Transform::RELATIVE_RF);
camShot-setViewport(0, 0, textureWidth, textureHeight);
camShot-setRenderOrder(osg::Camera::PRE_RENDER);
camShot-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camShot-attach(osg::Camera::COLOR_BUFFER, sourceSceneTexture);
camShot-addChild(root);
rttPlaneGroup-addChild(camShot.get());
}
osg::ref_ptrosg::Camera camPlano = new osg::Camera;
camPlano-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camPlano-setProjectionMatrixAsOrtho2D(0, 1, 0, 1);
camPlano-setViewMatrix(osg::Matrix::identity());
camPlano-setName(CamPlano);
camPlano-setClearColor(osg::Vec4(0.0,0.0,0.0,1.0));
camPlano-addChild(geo.get());
rttPlaneGroup-addChild(camPlano.get());
osg::StateSet* stateset = new osg::StateSet;
stateset-setTextureAttributeAndModes(0, sourceSceneTexture
,osg::StateAttribute::ON);
rttPlaneGroup-setStateSet(stateset);
where root is the original scene and rttPlaneGroup the final render group.
Thanks in advance!!
J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reproducing multi-threaded viewer + on screen camera/view crash
Hello Robert, did you look at my previous post with subject Camera Statistics cause crash in CullThreadPerCameraDrawThreadPerContext mode Could that be a similar problem. I have that issue with small non paged datasets though. And it is rather easy to reproduce. Uwe Robert Osfield schrieb: Hi All, When I original merged the new camera/view stats code in testing on my older machine I was able to see a crash when viewing large paged databases with the on screen camera + view stats switched on, it used to take a few minutes to see it, but it would eventually appear. However, now I've allotted some time to fix this bug I haven't been able to reproduce it... Others have also reported this crash, so perhaps together we can come up with a reliable test that reproduces the crash. Please speak up :-) The importance of reprodocing the crash is that if I refactor the code as I'm doing I'll need to be able to test that the crash is indeed fixed. Without a reliable crash to start with it'll be a case of hoping for the best once I apply my changes. Thanks in advance for you help, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- \\\|/// *HLRS, High Performance Computing Center Stuttgart* _I_ ( o o )*Visualization/VR* _I_ (_...@_)--oo0O--(_)--O0oo--(_...@_) | |Uwe Woessnerhttp://www.hlrs.de/people/woessner/ | | | | .ooo0 mobile: +49-173-7028729| | |_| ( ) Oooo. office: +49-711-6856-5790 |_| (_...@_)---\ (---( )-(_...@_) I \_) ) /I (_/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
--- On Fri, 23/1/09, Robert Osfield robert.osfi...@gmail.com wrote: snip I would very much like for us to get the OSG binaries sorted out for this OSG-2.8, both for platforms like Windows and OSX, and for linux, in particular knocking on the Linux distro doors to get OSG-2.8 in the up coming linux releases. I greatly appreciate any assistance you can provide in terms or testing or helping out on the coordinating with packaging of the final release. Hi, I'm currently teaching myself how to build rpms. Would that be of any use for you? I know they are typically targeted at specific distributions but I have a large hard drive and could try to make then up for any distribtions I can get my hands on! From what I've read so far it seems that it would be better to create a source rpm first and then I can build the actual binary rpm on the target platform. Or maybe it's only the source rpm itself that should be made available? Of course this would be my first project at building rpms which might be a bit ambitious but you have to learn somewhere and it would be great to give something back! Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Hi Ruqin, You could disable the depth test on the subgraph that rendered the dragger. Robert. On Mon, Jan 26, 2009 at 11:47 PM, Ruqin Zhang ruzh...@gmail.com wrote: Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ 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] ABSOLUTE_RF problem
Hi Pavel,
The RefererenceFrame in Transform is widely used and does work robust
with ABSOLTE_RF - this is how most users with do HUDs (Camera is a
subclass from Transform.)
Just becuase the view matrix is identity doesn't mean that any
subgraph underneath will be visible, far from it, the subgraph will
only be visible if the objects local coordinates place it in front of
the camera. In your transform set up code place add a query of the
center of the subgraph and then create a transform that takes this to
a position in front of the eye point.
Robert.
On Tue, Jan 27, 2009 at 8:49 AM, Pavel Domša pdo...@seznam.cz wrote:
Hi all,
i have an issue with osg::TransformMatrix::SetReferenceFrame and it's either
bug or my misunderstanding. Documentation on osg::Transform explains
difference between ABSOLUTE_RF and RELATIVE_RF pretty well. Also
MatrixTransform.cpp shows how localToWorld transformations are being handled
for both and code is clear and understandable.
To demonstrate issue i've created simpliest scenario. Hierarchy is
root-MatrixTransform-ModelNode(cow). Transformation is identity. By
default reference frame is RELATIVE_RF and cow is clearly visible. But when
reference frame is set to ABSOLUTE_RF nothing is being rendered at all. I
believe that for ABSOLUTE_RF cow should be visible as well since
transformation is still identity.
I googled a lot but it seems that ABSOLUTE_RF is being used only for
osg::Camera settings and i couldn't find any piece of code where it's set on
MatrixTransform.
So is SetReferenceFrame supposed to work on osg::MatrixTransform as well? i
believe it should because it's very handy to share states and attributes
from hierarchy above but be able to do transformation in world coords.
Demo is attached.
Thanks
Pavel Domsa
#include osg/Node
#include osg/MatrixTransform
#include osg/Group
#include osg/BlendFunc
#include osg/Geometry
#include osgText/Text
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osgViewer/ViewerEventHandlers
int main( int argc, char **argv )
{
osg::Referenced::setThreadSafeReferenceCounting(true);
int rval = -1;
osg::ArgumentParser args( argc, argv );
osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFiles(args);
if(!loadedModel)
{
loadedModel = osgDB::readNodeFile(cow.osg);
}
std::string filename;
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.addEventHandler(new osgViewer::WindowSizeHandler);
viewer.addEventHandler(new osgViewer::StatsHandler);
osg::ref_ptr osg::Group scene = new osg::Group;
viewer.setSceneData( scene.get() );
osg::ref_ptrosg::MatrixTransform mxt = new osg::MatrixTransform;
mxt-addChild(loadedModel.get());
// mxt-setReferenceFrame(osg::Transform::ABSOLUTE_RF); // uncomment here
scene-addChild(mxt.get());
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
viewer.run();
return( rval );
}
___
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] Reproducing multi-threaded viewer + on screen camera/view crash
Hi Uwe, Could send me the small .ive file that you've used to reproduce this problem. Could you also try reproducing the problem at your, but please don't do an svn update quite yet as last night I checked in a fix for the threading issues in Camera sets query - the one that your crash point suggested was the problem. Once you have reproduced it, could you then do an svn update to see if my fixes address this problem. The View stats code is still working in the original non thread safe way. Like the changes I made for the Camera stats code I will be re-factoring the stats collection so it works in a thread safe way. This should be complete in the next couple of hours. Robert. On Tue, Jan 27, 2009 at 8:51 AM, Uwe Woessner woess...@hlrs.de wrote: Hello Robert, did you look at my previous post with subject Camera Statistics cause crash in CullThreadPerCameraDrawThreadPerContext mode Could that be a similar problem. I have that issue with small non paged datasets though. And it is rather easy to reproduce. Uwe Robert Osfield schrieb: Hi All, When I original merged the new camera/view stats code in testing on my older machine I was able to see a crash when viewing large paged databases with the on screen camera + view stats switched on, it used to take a few minutes to see it, but it would eventually appear. However, now I've allotted some time to fix this bug I haven't been able to reproduce it... Others have also reported this crash, so perhaps together we can come up with a reliable test that reproduces the crash. Please speak up :-) The importance of reprodocing the crash is that if I refactor the code as I'm doing I'll need to be able to test that the crash is indeed fixed. Without a reliable crash to start with it'll be a case of hoping for the best once I apply my changes. Thanks in advance for you help, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- \\\|/// *HLRS, High Performance Computing Center Stuttgart* _I_ ( o o )*Visualization/VR* _I_ (_...@_)--oo0O--(_)--O0oo--(_...@_) | |Uwe Woessnerhttp://www.hlrs.de/people/woessner/ | | | | .ooo0 mobile: +49-173-7028729| | |_| ( ) Oooo. office: +49-711-6856-5790 |_| (_...@_)---\ (---( )-(_...@_) I \_) ) /I (_/ ___ 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] Development plan for imminent stable OSG-2.8
Hi Paul, On Tue, Jan 27, 2009 at 8:57 AM, Paul Fotheringham osg_u...@yahoo.co.uk wrote: I'm currently teaching myself how to build rpms. Would that be of any use for you? It would. There is a message of Mattias, on the thread about LIB_POSTFIX, which mentions how to create rpms using CPack, so this would be a good place to start. I know they are typically targeted at specific distributions but I have a large hard drive and could try to make then up for any distributions I can get my hands on! Will you have to install the various distros? I'd guess that that the main rpm based Distro's would be RedHat, Fedora and Mandriva. Do you have any these right now? The first step would be to get rpm's built for the upcoming 2.7.9 on your present platform then get others to test these out. Of course this would be my first project at building rpms which might be a bit ambitious but you have to learn somewhere and it would be great to give something back! That's the attitude! We would get much done if we were only ever tackle things we knew 100% about. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture and per vertex colors
Hi Joseba, have you took a look into osgPPU? This can do exactly what you are looking for. art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5222#5222 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] freetype and png plugin building errors
Hi to all, I'm facing some problems to build the osgdb_freetype and osgdb_png plugin in 64bits. I built the osg solution in 64bits without problem with visual studio 2005. The examples worked fine. Below are the errors i get when building these two plugins. I'm looking forward for a solution. Thanks in advance. Erreur1error LNK2019: symbole externe non résolu FT_Done_Face référencé dans la fonction public: virtual __cdecl FreeTypeFont::~FreeTypeFont(void) (??1FreeTypeFont@@u...@xz)FreeTypeFont.obj Erreur2error LNK2001: symbole externe non résolu FT_Done_Face FreeTypeFont3D.obj Erreur3error LNK2019: symbole externe non résolu FT_Set_Pixel_Sizes référencé dans la fonction protected: void __cdecl FreeTypeFont::setFontResolution(struct std::pairunsigned int,unsigned int const ) (?setfontresolut...@freetypefont@@ieaaxaebu?$p...@ii@std@@@Z) FreeTypeFont.obj Erreur4error LNK2001: symbole externe non résolu FT_Set_Pixel_Sizes FreeTypeFont3D.obj Erreur5error LNK2019: symbole externe non résolu FT_Load_Char référencé dans la fonction public: virtual class osgText::Font::Glyph * __cdecl FreeTypeFont::getGlyph(struct std::pairunsigned int,unsigned int const ,unsigned int) (?getgl...@freetypefont@@ueaapeavgl...@font@osgText@@aebu?$p...@ii@std@@i...@z) FreeTypeFont.obj Erreur6error LNK2001: symbole externe non résolu FT_Load_Char FreeTypeFont3D.obj Erreur7error LNK2019: symbole externe non résolu FT_Get_Kerning référencé dans la fonction public: virtual class osg::Vec2f __cdecl FreeTypeFont::getKerning(struct std::pairunsigned int,unsigned int const ,unsigned int,unsigned int,enum osgText::KerningType) (?getkern...@freetypefont@@ueaa?avve...@osg@@aebu?$p...@ii@std@@iiw4kerningt...@osgtext@@@Z) FreeTypeFont.obj Erreur8error LNK2001: symbole externe non résolu FT_Get_Kerning FreeTypeFont3D.obj Erreur9error LNK2019: symbole externe non résolu FT_Get_Char_Index référencé dans la fonction public: virtual class osg::Vec2f __cdecl FreeTypeFont::getKerning(struct std::pairunsigned int,unsigned int const ,unsigned int,unsigned int,enum osgText::KerningType) (?getkern...@freetypefont@@ueaa?avve...@osg@@aebu?$p...@ii@std@@iiw4kerningt...@osgtext@@@Z) FreeTypeFont.obj Erreur10error LNK2001: symbole externe non résolu FT_Get_Char_Index FreeTypeFont3D.obj Erreur11error LNK2019: symbole externe non résolu FT_Outline_Get_BBox référencé dans la fonction protected: void __cdecl FreeTypeFont3D::init(void) (?i...@freetypefont3d@@IEAAXXZ)FreeTypeFont3D.obj Erreur12error LNK2019: symbole externe non résolu FT_Outline_Decompose référencé dans la fonction protected: void __cdecl FreeTypeFont3D::init(void) (?i...@freetypefont3d@@IEAAXXZ)FreeTypeFont3D.obj Erreur13error LNK2019: symbole externe non résolu FT_Load_Glyph référencé dans la fonction protected: void __cdecl FreeTypeFont3D::init(void) (?i...@freetypefont3d@@IEAAXXZ)FreeTypeFont3D.obj Erreur14error LNK2019: symbole externe non résolu FT_Set_Char_Size référencé dans la fonction protected: void __cdecl FreeTypeFont3D::init(void) (?i...@freetypefont3d@@IEAAXXZ)FreeTypeFont3D.obj Erreur15error LNK2019: symbole externe non résolu FT_Init_FreeType référencé dans la fonction protected: __cdecl FreeTypeLibrary::FreeTypeLibrary(void) (??0FreeTypeLibrary@@i...@xz) FreeTypeLibrary.obj Erreur16error LNK2019: symbole externe non résolu FT_Done_FreeType référencé dans la fonction public: virtual __cdecl FreeTypeLibrary::~FreeTypeLibrary(void) (??1FreeTypeLibrary@@u...@xz) FreeTypeLibrary.obj Erreur17error LNK2019: symbole externe non résolu FT_New_Face référencé dans la fonction protected: bool __cdecl FreeTypeLibrary::getFace(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,unsigned int,struct FT_FaceRec_ * ) (?getf...@freetypelibrary@@ieaa_naebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@IAEAPEAUFT_FaceRec_@@@Z) FreeTypeLibrary.obj Erreur18error LNK2019: symbole externe non résolu FT_Open_Face référencé dans la fonction protected: unsigned char * __cdecl FreeTypeLibrary::getFace(class std::basic_istreamchar,struct std::char_traitschar ,unsigned int,struct FT_FaceRec_ * ) (?getf...@freetypelibrary@@ieaapeaeaeav?$basic_istr...@du?$char_traits@d...@std@@@std@@IAEAPEAUFT_FaceRec_@@@Z) FreeTypeLibrary.obj Erreur19error LNK2019: symbole externe non résolu FT_Set_Charmap référencé dans la fonction protected: void __cdecl FreeTypeLibrary::verifyCharacterMap(struct FT_FaceRec_ *) (?verifycharacter...@freetypelibrary@@IEAAXPEAUFT_FaceRec_@@@Z) FreeTypeLibrary.obj Erreur20fatal error LNK1120: 14 externes non résolus J:\OSG2.6.1\SRC\build_x64\bin\Debug\..\osgPlugins-2.6.1\osgdb_freetyped.dll
Re: [osg-users] Development plan for imminent stable OSG-2.8
--- On Tue, 27/1/09, Robert Osfield robert.osfi...@gmail.com wrote: From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Development plan for imminent stable OSG-2.8 To: osg_u...@yahoo.co.uk, OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Tuesday, 27 January, 2009, 9:24 AM Hi Paul, On Tue, Jan 27, 2009 at 8:57 AM, Paul Fotheringham osg_u...@yahoo.co.uk wrote: I'm currently teaching myself how to build rpms. Would that be of any use for you? It would. There is a message of Mattias, on the thread about LIB_POSTFIX, which mentions how to create rpms using CPack, so this would be a good place to start. Thanks, I'll check that out. I know they are typically targeted at specific distributions but I have a large hard drive and could try to make then up for any distributions I can get my hands on! Will you have to install the various distros? I thought so but perhaps there's an easier way? I'll investigate this further. I'd guess that that the main rpm based Distro's would be RedHat, Fedora and Mandriva. Do you have any these right now? I use Fedora at work and Mandriva at home so that should help. I think SuSE is rpm-based too or at least it was the last time I used it years ago. The first step would be to get rpm's built for the upcoming 2.7.9 on your present platform then get others to test these out. I'll start with that then. Can't promise how quickly it'll happen of course but I'll do my best :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture and per vertex colors
Does your shader code take into account you have no texture on the non
textured nodes.
One possible issue that I have seen before
I presume in your shader code you get and use the texture's rgb, but if you
get this on a non textured fragment you will get Zero so if you doing a
multiplication in your color calculation then it will most likely end up
with Zero thus black.
You need to pick up that you have not texture and use a fixed value for your
RGB,
__
Capture the magic of Christmas this year see www.capturethemagic.com
__
Gordon Tomlinson
gor...@gordontomlinson.com
IM: gordon3db...@3dscenegraph.com
www.vis-sim.com www.gordontomlinson.com
__
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Joseba
Sent: Tuesday, January 27, 2009 3:22 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Render to Texture and per vertex colors
Anyone has experience something similar?
J.
Hi all,
I want to do an RTT of the current camera to do some PostProcesses on it
(using shaders). When the geometry is textured, everything works ok, but
when i use non-textured objects, the objects renders in black. I tryed
the code in osgprerender example in my app and it does the same thing,
but the osgprerender example works correctly (with the cessna model for
ex.). I Attach an image of the result.
Here is the code i use:
/// Texture for RTT ///
{
sourceSceneTexture = new osg::Texture2D;
sourceSceneTexture-setTextureSize(textureWidth, textureHeight);
sourceSceneTexture-setInternalFormat(GL_RGBA);
sourceSceneTexture-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LIN
EAR);
sourceSceneTexture-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LIN
EAR);
}
// Geode without ilumination for attaching the RTT
rttPlaneGroup = new osg::Group;
osg::ref_ptrosg::Geode geo = new osg::Geode;
geo-setName(PlanoGeode);
osg::StateSet* ss = geo-getOrCreateStateSet();
ss-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
finalPlaneGeometry = new osg::Geometry();
finalPlaneGeometry-setName(PlanoGeometry);
geo-addDrawable(finalPlaneGeometry.get());
osg::Vec3Array* vertex = new osg::Vec3Array;
vertex-push_back( osg::Vec3 (0,0,0) ); // down left
vertex-push_back( osg::Vec3 (1,0,0) ); // down right
vertex-push_back( osg::Vec3 (1,1,0) ); // up right
vertex-push_back( osg::Vec3 (0,1,0) ); // up left
finalPlaneGeometry-setVertexArray(vertex);
GLuint vertplane[4] = {3,2,1,0};
finalPlaneGeometry-addPrimitiveSet(new
osg::DrawElementsUInt(osg::PrimitiveSet::QUADS, 4, vertplane));
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors-push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
finalPlaneGeometry-setColorArray(colors);
finalPlaneGeometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
osg::Vec2Array* tcoords = new osg::Vec2Array(4);
(*tcoords)[0].set(0.0f, 0.0f);
(*tcoords)[1].set(1.0f, 0.0f);
(*tcoords)[2].set(1.0f, 1.0f);
(*tcoords)[3].set(0.0f, 1.0f);
finalPlaneGeometry-setTexCoordArray(0, tcoords);
geo-addDrawable(finalPlaneGeometry);
rttPlaneGroup-addChild(geo.get());
/FBO -
Scene
// then create the camera node to do the render to texture
{
camShot = new osg::Camera;
camShot-setName(CamShot);
camShot-setClearColor(osg::Vec4(0.7,0.1,0.3,1));
camShot-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
camShot-setProjectionMatrix(osg::Matrix::identity());
camShot-setViewMatrix(osg::Matrix::identity());
camShot-setReferenceFrame(osg::Transform::RELATIVE_RF);
camShot-setViewport(0, 0, textureWidth, textureHeight);
camShot-setRenderOrder(osg::Camera::PRE_RENDER);
camShot-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camShot-attach(osg::Camera::COLOR_BUFFER, sourceSceneTexture);
camShot-addChild(root);
rttPlaneGroup-addChild(camShot.get());
}
osg::ref_ptrosg::Camera camPlano = new osg::Camera;
camPlano-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camPlano-setProjectionMatrixAsOrtho2D(0, 1, 0, 1);
camPlano-setViewMatrix(osg::Matrix::identity());
camPlano-setName(CamPlano);
camPlano-setClearColor(osg::Vec4(0.0,0.0,0.0,1.0));
camPlano-addChild(geo.get());
Re: [osg-users] cant clear background in composite viewer
Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed. Also, the gaps between the views shows garbage. I attached two screenshots showing the problem. Is there something that I could call on the composite viewer to clear the entire window? It could also be a Qt problem, since the composite viewer is derived from QGLWidget. If I resize the window after removing the fourth view, then the background is cleared. I tried calling repaint()/paintGL() on the QtWidget, but that didn't help. I would appreciate pointers from people who have successfully used composite viewers with Qt before. Thanks a lot! Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cant clear background in composite viewer
Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed. Also, the gaps between the views shows garbage. I attached two screenshots showing the problem. Is there something that I could call on the composite viewer to clear the entire window? It could also be a Qt problem, since the composite viewer is derived from QGLWidget. If I resize the window after removing the fourth view, then the background is cleared. I tried calling repaint()/paintGL() on the QtWidget, but that didn't help. I would appreciate pointers from people who have successfully used composite viewers with Qt before. Thanks a lot! Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi All, I've just updated the BugResolution page on the wiki for the work on getting ready for 2.8. The page can be found at: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution If have have bugs that exist in svn trunk + 2.7.x then please added them into this page, and include details on how to help to reproduce them. Also post to the osg-users list to help coordinate this work, as it's osg-users will be where all the dialogue happens - its the dialogue that typically gets these problems resolved so don't please don't hesitate to engage on these topics. When populating the BugResolution page it's good to add links to the osg-users archives on the topic to enable other engineers to follow discussions. Also providing examples that reproduce the problems is useful. The key to success is working together to resolve bugs, remember we are all in the same boat, all users/developers, we all have the source code so are all empowered to help track down the source of bugs as well as fix them. If you don't feel you have the knowledge to fix bugs, then work to make it easier for others with this knowledge to quickly reproduce and home in on the problems. For those who have time and skills they can put to good use on the packaging front please note we have a page for this, which needs updating with latest info on cpack etc. http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cant clear background in composite viewer
Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed. Also, the gaps between the views shows garbage. I attached two screenshots showing the problem. Is there something that I could call on the composite viewer to clear the entire window? It could also be a Qt problem, since the composite viewer is derived from QGLWidget. If I resize the window after removing the fourth view, then the background is cleared. I tried calling repaint()/paintGL() on the QtWidget, but that didn't help. I would appreciate pointers from people who have successfully used
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Robert, why making the life harder than it already is :) I mean making Wiki for Bug resolutions, which can be done with the Ticket system as well. I think using tickets will be an easier way than using the wiki. You only have to connect the ticket system with the mailing list and acitvate it, then we all will recieve a bug message as soon as somebody create a new ticket. Even more, I could catch up tickets sent to the mailing list and represent them in the forum marked in a certain way. This will make even the life of forum users easier, because they could directly see what happens with new bugs without checking the Wiki-Page. Thus we will have everything in one place, without loosing any new bugs/resolutions. cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5231#5231 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cant clear background in composite viewer
HI Morne, Ahh the missing bit of the jigsaw - that fact that you are using GraphicWindowEmbedded is key. The GraphicsContext::swapBuffers() is normally what does the swap buffers and then calls GraphicsContext::clear(), with GraphicsWindowEmbedded::swapBuffers() it's a non op, because there is no way it can do a swap buffers as it doesn't actually know about a real graphics context. What you'll need to do in your own QT code is call GraphicsContext::clear() explicitly after the swap buffers or prior to calling frame()/renderingTraversals(); Robert. On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Art, I must admit I'm not familiar with the Ticket system. I use Tracs in a very basic way. Perhaps it's time to learn... I am rather wary of using instigating a bug tracking system as sometimes they can be misused for feature request, and can create a barrier in direct communication. I got burned by bug tracking systems in the past, where is caused far more work than it helped so have avoided them since. The Ticket system may well avoid the pitfalls. Robert. On Tue, Jan 27, 2009 at 1:00 PM, Art Tevs stud_in...@yahoo.de wrote: Hi Robert, why making the life harder than it already is :) I mean making Wiki for Bug resolutions, which can be done with the Ticket system as well. I think using tickets will be an easier way than using the wiki. You only have to connect the ticket system with the mailing list and acitvate it, then we all will recieve a bug message as soon as somebody create a new ticket. Even more, I could catch up tickets sent to the mailing list and represent them in the forum marked in a certain way. This will make even the life of forum users easier, because they could directly see what happens with new bugs without checking the Wiki-Page. Thus we will have everything in one place, without loosing any new bugs/resolutions. cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5231#5231 ___ 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] cant clear background in composite viewer
Hi Robert, As I expected, the problem lies with using a GraphicsWindowEmbedded. I was able to reproduce the bug in oagviewerQt by adding viewerWindow-getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); viewerWindow-getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the composite viewer. Attached is the example recreating the bug. Cheers, Morne On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed.
Re: [osg-users] cant clear background in composite viewer
Hi Morné, I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. You really shouldn't be using GraphicsWindowEmbedded even in a Qt app. This is constraining you to single threaded use of OSG, and thus you're not using your hardware to its full potential. Plus you're getting problems because the way GraphicsWindowEmbedded works is not what you expect. Check out the osgviewerqt example (the --QOSGWidget part) to see how to use a regular GraphicsWindowWin32/GraphicsWindowX11/GraphicsWindowCarbon in conjunction with Qt. It's pretty simple, and will give you a tangible benefit in performance in the end. 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] Development plan for imminent stable OSG-2.8
Hi Robert, I've just updated the BugResolution page on the wiki for the work on getting ready for 2.8. The page can be found at: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution Just wondering, I noticed you placed the osgShadow circular reference issue in the Recently Fixed bugs category, but the fix has not been checked in yet. Should it be moved back to Should resolve until you've had time to review it? Thanks, 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] Development plan for imminent stable OSG-2.8
Robert Osfield wrote: I must admit I'm not familiar with the Ticket system. I use Tracs in a very basic way. Perhaps it's time to learn... I don't think there is much difference between Trac's tickets and what you find in a regular (bug) tracking system, such as Bugzilla or Roundup. The advantage of Trac is that everything (wiki, sources, tickets) is integrated, so you can easily refer to a source revision from a ticket or wiki page, or refer to a ticket from a FAQ page. I am rather wary of using instigating a bug tracking system as sometimes they can be misused for feature request, and can create a barrier in direct communication. I got burned by bug tracking systems in the past, where is caused far more work than it helped so have avoided them since. The Ticket system may well avoid the pitfalls. It seems the things you describe above are mostly social problems, e.g. users putting large amounts of feature requests in a system meant for tracking bugs. This might be out of lack of experience with software development (not being able to recognize when something is a bug), lack of OpenGL experience (thinking OSG screws up while the user is misusing OpenGL) or just plain ignorance. There may be some social solution to these, such as not allowing just everyone to enter tickets, but only a small number of experienced OSG users that can validate each requests/bugs merits (after these get posted to osg-users, or even a dedicated list). That way the advantages of having a central bug list are not lost. Currently, I think there isn't anybody (not even Robert) that has a complete overview of all outstanding issues with OSG. Having them in a central location for everybody to see might not immediately help them get resolved, but my feeling is that NOT having a central list isn't helping in that respect. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cant clear background in composite viewer
Hi Morne, Thanks for the example. This isn't a bug though, it's a limitation of using GraphicsWindowEmbedded, just like you can't use GraphicsWindowEmbedded for doing multi-threading or using it with multiple windows, or having pbuffers used in the scene. GraphicsWindowEmbedded is very limiting, only intended for basic windowing integration, for full functionality you need to use a full GraphicsWindow implementation. There isn't much we can do to make GraphicsWindowEmbedded work in the same way as a full GraphicsWindow, as it'll require the ability to know about the underlying graphics context, and to do this you end up having to implement a full GraphicsWindow so it ceases to be this super easy to use class that you can use off the shelf. For most serious graphics apps you'll need to use a full GraphicsWindow implementation, as JS mentions, even in the case of QT it uses the window inheritance feature of GraphicsWindow enables you to use QT and all of the full functionality of OSG. Robert. On Tue, Jan 27, 2009 at 1:45 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, As I expected, the problem lies with using a GraphicsWindowEmbedded. I was able to reproduce the bug in oagviewerQt by adding viewerWindow-getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); viewerWindow-getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the composite viewer. Attached is the example recreating the bug. Cheers, Morne On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Robert, Just wondering, I noticed you placed the osgShadow circular reference issue in the Recently Fixed bugs category, but the fix has not been checked in yet. Sorry about that, just got your other message. 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] Development plan for imminent stable OSG-2.8
Hi JS, On Tue, Jan 27, 2009 at 2:05 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Just wondering, I noticed you placed the osgShadow circular reference issue in the Recently Fixed bugs category, but the fix has not been checked in yet. Should it be moved back to Should resolve until you've had time to review it? I had a fix waiting to apply when I added the entry, I didn't see a need to list it as a unresolved bug otherwise others might end up trying to fix something that already has a fix. Now I've actually applied by own changes to fix this bug, inspired by your fix, and this is now checked in, so the web page is now fully correct (hopefully :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Robert Osfield wrote: Hi JS, On Tue, Jan 27, 2009 at 2:05 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Just wondering, I noticed you placed the osgShadow circular reference issue in the Recently Fixed bugs category, but the fix has not been checked in yet. Should it be moved back to Should resolve until you've had time to review it? I had a fix waiting to apply when I added the entry, I didn't see a need to list it as a unresolved bug otherwise others might end up trying to fix something that already has a fix. Now I've actually applied by own changes to fix this bug, inspired by your fix, and this is now checked in, so the web page is now fully correct (hopefully :-) I added the revision numbers for the fixed bugs. Trac at its finest :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mattias Helsing wrote: I'm also sure rpm's have a way of modifying the system too but with rpm's I'm currently at zero. (It is possible to generate rpm's as our cpack support goes today, e.g. cpack -G RPM --config CPackSource-libopenscenegraph-dev.cmake) There is something called a post-install script that you can use with RPM to do this. It needs to be added to the spec file, not sure the generated one using cpack will has a way to do so. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfxaGn11XseNj94gRAn3TAJ9ZemWxdsb1cklqK6DPXAA5Ur6xiQCgp8/H ml1QsesQD7cPTyz2CHBibPQ= =ijTJ -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Paul, On Tue, Jan 27, 2009 at 2:08 PM, Paul Melis p...@science.uva.nl wrote: I am rather wary of using instigating a bug tracking system as sometimes they can be misused for feature request, and can create a barrier in direct communication. I got burned by bug tracking systems in the past, where is caused far more work than it helped so have avoided them since. The Ticket system may well avoid the pitfalls. It seems the things you describe above are mostly social problems, e.g. users putting large amounts of feature requests in a system meant for tracking bugs. This might be out of lack of experience with software development (not being able to recognize when something is a bug), lack of OpenGL experience (thinking OSG screws up while the user is misusing OpenGL) or just plain ignorance. My experiences were from nearly 10 years ago now.. But issues are the same. Fixing bugs is very much a social activity, in as much as it's the fixing bugs almost always requires a two way dialogue between the people able to reproduce the bug and those engaged in try to fix it. Facilitating the two way dialogue is absolutely the most important part of any bug resolution scheme - which is why I've always focused on osg-users as the route for bug resolution. There may be some social solution to these, such as not allowing just everyone to enter tickets, but only a small number of experienced OSG users that can validate each requests/bugs merits (after these get posted to osg-users, or even a dedicated list). That way the advantages of having a central bug list are not lost. Currently, I think there isn't anybody (not even Robert) that has a complete overview of all outstanding issues with OSG. Having them in a central location for everybody to see might not immediately help them get resolved, but my feeling is that NOT having a central list isn't helping in that respect. I can certainly see value in having a properly maintained issue tracking system, but this requires active management which in turn means that it takes time to engage in - time that could be spent actually fixing bugs. One only gains once such as system helps resolve more bugs than would have otherwise been fixed. Learning an maintaining a new system is something takes time for me and others in the community. Perhaps after 2.8 is out the door we can properly explore this possibility. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Art, I must admit I'm not familiar with the Ticket system. I use Tracs in a very basic way. Perhaps it's time to learn... I am rather wary of using instigating a bug tracking system as sometimes they can be misused for feature request, and can create a barrier in direct communication. The usual way to deal with this is that a bug tracker has categories and severities for bugs. E.g Mandriva's Bugzilla has a severity wishlist for a new feature request - it makes it easy to track these as well and things will not fall through the cracks. They are not bugs in the original sense of the word, but the system works well for them too. Certainly beats keeping track of all that manually in some file, where noone else can see it or some kind of unstructured Wiki page. Regarding the direct communication - I do not see where the barrier could be. Just send an e-mail to the reporter. If you mean the discussion that can occur (and frequently does) under the individual items in the bug tracker instead on a mailing list, I think that is valuable info for whoever tries to fix the bug - everything is in one place. Mandriva usually does both - the bug gets described on Bugzilla, then people comment and discuss it on the list and additional info is added to the bug description, sometimes with links to the list archives when mails are referenced. That is why it is important to have a link between the bug tracker and a mailing list, where new bug reports are cc-d - so that people are kept aware of new things being reported without having to search for them. I got burned by bug tracking systems in the past, where is caused far more work than it helped so have avoided them since. The Ticket system may well avoid the pitfalls. I think it comes down to the way the tool is used - set some rules and policies (like with the patch submission protocol) and it will work. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfxisn11XseNj94gRAuTrAKDhvlda4MUAn6z81JfYqOkt5kOyiwCffjXI vc9M1M/aDfKfhZw+lJUngZk= =2VFX -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Paul, I added the revision numbers for the fixed bugs. Trac at its finest :) Yep, very nice :-) 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] Development plan for imminent stable OSG-2.8
Robert Osfield wrote: Hi All, I've just updated the BugResolution page on the wiki for the work on getting ready for 2.8. The page can be found at: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution If have have bugs that exist in svn trunk + 2.7.x then please added them into this page, and include details on how to help to reproduce them. Also post to the osg-users list to help coordinate this work, I added a small issue where the statistics are not shown in a very readable way. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
On Mon, 2009-01-26 at 19:12 -0800, Ryan Morris wrote: Hoping someone can help me out here, I think I'm missing something in Blender, I export my animations and I get TransformVertexFunctor::UniqBoneSetVertexSet no bones found when I load them. Any thoughts? -Russ There are exactly 1,323,239 ways a Blender file can be constructed improperly resulting in a bad state for export. We do as much as we can in the exporter to accommodate for this, but Blender is HUGE and the API leaves MUCH to be desired in terms of predictability. The bottom line is: you need to provide your .blend file before either Cedric or myself can help. :) 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] Development plan for imminent stable OSG-2.8
On Tue, Jan 27, 2009 at 2:37 PM, Paul Melis p...@science.uva.nl wrote: I added a small issue where the statistics are not shown in a very readable way. I noted these problems when I was refactoring the internals to fix the threading issues. Fixing the sizes of the rectangles is trivial. Extra labels are needed as well. Feel free to go fix these while I go chase some other bugs :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Robert, Robert Osfield wrote: My experiences were from nearly 10 years ago now.. But issues are the same. Fixing bugs is very much a social activity, in as much as it's the fixing bugs almost always requires a two way dialogue between the people able to reproduce the bug and those engaged in try to fix it. Facilitating the two way dialogue is absolutely the most important part of any bug resolution scheme - which is why I've always focused on osg-users as the route for bug resolution. I think using a ticket system as already providid by the trac enviornment you are using for the project is the way one should go to make the project more flexible and younger. Look, the osg project is not a small project anymore and the community is continuosly growing. Using mailing lists only doesn't make all the users happy. And I still think that this kind of support/community is outdated. There exists a lot of capabilities to handle big projects well. Forums, Tickets and Wikis are such systems. We are happy to have a Wiki and a Forum now and ticket system would just make the whole project more flexible and better supported than now. It could even reduce your workload, because users could assigned tickets to themself and help other users without your intronvention. I understand that it is hard to give away a control to more dezentralized way, however for a such big project as osg it is the way to go in the future, I think. Come on, you will still stay the big boss/president of the osg community ;) Users/Developers/Contributors could register on the trac system with their own usernames. Then whenever a new ticket or feature request is posted somebody who thinks he is able to manage the bug, could assign the current ticket to himself. Peoples visiting the ticket system are able then to trace the bug resolution process and could see who is currently responsible for writing a solution. Even more as we have discussed in another thread (Ideas for osg 3.0) ticket system/trac environment could be setted up in a hierarchical way, so that there will be a hierarchy of contributors/maintainers of the project. When we split up osg to main core and node kit suites, there could be categories in the ticket system handling only about the node kits and the maintainer responsible for his node kit will do the managing work. I think this is the way we have to go, instead of managing bugs on a wiki page. Wiki pages would produce more work because of persistent mirroring of real osg state on the wiki page. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5264#5264 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About osgVolume example
Hi, Robert, Thanks for the link. I'd like to go and have a try. 2009/1/25 Robert Osfield robert.osfi...@gmail.com Hi Hesicong, osgVolume doesn't directly load or require any particular file format,so you can use it with an 3D osg::Image data that you have. The OSG's dicom plugin can generate such 3D osg::Image by reading a directory of dicom files if you use osgDB::readImageFile() or a complete VolumeTIle node with all associate data and rendering techniques set up if you use osgDB::readNodeFile(). You can select the the dicom plugin for reading dicom directories by appending a .dicom to the end of the filename i.e. osgviewer CardicCT.dicom The osgvolume example with append the .dicom automatically for you so you can do: osgvolume CardicCT Examples of dicom files can be found on the web, and I don't plan to add these of OpenSceneGarph-Data as they are typically very large - often hundreds of Mb, and also I don't have copyright for them so can't go including them. A couple of example of dicom files can be found on the Osix website: http://www.osirix-viewer.com/Downloads.html I've come across other sample dicom on the web, but a quick search with google didn't pick up on links to these, I'll populate a wiki page with links once I track them down. Robert. On Sun, Jan 25, 2009 at 11:05 AM, sicong he hesicong2...@gmail.com wrote: Hi, Robert, I'm very glad to see the volume support of OSG. The osgVolume example should be a good start. By checking out the latest version of OpenSceneGraph-Data, I still can't find any data to run the example, only some shaders. So would you please provide some CT or MRI dataset to run the example? Regards, Hesicong www.april1985.com January,25, 2009 ___ 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] Dragger rendering issue
Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple Render Target Question
I'm attempt to develop a Multiple Render Target (MRT) program and have a few questions.. First, I see this in the osgstereomatch example: Two textures are needed, because shaders cannot read and write to the same texture during calculation. One texture is used as input and the other as output. After a calculation, the input and output textures are swapped. The technique is known as ping-ponging or flip-flopping the textures. What does this mean? Can I have the same texture defined as input (assigned to the StateSet) and still have it attached (but not used) as a render target? In short, I see how I can ping-pong the input by changing the texture uniform but how do I ping-pong the attached render buffer? Can I attach all my render targets but then not use them (if it's an input)? What happens if you do read and write to the same texture each frame? Also, does this clear all my render targets (between frames): _Camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); What I'm trying to do is calculate a temporal averaging of a specific number of consecutive frames. I assume I need to keep a running average of frames as well as well as save each of the frames. Then each frame: SUM = (SUM - oldestFrame + newFrame) and Output = SUM/numberOfFrames; I think I'm done asking questions for now :-). Thanks for any help you can provide... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Guys, please stop pontificating about bug tracking/ticketing etc. Leave this type of long winded discussion until after we've got OSG-2.8 out the door. Learning and introducing new schemes is not what you do when you have an immenient release, instead you get on with job of testing and debugging and readying packaging. Sometimes this community is far more capable of talking than doing... Lets just go the job done. Things that need doing are: 1) Testing of build + runtime against real client apps across as many platforms as possible. 2) Fixing bugs 3) Completing the packaging support 4) Working out how we can better fit into distro packaging systems, liasing with package maintainers. 5) Submitting builds to the CDash dashboard : http://www.cdash.org/CDashPublic/viewConfigure.php?buildid=7682 6) Updating docs/wiki/news items for the OSG-2.8 Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
On Tue, 2009-01-27 at 15:16 +, Art Tevs wrote: Hi Robert, Robert Osfield wrote: My experiences were from nearly 10 years ago now.. But issues are the same. Fixing bugs is very much a social activity, in as much as it's the fixing bugs almost always requires a two way dialogue between the people able to reproduce the bug and those engaged in try to fix it. Facilitating the two way dialogue is absolutely the most important part of any bug resolution scheme - which is why I've always focused on osg-users as the route for bug resolution. I think using a ticket system as already providid by the trac enviornment you are using for the project is the way one should go to make the project more flexible and younger. Look, the osg project is not a small project anymore and the community is continuosly growing. Using mailing lists only doesn't make all the users happy. And I still think that this kind of support/community is outdated. There exists a lot of capabilities to handle big projects well. Forums, Tickets and Wikis are such systems. We are happy to have a Wiki and a Forum now and ticket system would just make the whole project more flexible and better supported than now. I'm confused by this thread somewhat--what exactly is going on? Is OSG adopting some external management software for bug tracking and what not, or are we discussing the possibility thereof? It could even reduce your workload, because users would assigned tickets to themself and help other users without your intronvention. I understand that it is hard to give away a control to more dezentralized way, however for a such big project as osg it is the way to go in the future, I think. Come on, you will still stay the big boss/president of the osg community ;) Users/Developers/Contributors could register on the trac system with their own usernames. Then whenever a new ticket or feature request is posted somebody who thinks he is able to manage the bug, could assign the current ticket to himself. Peoples visiting the ticket system are able then to trace the bug resolution process and could see who is currently responsible for writing a solution. Even more as we have discussed in another thread (Ideas for osg 3.0) ticket system/trac environment could be setted up in a hierarchical way, so that there will be a hierarchy of contributors/maintainers of the project. When we split up osg to main core and node kit suites, there could be categories in the ticket system handling only about the node kits and the maintainer responsible for his node kit will do the managing work. I think this is the way we have to go, instead of managing bugs on a wiki page. Wiki pages would produce more work because of persistent mirroring of real osg state on the wiki page. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5264#5264 ___ 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] What is the ideal default value for LIB_POSTFIX under Linux?
Hi Guys, I'd like to wrap up this thread with some concrete actions. First up, change the /usr/local/lib postfix for 64bit builds looks like it will be of little overall benefit, so I'll stick with the existing scheme. Second, our make install isn't suggest anything about the need to add the installed library directory to LD_LIBRARY (and other platform specific env vars) or ld.so.conf which could do with addressing. I'm now cmake expert so could someone with better cmake skills than I step in and have a look at this. Thirds, we could provide an automatically generated openscenegraph-library-path.conf file in the distro that users could copy/or even CMake do the install of. I'm in two minds about this. If we have proper docs generated on the make install about the install path and the options open for adding the path I think the need to install this feel is diminished. Even if we do create and install such a file the need to document this on make install output is still required so the above would need to be addressed first, so we can defer this task till after the docs are improved. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Jeremy, On Tue, Jan 27, 2009 at 3:40 PM, Jeremy Moles jer...@emperorlinux.com wrote: I'm confused by this thread somewhat--what exactly is going on? Is OSG adopting some external management software for bug tracking and what not, or are we discussing the possibility thereof? It's just ended up being another me-too thread... lots of suggestions, little action... Nothing is happening on introducing new systems. For OSG-2.8 we'll stick with osg-users for reporting bugs and resolve them as usual, and posting details on these bugs and their resolution on the usual BugResolution page. Once OSG-2.8 we can discuss the possibility of introducing an formal system for issue tracking. Job now is to getting everything ready for OSG-2.8 and make it as best we can. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Robert Osfield wrote: On Tue, Jan 27, 2009 at 2:37 PM, Paul Melis p...@science.uva.nl wrote: I added a small issue where the statistics are not shown in a very readable way. I noted these problems when I was refactoring the internals to fix the threading issues. Fixing the sizes of the rectangles is trivial. Extra labels are needed as well. Feel free to go fix these while I go chase some other bugs :-) It's being worked on (by me) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
On Tue, 2009-01-27 at 15:51 +, Robert Osfield wrote: Hi Jeremy, On Tue, Jan 27, 2009 at 3:40 PM, Jeremy Moles jer...@emperorlinux.com wrote: I'm confused by this thread somewhat--what exactly is going on? Is OSG adopting some external management software for bug tracking and what not, or are we discussing the possibility thereof? It's just ended up being another me-too thread... lots of suggestions, little action... Nothing is happening on introducing new systems. For OSG-2.8 we'll stick with osg-users for reporting bugs and resolve them as usual, and posting details on these bugs and their resolution on the usual BugResolution page. Once OSG-2.8 we can discuss the possibility of introducing an formal system for issue tracking. Job now is to getting everything ready for OSG-2.8 and make it as best we can. Okay, cool. :) I get about 1000 lines worth of warnings when I build OSG with: -W -Wall ...which is troublesome, because it prevents me from using those arguments in my own projects because of the warnings in OSG headers. I'd like to fix this (and have brought it up in the past), but it doesn't make sense to submit 50 or 60 full files for one-line fixes. Any ideas on this? Again, I can fix it myself--the question is, do you trust me to do it? :) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Jeremy, On Tue, Jan 27, 2009 at 4:00 PM, Jeremy Moles jer...@emperorlinux.com wrote: I get about 1000 lines worth of warnings when I build OSG with: -W -Wall ...which is troublesome, because it prevents me from using those arguments in my own projects because of the warnings in OSG headers. I'd like to fix this (and have brought it up in the past), but it doesn't make sense to submit 50 or 60 full files for one-line fixes. Any ideas on this? Again, I can fix it myself--the question is, do you trust me to do it? :) I've spent quite a bit of time on doing a warnings purge, and pretty well all the sensible/fixable warnings have been fixed now. By default the OSG now builds with aggressive warnings enabled, so I kinda surprised that you are still seeing warnings. Could you post me the compile output you are seeing. What compiler are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Anti-Grain and OpenSceneGraph
Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. http://www.antigrain.com/index.html Thanks, Kurt _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_012009___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug: Light management and slave cameras
Hi Alexande, FYI, I'm now looking at this issue. It does look like a bug, I haven't characterised the problem yet though... Robert. On Mon, Jan 26, 2009 at 4:42 PM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, thank you for according some time to this case, it's very important to me to understand what I'm doing wrong or if it's a bug from osg ;-) Kind regards, 2009/1/26 Robert Osfield robert.osfi...@gmail.com Hi Alexandre, Thanks for the updated example and screenshot, this makes it much clearer. I'm fixing another bug right now, but once that is complete I'll have another look at this example. Robert. On Mon, Jan 26, 2009 at 4:32 PM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, Well I attached new version from my sample file. If you launch sample file without argument you should see no_slave_camera.png. If you launch with argument --addslave, it's activate a piece of code wich add a slave camera to an osg::View and you'll see attached screenshot with_slave_camera.png. You see that in with_slave_camera.png screenshot there's no light, because of adding this slave camera to the view. Maybe like you said it's only an incorrect usage from slave cameras but It will be nice if you confirm that I'm mistaken if it's. 2009/1/26 Robert Osfield robert.osfi...@gmail.com HI Alexandre, I read your explanation but am still am confused. Could you modify the code so that you use a command line argument to add/remove the code this will make it easy to test the two configuration without recompile. As for it being a serious issue, well it could well still be an incorrect usage issue rather than a bug. Could you explain by what you mean by corrupt. Robert. On Mon, Jan 26, 2009 at 4:04 PM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, I'm sorry If my explanation wasn't clear enough but it seems to be to be a serious issue so I will take more time to make myself clear. In the file osgLight.cpp previously attached there is a piece of code in main function at line 397 to 400 : /// // SLAVE CAM REMOVE LIGHT osg::ref_ptrosg::Camera camera = new osg::Camera; camera-setGraphicsContext(view-getCamera()-getGraphicsContext()); camera-setViewport(new osg::Viewport(0, 0 , traits-width/2, traits-height/2)); view-addSlave(camera.get(), osg::Matrixd(), osg::Matrixd()); /// If you launch this sample file by this piece of code the scene is well lighted, but if you try to launch the same file without commenting those lines, the scene isn't well lighted. It seems to me that when we add a slave camera to an osg::View the lighting from the scene is corrupt. I hope I was clear enough. Kind regards, 2009/1/26 Robert Osfield robert.osfi...@gmail.com HI Alexandre, I can't find the code you are referring to in the osglight.cpp you provided. I'm afraid I really don't understand what you are trying to achieve, and what is happening that is wrong. Given this there is nothing I can do till you provide a clear example code and a better explanation. Robert. On Mon, Jan 26, 2009 at 8:29 AM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi osg-users, I recently have found something weird about adding slave camera to osgViewer::View when managing my own lightning. I'm using OSG SVN version. I derived osgLight example to show you my problem, please compile attached code with uncommenting following lines : // Adding slave camera, uncomment to show bug !! and you'll see that lighting has disappear... when you remove comments scene isn't lighted has expected because of adding slave camera... Kind regards, -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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 -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.html Thanks, Kurt __ Windows Live™ Hotmail®…more than just e-mail. See how it works. ___ 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] Dragger rendering issue
Thank you guys! I tried the idea of turning off the depth test. It works ok but not perfect. Just as Chris mentioned, there is some rendering problem of the dragger geometries. Anyone has idea of solving this problem? Thanks again! Ruqin On Tue, Jan 27, 2009 at 9:20 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Have you tried my earlier suggestion?i.e. adding a post render camera just above the dragger. Can be a bit fiddly to manage the scenegraph, so might be worth trying any other ideas first. But I can give you some code snippets if you want to try it. Chris. - Original Message - From: Ruqin Zhang To: Chris Denham ; osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 4:45 PM Subject: Re: [osg-users] Dragger rendering issue Thank you guys! I tried the idea of turning off the depth test. It works ok but not perfect. Just as Chris mentioned, there is some rendering problem of the dragger geometries. Anyone has idea of solving this problem? Thanks again! Ruqin On Tue, Jan 27, 2009 at 9:20 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ 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.7.9 dev release
Hi, Windows Vista 32Bit Geforce 8600M with NVIDIA notebook beta drivers Intel Core 2 Visual Studio 2008 SP1 Express Built OK, with some mutterings about 'cannot generate assignment operator', but I think we already touched on that one. Ubuntu 8.04 32Bit Linux 2.6.23.14 GeForce 8800GTS Intel Core 2 Builds OK. I turned on -Wextra and this causes warnings of the form 'class X should be explicitly initialised' in various copy constructors. Robert Osfield wrote: Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5286#5286 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
Hi Guys,
I'd like to wrap up this thread with some concrete actions.
Second, our make install isn't suggest anything about the need to add
the installed library directory to LD_LIBRARY (and other platform
specific env vars) or ld.so.conf which could do with addressing. I'm
now cmake expert so could someone with better cmake skills than I step
in and have a look at this.
You can do something like this:
ADD_CUSTOM_TARGET(ldlibpath_warning ALL DEPENDS tracker COMMENT Do not
forget to add ${CMAKE_INSTALL_PREFIX}/lib to LD_LIBRARY_PATH environment
variable)
Of course, replace the target tracker with target that gets built
last, e.g. install. It will print the message specified after COMMENT.
However, I am cmake rookie at best, so feel free to improve it :)
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJf0Nhn11XseNj94gRAnlnAKCcdNwWPmkt4LwucrsYbpg6DFun2wCg5wlu
m5OhmSRThQl9dVeOYyr7xd8=
=rfUZ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Sure, I'd like to try it. Thanks! Ruqin On Tue, Jan 27, 2009 at 11:04 AM, Chris Denham c.m.den...@gmail.com wrote: Have you tried my earlier suggestion?i.e. adding a post render camera just above the dragger. Can be a bit fiddly to manage the scenegraph, so might be worth trying any other ideas first. But I can give you some code snippets if you want to try it. Chris. - Original Message - From: Ruqin Zhang To: Chris Denham ; osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 4:45 PM Subject: Re: [osg-users] Dragger rendering issue Thank you guys! I tried the idea of turning off the depth test. It works ok but not perfect. Just as Chris mentioned, there is some rendering problem of the dragger geometries. Anyone has idea of solving this problem? Thanks again! Ruqin On Tue, Jan 27, 2009 at 9:20 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin -- Research Assistant Human Computer Interaction Program Virtual Reality Applications Center(VRAC) Iowa State University ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug: Light management and slave cameras
Hi Alexandre, I have some intial finding w.r.t the lighting turning off in the scene when you use: view-setLightingMode(osg::View::NO_LIGHT); The reason why this unlights the scene, is because the scene graph setup lacks any enabling of GL_LIGHTING, and it was only visible because when LightingMode != NO_LIGHT that the internal SceneView would enable GL_LIGHTING by default. So not getting any lighting in the scene is actually correct for the viewer and scene graph setting. So rather --addslave revealling a bug, it actually makes the code work as you've set the scene graph/viewer up as. Adding the following line to osglight.cpp fixes this problem, as it explicitly enables lighting for the scene you want to light. rootnode-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::ON); Now, the question for me is why adding the slave fixes things, and why without the slave the defaults are having an effect. It looks like an order of initialisation issue - i.e. the master camera and it's Renderer intialize with the defaults of the HEADLIGHT which enables the GL_LIGHTING mode by default, but the later reset of the LightingMode to be NO_LIGHT doesn't actively change the GL_LIGHTING mode/enable disable. I will continue to look into this, but once I do fix it the behaviour we should see is that there will be no lighting enabled by default if you do NO_LIGHT. I hope this makes sense. Robert. ___ 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.7.9 dev release
Hi Tony, Could you send me the warnings, as I and others can't do anything about unless we know where they are and what is causing them. Robert. On Tue, Jan 27, 2009 at 5:07 PM, Tony Horrobin a.j.horro...@its.leeds.ac.uk wrote: Hi, Windows Vista 32Bit Geforce 8600M with NVIDIA notebook beta drivers Intel Core 2 Visual Studio 2008 SP1 Express Built OK, with some mutterings about 'cannot generate assignment operator', but I think we already touched on that one. Ubuntu 8.04 32Bit Linux 2.6.23.14 GeForce 8800GTS Intel Core 2 Builds OK. I turned on -Wextra and this causes warnings of the form 'class X should be explicitly initialised' in various copy constructors. Robert Osfield wrote: Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5286#5286 ___ 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.7.9 dev release
Hi Robert, The Windows warnings are caused by having const references but not declaring the copy/assignment private. I think a load of these had been fixed recently. Under Linux, an example would be: In file included from osgal/examples/osgalocclude/osgalocclude.cpp:43: include/osgViewer/ViewerEventHandlers: In copy constructor ‘osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)’: include/osgViewer/ViewerEventHandlers:393: warning: base class ‘class osg::Object’ should be explicitly initialised in the copy constructor From a simple test case, it appears that the default constructor is called instead. The flags used were: -Wall -Wextra -Wno-unused-parameter Cheers, -Tony Robert Osfield wrote: Hi Tony, Could you send me the warnings, as I and others can't do anything about unless we know where they are and what is causing them. Robert. On Tue, Jan 27, 2009 at 5:07 PM, Tony Horrobin wrote: Hi, Windows Vista 32Bit Geforce 8600M with NVIDIA notebook beta drivers Intel Core 2 Visual Studio 2008 SP1 Express Built OK, with some mutterings about 'cannot generate assignment operator', but I think we already touched on that one. Ubuntu 8.04 32Bit Linux 2.6.23.14 GeForce 8800GTS Intel Core 2 Builds OK. I turned on -Wextra and this causes warnings of the form 'class X should be explicitly initialised' in various copy constructors. Robert Osfield wrote: Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5286#5286 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5293#5293 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vehicle at constant velocity
Jean-Sebastien, Robert and all, I'm afraid I already have the KB896256 patch installed because I have Windows XP sp3. I will try to update the nvidia drivers to see if the timer problems are solved. Thank you, Alfonso ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vehicle at constant velocity
Jean-Sebastien, Robert and all, I'm afraid I already have the KB896256 patch installed because I have Windows XP sp3. I will try to update the nvidia drivers to see if the timer problems are solved. Thank you, Alfonso ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vehicle at constant velocity
Hi Alfonso, I'm afraid I already have the KB896256 patch installed because I have Windows XP sp3. I will try to update the nvidia drivers to see if the timer problems are solved. Hmmm, it was just a guess anyways. I have never really seen timer inaccuracies of the order you describe... I'm afraid you're on your own on this. Sorry I couldn't help more. 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] Please test svn/trunk in prep for 2.7.9 dev release
Hi Tony, I don't need an explanation, I need the actual warnings generated. Please just copy the output to a file and post it. Thanks, Robert. On Tue, Jan 27, 2009 at 6:13 PM, Tony Horrobin a.j.horro...@its.leeds.ac.uk wrote: Hi Robert, The Windows warnings are caused by having const references but not declaring the copy/assignment private. I think a load of these had been fixed recently. Under Linux, an example would be: In file included from osgal/examples/osgalocclude/osgalocclude.cpp:43: include/osgViewer/ViewerEventHandlers: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor From a simple test case, it appears that the default constructor is called instead. The flags used were: -Wall -Wextra -Wno-unused-parameter Cheers, -Tony Robert Osfield wrote: Hi Tony, Could you send me the warnings, as I and others can't do anything about unless we know where they are and what is causing them. Robert. On Tue, Jan 27, 2009 at 5:07 PM, Tony Horrobin wrote: Hi, Windows Vista 32Bit Geforce 8600M with NVIDIA notebook beta drivers Intel Core 2 Visual Studio 2008 SP1 Express Built OK, with some mutterings about 'cannot generate assignment operator', but I think we already touched on that one. Ubuntu 8.04 32Bit Linux 2.6.23.14 GeForce 8800GTS Intel Core 2 Builds OK. I turned on -Wextra and this causes warnings of the form 'class X should be explicitly initialised' in various copy constructors. Robert Osfield wrote: Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5286#5286 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5293#5293 ___ 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] Rendering double-sided surfaces.
Thank you all for suggestions, I'll try them as soon as possible and will let you know. Regards. Alessandro On Mon, Jan 26, 2009 at 5:42 PM, Paul Martz pma...@skew-matrix.com wrote: Yes, two sided lighting was what I was going to suggest, but you beat me to it. Note that two sided lighting is deprecated in OpenGL 3.0, so you should consider looking for a shader-based solution instead. In the shader, if the dot product of the normal and eye vector is negative, just negate it, then calculate lighting as usual. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of frankmil...@jhmi.edu Sent: Monday, January 26, 2009 8:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Rendering double-sided surfaces. For sure the best thing to do would be to process the incoming data as suggested. However, you might be able to get OpenGL to do what you want by setting all material properties for both sides of the polygon and enabling two sided lighting. Something like this. osg::ref_ptr osg::LightModel pLightModel = new osg::LightModel(); pLightModel-setTwoSided( true ); pState-setAttributeAndModes( pLightModel.get(), osg::StateAttribute::ON ); osg::ref_ptrosg::Material pMaterial = new osg::Material(); pMaterial-setColorMode( osg::Material::DIFFUSE ); pMaterial-setAmbient( osg::Material::FRONT_AND_BACK, osg::Vec4( 0.0, 0.0, 0.0, 1.0 ) ); pMaterial-setSpecular( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0, 1.0, 1.0, 1.0 ) ); pMaterial-setShininess( osg::Material::FRONT_AND_BACK, 64.0f ); pState-setAttributeAndModes( pMaterial.get(), osg::StateAttribute::ON ); I have never tried this for data like you have but it seems to me like it should work. Frank On Mon, Jan 26, 2009 at 04:21:41PM +0100, alessandro terenzi wrote: Problem is that the models that come to my application are already prepared by people that do not (and unfortunately won't) think about normals issues, so maybe the best thing to do would be to really render both front and back faces, I'm not an expert, but the only approach I can think is to double the geometry so to have both faces, but it would be really a waste (not to mention performace problems that may arise..and other unexpected visualization problems I cannot think of..) Regards. Alessandro On Mon, Jan 26, 2009 at 1:37 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: your triangles all need to be wound the same way (anticlockwise by default for OSG Opengl), whether or not your normal's are correct The easiest fix would be to ensure that your modeling package sets up correct normal's before you get to OSG Assuming your triangles are wound the same way ( if not you will have to fix that ) try using the SmoothingVistor on the data see include\osgUtil\SmoothingVisitor *Gordon* __ *Gordon Tomlinson* *Product Manager 3D **Email * : gtomlinson @ overwatch.textron.com __ *(C): (+1) 571-265-2612 (W)**: (+1) 703-437-7651* Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - *Master Tambo Tetsura* -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *alessandro terenzi *Sent:* Monday, January 26, 2009 7:09 AM *To:* OpenSceneGraph Users *Subject:* [osg-users] Rendering double-sided surfaces. Sometimes my application has to load models that have normals not always oriented in the same coherent way, so it is not always possible to say that a surface is oriented in a way or in another and my renderings do not look correct. I'd like to fix this problem in some way...so I was thinking about rendering both front and back faces, but how do I ask OSG do this? Or perhaps, is there another way/technique to achive the same result? (ie. orient a surface in a coherent way: all faces inward XOR outward) Thank you. Alessandro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap h.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] Bug: Light management and slave cameras
Hi Alexandre, On Tue, Jan 27, 2009 at 5:29 PM, Robert Osfield robert.osfi...@gmail.com wrote: Now, the question for me is why adding the slave fixes things, and why without the slave the defaults are having an effect. It looks like an order of initialisation issue - i.e. the master camera and it's Renderer intialize with the defaults of the HEADLIGHT which enables the GL_LIGHTING mode by default, but the later reset of the LightingMode to be NO_LIGHT doesn't actively change the GL_LIGHTING mode/enable disable. I will continue to look into this, but once I do fix it the behaviour we should see is that there will be no lighting enabled by default if you do NO_LIGHT. I have now tracked down the inconsitency to osgUtil::SceneView not passing on changes the GL_LIGHTING mode when the LightingMode is toggled on/off. I've now fixed this and checked it into svn/trunk. This fix, will mean that in your example both with and without the slave Camera will behave the same, both won't have GL_LIGHTING mode enabled - which is exactly what you've told the viewer to do, and since the scene graph doesn't explictly enable GL_LIGHTING then this mode remains off, so no OpenGL lighting is enabled. To enable it you simple enable it manually in the scene graph, since you are managing your lighting in the scene graph then it makes perfect sense that you you be enabling the GL_LIGHTING mode for the subgraphs that require OpenGL lighting. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] looking for latest prebuilt windows binaries and winforms examples
Hi Peter, On 1/27/09, pe...@jumbovision.com.au pe...@jumbovision.com.au wrote: Hello i was wondering if there were pprebuilt binaries available for download for windows for use with VS2008 c++ for the latest released versions of OSG. There is a set of prebuilt binaries here: http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing A recent post suggests updates to this zip so it might get updated in near future. I seem to only be able to find up to v2.4. In addition is there any site/info that has examples for having osg viewer running in a dotNET winforms form/panel. So i wanted to use the winforms/dotnet part for GUI and display, and unmanged c++ for the rest of OSG stuff. Any tutorials on integrating these two in this manner ? Can't help you here but try: http://www.openscenegraph.com/projects/osgDotNet Mattias thanks for any help, its been a long while since i last looked at osg, and i cam up empty on searching the net for these thanks Peted ___ 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] Dragger rendering issue
Hi Chris, can I have a look of the chunk of code you mentioned? Thanks a lot! Ruqin On Tue, Jan 27, 2009 at 11:04 AM, Chris Denham c.m.den...@gmail.com wrote: Have you tried my earlier suggestion?i.e. adding a post render camera just above the dragger. Can be a bit fiddly to manage the scenegraph, so might be worth trying any other ideas first. But I can give you some code snippets if you want to try it. Chris. - Original Message - From: Ruqin Zhang To: Chris Denham ; osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 4:45 PM Subject: Re: [osg-users] Dragger rendering issue Thank you guys! I tried the idea of turning off the depth test. It works ok but not perfect. Just as Chris mentioned, there is some rendering problem of the dragger geometries. Anyone has idea of solving this problem? Thanks again! Ruqin On Tue, Jan 27, 2009 at 9:20 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
Jeremy, I was looking at your osgPango node kit and would actually love to use it, but what else would be required? We are ported to Windows and will also need to support Mac, not Linux or Unix at this point. We are pretty fussy about the entire user experience and the current osgText implementation gives a rather chunky result at times. Date: Tue, 27 Jan 2009 11:17:11 -0500 From: Jeremy Moles jer...@emperorlinux.com Subject: Re: [osg-users] Anti-Grain and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 1233073031.3353.40.ca...@dhcp196.emperorlinux.com Content-Type: text/plain; charset=UTF-8 On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.htmlThanks, Kurt __ Windows Live? Hotmail??more than just e-mail. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] possible bug in cfg plugin
I noticed a bug in the 2.6.0 version of the API with the viewer config
file reader plugin. I can't access the latest developer source code
right now so I can't verify that the bug still exists in the 2.7 version
of the API, but I've attached the config file that I used to reproduce
the problem. The problem is that the plugin causes a segfault when it
reads that configuration file because the _realized member variable of
the RenderSurface class defined in src/osgPlugins/cfg/RenderSurface.cpp
is never given an initial value. Interestingly enough this problem does
not occur on my Linux box, which is running Redhat Enterprise Client 5.
However, on my Windows box with Visual Studio 2005 Professional the
_realized variable is auto-initialized to true which ends up causing the
segfault to occur. I'm guessing, but haven't verified, that the reason
it works on my Linux box is because the GCC compiler auto-initializes
the variable to false which prevents the bug from occurring.
Here is how I ran the osgviewer to get it to crash:
osgviewer -c oneWindow.cfg name of osg file
I also found that once I went into the ReaderSurface's constructor and
added _realized = false; to it then the bug went away.
Alex
Camera Camera 1
{
RenderSurface GDE Viewer {
Visual { SetSimple }
Screen 0;
WindowRect 0 0 1024 768;
Border on;
}
Lens {
Perspective 40.0 30.0 1.0 1.0;
}
Offset {
Shear 0.0 0.0;
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Tue, 2009-01-27 at 18:33 -0500, Kurt Sierens wrote: Jeremy, I was looking at your osgPango node kit and would actually love to use it, but what else would be required? We are ported to Windows and will also need to support Mac, not Linux or Unix at this point. We are pretty fussy about the entire user experience and the current osgText implementation gives a rather chunky result at times. I'm headed out the door now, so I'll respond more tomorrow. :) Useless, I know. And yes, osgText is horrid if you CARE about font quality, but we appear to be the minority. Date: Tue, 27 Jan 2009 11:17:11 -0500 From: Jeremy Moles jer...@emperorlinux.com Subject: Re: [osg-users] Anti-Grain and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 1233073031.3353.40.ca...@dhcp196.emperorlinux.com Content-Type: text/plain; charset=UTF-8 On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.html Thanks, Kurt __ Windows Live? Hotmail??more than just e-mail. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reproducing multi-threaded viewer + on screen camera/view crash
Hello Robert, Could send me the small .ive file that you've used to reproduce this problem. Could you also try reproducing the problem at your, but please don't do an svn update quite yet as last night I checked in a fix for the threading issues in Camera sets query - the one that your crash point suggested was the problem. Once you have reproduced it, could you then do an svn update to see if my fixes address this problem. The View stats code is still working in the original non thread safe way. Like the changes I made for the Camera stats code I will be re-factoring the stats collection so it works in a thread safe way. This should be complete in the next couple of hours. I did an update and neither Camera nor View stats cause a crash anymore. perfect, thanks Uwe -- \\\|/// *HLRS, High Performance Computing Center Stuttgart* _I_ ( o o )*Visualization/VR* _I_ (_...@_)--oo0O--(_)--O0oo--(_...@_) | |Uwe Woessnerhttp://www.hlrs.de/people/woessner/ | | | | .ooo0 mobile: +49-173-7028729| | |_| ( ) Oooo. office: +49-711-6856-5790 |_| (_...@_)---\ (---( )-(_...@_) I \_) ) /I (_/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] packaging wiki
Hi all, I have added some cpack support documentation to http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging While editing I removed Roberts draft since they got outdated in the process. Much of it (like dependency hints) were reused and lives on. Teh page is currently not very pretty but I will be editing it through this week. Proposals (additions, errors, whatever) are welcome. An idea was to move it from Community/Packaging to Support/CPack. Ok? I also intend to update the Support/CMake page. The todo list at the bottom is a bit out of date Mattias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
Haha, as soon as I posted this I knew that was going to be the response. I know there are several ways to do armatures in blender, my basic test process has been this: 1) create a long box 2) subdivide a bunch of times 3) create a vertex group 4) create the armature (2 bones) 5) add an armature modifier to the box 6) parent the armature to the box (CTRL-P) This apparently doesn't work, is there a different process that the exporter requires? I'll submit a file if that is needed. Thanks for the continued help guys! I really appreciate it. -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Target Question
Hi Paul, paul1...@yahoo.com wrote: I'm attempt to develop a Multiple Render Target (MRT) program and have a few questions.. First, I see this in the osgstereomatch example: Two textures are needed, because shaders cannot read and write to the same texture during calculation. One texture is used as input and the other as output. After a calculation, the input and output textures are swapped. The technique is known as ping-ponging or flip-flopping the textures. What does this mean? Can I have the same texture defined as input (assigned to the StateSet) and still have it attached (but not used) as a render target? I'm not sure if it will work. If the current output depends on the previous output you need to fill a single of two targets (the current output) while reading from the other (the previous output). If the targets are attached to the same RTT camera I'm not sure how you can write to one but not write to the other one. In short, I see how I can ping-pong the input by changing the texture uniform but how do I ping-pong the attached render buffer? Can I attach all my render targets but then not use them (if it's an input)? In all the code that I've made, I've ping-ponged the attached textures by swapping between two osg RTT cameras. The simplest example of this is osggameoflife. There are other ways to swap, but they are not easy to do with base osg (I think, but am not sure, that osgPPU might help). For the options, have a look at this: http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html search for ping pong. The disadvantage of the two camera approach is that we are wasting FBOs. An easier way to change attachments would help. What happens if you do read and write to the same texture each frame? Craziness. Try it. Think of multiple processes reading and writing to the same memory in parallel. If there is any dependency between in/out the data will get corrupted. Also, does this clear all my render targets (between frames): _Camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); I think so, but write out the buffers to check. What I'm trying to do is calculate a temporal averaging of a specific number of consecutive frames. I assume I need to keep a running average of frames as well as well as save each of the frames. Then each frame: SUM = (SUM - oldestFrame + newFrame) and Output = SUM/numberOfFrames; You might be able to get away with just storing a running average. You can do something like: time_constant = 10; avg = ((time_constant-1)*avg + new_image)/time_constant; This in effect creates a low-pass filter. I think I'm done asking questions for now :-). Thanks for any help you can provide... Paul cheers jp ___ 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
