Re: [osg-users] Tips for low-end GPUs?
Hi Cyril, Cyril Brulebois writes: Hi, [...] Random thoughts: - dimensions/resolutions (maybe some “native” screen/window size are better than others in order to limit resizing overhead)? - texture blending modes (how transparency is handled, etc.)? - level of detail (there is even osg::LOD for that)? - use a tree-like scene-graph (rather than a flat one) to ensure osg will do its job properly? - checking compositing on X's side (forgot to mention: running Linux machines)? acceleration type (EXA et al.)? I know there's also the “stats” display that might be of some help, and it indeed shows that most of the time is spent during “Draw”. I should mention I've tested with both OSG 2.4 and 2.8 on both desktops and laptops, and it looks like versions don't have much impact on performances, only GPUs do. (To give an idea, I'm at 100-150+ FPS with Nvidia, limited to either 60 or 75 via vblanc sync, and around 10-15 FPS with Intel.) Hardware is like Intel Core 2 Duo, 2 GB RAM. The application isn't eating more than a few MB so RAM clearly isn't the bottleneck. A single CPU out of 2 seems to be used, around 50%, so that probably isn't the bottleneck either. So, if you have any rules of thumb to share about how to get a better framerate on low-end GPUs, I'll be very pleased to read them. :) I think you are already on the right track. From your description, your program bottleneck seems to lie on the card fill rate and/or texture handling. Tips for diminishing that work would be: - As you mentioned, lowering the resolution of the rendering window as much as you can. - Lowering the resolution of the textures you are employing or inspecting if you can go faster through the use of mipmapping. The results will vary with the amount of available GPU RAM you have. - Try to disable as many blending effects you can. - Use LODs mainly for that purpose, in order to deactivate blending effects on farther objects where they can't be seen so well. - Set the cheapest texture filters that you can cope with, NEAREST ones are the fastest. - Disable any anti-aliasing or oversampling. Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tips for low-end GPUs?
Hi Cyril, I'm afriad getting low end performance from low end graphics hardware is something we have to live with and do our best to work around. In some cases app developers can recommend to their end users they use more suitable hardware, I know even in some cases they have bought graphics hardware for their clients just to avoid issues with performance and driver quality. If you are stuck having to support low end hardware then you'll need to work out what the bottlenecks are and address them accordingly. The same principles will work for all hardware - are you CPU limited? GPU limited? Fill limited or transform limited? Lots of questions and there will be even more answers. Performance optimization is a *huge* topic covered many times on osg-users so I recommend you do searches on this this topic. Robert. On Tue, Nov 3, 2009 at 9:38 PM, Cyril Brulebois cyril.bruleb...@kerlabs.com wrote: Hi, I've been very happy developing using OSG but unfortunately, even “simple” graphics¹ tend to result in very low performance on Intel GPUs (which happen to be very common on wide-spread desktops and laptops); while I ACK that well, there are better GPUs available, it'd still be nice to be able to somehow run the app I've developed on other machines without having to upgrade them, so I've been wondering whether there are some guidelines to help getting things “easier” on the GPU. Random thoughts: - dimensions/resolutions (maybe some “native” screen/window size are better than others in order to limit resizing overhead)? - texture blending modes (how transparency is handled, etc.)? - level of detail (there is even osg::LOD for that)? - use a tree-like scene-graph (rather than a flat one) to ensure osg will do its job properly? - checking compositing on X's side (forgot to mention: running Linux machines)? acceleration type (EXA et al.)? I know there's also the “stats” display that might be of some help, and it indeed shows that most of the time is spent during “Draw”. I should mention I've tested with both OSG 2.4 and 2.8 on both desktops and laptops, and it looks like versions don't have much impact on performances, only GPUs do. (To give an idea, I'm at 100-150+ FPS with Nvidia, limited to either 60 or 75 via vblanc sync, and around 10-15 FPS with Intel.) Hardware is like Intel Core 2 Duo, 2 GB RAM. The application isn't eating more than a few MB so RAM clearly isn't the bottleneck. A single CPU out of 2 seems to be used, around 50%, so that probably isn't the bottleneck either. So, if you have any rules of thumb to share about how to get a better framerate on low-end GPUs, I'll be very pleased to read them. :) Cheers, -- Cyril Brulebois Details: ¹: That is some dozens/hundreds of geometrical forms (boxes, spheres with uniform textures), a few of them being transparent somehow, only colours/sphere radius/positions of some spheres change; using a single camera; and with some texts as overlay, HUD-like. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrwou8ACgkQ0bIwSk8kpU5k/ACeJvJnkllhZEqEtbIKl6kOw6yh HJQAoIMT5tYB/anqMMecxYV2m/pHxT7M =J88J -END PGP SIGNATURE- ___ 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] Setting up VPBMaster
On Tue, Nov 3, 2009 at 10:13 PM, Riepl, David M david.m.ri...@boeing.com wrote: Regarding your questions on what osgdem does if it crashes... 1) No, it cannot pick back up from where it left off and continue on. You would have to start over and hope for better results. I always suffered from laughable experiences where it would be on the 10th day of a build and the power would go out. Just for clarification, osgdem itself can't pick up on a partial build, but a vpbmaster can pick up from an aborted/failed build - as it breaks the whole job down into potentially thousands of task (even hundreds of thousands in large databases) and each task is dispatched in parallell for osgdem to build. Each of these tasks can't be partially built and then restarted so will have to be repeated in full if it aborts, but overall this is not a big overhead as each task only task a small portion of the overall build. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] 3D model material display error!
Set the alpha on the model to 0 when it's above water and the glare
won't appear on the model
if(osgOcean_EnableGlare){
final_color.a = 0.0;
}
Alternatively tweak the glare intensity from OceanScene. All the
functions have been commented in the header.
K.
2009/11/4 Tian Ma tianxiao...@foxmail.com:
Hi Kim:
Thank you for the useful informations!
I could understand the default shader code a little now.
When I apply the default shader to the model, it looks a little bit
too shinning and glaring Can I weaken the glaring thing?
Regards,
MT
Kim Bale wrote:
Hi MT,
If you open boat.3ds in osgviewer you will notice that the model
itself is white. It doesn't have any textures on it and it's there
purely as a test case for the collision. But yes the default shader
has been added to it.
Will you please give us a example about how to add a model to the
oceanScene to keep what they are?
The terrain is an external model that has a custom shader applied to
it, you can look at that. Alternatively look at the default shader
source.
K.
2009/11/3 Tian Ma :
Hi Kim:
I have downloaded the newest version through SVN, and also compiled the
code successfully.
When I turn on the oceanExample's testCollision, I found that the
boat.3ds model is just white, the same situation I met before. Is this
what the example just want to show us?
In the example, you did not add any shader to the model. Does this
mean that: a default shader was added to the model? But why the model
looks just white?
Will you please give us a example about how to add a model to the
oceanScene to keep what they are?
Regards,
MT
Kim Bale wrote:
Hi MT,
For the reasons I just gave, you can't add objects to the scene and
have the full compliment of effects without either using the default
shader or using your own shader implementation.
Reflections/refractions etc will continue to work since they act on
the ocean surface and not the model. However, other such as glare,
depth of field, light scattering, fogging etc will not as they act on
the models themselves.
However, it is pretty straight forward to duplicate a subset of fixed
pipeline functionality within a shader and then add the relevant
osgOcean shader effects to it, you can just copy functions from the
default shader and mix them in with the result of your shader.
K.
2009/11/2 Tian Ma :
Hi Jan,Kim:
Thank you a lot.
Kim, does it means that: I can never keep the models looks like
what they are before? And I have to program shaders for every loaded
models, in order to have reflect or other effects?
I want to know that: is there a simple way to make the models just
look like what they are?
Kim Bale wrote:
Hi Jan, Tian,
osgOcean uses shaders for pretty much every effect in the scene -
fogging, depth of field, glare, lighting etc. If objects that are
added to the scene are to look consistent with the ocean effects they
will require a shader to be applied that takes into account these
effects. This is particularly necessary if the fullscreen effects are
used as they require the alpha component of the frame buffer to work.
In order to address this issue, OceanScene will apply a default
shader
to objects added as children (default_scene.frag vert) which
illustrates how to use the uniforms supplied by osgocean (prefixed
osgOcean_* ) in conjunction with your own shader. Since I could not
anticipate the many wierd and wonderful ways that shaders can be used
it only offers a very basic implementation (1 texture unit, limited
phong lighting etc) and should be seen as a shader to customise and
build on yourself.
You can override the default shader either by attaching a new program
to the object you wish to use in the scene or by using this function
in OceanScene:
/** Override the default scene shader for custom shaders.
* If custom shaders are required for individual nodes add them
before adding to the OceanScene.
* Dirties state.
*/
void setDefaultSceneShader( osg::Program* program )
{
_defaultSceneShader = program;
_isDirty = true;
}
Alternatively you can turn the default shader off completely with
setter in OceanScene.
Regards,
Kim.
2009/11/2 Jan Ciger :
Tian Ma wrote:
Hi,
When I load a model into the osgOcean scene, the model looks
white all
over, without any material. Anybody knows why?
Yes, I have seen the same thing. I believe that the shaders
applied by
osgOcean are responsible and are not passing the
Re: [osg-users] Setting up VPBMaster
On Tue, Nov 3, 2009 at 5:12 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Well, I don't know that the development team for OpenSceneGraph is a clearly defined set. By volume, Robert is the author of the vast majority of the OSG source code, but there's a long list of other contributors as well. I'm not quite as prolific as Chris makes out ;-) I'm the lead author of the of the core libosg, libosgUtil, osgDB, osgViewer and a few of the NodeKits, but far this is far from the majority of the OSG source code, the majority of the OSG code base is actually found in the plugins which are predominantly work of the community and this is no small feat. At last count we had 390 contributors, guess we might even get to the big 400 contributors, before with hit 3.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture on Cylinder
Hi Nils,
It's likely going dark because the surface normals are all pointing
outwards. Switch lighting of for the ShapeDrawable using:
stateset-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
Robert.
On Wed, Nov 4, 2009 at 1:19 AM, Nils
werbung.openscenegraph@drego.de wrote:
Hey,
I would like to build a simple panorma program with osg.
I used a Cylinder and a similiar Code to sampleshape:
osg::Geode* geode = new osg::Geode();
// ---
// Set up a StateSet to texture the objects
// ---
osg::StateSet* stateset = new osg::StateSet();
osg::Image* image = osgDB::readImageFile( Images/lz.rgb );
if (image)
{
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
stateset-setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON);
}
geode-setStateSet( stateset );
float radius = 50.0f;
float height = 20.0f;
osg::TessellationHints* hints = new osg::TessellationHints;
hints-setDetailRatio(0.5f);
geode-addDrawable(new osg::ShapeDrawable(new
osg::Cylinder(osg::Vec3(6.0f,0.0f,0.0f),radius,height),hints));
When I zoom into the cylinder, everything is dark and I cant see my texture.
What can I do?
Thanks,
Nils
___
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] [build] error LNK2019: unresolved external symbol __declspec(dllimport)
Hi, I'm trying to build osg project. I'm having some problems during linking time :- 1Linking... 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) (__imp_?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@1@@Z) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: class osgDB::ReaderWriter::Options * __thiscall osgDB::Registry::getOptions(void) (__imp_?getopti...@registry@osgDB@@qaepavopti...@readerwriter@2...@xz) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: static class osgDB::Registry * __cdecl osgDB::Registry::instance(bool) (__imp_?insta...@registry@osgDB@@sapa...@_n@Z) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class osg::Image * __cdecl osgDB::readImageFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) (__imp_?readimagef...@osgdb@@yapavim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@1@@Z) referenced in function class osg::Image * __cdecl osgDB::readImageFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?readimagef...@osgdb@@yapavim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1C:\OSG\Program\AutoTransform\Debug\AutoTransform.exe : fatal error LNK1120: 4 unresolved externals [/code/] What is wrong? Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19151#19151 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] error LNK2019: unresolved external symbol __declspec(dllimport)
Hi Manish Did you add osgDB.lib in the linker input ? Vincent. manish Choudhary a écrit : Hi, I'm trying to build osg project. I'm having some problems during linking time :- 1Linking... 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) (__imp_?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@1@@Z) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: class osgDB::ReaderWriter::Options * __thiscall osgDB::Registry::getOptions(void) (__imp_?getopti...@registry@osgDB@@qaepavopti...@readerwriter@2...@xz) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: static class osgDB::Registry * __cdecl osgDB::Registry::instance(bool) (__imp_?insta...@registry@osgDB@@sapa...@_n@Z) referenced in function bool __cdecl osgDB::writeImageFile(class osg::Image const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?writeimagef...@osgdb@@ya_nabvim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1AutoTransform.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class osg::Image * __cdecl osgDB::readImageFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) (__imp_?readimagef...@osgdb@@yapavim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pbvopti...@readerwriter@1@@Z) referenced in function class osg::Image * __cdecl osgDB::readImageFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?readimagef...@osgdb@@yapavim...@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) 1C:\OSG\Program\AutoTransform\Debug\AutoTransform.exe : fatal error LNK1120: 4 unresolved externals [/code/] What is wrong? Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19151#19151 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Information from ESET NOD32 Antivirus, version of virus signature database 4571 (20091104) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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 Shadows
Hi, thanks for the suggestion, with RTT slave views it works. tugkan Hi Tugkan, Somebody recently, also mentioned that nested cams not work with LiSPSM. Frankly, I have no time to investigate this. I would recommend using RTT slave views instead of nested RTT cam. I think this will have more chance to work as intended. I apologize for trouble. Wojtek Lewandowski - Original Message - From: Tugkan Calapoglu tug...@vires.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, November 03, 2009 9:10 AM Subject: [osg-users] Render to texture and Shadows Hi All, I am using Light Space Perspective Shadow Maps for shadowing. I would like to render the shadowed scene to a texture, so I have another camera on top of the shadowed scene. It looks like following: root | RTTCamera | ShadowedScene I also render a small sized screen aligned quad which visualizes the texture to which RTTCamera is rendering. When there is no RTT, shadows work as expected. However, when I am rendering onto the texture, there are no shadows. I can see the scene on the screen aligned quad but it simply has no shadows. When I debugged the application I found out that StandardShadowMap::ViewData::selectLight does not find the light. Following line should normally give a list of matrices/attrib pairs rs-getPositionalStateContainer()-getAttrMatrixList(); however, it returns an empty list. I am not familiar with the implementation of Shadows in OSG so I got stuck here. Does anybody have an idea? Thanks, Tugkan ___ 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 -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463641 fax +49.8031.463645 emailtug...@vires.com internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] Persistant texture modification using osgCompute / CUDA
Dear all,
I’m interested to see whether I can use osgCompute for my project’s goal, which
is real-time height-map deformation system. For starters, I’m trying to let an
osgCompute node modify a 2D OSG float texture (the height-map) each frame,
using a CUDA kernel.
My problem now is that I can’t get osgCompute to make persistent changes to the
source texture, it seems that either the CUDA kernel changes the texture only
once or that it performs the same changes each frame to the original texture
data. Any advice or hints on how to set up my buffers, textures and arrays in
osgCompute to achieve persistent changes would be greatly appreciated.
I’m using osgCompute 0.4 (with CUDA 2.3, OSG 2.8.2, VS 9.0 / WinXP) and I
started off with modifying the provided osgTexDemo example:
With regard to the original source code I changed the SrceBuffer and TempBuffer
to single dimension (linear) osg::Cuda::Arrays with the intent to alternatingly
read from, and write to, these respectively.
The extended (overloaded) osgCompute::Module::launch() alternatingly maps the
SrceBuffer and TempBuffer as the source and target for the primary Cuda kernel
respectively.
The setImage() call in the else is a hack to ensure that osgCompute cannot
overwrite the buffer with the original image again when mapping the buffer to
the device. This code so far has been tailored to simply try get it to work
based on the original example; I can image this not being to best approach
however.
Sincerely,
Asmar B. Arsala
(for code snippets see attachment)
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/// Setup
{
osg::Image *pImage = osgDB::readImageFile( Data//Image.bmp );
osgCuda::Texture2D *pTexture = new osgCuda::Texture2D;
pTexture-setInternalFormat( GL_RGBA );
pTexture-setSourceType( GL_UNSIGNED_BYTE );
pTexture-setElementSize( sizeof( osg::Vec4ub ) );
pTexture-setDimension( 0, pImage0-s() );
pTexture-setDimension( 1, pImage0-t() );
pTexture-setName( DestBuffer );
pTexture-addHandle( DEST_BUFFER );
pTexture-setFilter( osg::Texture2D::MIN_FILTER,
osg::Texture2D::NEAREST );
pTexture-setFilter( osg::Texture2D::MAG_FILTER,
osg::Texture2D::NEAREST );
osgCuda::Array *pSrceBuffer = new osgCuda::Array;
pSrceBuffer-setElementSize( sizeof( osg::Vec4ub ) );
pSrceBuffer-setChannelFormatDesc( CudaChannelFormatDesc );
pSrceBuffer-setDimension( 0, pImage-s() * pImage-t() );
pSrceBuffer-setImage( pImage );
pSrceBuffer-setName( SrceBuffer);
pSrceBuffer-addHandle( SRCE_BUFFER );
osgCuda::Array *pTempBuffer = new osgCuda::Array;
pTempBuffer-setElementSize( sizeof( osg::Vec4ub ) );
pTempBuffer-setChannelFormatDesc( CudaChannelFormatDesc );
pTempBuffer-setDimension( 0, pImage-s() * pImage-t() );
pTempBuffer-setName( TempBuffer );
pTempBuffer-addHandle( TEMP_BUFFER );
}
void CCudaModule::launch( const osgCompute::Context rContext ) const
{
static int iToggle = false;
static int iSwitch = true;
if( !isClear() )
{
void *pvSrceBuffer;
void *pvTempBuffer;
void *pvDestBuffer;
if( iToggle = !iToggle )
{
pvSrceBuffer = pSrceBuffer-map( rContext,
osgCompute::MAP_DEVICE_SOURCE );
pvTempBuffer = pTempBuffer-map( rContext,
osgCompute::MAP_DEVICE );
pvDestBuffer = pDestBuffer-map( rContext,
osgCompute::MAP_DEVICE_TARGET );
}
else
{
osgCuda::Array *pArray = static_cast osgCuda::Array*
( const_cast osgCompute::Buffer* ( pSrceArray ) );
if( pArray-getImage() ) pArray-setImage( NULL );
pvSrceBuffer = pTempBuffer-map( rContext,
osgCompute::MAP_DEVICE_SOURCE );
pvTempBuffer = pSrceBuffer-map( rContext,
osgCompute::MAP_DEVICE );
pvDestBuffer = pDestBuffer-map( rContext,
osgCompute::MAP_DEVICE_TARGET );
}
// KERNEL CALL 0
cuda_filter( NumBlocks, NumThreads, pvSrceBuffer, pvTempBuffer
);
// KERNEL CALL 1
cuda_copy( NumBlocks, NumThreads, pvTempBuffer, pvDestBuffer );
}
}
extern C
void cuda_filter( osg::Vec2s rNumBlocks, osg::Vec2s rNumThreads, void
*pvSrceArray, void *pvDestBuffer )
{
SrceTexture.normalized = true;
SrceTexture.filterMode = cudaFilterModeLinear;
SrceTexture.addressMode[0] = cudaAddressModeClamp;
SrceTexture.addressMode[1] = cudaAddressModeClamp;
Re: [osg-users] Setting up VPBMaster
Thanks again to everyone for their help with these questions. I've got a much better understanding of what's going on based on your feedback and information that was just presented to me yesterday by management. It turns out that the process I'm trying to implement now was designed over 2 years ago (right about when we were supposed to be receiving the OpenFlight data from our customer). The design was based on OSG-1.2, and VPBMaster wasn't even a twinkle in OSG's eye, if you will. By the time we received the OpenFlight data (June of this year), the engineer-in-charge of the process picked his design back up and began modifying his conversion tool to match some unexpected input from the data. Part of this re-design was accounting a 1000 x 1000 km DB, when we were expecting it to be 500 x 500 km. Unfortunately, he didn't foresee the issues we're having with Process Time and Data Storage back then. Now we're paying for it with program dollars, and I'm paying for it with a few gray hairs. I think it's obvious that VBPMaster is the tool for this job, but I don't think it's likely that I will get approvable to upgrade our version of OSG, get VPBMaster, and then test our process using these new tools. It's just too risky of a move this late in the game. I'm presenting these issues to management today, and I believe they will make the decision to lower the resolution over the entire database and re-run the process. I guess I just work for an old-school-minded company that's afraid of drastic or sudden change :). Anyway, thanks again to everyone for your input! It's greatly appreciated! Date: Wed, 4 Nov 2009 09:11:52 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster On Tue, Nov 3, 2009 at 5:12 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Well, I don't know that the development team for OpenSceneGraph is a clearly defined set. By volume, Robert is the author of the vast majority of the OSG source code, but there's a long list of other contributors as well. I'm not quite as prolific as Chris makes out ;-) I'm the lead author of the of the core libosg, libosgUtil, osgDB, osgViewer and a few of the NodeKits, but far this is far from the majority of the OSG source code, the majority of the OSG code base is actually found in the plugins which are predominantly work of the community and this is no small feat. At last count we had 390 contributors, guess we might even get to the big 400 contributors, before with hit 3.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Bing brings you maps, menus, and reviews organized in one place. http://www.bing.com/search?q=restaurantsform=MFESRPpubl=WLHMTAGcrea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up VPBMaster
Hi Jacob, I can't help too much with management decisions, but I would suggest that OSG-1.2 is less mature, less robust, less supportable and would not recommend that any new projects adopt it as a base - OSG-2.8.x is far more mature, debugged and far better supported, not to mention far better feature set. I would consider using OSG-1.2 over OSG-2.8 a project liability, and one that you may well have to carry for a long time going forward. I would further add that OSG-1.2 is no longer supported by myself or members of the community. I haven't personally been anywhere near the OSG-1.2 for several years. I like most of the OSG community are working on the OSG-2.x branch now. If you want to use OSG-1.2 then you are pretty well on your own w.r.t support/bug fixes. Moving from OSG-1.2 to OSG-2.x should be straight forward and will reduce your project risks now and going forward. Robert. On Wed, Nov 4, 2009 at 1:24 PM, Jacob Armstrong jaco...@hotmail.com wrote: Thanks again to everyone for their help with these questions. I've got a much better understanding of what's going on based on your feedback and information that was just presented to me yesterday by management. It turns out that the process I'm trying to implement now was designed over 2 years ago (right about when we were supposed to be receiving the OpenFlight data from our customer). The design was based on OSG-1.2, and VPBMaster wasn't even a twinkle in OSG's eye, if you will. By the time we received the OpenFlight data (June of this year), the engineer-in-charge of the process picked his design back up and began modifying his conversion tool to match some unexpected input from the data. Part of this re-design was accounting a 1000 x 1000 km DB, when we were expecting it to be 500 x 500 km. Unfortunately, he didn't foresee the issues we're having with Process Time and Data Storage back then. Now we're paying for it with program dollars, and I'm paying for it with a few gray hairs. I think it's obvious that VBPMaster is the tool for this job, but I don't think it's likely that I will get approvable to upgrade our version of OSG, get VPBMaster, and then test our process using these new tools. It's just too risky of a move this late in the game. I'm presenting these issues to management today, and I believe they will make the decision to lower the resolution over the entire database and re-run the process. I guess I just work for an old-school-minded company that's afraid of drastic or sudden change :). Anyway, thanks again to everyone for your input! It's greatly appreciated! Date: Wed, 4 Nov 2009 09:11:52 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster On Tue, Nov 3, 2009 at 5:12 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Well, I don't know that the development team for OpenSceneGraph is a clearly defined set. By volume, Robert is the author of the vast majority of the OSG source code, but there's a long list of other contributors as well. I'm not quite as prolific as Chris makes out ;-) I'm the lead author of the of the core libosg, libosgUtil, osgDB, osgViewer and a few of the NodeKits, but far this is far from the majority of the OSG source code, the majority of the OSG code base is actually found in the plugins which are predominantly work of the community and this is no small feat. At last count we had 390 contributors, guess we might even get to the big 400 contributors, before with hit 3.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Bing brings you maps, menus, and reviews organized in one place. Try it now. ___ 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] Crash in nVidia driver : particles + dynamically adding/removing views
Hi J-S, I've been having issues adding/removing Views to a CompositeViewer using osgEarth and VPB terrain databases and have the same issues in your example. There is *something* going on with regards to OSG's context ID reuse and not cleaning up resources properly. I played around with your example with osgEarth / VPB and found that I can open one new window fine, close it, and then get crashes when I load the second window. I tested with your program and I see the same thing with the precipitation effect. If you change the graphics context creation code to the following and uncomment the incrementContextIDUsageCount then your example seems to work fine with no shared context. This will force a new context ID to be created the next time a graphics context is created rather than trying to reuse the previous one. osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 60; traits-y = 60; traits-width = 800; traits-height = 600; traits-windowDecoration = true; traits-doubleBuffer = true; osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); //Uncomment the next line to force the next context to use a new ID rather than reuse a previous one //osg::GraphicsContext::incrementContextIDUsageCount( gc-getState()-getContextID() ); There is obviously something going on as your usage doesn't seem out of line to me, but I'm not quite sure what it is. Thanks, Jason On Wed, Nov 4, 2009 at 2:50 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi J-S, Jean-Sébastien Guay wrote: Hi all, Some might recall, about a year ago, I identified a bug and provided examples for nVidia to fix a bug in their driver when adding/removing views (graphics contexts) at run time in a multithreaded app. That's been working great for a while. Now I'm getting a crash in the nvidia driver when adding/and removing views dynamically at run time, but only when the scene contains an osgParticle::PrecipitationEffect (or a similar effect, such as the osgOcean::SiltEffect which was derived from PrecipitationEffect). I've put together an example app that demonstrates this. The code is attached. Note that you need to link to osg, osgDB, osgGA, osgUtil, osgViewer, osgText, osgParticle, and OpenThreads (as well as OpenGL32.lib on Windows for the straight OpenGL calls present in SiltEffect.cpp). The example app can be compiled to use either osgParticle::PrecipitationEffect (which comes from OSG, no modification), osgOcean::SiltEffect (which comes from osgOcean) or no effect. See the #define USE_EFFECT at the top of the osgviewer.cpp file. Once the app is running, you can press 'a' to spawn a new view (with a new graphics context). Press 'a' again to remove that second view. You can in theory do this many times, and it should work as many times as you want (open, close, open, close, ...). In my testing, the second time you spawn a new view (so pressing 'a' 3 times total), either the app crashes or the second view starts displaying weirdly (all gray). The crash occurs in nvogl32.dll which is part of the nVidia driver. Of course, when using neither PrecipitationEffect nor SiltEffect, no crash occurs. I can confirm that this occurs both on Windows (Vista 32bit, driver 190.62) and Linux (Ubuntu 64bit, 180.44). Though on Ubuntu, the app crashes much less often, but the second window displays weirdly (all gray) which happens sometimes on Windows too as mentioned above. Now, taking the SiltEffect for example, it seems that it's the drawing itself that causes problems, because commenting out the last 2 lines of SiltEffect::SiltDrawable::drawImplementation() (SiltEffect.cpp lines 805-806) removes the crash (of course then the effect is not visible anymore). Could someone please try this example to see if they can reproduce the issue? with #define USE_EFFECT SILT I get the gray screen in added view on 3rd 'a'. output: $ ./test cessna.osg Constructing PixelBufferObject for image=0x95d67e8 _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=131072 GLBufferObjectSet::GLBufferObjectSet _profile._size=32768 first 'a' Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=131072 GLBufferObjectSet::GLBufferObjectSet _profile._size=32768 second 'a' third 'a' Reusing orhpahned TextureObject, _numOfTextureObjects=1 Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) ... Debian 32-bit, Nvidia GeForce Go 7400, driver 185.18.36, OSG svn 10609. Hmm, what is strange is that the modified (extremely hacky) version attached does not crash and seems to work. It just uses a shared context, so maybe there is something in the context vs vertex array that is not working properly. jp Also, if someone could check the code I have and see if something
Re: [osg-users] Crash in nVidia driver : particles + dynamically adding/removing views
Hi J.P., with #define USE_EFFECT SILT I get the gray screen in added view on 3rd 'a'. Thanks for testing, that's what I saw too on Ubuntu. I expect if you use USE_EFFECT PRECIPITATION you'll see the same results. Hmm, what is strange is that the modified (extremely hacky) version attached does not crash and seems to work. It just uses a shared context, so maybe there is something in the context vs vertex array that is not working properly. Yes, well one of my hunches was that something in the context creation/reuse was buggy, since the problem appears because we're creating, then deleting, then creating contexts. I've traced into the code of the effect, and the same context ID seems to be reused the second time the secondary view is created (3rd 'a') as the first time (1st 'a'). That means that when getting the osg::Drawable::Extensions object, the same one that was created for the old context is reused for the new context. But that apparently isn't the problem, because if I force the Extensions object to be destroyed when the secondary view is closed (so that the next time it's spawned, a new Extensions object will be created) like so: // In doRemoveView(), between the stopThreading() and startThreading() unsigned int contextID = _view-getCamera()-getGraphicsContext()-getState()-getContextID(); _viewer-removeView(_view.get()); _view = 0; osg::Drawable::setExtensions(contextID, 0); it doesn't remove the crash. Also, I tried to make the scene delete all its OpenGL objects for all contexts, like so: // Again in doRemoveView() before the startThreading() _root-releaseGLObjects(); and it doesn't fix it either. So yes, it's probably related to the creation/deletion/reuse of contexts or context-specific objects, but I haven't been able to pinpoint it yet to something that's wrong in OSG itself. If anyone else would like to take up the challenge of explaining this mystery, please step up :-) 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] Crash in nVidia driver : particles + dynamically adding/removing views
Hi J-S, Jean-Sébastien Guay wrote: Hmm, what is strange is that the modified (extremely hacky) version attached does not crash and seems to work. It just uses a shared context, so maybe there is something in the context vs vertex array that is not working properly. Yes, well one of my hunches was that something in the context creation/reuse was buggy, since the problem appears because we're creating, then deleting, then creating contexts. I've traced into the code of the effect, and the same context ID seems to be reused the second time the secondary view is created (3rd 'a') as the first time (1st 'a'). That means that when getting the osg::Drawable::Extensions object, the same one that was created for the old context is reused for the new context. Did the shared context version I previously attached work on Windows? Just curious. When I tried it on Linux I could add/remove many times. rgds jp -- 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
[osg-users] Frame Count/Threading Models
I was using glXWaitVideoSyncSGI() in a Pre Draw Callback (the place I need it
to be) to get the current Frame Count from the video card. I've recently found
out that this Frame Count number from this function can be incorrect when I'm
reading textures from the GPU to the CPU or writing textures from the CPU to
the GPU. In particular, I would see about 100ms between calls to
glXWaitVideoSyncSGI but the frame counter returned would either be consecutive
(i.e. no missed frames) or skipping one number (i.e. one missed frame). I'm
running at 60 Hz (16ms frames).
Therefore, I'm now trying to use glXQueryFrameCountNV() (I have G-SYNC II card
and have enabled Frame Lock). It would appear I need to call this when I have a
valid Graphics Context. I assume this isn't normally the case in a
PreDrawCallback. I've had to do this in the PreDrawCallback:
if (camera.getGraphicsContext()
camera.getGraphicsContext()-valid()
camera.getGraphicsContext()-isRealized())
{
osg::GraphicsContext* gc =
const_castosg::GraphicsContext*(camera.getGraphicsContext());
gc-makeCurrent();
}
followed by my call to glXQueryFrameCountNV().
However, to make this work, I've had to set my osgViewer's threading model to
SingleThreaded. If I don't do this I usually see a Xlib: unexpected async
reply (sequence 0x6a)! message followed by a segmentation fault.
What am I doing wrong? Is there some better way to do something in a valid
graphics context when not in a draw callback?
Paul P.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash in nVidia driver : particles + dynamically adding/removing views
Hi J.P., Did the shared context version I previously attached work on Windows? Just curious. When I tried it on Linux I could add/remove many times. Yes, it does. I don't quite understand the tradeoffs of using shared contexts. Does it mean the draws to both windows won't be multithreaded but need to be serialized? What other tradeoffs are there? There has to be a downside, otherwise we'd always use only one context shared across all windows, right? 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] Change to Optimizer OptimizationOptions
Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. Wow, that's really interesting. I never imagined there were so many bitflag/mask patterns available. But I imagine you guys already know how I feel about this. :-) Personally, I already feel that using an enum to store bitflags is overkill. Defining an entire class to implement the bitflag/mask pattern along with set/get methods strikes me as the epitome of C++ abuse. I don't think I can back this, not even if measurements indicate no memory or performance bloat. It's an unnecessary layer of obfuscation. Using bitwise logic ops and unsigned bits/masks makes it perfectly clear what is happening, even at the assembly level. It reduces the potential for error and makes the code more readable. It works great in this simple form. It's not broke, and does not need to be fixed with a new C++ class. But I'm content to let Robert make the final call on this one. Clearly, we can't agree on a path forward ourselves. Further discussion is pointless; we should wait until he wraps up GL ES 2 and has time to respond to this issue. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up VPBMaster
Robert, I couldn't agree with you more. If we came up with this design in the past couple months, we certainly would have used the latest version, with VPBMaster and we probably wouldn't be having any problems. We're kind of victims of circumstance here, especially me since I knew nothing about any of this until 5 weeks ago, and this process has been in place for 2 years. We're trying to reach a deadline with a fixed amount of money, so my hands are tied by management, and theirs may be tied by the customer - I guess I'll find out real soon. If we do use this process in the future, I will make sure we upgrade our OSG version and get approval for verification testing with our process before agreeing to any set schedule. I completely understand that there's no support for 1.2 at this point, and I definitely appreciate what support has been given to me regardless of that fact! I'm sure I'll be in contact with the OSG community in the future, but hopefully with a more sturdy footing. :) Thanks again, Jake Date: Wed, 4 Nov 2009 13:48:33 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster Hi Jacob, I can't help too much with management decisions, but I would suggest that OSG-1.2 is less mature, less robust, less supportable and would not recommend that any new projects adopt it as a base - OSG-2.8.x is far more mature, debugged and far better supported, not to mention far better feature set. I would consider using OSG-1.2 over OSG-2.8 a project liability, and one that you may well have to carry for a long time going forward. I would further add that OSG-1.2 is no longer supported by myself or members of the community. I haven't personally been anywhere near the OSG-1.2 for several years. I like most of the OSG community are working on the OSG-2.x branch now. If you want to use OSG-1.2 then you are pretty well on your own w.r.t support/bug fixes. Moving from OSG-1.2 to OSG-2.x should be straight forward and will reduce your project risks now and going forward. Robert. On Wed, Nov 4, 2009 at 1:24 PM, Jacob Armstrong jaco...@hotmail.com wrote: Thanks again to everyone for their help with these questions. I've got a much better understanding of what's going on based on your feedback and information that was just presented to me yesterday by management. It turns out that the process I'm trying to implement now was designed over 2 years ago (right about when we were supposed to be receiving the OpenFlight data from our customer). The design was based on OSG-1.2, and VPBMaster wasn't even a twinkle in OSG's eye, if you will. By the time we received the OpenFlight data (June of this year), the engineer-in-charge of the process picked his design back up and began modifying his conversion tool to match some unexpected input from the data. Part of this re-design was accounting a 1000 x 1000 km DB, when we were expecting it to be 500 x 500 km. Unfortunately, he didn't foresee the issues we're having with Process Time and Data Storage back then. Now we're paying for it with program dollars, and I'm paying for it with a few gray hairs. I think it's obvious that VBPMaster is the tool for this job, but I don't think it's likely that I will get approvable to upgrade our version of OSG, get VPBMaster, and then test our process using these new tools. It's just too risky of a move this late in the game. I'm presenting these issues to management today, and I believe they will make the decision to lower the resolution over the entire database and re-run the process. I guess I just work for an old-school-minded company that's afraid of drastic or sudden change :). Anyway, thanks again to everyone for your input! It's greatly appreciated! Date: Wed, 4 Nov 2009 09:11:52 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster On Tue, Nov 3, 2009 at 5:12 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Well, I don't know that the development team for OpenSceneGraph is a clearly defined set. By volume, Robert is the author of the vast majority of the OSG source code, but there's a long list of other contributors as well. I'm not quite as prolific as Chris makes out ;-) I'm the lead author of the of the core libosg, libosgUtil, osgDB, osgViewer and a few of the NodeKits, but far this is far from the majority of the OSG source code, the majority of the OSG code base is actually found in the plugins which are predominantly work of the community and this is no small feat. At last count we had 390 contributors, guess we might even get to the big 400 contributors, before with hit 3.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org
[osg-users] RenderBin mode
Hi all, Still working on the transparency effect, I have a question about RenderBinMode usage : I don't see any documentation about that... So the question is simple : What does the RenderBin Mode is for ? How to use it for transparent /opaque nodes ? Thanks a lot. Regards, Vincent. __ Information from ESET NOD32 Antivirus, version of virus signature database 4573 (20091104) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash in nVidia driver : particles + dynamically adding/removing views
J.P. Delport wrote: to be honest I'm not sure either. I've always thought that sharing might prevent duplication of objects on the GPU. Hopefully someone can enlighten us... jp Yes, using a shared context prevents duplication of objects. Unless the context is shared you cannot access the same textures, vbo's, display lists, etc., so each context has to have its own copy. OSG does this for you -- it keeps a per-context record of whether or not something has been applied. So using a shared context does avoid duplication on the GPU assuming the scenes actually use the same data. As for the multithreading tradeoffs, I'm not sure. You CAN render to the two shared contexts at the same time (they have separate ogl state, just shared ogl objects) but you'd need to do some kind of locking between the two rendering threads any time you messed with the shared objects. I don't know if OSG does all that. -Nathan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19167#19167 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgsteroimage on HMD
Hi, I want to realize something similar to osgstereoimage application, in order to visualize left_image.jpeg on left eye and righ_image.jpeg on right eye. My visualization HW is composed by: - HMD : PC3D SVGA Glasses, IO-Display, DDC stereo Protocol - Graphic CARD: QUADRO FX 540 Graphic card. For a standard 3D application i set the QUAD_BUFFER stereo mode and i see in stereo ie with a simple osgviewer commnad. My question is: How can i draw image_left in the left buffer and image_right in the right buffer... is it possible? Any idea in order to obtain this goal? Thank you! Cheers, Luigi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19164#19164 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderBin mode
Hi Vincent -- Your best source of information here is to look at the CullVisitor source code -- It's the only place where the bin modes have any meaning. Second best would be to search the archives, as this has been discussed multiple times. -Paul Vincent Bourdier wrote: Hi all, Still working on the transparency effect, I have a question about RenderBinMode usage : I don't see any documentation about that... So the question is simple : What does the RenderBin Mode is for ? How to use it for transparent /opaque nodes ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Paul Martz wrote: Personally, I already feel that using an enum to store bitflags is overkill. Defining an entire class to implement the bitflag/mask pattern along with set/get methods strikes me as the epitome of C++ abuse. I don't think I can back this, not even if measurements indicate no memory or performance bloat. It's an unnecessary layer of obfuscation. Using bitwise logic ops and unsigned bits/masks makes it perfectly clear what is happening, even at the assembly level. It reduces the potential for error and makes the code more readable. Oh, I love getting to wrangle theory with friends. ;) Wouldn't you think, though, that some code isn't actually concerned with thinking about bits, all it really cares about is state? Many times the bits in a bitmask are unrelated, and they're just grouped because you have several non-exclusive states you want to combine into a single member for storage efficiency. (I suspect the OptimizerOptions usage that originally spawned this discussion IS probably mostly-related state bits, so this may not apply). In the situation where they are unrelated state bits, being able to say stateBits.test(MY_STATE) it actually is perhaps more obvious and clear what's going on than doing it by hand with a bitwise operator. (I just can't resist stirring the pot... ;) -Paul -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up VPBMaster
Robert Osfield wrote: Just for clarification, osgdem itself can't pick up on a partial build, but a vpbmaster can pick up from an aborted/failed build - as it breaks the whole job down into potentially thousands of task (even hundreds of thousands in large databases) and each task is dispatched in parallell for osgdem to build. Each of these tasks can't be partially built and then restarted so will have to be repeated in full if it aborts, but overall this is not a big overhead as each task only task a small portion of the overall build. Yeah. That's what I was trying to say. Thanks for the lucid explanation. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tips for low-end GPUs? → check sp here count!
Hi Alberto, Alberto Luaces alua...@udc.es (04/11/2009): I think you are already on the right track. From your description, your program bottleneck seems to lie on the card fill rate and/or texture handling. Tips for diminishing that work would be: Thanks. Here's my findings after some testing: - As you mentioned, lowering the resolution of the rendering window as much as you can. Quite surprisingly, that didn't help. Even moving from 1280x1024 to 400x300 (be it fullscreen or not). - Lowering the resolution of the textures you are employing or inspecting if you can go faster through the use of mipmapping. The results will vary with the amount of available GPU RAM you have. I'm actually using no texture at all but only setColor(). - Try to disable as many blending effects you can. There weren't that many such effects, only a HUD with a few lines of text, no big deal, and only some containers (mostly: 1 box contains various spheres, and that containing box is transparent). So it didn't help either. - Use LODs mainly for that purpose, in order to deactivate blending effects on farther objects where they can't be seen so well. I didn't try that: there are no far objects (not much further than the ones on the foreground), and since disabling blending totally didn't help, I didn't bother. - Set the cheapest texture filters that you can cope with, NEAREST ones are the fastest. I think I've covered that above. - Disable any anti-aliasing or oversampling. I tried that, didn't help either (if we're talking about features accessible through the DisplaySettings instance). Anyway, disabling object after object, I finally found the culprit: the default level of detail for spheres was making the GPU feel completely overwhelmed. I've therefore switched some objects from Sphere to Box shapes, and used Tessellation Hints to lower the level of detail on the remaining items. I've now moved from ~ 5 FPS to 60. For reference, should someone find this thread later, here's how to use it: ,--[ TessellationHints are our friends ]-- | // Set lower amount of detail: | ref_ptrTessellationHints hints_low = new TessellationHints; | hints_low-setDetailRatio(0.15f); | | // Create a regular Sphere: | ref_ptrSphere obj = new Sphere(Vec3(0, 0, 0), 1.0); | | // Use the TessellationHints object when creating the ShapeDrawable object: | ref_ptrShapeDrawable obj_drawable | = new ShapeDrawable(obj.get(), hints_low.get()); `-- Thanks again Alberto for confirming my initial thoughts. Cheers, -- Cyril Brulebois signature.asc Description: Digital signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] releaseGLObjects and shared contexts
I have an application with two windows, one of which can be added and removed dynamically. They use a shared GL context (i.e. I set the sharedContext flag in the graphics context traits) so that I don't need to keep two copies of my enormous textures. I'm having a problem when I try to close one of the windows. When the underlying graphics context closes, it makes a call to releaseGLObjects on the associated camera and cleans up all the objects associated with my scene... But since the context was shared, it's deleting objects out from under my first view. I had some success with a workaround -- just remove the scene data from my second view before closing it. That way only the gl objects associated with the camera itself get released, nothing else. Has anyone else run into this? Maybe I could write a fix to OSG by checking the context ID usage count before calling releaseGLObjects? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19173#19173 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgsteroimage on HMD
Hi Luigi, Luigi LANEVE writes: Hi, I want to realize something similar to osgstereoimage application, in order to visualize left_image.jpeg on left eye and righ_image.jpeg on right eye. My visualization HW is composed by: - HMD : PC3D SVGA Glasses, IO-Display, DDC stereo Protocol - Graphic CARD: QUADRO FX 540 Graphic card. For a standard 3D application i set the QUAD_BUFFER stereo mode and i see in stereo ie with a simple osgviewer commnad. My question is: How can i draw image_left in the left buffer and image_right in the right buffer... is it possible? Any idea in order to obtain this goal? Just make a quad that fills the whole screen and put the left and right images in either sides of it. Use the orthographic perspective for that. Using the stereo mode, you will see every image in its own channel. Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting up VPBMaster
HI Jacob, Porting between OSG-1.2 to OSG-2.x should not be that difficult. The same design for OSG-1.2 should work for OSG-2.x. The core scene graph is very little change in general principles and the bulk of the API. The main difference between OSG-2.x and OSG-1.2 is that osgViewer replaces osgProducer. osgProducer::Viewer and osgViewer::Viewer are design wise pretty equivalent, so while the implementations and API are different that aren't completely different types of beasts. A couple of days spent porting to OSG-2.x will likely save you far more days in project time. It might not even take you that long. W.r.t your design docs, just renamed osgProduce to osgViewer and you'll be most of the way there. Robert. On Wed, Nov 4, 2009 at 3:23 PM, Jacob Armstrong jaco...@hotmail.com wrote: Robert, I couldn't agree with you more. If we came up with this design in the past couple months, we certainly would have used the latest version, with VPBMaster and we probably wouldn't be having any problems. We're kind of victims of circumstance here, especially me since I knew nothing about any of this until 5 weeks ago, and this process has been in place for 2 years. We're trying to reach a deadline with a fixed amount of money, so my hands are tied by management, and theirs may be tied by the customer - I guess I'll find out real soon. If we do use this process in the future, I will make sure we upgrade our OSG version and get approval for verification testing with our process before agreeing to any set schedule. I completely understand that there's no support for 1.2 at this point, and I definitely appreciate what support has been given to me regardless of that fact! I'm sure I'll be in contact with the OSG community in the future, but hopefully with a more sturdy footing. :) Thanks again, Jake Date: Wed, 4 Nov 2009 13:48:33 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster Hi Jacob, I can't help too much with management decisions, but I would suggest that OSG-1.2 is less mature, less robust, less supportable and would not recommend that any new projects adopt it as a base - OSG-2.8.x is far more mature, debugged and far better supported, not to mention far better feature set. I would consider using OSG-1.2 over OSG-2.8 a project liability, and one that you may well have to carry for a long time going forward. I would further add that OSG-1.2 is no longer supported by myself or members of the community. I haven't personally been anywhere near the OSG-1.2 for several years. I like most of the OSG community are working on the OSG-2.x branch now. If you want to use OSG-1.2 then you are pretty well on your own w.r.t support/bug fixes. Moving from OSG-1.2 to OSG-2.x should be straight forward and will reduce your project risks now and going forward. Robert. On Wed, Nov 4, 2009 at 1:24 PM, Jacob Armstrong jaco...@hotmail.com wrote: Thanks again to everyone for their help with these questions. I've got a much better understanding of what's going on based on your feedback and information that was just presented to me yesterday by management. It turns out that the process I'm trying to implement now was designed over 2 years ago (right about when we were supposed to be receiving the OpenFlight data from our customer). The design was based on OSG-1.2, and VPBMaster wasn't even a twinkle in OSG's eye, if you will. By the time we received the OpenFlight data (June of this year), the engineer-in-charge of the process picked his design back up and began modifying his conversion tool to match some unexpected input from the data. Part of this re-design was accounting a 1000 x 1000 km DB, when we were expecting it to be 500 x 500 km. Unfortunately, he didn't foresee the issues we're having with Process Time and Data Storage back then. Now we're paying for it with program dollars, and I'm paying for it with a few gray hairs. I think it's obvious that VBPMaster is the tool for this job, but I don't think it's likely that I will get approvable to upgrade our version of OSG, get VPBMaster, and then test our process using these new tools. It's just too risky of a move this late in the game. I'm presenting these issues to management today, and I believe they will make the decision to lower the resolution over the entire database and re-run the process. I guess I just work for an old-school-minded company that's afraid of drastic or sudden change :). Anyway, thanks again to everyone for your input! It's greatly appreciated! Date: Wed, 4 Nov 2009 09:11:52 + From: robert.osfi...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Setting up VPBMaster On Tue, Nov 3, 2009 at 5:12 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Well, I don't know that the development team for OpenSceneGraph
Re: [osg-users] Tips for low-end GPUs?
Robert Osfield robert.osfi...@gmail.com (04/11/2009): Hi Cyril, Hi Robert, I'm afriad getting low end performance from low end graphics hardware is something we have to live with and do our best to work around. In some cases app developers can recommend to their end users they use more suitable hardware, I know even in some cases they have bought graphics hardware for their clients just to avoid issues with performance and driver quality. well, it's particularly unpleasant to get stuck with a few FPS with a few boxes and spheres using a “high performance 3D graphics toolkit” while the same hardware makes it possible to play OpenArena or even Nexuiz (granted, in a quite degraded mode). So yes, I'm quite familiar with reading on this list that people might want to get better GPUs and so on, but in my case it looked like there were at least sufficient hardware performances to be taken advantage of. If you are stuck having to support low end hardware then you'll need to work out what the bottlenecks are and address them accordingly. The same principles will work for all hardware - are you CPU limited? GPU limited? Fill limited or transform limited? Lots of questions and there will be even more answers. Performance optimization is a *huge* topic covered many times on osg-users so I recommend you do searches on this this topic. Having plenty of threads to dig through (eventually with things being said and rehearsed) makes it a bit hard to get anything usable; it's also easy to get into a very case-specific discussion. That's why I think it'd be nice to have a wiki page offering a kind of checklist of what can be: - ruining performances (like full-detailed spheres); - done to check it (like StatsHandler); - done to improve the situation; Not necessarily much detailed, just pointing back to appropriate mail threads for example. But just so that people can get the big picture and quickcheck their stuff before bothering this list again. Please note I'm not *demanding* it, I'm merely suggesting it to save everyone time in the future. (As for my specific case, TessellationHints on my spheres led me to 60 FPS. Even on crappy Intel cards. Yay.) Cheers, -- Cyril Brulebois signature.asc Description: Digital signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Chris 'Xenon' Hanson wrote: Oh, I love getting to wrangle theory with friends. ;) You can call me an idiot if you want, and I'll still buy you coffee. :-) In the situation where they are unrelated state bits, being able to say stateBits.test(MY_STATE) it actually is perhaps more obvious and clear what's going on than doing it by hand with a bitwise operator. I stand by my previous statement that it makes things less clear. Suppose you're debugging and you encounter that in the code as you step through the debugger. You now need to step in and make sure it's doing the right thing, whereas (stateBits MY_STATE) requires no debugging at all. This new class becomes just one more chunk of code to debug and vet. And if performance is an issue, I now have to wonder what the StateBits class compiled to, whereas I know that (stateBits MY_STATE) compiles to exactly one instruction. Sorry to disagree on this, but I would no sooner write my own class to hide the bitwise AND operator than I would write my own class to hide the 32-bit integer addition operator. Like I said, it's Robert's call, and we'll all go with what he says. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
On Wed, Nov 4, 2009 at 4:51 PM, Paul Martz pma...@skew-matrix.com wrote: Like I said, it's Robert's call, and we'll all go with what he says. From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TerrainManipulator Questions
Hi, Thanks guys for all the help. I finally figured out how to setup a Rotation Matrix and I am now using the setByMatrix of the TerrainManipulator correctly to position the camera. It's awesome! But I have found a curious thing, it appears that the same method in Trackball Manipulator is not correct. Every time I've called it, it never updates the camera's position and I do not think it's calculating the position/orientation information correctly, either. but thanks for the help! I really appreciate it. ... Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19179#19179 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NESTED_RENDER
I understand the PRE_ and POST_ render but what does NESTED_RENDER mean? How does that work? W ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera question
Does osg::Camera only render that what is below it in the scene graph? W ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera question
On Wed, Nov 4, 2009 at 5:44 PM, Wyatt Earp wyattbsearp1...@gmail.com wrote: Does osg::Camera only render that what is below it in the scene graph? Yes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera question
So if I want to have, say, 3 render passes of my entire scene data, I need 3 cameras at the root of the scene graph, and set the render order according to how I want them ordered? W On Wed, Nov 4, 2009 at 11:45 AM, Robert Osfield robert.osfi...@gmail.com wrote: On Wed, Nov 4, 2009 at 5:44 PM, Wyatt Earp wyattbsearp1...@gmail.com wrote: Does osg::Camera only render that what is below it in the scene graph? Yes. 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] Change to Optimizer OptimizationOptions
From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) Absolutely! I agree with you on all points! Robert has spoken! ... but don't hate me if I had to Google to find out what toss the caber meant ... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TrackballManipulator possible bug; definite issue
Hi,
I don't know if anyone has delt w/ this problem yet, but it appears that
TrackballManipulator has a bug in it in the methods, setByMatrix() and
computePosition().
I could be wrong, as I'm a novice in OSG, but I have observed the following:
setByMatrix()
1. does not work for me as every time I call it, the camera's position
orientation are not altered or updated
2. the code appears to be incorrect compared to other manipulator examples
which work.
from NodeTrackerManipulator:
void NodeTrackerManipulator::setByMatrix(const osg::Matrixd matrix)
{
osg::Vec3d eye,center,up;
matrix.getLookAt(eye,center,up,_distance);
computePosition(eye,center,up);
}
this code works. But from TrackballManipulator:
void TrackballManipulator::setByMatrix(const osg::Matrixd matrix)
{
_center = osg::Vec3(0.0f,0.0f,-_distance)*matrix;
_rotation = matrix.getRotate();
}
This code does NOT work.
as for computePosition()
1. in TrackballManipulator, it appears to be using COLUMN MAJOR matrices but
OSG is row major.
2. as compared to NodeTracker and Terrain manipulators, the method for
computing the position/orientation is consistent. However, in the Trackball it
is performed using, I believe, an invalid way to fill a matrix with
rotation/orientation information.
Has anyone else encountered this?
...
Thank you!
Cheers,
Allen
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19184#19184
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Robert Osfield wrote: From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) As long as I don't have to shave my legs. Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GraphicsWindow::setWindowDecoration using kde4 and icewm
Hi, Switching osgviewer to windowed mode (using the 'f' key) yields a decorated window using icewm. However, I get a borderless window using kde4. The same happens if I change the window decoration in my own app using osgViewer::GraphicsWindow::setWindowDecoration(). Is there a way to force kde to put borders around the window? Or am I just missing a simple kde setting and should rather post on a kde mailing list? Thanks for help, Cheers, Thilo _ DSL-Preisknaller: DSL-Komplettpakete von WEB.DE schon für 16,99 Euro/mtl.!* Hier klicken: http://produkte.web.de/go/02/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera question
On Wed, Nov 4, 2009 at 11:47 AM, Wyatt Earp wyattbsearp1...@gmail.com wrote: So if I want to have, say, 3 render passes of my entire scene data, I need 3 cameras at the root of the scene graph, and set the render order according to how I want them ordered? W On Wed, Nov 4, 2009 at 11:45 AM, Robert Osfield robert.osfi...@gmail.com wrote: On Wed, Nov 4, 2009 at 5:44 PM, Wyatt Earp wyattbsearp1...@gmail.com wrote: Does osg::Camera only render that what is below it in the scene graph? Yes. 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] Camera question
Wyatt Earp wrote: So if I want to have, say, 3 render passes of my entire scene data, I need 3 cameras at the root of the scene graph, and set the render order according to how I want them ordered? This was just discussed 2 weeks ago. Search the archives for Repeatable rendering of subgraphs, ideas?. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NESTED_RENDER
Wyatt Earp wrote: I understand the PRE_ and POST_ render but what does NESTED_RENDER mean? How does that work? The answer is in the function CullVisitor::apply(Camera) in osgUtil CullVisitor.cpp. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera question
I read that discussion and not sure I follow it with respect to what I need to do. I think maybe mistated or didn't say enough concerning what I meant. If I have a prerender camera for rtt, and another camera which will take as input the texture from the rtt camera do some stuff then render to texture the output, and then a third camera which takes camera 2s output as input and performs then final render... what would my scenegraph look like? I guess that is more the question I am really asking... For example in osgprerender (if I understand correctly)... root node | group - poygeom/texture | group - RTT Camera - Subgraph (cessna) So if I were adding another pass to osgprerender, would I need to create a scene graph like this? root node | group - polygeom1/texture1 - polygeom2/texture2 | group - RTT Camera 1 - RTT Camera 2 - Final Render Camera - Subgraph(cessna) W On Wed, Nov 4, 2009 at 1:24 PM, Paul Martz pma...@skew-matrix.com wrote: Wyatt Earp wrote: So if I want to have, say, 3 render passes of my entire scene data, I need 3 cameras at the root of the scene graph, and set the render order according to how I want them ordered? This was just discussed 2 weeks ago. Search the archives for Repeatable rendering of subgraphs, ideas?. -Paul ___ 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] Camera question
Wyatt Earp wrote: If I have a prerender camera for rtt, and another camera which will take as input the texture from the rtt camera do some stuff then render to texture the output, and then a third camera which takes camera 2s output as input and performs then final render... what would my scenegraph look like? It really depends on how you want the Viewer's Camera manipulator to work. Do you want it to manipulate Camera 1 or do you want it to manipulate your final render camera? It also depends on what kind of scene geometry you are rendering for each of your Cameras. Here's one way to do it: I would have your Camera 2 configured as prerender at the top of the scene graph. I would have your Camera 1 also configured as prerender and added as a child to Camera 2. The I would setSceneData in osgViewer::Viewer, passing in Camera 2 -- osgViewer's built-in Camera will be the final render camera in your example. The problem you typically run into with this kind of setup is that you want to attach a camera manipulator to the osgViewer::Viewer, but you want it to manipulate the matrices in Camera 1, not the top-level Viewer (final render) Camera. You can do this with some fairly hairy rewiring, but... Here's another way to do it: Use the osgViewer::Viewer Camera as Camera 1 in your example. So you'll need to call Viewer::getCamera()-attach to make it into an RTT Camera (just like you would any Camera). For the top of your scene graph, you'll probably want a Group with Camera 2 as a child. Camera 2 is configured as post render, and it will have the final render Camera as a child, also set up to post render. In addition to having Camera 2 as a child, your top Group node will probably also be the parent of the geometry you need to render in your first render pass. With this configuration, the camera manipulator attached to Viewer will manipulate the matrices in Camera 1 without the need for fancy rewiring. That is the most common case, as Camera 1 in your example is usually the parent of a large scene graph, whereas Camera 2 and the final render Camera are usually just rendering screen-oriented textured quads and therefore do not need a camera manipulator. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgviewerQT - Slot connection with QMainWindow
Hi, I’m having trouble modifying osgviewerQT. I am trying to modify the ViewerQT MDI version portion of the code. I am adding file menus to QMainWindow* mw (ex File – New, Open, Save etc) successfully but I am having troubles getting the SLOT connections to work based on actions. How do you get the SLOT connections from QMainWindow* mw and not the class inherited AdapterWidget or QApplication Slot connections. I am using vs2008 so if there is a way to do this without Moc it would be great. If I have to use Moc what is the procedure? Thank you! Cheers, Darick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19178#19178 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera question
Ok.. thanks for the information... Good stuff... One last question... Is it possible to switch off a camera(s) in the chain and only render with the remaining camera(s)? In other words render with 1, 2 or 3 passes? W On Wed, Nov 4, 2009 at 2:39 PM, Paul Martz pma...@skew-matrix.com wrote: Wyatt Earp wrote: If I have a prerender camera for rtt, and another camera which will take as input the texture from the rtt camera do some stuff then render to texture the output, and then a third camera which takes camera 2s output as input and performs then final render... what would my scenegraph look like? It really depends on how you want the Viewer's Camera manipulator to work. Do you want it to manipulate Camera 1 or do you want it to manipulate your final render camera? It also depends on what kind of scene geometry you are rendering for each of your Cameras. Here's one way to do it: I would have your Camera 2 configured as prerender at the top of the scene graph. I would have your Camera 1 also configured as prerender and added as a child to Camera 2. The I would setSceneData in osgViewer::Viewer, passing in Camera 2 -- osgViewer's built-in Camera will be the final render camera in your example. The problem you typically run into with this kind of setup is that you want to attach a camera manipulator to the osgViewer::Viewer, but you want it to manipulate the matrices in Camera 1, not the top-level Viewer (final render) Camera. You can do this with some fairly hairy rewiring, but... Here's another way to do it: Use the osgViewer::Viewer Camera as Camera 1 in your example. So you'll need to call Viewer::getCamera()-attach to make it into an RTT Camera (just like you would any Camera). For the top of your scene graph, you'll probably want a Group with Camera 2 as a child. Camera 2 is configured as post render, and it will have the final render Camera as a child, also set up to post render. In addition to having Camera 2 as a child, your top Group node will probably also be the parent of the geometry you need to render in your first render pass. With this configuration, the camera manipulator attached to Viewer will manipulate the matrices in Camera 1 without the need for fancy rewiring. That is the most common case, as Camera 1 in your example is usually the parent of a large scene graph, whereas Camera 2 and the final render Camera are usually just rendering screen-oriented textured quads and therefore do not need a camera manipulator. -Paul ___ 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] Databasepager + multiple views + different camera positions = memory leak?
Wojtek, I tried what you suggested. Unfortunately it did not solve the problem :-( Does this look like what you were referring to? osg::ref_ptrosgDB::ReaderWriter::Options opt = new osgDB::ReaderWriter::Options; opt-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_NONE); osgDB::Registry::instance()-setOptions(opt.get()); terrain = osgDB::readNodeFile(path); thanks for the try anyways:-). Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19196#19196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camerapositions = memory leak?
Sergey, The more I thought about this the more I doubted it may be related in your case, but I could not remove post already sent. However, we have found another, and this time looking much more real, PageLOD leak issue when node cache was active. Maybe this could be indirectly related to your case. In our case, cache keeping PageLOD ref counts above 1 was an additional factor that was neccessary for the leaks to happen, but I suspect that any other reference that would cause PagedLOD to not drop to 1 when when they were being disconnected from the graph may work as similar catalyst. I do not know exact details yet, my friend was investigating this issue and tomorrow we will post the report. You may want to check it. We will probably post it under the thread PagedLOD experts ? started few days ago (because, yes, NeedToRemove nodes are involved). Wojtek -- From: sergey leontyev sleon...@ist.ucf.edu Sent: Wednesday, November 04, 2009 10:03 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Databasepager + multiple views + different camerapositions = memory leak? Wojtek, I tried what you suggested. Unfortunately it did not solve the problem :-( Does this look like what you were referring to? osg::ref_ptrosgDB::ReaderWriter::Options opt = new osgDB::ReaderWriter::Options; opt-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_NONE); osgDB::Registry::instance()-setOptions(opt.get()); terrain = osgDB::readNodeFile(path); thanks for the try anyways:-). Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19196#19196 ___ 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] osgManipulator bug in removeTransformUpdating
nobody an idea? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19198#19198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
