[osg-users] questions about frame rate lock(locking FPS)
Hi, i m wondering is it possible to lock(maintatin) the frame rate? i mean that we can see the frame rate on the viewer if we press 's'. then i can see the frame rate is around 60 but i would like to lock the frame rate aroud 30 is there some osg library for that? Thanks in advance Cheers, Kim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54294#54294 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] questions about frame rate lock(locking FPS)
Hi Kim, I don't think that there is a library. Personally I think there are two options. 1. See if your driver can do it via vsync. Newer Nvidia drivers for instance allow you to sync to half of the refresh rate. 2. Lock it yourself by issuing the viewer.frame() in the right moment. In order to do this you'll need some kind of micro sleep to wait a potentially very short time. But beware: Locking the frame rate to something else than the output's sync rate, you might get artifacts cheers Sebastian Hi, i m wondering is it possible to lock(maintatin) the frame rate? i mean that we can see the frame rate on the viewer if we press 's'. then i can see the frame rate is around 60 but i would like to lock the frame rate aroud 30 is there some osg library for that? Thanks in advance Cheers, Kim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54294#54294 ___ 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] Integer texture buffers
Hi, I have a camera setup with multiple render targets. Currently I bind some buffers with GL_RGBA as source and for instance GL_RGBA16F as internal format with source type set to GL_FLOAT together with a depth/stencil target etc. Now I tried to bind an integer buffer by setting the texture to GL_RB, with source GL_RB16UI and source type set to GL_UNSIGNED_INT. Unfortunately this gives me an error regarding framebuffer completeness. Has anyone done this and give me some hints this? Also I'd like to know how write into the bound integer target correctly inside the fragment shader. Is this correct: gl_FragData[0] = uivec2(128,534); cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compar polygons in Geometry
Hi Daniel, On 29 May 2013 14:01, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: No I have a hard time to figure out if there is already some classes in osg that help me do such thing, or how I should accomplish that. I’m not very used to PrimitiveSet and this stuff, so can somebody help me? There isn't any existing OSG functionality that does this. You could either create a visitor that find the geometry leaves and then traverses the vertex/normal and primitive data as you've suggested, or write a vertex shader then moves the vertex position up along the direction of the normal, personally I'd do the later. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Judson, On 29 May 2013 15:01, Judson Weissert jud...@mfrac.com wrote: My fault, I performed an invalid test. My osgviewer.cpp source was modified, and I did not realize it. It was still overriding checkNeedToDoFrame(). I retested, and it appears to be working as expected. Sorry about that. I will continue testing and report back my findings if I find anything. Good to hear it's working. With your own code with modified checkNeedToDoFrame() you will be best to either call the base classes checkNeedToDoFrame() or recreate similar code w.r.t calling the new bool checkEvents() method rather than doing a full event traversal. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem when using DrawCallbacks with nested cameras
Hello Robert, thank you for your help. Using mutliple RTT Cameras worked, but I went back to using just a single one. Executing mutliple read backs per frame had a huge impact on the performance. I just changed inherhitance mask of the read back camera that it doesn't inherit the cull mask. With this setting I can determine the textures for the first layer. This solution is not perfect because it doesn't determine all necessary textures, but it looks good enough. Cheers, Marcel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54303#54303 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem when using DrawCallbacks with nested cameras
Hi Marcel, On 30 May 2013 10:33, Marcel Pursche marcel.purs...@student.hpi.uni-potsdam.de wrote: thank you for your help. Using mutliple RTT Cameras worked, but I went back to using just a single one. Executing mutliple read backs per frame had a huge impact on the performance. My suggested approach of using multiple RTT Camera included the need for a custom cull callback to determine which Camera to render each frame, without this you would indeed end up with multiple render/read backs. I just changed inherhitance mask of the read back camera that it doesn't inherit the cull mask. With this setting I can determine the textures for the first layer. This solution is not perfect because it doesn't determine all necessary textures, but it looks good enough. If it works don't knock it :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] color interpolation at tile boundaries even with --no-interpolate-imagery
I use osgdem with the --no-interpolate-imagery and --no-mipmap optiosn to wrap geotiff imagery onto my terrain complex. However, the unsigned int rgb channels contain index values to be used in lookup tables in the shader, not real imagery. Because of this, it is important that the color values contained in the input geotiffs be carried all the way through the osgdem process without any interpolation. I modified the src for VPB to force NEAREST for the textures, and use the --no-interpolate-imagery and --no-mipmap options to try to keep any interpolation from happening. For the most part, everything works and I am able to get the correct index values in my shader. The exception is at tile boundaries of the osgdem-generated terrain complex. To test this, I used a geotiff that only had values of 13 and 15 in it and generated an osgdem terrain. In my shader, I decode those index values and color the terrain grees in the value is either 13 or 15, and red if it's 14. The entire terrain is green except at the tile boundaries where spots of red show up. This leads me to believe that interpolation is happening at the tile boundaries. Am I correct in this assumption? Any thoughts on how I might prevent this from happening? Thanks. -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54312#54312 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Separate Blending, clearmask and writemask per FBO attachment
Hi folks, Hi Robert I know there is EXT_draw_buffers2 [0] and EXT_draw_buffers_blend [1] and per attachment blending enable/disable, clear masks and color write masks in core 3.3. Any idea how we could include this functionality into OSG, or this there already something I could use? What I would need is control over the blending being enabled, disabled per attachments and disabling writing to certain components of the attachments. For instance I have a first pass that binds two color targets and writes to both of them Target1 RGBA Target2 RGBA Now in the second pass I want to blend the Target1 but overwrite only parts of the Target2 Target1 RGBA, blending enabled, write mask(1,1,1,1) Target2 RGBA,blending disabled, write mask(1,1,0,0) cheers Sebastian [0]https://www.opengl.org/registry/specs/EXT/draw_buffers2.txt [1]https://www.opengl.org/registry/specs/ARB/draw_buffers_blend.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] color interpolation at tile boundaries even with --no-interpolate-imagery
Hi Ethan, You are correct, VPB does texture colour and normal equalization at tile boundary to avoid the tile boundaries being obvious. The code is written specifically for RGB/RGBA data and was never written with the idea that int data would be used. In your case one would need to turn off the boundary equalization for the imagery. Robert. On 30 May 2013 15:17, Ethan Fahy ethanf...@gmail.com wrote: I use osgdem with the --no-interpolate-imagery and --no-mipmap optiosn to wrap geotiff imagery onto my terrain complex. However, the unsigned int rgb channels contain index values to be used in lookup tables in the shader, not real imagery. Because of this, it is important that the color values contained in the input geotiffs be carried all the way through the osgdem process without any interpolation. I modified the src for VPB to force NEAREST for the textures, and use the --no-interpolate-imagery and --no-mipmap options to try to keep any interpolation from happening. For the most part, everything works and I am able to get the correct index values in my shader. The exception is at tile boundaries of the osgdem-generated terrain complex. To test this, I used a geotiff that only had values of 13 and 15 in it and generated an osgdem terrain. In my shader, I decode those index values and color the terrain grees in the value is either 13 or 15, and red if it's 14. The entire terrain is green except at the tile boundaries where spots of red show up. This leads me to believe that interpolation is happening at the tile boundaries. Am I correct in this assumption? Any thoughts on how I might prevent this from happening? Thanks. -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54312#54312 ___ 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] [vpb] color interpolation at tile boundaries even with --no-interpolate-imagery
Thank you Robert. I should assume this is a change I'd make in the VPB src and not a command line option (that I'm missing) in osgdem correct? -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54317#54317 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] color interpolation at tile boundaries even with --no-interpolate-imagery
Hi Ethan, On 30 May 2013 16:01, Ethan Fahy ethanf...@gmail.com wrote: Thank you Robert. I should assume this is a change I'd make in the VPB src and not a command line option (that I'm missing) in osgdem correct? I have just checked the source and there is no option to enable/disable the calls the boundary equalization code. You'd need to look to adding this and an option that enables/disables it. You'd want to keep the height field equalization enabled, but disable the equalization for the non RGBA/RGB image layers. The relevant code looks to be in VirtualPlanetBuilder/src/vpb/DestinationTile.cpp, in the void DestinationTile::equalizeEdge(Position position) method. I expect you'd want to individual turn on/off the equalization for each image layer. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Warning messages VS2012...
Hi all, I am receiving a huge quantity of warnings when compiling OSG and VPB, they are both the same thing. Warning 27 warning C4250: 'osgDB::fstream' : inherits 'std::basic_istream_Elem,_Traits::std::basic_istream_Elem,_Traits::_Add_ vtordisp1' via dominance H:\Coding\OSG\OpenSceneGraph\include\osgDB\fstream 41 1 vpb The message is a warning and I cannot see any problem with it apart from its annoying! Here is the article on the warning: http://msdn.microsoft.com/en-us/library/6b3sy7ae(v=vs.80).aspx Could this be fixed in code or do we need to add a pragma to supress the warning, I cannot seem to find any explicity defined pragma's in the code for windows? Thanks Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning messages VS2012...
Hi Martin, The warning docs discuss multiple inheritance, but the osgDB::fstream class just inherits directly from std::fstream so on first doesn't look that relevant. I've looked at the implementation of fstream here on Linux and the only issue I've seen that might be a problem is that open() method isn't virtual so overriding it locally in osgDB::fstream will only work when calling osgDB::fstream directly, and not through a pointer to the std::fstream. I would have thought this type of issue would generate a different warning through. The only reason for the existance of the osgDB::fstream is that it runs OSGDB_CONVERT_UTF8_FILENAME() on the filename. Perhaps one could remove osgDB::fstream and provided a convience function such as: osgDB::open(std::fstream fs, const char* filename,std::ios_base::openmode mode) { fs-open(OSGDB_CONVERT_UTF8_FILENAME(filename), mode); } This would require going through the OSG examples that utilize the fstream, replacing the fs.open(..) with an osgDB::open(fs,..) but this wouldn't be too much work and would avoid the need for subclassing fstream which doesn't sit that well with me as it's just done to hide the UTF8 filename conversion. I'm not the original author of this code though, perhaps Michael Platings can dive in to explain the reasoning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] color interpolation at tile boundaries even with --no-interpolate-imagery
Thanks Robert I'll have a look. I was going to start a new thread for this next question but since I've already explained my situation and why it's necessary to have precise colors I'll just ask it here: I notice that my index values can be slightly off if the angle between the terrain texture normal and the line from the camera-to-terrain is close to 90 degrees. I figured out that this goes away if I force Anisotropic Filtering to be off in my NVidia control panel, so it's definitely an effect of AF. However, I checked the VPB source and see that the default maxAnisotropy value is set to 1.0, and in the osg::Texture::setMaxAnisotropy() function I see a note saying that if maxAnisotropy is set to 1.0 that AF will be off. Am I missing something? Is there any way to make sure that the effects of AF do not interfere with my indexing scheme without turning off AF in the graphics card driver settings? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54323#54323 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HowTo use UPDATE_TO_VERSION for custom osg::Object separate from osgVersion()
Hi Wang, Just wanted to ping this ticket again to see if there's any update. Thanks! -- Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54326#54326 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL 3.x support
Hi, just for ref https://hogbox.googlecode.com has following code which might be of some use: https://code.google.com/p/hogbox/source/browse/trunk/include/hogbox/HogBoxMaterial.h https://code.google.com/p/hogbox/source/browse/trunk/src/hogbox/HogBoxMaterial.cpp https://code.google.com/p/hogbox/source/browse/trunk/include/hogbox/HogBoxLight.h https://code.google.com/p/hogbox/source/browse/trunk/src/hogbox/HogBoxLight.cpp Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org