[osg-users] latest NVIDIA drivers
Hi community, anyone has experienced some weirdness with the latest drivers from NVIDIA? My shaders just stopped working with them without any warning/error from OSG ... -Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Trajce,
I have noticed issues with Shader compilation on 256 (and above) series on
Windows 7. Some fragment shaders using gl_LightSource fields were generating
internal compiler errors. In fact I also posted a bug report to NVidia. These
errors were normally reported by OSG with compilation log showing assembly cg
output that was causing trouble for compiler. You don't see any compilation
errors even with OSG_NOTIFY_LEVEL=DEBUG_INFO ?
I have attached the bug report I posted to NVidia you can check if it could
related.
Cheers,
Wojtek
From: Trajce (Nick) Nikolov
Sent: Thursday, August 05, 2010 8:47 AM
To: OpenSceneGraph Users
Subject: [osg-users] latest NVIDIA drivers
Hi community,
anyone has experienced some weirdness with the latest drivers from NVIDIA? My
shaders just stopped working with them without any warning/error from OSG ...
-Nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Any OpenGL program doing pixel shader lighting using standard
OpenGL state variables may encounter this problem.
Compilation of pretty standard fragment shaders doing pixel lighting math
using gl_LightSource / gl_FrontMaterial uniforms
fail with internal GLSL compiler error:
Internal error: assembly compile error for fragment shader at offset
13132:
-- error message --
line 254, column 1: error: binding in multiple relative-addressedarrays
After examination it looks like gl_LightSource.attenuation factors are multiply
generated into intermediate shader constants. This problem was not present on
Windows drivers before 256 series. I observed the error with driver versions
257.15 and
recent WHQL 257.21 on GeForce FX 280 / GeForce FX 8800 GTS and Quadro 5800
(Quadro Plex D2).
I have not tested other boards. So it was happening on every board I tested.
Below are simplified example shaders and generated GLSL compiler error output
showing the error.
My program uses 3 lights. Using 1 or 2 lights does not generate error:
Compiling VERTEX source:
1: varying vec3 position;
2: varying vec3 normal;
3:
4: void main(void)
5: {
6: gl_Position = ftransform();
7: position = vec3(gl_ModelViewMatrix * gl_Vertex);
8: normal = normalize(gl_NormalMatrix * gl_Normal.xyz);
9: }
Compiling FRAGMENT source:
1: varying vec3 position;
2: varying vec3 normal;
3:
4: void main( )
5: {
6: vec4 ambient = vec4(0.0, 0.0, 0.0, 0.0);
7: vec4 diffuse = vec4(0.0, 0.0, 0.0, 0.0);
8: vec4 specular = vec4(0.0, 0.0, 0.0, 0.0);
9:
10: vec3 normalizedNormal = normalize(normal);
11:
12: for(int lightId = 0; lightId 3; lightId++)
13: {
14:vec3 lightVector = gl_LightSource[lightId].position.xyz;
15:
16:float attenuation = 1.0;
17:
18:if( gl_LightSource[lightId].position.w != 0.0 )
19:{
20: lightVector -= position;
21: float distance = length(lightVector);
22: attenuation = 1.0 / (gl_LightSource[lightId].constantAttenuation +
23: gl_LightSource[lightId].linearAttenuation * distance +
24: gl_LightSource[lightId].quadraticAttenuation * distance *
distance)
25:}
26:
27:ambient += attenuation * gl_LightSource[lightId].ambient;
28:
29:vec3 normalizedLightVector = normalize(lightVector);
30:
31:float nDotL = dot(normalizedNormal, normalizedLightVector);
32:
33:if( nDotL 0.0 )
34:{
35: diffuse += attenuation * nDotL * gl_LightSource[lightId].diffuse;
36:
37: if(gl_FrontMaterial.shininess 0.0) {
38:float nDotHV = 0.0001;
39:float pf = pow( nDotHV, gl_FrontMaterial.shininess );
40:specular += attenuation * pf * gl_LightSource[lightId].specular;
41: }
42:}
43: }
44:
45: gl_FragColor =
46: gl_FrontLightModelProduct.sceneColor +
47: gl_FrontMaterial.emission +
48: ambient * gl_FrontMaterial.ambient +
49: diffuse * gl_FrontMaterial.diffuse +
50: specular * gl_FrontMaterial.specular;
51: }
52:
Linking osg::Program id=1 contextID=0
glLinkProgram FAILED
Program infolog:
Fragment info
-
Internal error: assembly compile error for fragment shader at offset 13132:
-- error message --
line 254, column 1: error: binding in multiple relative-addressedarrays
-- internal assembly text --
!!NVfp4.0
OPTION NV_parameter_buffer_object2;
# cgc version 3.0.0001, build date Jun 7 2010
# command line args:
#vendor NVIDIA Corporation
#version 3.0.0.1
#profile gp4fp
#program main
#semantic gl_LightSource : state.light
#semantic gl_FrontMaterial : state.material.front
#semantic gl_FrontLightModelProduct : state.lightmodel.front
#var float4 gl_LightSource[0].ambient : state.light[0].ambient : c[0] : -1 : 1
#var float4 gl_LightSource[0].diffuse : state.light[0].diffuse :
Re: [osg-users] threading and captureCurrentState
Hi John, If you need this to setup uniforms for shadow fragment shaders then maybe standard GL gl_FrontFacing variable could do the trick ? Its available at least in GLSL 1.50 and above. I have not checked when it was introduced maybe its available in earlier GLSL profiles. Wojtek From: PCJohn Sent: Thursday, August 05, 2010 12:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] threading and captureCurrentState Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is current attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the attribute stack. I'll say it again: you can't access those attribute stacks from the cull traversal. They don't contain anything sensible. I that case a different question: How to get current osg::FrontFace attribute? I mean the one that would be active for any drawable traversed at the present moment during cull traversal that is just in progress and I am handling it in my custom Shadow class that is already working perfectly except some attribute values that user may pass from the scene graph above and that need to be properly handled to cast shadows correctly. The answer: you do not need it would be wrong at the moment. Thx, John ___ 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] latest NVIDIA drivers
Hi Wojtek, looks like that is it. The shader failing is the lighting shader ... Thanks ! -Nick On Thu, Aug 5, 2010 at 11:51 AM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi Trajce, I have noticed issues with Shader compilation on 256 (and above) series on Windows 7. Some fragment shaders using gl_LightSource fields were generating internal compiler errors. In fact I also posted a bug report to NVidia. These errors were normally reported by OSG with compilation log showing assembly cg output that was causing trouble for compiler. You don't see any compilation errors even with OSG_NOTIFY_LEVEL=DEBUG_INFO ? I have attached the bug report I posted to NVidia you can check if it could related. Cheers, Wojtek *From:* Trajce (Nick) Nikolov nikolov.tra...@gmail.com *Sent:* Thursday, August 05, 2010 8:47 AM *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Subject:* [osg-users] latest NVIDIA drivers Hi community, anyone has experienced some weirdness with the latest drivers from NVIDIA? My shaders just stopped working with them without any warning/error from OSG ... -Nick -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mixin Shadow Technique
Hello, is it possible to mix two different osg shadow techniques. I would like use the parallel split shadow map for my terrain and the standard shadow map for my vehicle. Cheers Martin -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Hi guys, thanks for all your answers. Unfortunately, I am leaving for a week holidays in one hour. Anyway, the problem is following: - I am generating shadow volumes on the fly in cull visitor - It works perfectly, except the cases when mirrors are used - let's recall that mirror turns right-handed coordinate system to left-handed, thus the programmer needs to change FrontFace setting to keep face culling working properly. - Ignoring FrontFace settings, I may construct anti-shadow volume that produces wrong results when mixed with non-anti volumes, etc. - Moreover, blending and alpha test settings should be detected and semi-transparent object should not cast shadows. I can detect them bellow in the scene graph during triangle collecting traversal, but what about attributes above my shadow node? Ignoring them may result in wrong results. I guess, the best solution is to query current traversal state for blending and front face settings. At least that is what I have done in another scene graph library. Other option is to traverse scene graph up from my shadowed node to see if there are any attributes important for myself. But if there is no nice solution, lets leave the problem. I just wanted to create complete issue-free solution, as this solution may be contributed back to OSG one day when stable enough. John Wojciech Lewandowski wrote: Hi John, If you need this to setup uniforms for shadow fragment shaders then maybe standard GL gl_FrontFacing variable could do the trick ? Its available at least in GLSL 1.50 and above. I have not checked when it was introduced maybe its available in earlier GLSL profiles. Wojtek *From:* PCJohn mailto:pec...@fit.vutbr.cz *Sent:* Thursday, August 05, 2010 12:41 AM *To:* OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org *Subject:* Re: [osg-users] threading and captureCurrentState Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is current attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the attribute stack. I'll say it again: you can't access those attribute stacks from the cull traversal. They don't contain anything sensible. I that case a different question: How to get current osg::FrontFace attribute? I mean the one that would be active for any drawable traversed at the present moment during cull traversal that is just in progress and I am handling it in my custom Shadow class that is already working perfectly except some attribute values that user may pass from the scene graph above and that need to be properly handled to cast shadows correctly. The answer: you do not need it would be wrong at the moment. Thx, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles not working
I'm posting the solution to my problem should anyone encounter the same dumb problem. It appears I had left in my code a line that changed the root scene node every frame. I think the particles may be reinitialized when the root scene node is changed, so the particles never got beyond the first frame. I just changed to change the root scene node only if an actual change took place, and it works. It was on my todo list, but didn't think it would be relevant. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30555#30555 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Repeating and Bumpmapping a texture
Hello Mike, So I've been prodding around a bit in the osgFX::BumpMapping code and noticed that vertex and fragment shader programs are embedded in BumpMapping.cpp. I'm guessing the TexMat ceases to do anything because the shader programs ignore it? Is there any way to bypass that without writing my own shaders? The texture matrix still applies when using shaders, it's just that some shaders ignore it. In short, if you have a line like this in the vertex shader: gl_TexCoord[0] = gl_MultiTexCoord0; then you have to replace it by: gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; So what you could do is copy the whole shaders from the source files of osgFX::BumpMapping, just fix those lines and apply it to the same nodes. Hopefully once Robert is done with shader composition, we'll have less non-overridable shader code lying around everywhere. It should be easier for users to override just parts of the shaders to fix things like this. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixin Shadow Technique
Hi Martin, is it possible to mix two different osg shadow techniques. I would like use the parallel split shadow map for my terrain and the standard shadow map for my vehicle. No, that won't work. At least not easily. The shadows from your vehicle needs to be cast on your terrain, and if your terrain has mountains or other large features then its shadows need to be cast on your vehicle. The problem is that shadows are only calculated AND applied to objects in the subgraph under the ShadowedScene. So if you have two ShadowedScenes each with its own shadow technique, but each with a different subgraph (one with the terrain, the other with the vehicle under it) each will only calculate and apply shadows to its own subgraph. I said not easily because you could probably do some intricate setup with the CastShadow node mask and shaders, so that both ShadowedScenes have the whole scene, but one of them calculates shadows from the vehicle and applies them to the terrain, and the other calculates shadows from the rest. But I've never tried this, it may not work, and you may be doing all the work twice, so it might not be practical. You'll have to try it and see. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] parameters
Hi, I wanted help with setting these five camera parameters: focal length, f, the location of the image in pixel coordinates (o_x, o_y), the effective pixel size in the horizontal and vertical direction (s_x, s_y)? How can I set these is osg?? Thank you! Cheers, Ricky -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30558#30558 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unresolved externals while building Plugins gif/jpeg/png/etc
- Kris Dale a écrit : ReaderWriterPNG.obj : error LNK2019: unresolved external symbol png_get_io_ptr referenced in function void __cdecl png_read_istream(struct png_struct_def *,unsigned char *,unsigned __int64) (?png_read_istream@@YAXPEAUpng_struct_def@@pea...@z) I fixed that by downloading and compiling libpng 1.4 -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Torben, I haven't decided on what the remote side architecture would be. I was not sure if I needed to have a full fledged PC on the remote side or could I get away with using a monitor connected to a device that receives the wireless video feed. Not having a full fledged OC on the remote side would be my preferred option. If you replace this monitor with a video transmitter hardware, you could send this local rendered output to your reciever monitor. I'm sorry but I don't know how this could be achieved (what parts)? Thanks Sanat -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30560#30560 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RGB Color of Texture Map at Intersection
Hi, I've got a texture mapped geometry in a scene that I'm shooting rays at. I'm using the osgUtil::IntersectVisitor::Hit structure to get at the drawable that was intersected. What I really need is the color of the polygon at the intersected point. I have the hit point location in world coordinates, the normals, but now just need the RGB value of the texture hit. Thank you! Cheers, Robert -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30561#30561 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remotemonitor
Sanat Talmaki wrote: If you replace this monitor with a video transmitter hardware, you could send this local rendered output to your reciever monitor. I'm sorry but I don't know how this could be achieved (what parts)? Try Googling for video transmitter. There is hardware available for VGA, DVI, and HDMI connections as well as others. You can also choose between radio transmitter/receivers and video over IP solutions. There are a lot of possibilities. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG Programming Contest!
Dear OSG community, As you may know, VT MÄK is the vendor of the VR-Vantage visualization product line, which is based on OSG. We would like to invite you, the members of the OSG community, to participate in a visualization innovation contest that we are sponsoring. We are offering cash prizes of up to $1,500 for the winners! http://www.mak.com/vrvcontest/ All you have to do is build something that demo’s well! It could be code that you’ve written or a 3rd party nodekit that you’ve integrated, or a cool terrain and scenario… Just build a cool demo using VR-Vantage and you could win! In order to be eligible, your demo must run within the VR-Vantage framework that we've built on top of OSG. We will provide free temporary runtime and developer licenses of VR-Vantage to those who intend to participate in the contest, along with some basic support to help you understand how to fit your OSG-based code, models or simulation in. Entries must be submitted by Oct 31st, 2010 (before 11:59pm). Winners will be announced to the OSG mailing list (and at the IITSEC Tradeshow) on Nov 29th, 2010. Here are the details: 1) By submitting an entry, you are agreeing to allow MAK and our sales distributors to use and promote your work - to show it at tradeshows, reference it on our web site, capture and show video and screenshots, etc. The idea is that we want to be able to demonstrate what's possible using VR-Vantage, and in particular demonstrate that OSG-based code can be easily incorporated into VR-Vantage-based applications. 2) All you need to provide is an executable, plug-in (source code is optional but preferred) or configuration files (with instructions). VR-Vantage runs on both Windows and Linux platforms. Obviously, you also need to include any data that is required for us to run your demo. 3) The contest will be judged by a panel of simulation experts. Entries will be judged based on creativity, visual quality, and on how well they meet our goal of demonstrating what's possible in a VR-Vantage-based application. 4) If there are three or more entries that we decide are compelling enough to use in our marketing efforts, we will pay three prizes: Winner:$1,500 (USD) 2nd place: $1,000 3rd place: $500 The first place winner will also receive a permanent VR-Vantage developer’s license. 5) If we do use your work, we will always give proper attribution. We don't want to take credit for your work! 6) Please make sure that you are only submitting work that you own, or that you have the legal right to distribute. If you want to participate, please visit http://www.mak.com/vrvcontest/ for download links and entry submission instructions. For official rules, see http://www.mak.com/vrvcontest/contest-rules.php Good luck! Brett Wiesner Product Manager, Visualize Products VT MAK www.mak.com == The VR-Vantage product line includes: - VR-Vantage Stealth - an OSG-based battlefield visualization tool - VR-Vantage IG - a CIGI-compliant, commercial, OSG-based IG - VR-Vantage XR - provides a combined 2D/3D Common Operating Picture - VR-Vantage Toolkit - a powerful application-level SDK built on top of OSG, that includes built-in distributed rendering, game-like navigation interface, a Qt-based GUI framework, DI-Guy Human Characters, SpeedTree vegetation, GL-Studio HUDs and cockpit displays, SilverLining atmosphere and volumetric clouds, streaming terrain through osgEarth, built-in DIS/HLA networking, and a rich set of high-quality 3D visual models from companies like Simthetiq and RealDB. For more information about VR-Vantage, please see www.vr-vantage.com. == ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, Ok, letts assume you don't use a full fleged pc but a single monitor on the remote site. Instead plugin this monitor directly to your pc, you plaug teh video rtansmitter on the pc and the monitor on the video receiver. e.g http://www.ramelectronics.net/computer-parts/computer-cables/monitor-cables/wireless-display-extension/gefen-gtv-wvga-lr/prodGTVWVGALR.html As Jason said, it's available for a lot of technologies and video standards. Good luck, Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30564#30564 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unresolved externals while building Plugins gif/jpeg/png/etc
Frederic Bouvier wrote: - Kris Dale a écrit : Kris Dale wrote: Afternoon all! I'm having a bit of an issue I've never run into before trying to build OSG. Hoping someone can point me in the right direction. I have all of the image library .libs and includes in a directory labled ImageLibraries under my third party director. CMake finds all the libs and everything okay, links them into the solution and generates just fine. But, when I go to build, I get unresolved externals on curl, FreeType, GIF, GLUT, JPEG, PNG, and TIFF (and a couple others that I can't remember off hand). General format of the errors are: ReaderWriterPNG.obj : error LNK2019: unresolved external symbol png_get_io_ptr referenced in function void __cdecl png_read_istream(struct png_struct_def *,unsigned char *,unsigned __int64) (?png_read_istream@@YAXPEAUpng_struct_def@@pea...@z) I fixed that by downloading and compiling libpng 1.4 -Fred Thanks for your reply. :) I'm currently trying that out, but I'm having a hell of a time getting it to build (came without zlib but the solution has a zlib project as a dependency...), but do you have any idea why I'm having this problem when I've had no trouble with these libraries before? It's all very strange, and even if this works, I'm not sure what to do about JPEG and the others... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30565#30565 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Torben, Jason Thanks for the explanation, I clearly understand the video transmission part now. But using a set up such as that, I am basically transmitting the entire video feed to the remote screen. I am interested in sending the rendering of only 1 of those 3 viewports(1 view from the compositeViewer), not all 3. (as seen in the attachment below). With that being the case, does it make more sense to use the image based approach ? the rendering the image on the master pc and transfering the final image Or can it still be achieved using the method in the earlier post ? Thanks for the help ! Sanat. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30567#30567 Attachments: http://forum.openscenegraph.org//files/test_scrshot_inset_151.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, But using a set up such as that, I am basically transmitting the entire video feed to the remote screen. I am interested in sending the rendering of only 1 of those 3 viewports(1 view from the compositeViewer), not all 3. (as seen in the attachment below). With that being the case, does it make more sense to use the image based approach ? the rendering the image on the master pc and transfering the final image Or can it still be achieved using the method in the earlier post ? If your master PC has two VGA/DVI/... outputs (as most graphics cards now do) you could easily have a first monitor that would have the three viewports for the local viewer, and only render the bottom left viewport on the second monitor (which would be transmitted to a remote monitor). Essentially, the box Torben linked to takes a VGA output and sends it to the remote box, so anything you can do with a separate video output will work the same with that. 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] Transfer osgViewer stream wirelessly to a remote monitor
Hi Skylark, Thanks for your reply Are there any examples in the source that show how to only render the bottom left viewport on the second monitor (basically a generic example for selective rendering) or any suggested reading ? Thanks Sanat -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30569#30569 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, Are there any examples in the source that show how to only render the bottom left viewport on the second monitor (basically a generic example for selective rendering) or any suggested reading ? See the osgcompositeviewer example. In general, a CompositeViewer has a list of Views, each View has a master Camera, and each camera (can) have a GraphicsContext. In your current case, your three views have the same GraphicsContext, so they render to the same window. You can do what you want a few different ways. If you want your master monitor and the remote monitor to always render the views in fullscreen mode (not windowed), then you could simply set up a single GraphicsContext across both screens (see osgViewer::View::setUpViewAcrossAllScreens()), set up your three current views' Viewports to map to the part of the GraphicsContext that's visible on the first monitor, and map a new, fourth View's viewport to map to the part of the GraphicsContext that's visible on the second (remote) monitor. If it's possible that you will want either the local or the remote monitors to display the graphics in a window, then you can keep the local part the same way you have now (a GraphicsContext that has the renders three Views you have now), and set up a separate GraphicsContext on the other monitor (see osgViewer::View::setUpViewOnSingleScreen()). Then you would have a fourth View, whose Camera would have this GraphicsConext. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Thanks Jean, I'll try this out right away using a cable for the remote screen for now. -Sanat. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30571#30571 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and vsync (UNCLASSIFIED)
The sync blocks on a swap buffers call, not on the first OpenGL call (unless by
accident it's an actual OpenGL blocking call).
Non-blocking OpenGL calls run asynchronous on the back buffer (traditional
double buffering).
A glGet call is an actual OpenGL blocking call as it forces a pipe flush.
Making blocking calls when trying to run real time thoroughly defeats the
purpose.
Giovanni, what you're seeing is typical behavior when syncing with the vertical
retrace.
To maintain real-time at 50Hz each frame must be rendered in less than 20ms
(1/50).
If a frame just happens to take 21ms, then the buffer swap will block for 19ms
before actually swapping buffers.
Hence, your frame rate is cut completely in half (21ms + 19ms = 40ms = 25Hz).
And it also introduces nasty temporal aliasing.
I'm not aware of another way to synchronize with such regularity as the monitor
retrace.
I'm guessing that deterministic hardware is required given the nature of
something like OpenSceneGraph on a PC.
Although, you can achieve near real-time by things like database tuning and
pre-emptive rendering.
But, nothing to guarantee actual real time.
Extra hardware is not needed to run at multiples of the frame rate.
Just set the retrace rate to the desired frame rate and run sync'd.
Boom - multiples of the frame rate.
BTW, there's something about this alleged '2 frame latency' charge that just
doesn't pass the smell test.
Mostly - ATI sure the hell wouldn't let 'em!
Bob
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bunfield,
Dennis AMRDEC/AEgis
Sent: Wednesday, June 23, 2010 4:35 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: FOUO
The sync actually blocks on the first open gl call. So your osg update
and cull stages will run then you will block on the draw stage until the
vsync. Your problem is actually worse than 20ms w/o you knowing it.
For Nvidia cards there is a built in 2 frames of latency. So even after
your sync you won't see the image you updated come out the DVI until 2
render frames later.
In order for you to do what you want you will need some expensive frame
lock hardware with external syncs to run at a multiple of the frame
rate.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Giovanni Ferrari
Sent: Wednesday, June 23, 2010 3:28 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] OSG and vsync
Hi,
i'm developing an application that need vsync to avoid tearing but i'm
having some problems.
Here is the (really simplified) code structure of my application:
Code:
...
while ( !mViewer-done() ) {
mGraph-Update(...);
mViewer-frame();
}
I've noticed frame() function is blocking when vsync is enabled.
This means that i call the frame function, i stay blocked for something
like 20ms (50hz PAL), and then i must terminate the Update call in the
vsync period otherwise i won't be able to draw a new frame ( the graphic
card draw the old content of frame buffer without changes performed in
the update function. Changes will be performed in the next frame ).
As you can immagine this is a big problem for real-time applications
cause i'm introducing 20ms of retard.
Is there a way to syncronize frame call without using vsync ? or can i
scompose the frame function to be able to separate functions that
operate on the graph from those that perform the rendering ?
The second solution could help me cause i would be able to operate on
the graph with mGraph-Update(...) even if the frame part that write
the frameBuffer is blocked.
I hope i've explained my problem clearly.
Thank you!
Cheers,
Giovanni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=29295#29295
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
Classification: UNCLASSIFIED
Caveats: FOUO
___
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] OSG and vsync (UNCLASSIFIED)
My own research indicates that the timing rules are:
The first opengl call will block if the back buffer is not available at that
point.
The swapbuffers will block if there is already a pending swap queued (by the
last call to swapbuffers)
So, depending on the circumstances, both can block.
Lilith
On 2010-08-06 11:15:14 AM, Buckley, Bob CTR MDA/DES wrote:
The sync blocks on a swap buffers call, not on the first OpenGL call
(unless
by accident it's an actual OpenGL blocking call).
Non-blocking OpenGL calls run asynchronous on the back buffer (traditional
double buffering).
A glGet call is an actual OpenGL blocking call as it forces a pipe flush.
Making blocking calls when trying to run real time thoroughly defeats the
purpose.
Giovanni, what you're seeing is typical behavior when syncing with the
vertical retrace.
To maintain real-time at 50Hz each frame must be rendered in less than 20ms
(1/50).
If a frame just happens to take 21ms, then the buffer swap will block for
19ms before actually swapping buffers.
Hence, your frame rate is cut completely in half (21ms + 19ms = 40ms =
25Hz).
And it also introduces nasty temporal aliasing.
I'm not aware of another way to synchronize with such regularity as the
monitor retrace.
I'm guessing that deterministic hardware is required given the nature of
something like OpenSceneGraph on a PC.
Although, you can achieve near real-time by things like database tuning and
pre-emptive rendering.
But, nothing to guarantee actual real time.
Extra hardware is not needed to run at multiples of the frame rate.
Just set the retrace rate to the desired frame rate and run sync'd.
Boom - multiples of the frame rate.
BTW, there's something about this alleged '2 frame latency' charge that
just
doesn't pass the smell test.
Mostly - ATI sure the hell wouldn't let 'em!
Bob
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bunfield,
Dennis AMRDEC/AEgis
Sent: Wednesday, June 23, 2010 4:35 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: FOUO
The sync actually blocks on the first open gl call. So your osg update
and cull stages will run then you will block on the draw stage until the
vsync. Your problem is actually worse than 20ms w/o you knowing it.
For Nvidia cards there is a built in 2 frames of latency. So even after
your sync you won't see the image you updated come out the DVI until 2
render frames later.
In order for you to do what you want you will need some expensive frame
lock hardware with external syncs to run at a multiple of the frame
rate.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Giovanni Ferrari
Sent: Wednesday, June 23, 2010 3:28 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] OSG and vsync
Hi,
i'm developing an application that need vsync to avoid tearing but i'm
having some problems.
Here is the (really simplified) code structure of my application:
Code:
...
while ( !mViewer-done() ) {
mGraph-Update(...);
mViewer-frame();
}
I've noticed frame() function is blocking when vsync is enabled.
This means that i call the frame function, i stay blocked for something
like 20ms (50hz PAL), and then i must terminate the Update call in the
vsync period otherwise i won't be able to draw a new frame ( the graphic
card draw the old content of frame buffer without changes performed in
the update function. Changes will be performed in the next frame ).
As you can immagine this is a big problem for real-time applications
cause i'm introducing 20ms of retard.
Is there a way to syncronize frame call without using vsync ? or can i
scompose the frame function to be able to separate functions that
operate on the graph from those that perform the rendering ?
The second solution could help me cause i would be able to operate on
the graph with mGraph-Update(...) even if the frame part that write
the frameBuffer is blocked.
I hope i've explained my problem clearly.
Thank you!
Cheers,
Giovanni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=29295#29295
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
Classification: UNCLASSIFIED
Caveats: FOUO
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] OSG and vsync (UNCLASSIFIED)
I'm talking traditional/typical double buffering, not special cases.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Lilith Bryant
Sent: Thursday, August 05, 2010 5:27 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED)
My own research indicates that the timing rules are:
The first opengl call will block if the back buffer is not available at that
point.
The swapbuffers will block if there is already a pending swap queued (by the
last call to swapbuffers)
So, depending on the circumstances, both can block.
Lilith
On 2010-08-06 11:15:14 AM, Buckley, Bob CTR MDA/DES wrote:
The sync blocks on a swap buffers call, not on the first OpenGL call
(unless
by accident it's an actual OpenGL blocking call).
Non-blocking OpenGL calls run asynchronous on the back buffer (traditional
double buffering).
A glGet call is an actual OpenGL blocking call as it forces a pipe flush.
Making blocking calls when trying to run real time thoroughly defeats the
purpose.
Giovanni, what you're seeing is typical behavior when syncing with the
vertical retrace.
To maintain real-time at 50Hz each frame must be rendered in less than 20ms
(1/50).
If a frame just happens to take 21ms, then the buffer swap will block for
19ms before actually swapping buffers.
Hence, your frame rate is cut completely in half (21ms + 19ms = 40ms =
25Hz).
And it also introduces nasty temporal aliasing.
I'm not aware of another way to synchronize with such regularity as the
monitor retrace.
I'm guessing that deterministic hardware is required given the nature of
something like OpenSceneGraph on a PC.
Although, you can achieve near real-time by things like database tuning and
pre-emptive rendering.
But, nothing to guarantee actual real time.
Extra hardware is not needed to run at multiples of the frame rate.
Just set the retrace rate to the desired frame rate and run sync'd.
Boom - multiples of the frame rate.
BTW, there's something about this alleged '2 frame latency' charge that
just
doesn't pass the smell test.
Mostly - ATI sure the hell wouldn't let 'em!
Bob
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bunfield,
Dennis AMRDEC/AEgis
Sent: Wednesday, June 23, 2010 4:35 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: FOUO
The sync actually blocks on the first open gl call. So your osg update
and cull stages will run then you will block on the draw stage until the
vsync. Your problem is actually worse than 20ms w/o you knowing it.
For Nvidia cards there is a built in 2 frames of latency. So even after
your sync you won't see the image you updated come out the DVI until 2
render frames later.
In order for you to do what you want you will need some expensive frame
lock hardware with external syncs to run at a multiple of the frame
rate.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Giovanni Ferrari
Sent: Wednesday, June 23, 2010 3:28 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] OSG and vsync
Hi,
i'm developing an application that need vsync to avoid tearing but i'm
having some problems.
Here is the (really simplified) code structure of my application:
Code:
...
while ( !mViewer-done() ) {
mGraph-Update(...);
mViewer-frame();
}
I've noticed frame() function is blocking when vsync is enabled.
This means that i call the frame function, i stay blocked for something
like 20ms (50hz PAL), and then i must terminate the Update call in the
vsync period otherwise i won't be able to draw a new frame ( the graphic
card draw the old content of frame buffer without changes performed in
the update function. Changes will be performed in the next frame ).
As you can immagine this is a big problem for real-time applications
cause i'm introducing 20ms of retard.
Is there a way to syncronize frame call without using vsync ? or can i
scompose the frame function to be able to separate functions that
operate on the graph from those that perform the rendering ?
The second solution could help me cause i would be able to operate on
the graph with mGraph-Update(...) even if the frame part that write
the frameBuffer is blocked.
I hope i've explained my problem clearly.
Thank you!
Cheers,
Giovanni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=29295#29295
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
Classification:
