Re: [osg-users] [build] DAE build failure.. dae.h not found
Hi Dave Hi, This is my current latest COLLADA configuration. The reason that the COLLADA_DOM_ROOT was wrong was because I had an improper COLLADA_DIR environment variable. https://drive.google.com/open?id=0BzUf-8Ad-iIkOWhuYUhWSTZEWDQ Can you see something in this configuration that would cause COLLADA_DOM_2_4_OR_LATER to be set? Yes. In FindCOLLADA.cmake : IF (COLLADA_INCLUDE_DOMANY_DIR) SET(COLLADA_DOM_2_4_OR_LATER TRUE) ELSEIF() SET(COLLADA_DOM_2_4_OR_LATER FALSE) ENDIF() You will have to unset/remove entry COLLADA_INCLUDE_DOMANY_DIR . Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] DAE build failure.. dae.h not found
Hi Dave, I apologize for not providing the detail. Let me attempt to. Rather than compile the DOM, I downloaded the full set of 3rd party dependencies from this page. http://www.openscenegraph.org/index.php/download-section/dependencies The specific download I used is this one (http://download.osgvisual.org/3rdParty_VS2013_v120_x86_x64_V9_full.7z). There is a 1.4 and a 1.5 DOM within this set. I extracted the dependcies and placed them under my OSG source tree. You can see their location within my tree here. https://drive.google.com/open?id=0BzUf-8Ad-iIkQ0Jzd245eHZGTWM I went through several iterations of trying to get COLLADA configured. This is my current latest. https://drive.google.com/open?id=0BzUf-8Ad-iIkOGVWTDJ6LWNDT1E I believe COLLADA_INCLUDE_DIR shouldn't point to DOM headers. You should probably set it to c:/osg/OpenSceneGraph-3.4.0/OpenSceneGraph-3.4.0/3rdParty/x64/include . You should also set DEBUG variants of the boost libraries to point to libboost_*mt-gd*.lib (mt = multi threaded, gd = debug) and COLLADA_PCRECPP_LIBRARY_DEBUG to pcrecppd.lib (pcrecpp(with d suffix).lib) and also COLLADA_PCRE_LIBRARY_DEBUG to pcred.lib. Cheers, Robert M. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Speed of Shaders
Hi Daniel, Based on my recent benchmark I'd say there shouldn't be much difference in overall performance between fixed and programmable pipeline, at least not on Windows OS. The benchmark uses standard lighting and phong/blinn materials, with the lighting done in fragment shader. The shaders are auto generated with osg shader composer (no branching at all). With the GPU bound scene I've got: CAD Model: Vertices: 990 Faces: 49500 Display lists OFF, vertex buffers ON AMD Radeon HD 6900 Series Fixed Function DrawThreadPerContext: 83.7974 fps, warm up 0.355743 s With Shader - Per fragment lighting / Phong DrawThreadPerContext: 83.2916 fps, warm up 0.321948 s GeForce GTX 970/PCIe/SSE2 Fixed Function DrawThreadPerContext: 58.0693 fps, warm up 1.57383 s With Shader - Per fragment lighting / Phong DrawThreadPerContext: 57.2264 fps, warm up 0.338653 s Robert Milharcic Hi there I have experienced that generally as soon as I use shaders, my DRAW time starts to increase significantly, and this even if I just reimplement the fixed function pipeline basic functionality. I wonder if some out there make the same experiences. Either it is my poor shader programming (i know about if's and branches that kill performance) or is there really a price for the added flexibility? I'm running a GTX TITAN so usually there is plenty of power... Cheers, Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Robert Osfield et. al., On 14.1.2016 16:34, Robert Osfield wrote: I'm still open to making the shader parsing extensible, it seems like an interesting experimental tool. As Sebastian already pointed out, the actual parsing can be done outside osg, perhaps before Shader::setShaderSource() call or at some already provided callback. In my opinion, it is more interesting to have a spot where all the necessary information for the preprocessing step converge, so that at this point user can regain some useful control over the shader composition. I was going through a Shader.cpp to find a spot/function where all the information needed for the shader composition is at hand. Unsurprisingly, that function turned out to be void PerContextShader::compileShader(osg::State& state);. The PerContextShader::compileShader() does all the preprocessing on a shader source, like state.convertVertexShaderSourceToOsgBuiltIns(), insertion of the #version, inserting line numbers for debug purposes and generates the define string based on current define set found in osg::State. The PerContextShader::compileShader() is a function of an internal class but the osg::Shader::compileShader(osg::State& state) (which calls PerContextShader::compileShader()) isn't. That being said, minimum work required to provide some degree of extensibility is to simply make osg::Shader::compileShader(osg::State& state) virtual. Thoughts? Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Sebastian, Hi Robert, Hi Sebastian , First of all, the lightning shader only illustrates one of the cases where (optionally) repeating a code block containing substitution parameter can be useful. I used the multi-light lightning as an illustration only. First, thank you for your input. Yes, that is more or less the same approach I'm currently using. The downside of this approach is that it requires additional nontrivial code logic for the uniform array management (u_LightColor) and that is why I started to look at the alternatives. What could be more complicated there than to setup individual uniforms? Sorry this doesn't pass as a valid argument. If you have to hold the number of used lights somewhere you can hold a reference to the uniform as well. Sorry, but that is not what I had in mind. The problem here is the management of the array uniform's content and not the reference to it or the light count etc. Let say I only want to disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", osg::StateAttribute::OFF). What will you do? Let's say you have a fixed maximum on N, than you create a UBO/Array of this size and provide a count-uniform for the maximum valid entries. If a light gets disabled, you simply remove it, copy it to the back and set your count to N-1. In the shader you simply loop from 0 to count instead of N. That might break compiler optimization, but it won't hurt too much I guess. When using the setDefine, OSG will have to issue a recompile of this new variant, which will degrade performance if all combinations are needed. Assume 16 Lightsource, that will produce 65536 possible shader programs ... and that is only 16, not 500, or 1000 ... Having 1024 individually switchable Lightsources would totally wreck your idea of having an alternative to my solution. 2^1024 might exceed the numbers of atoms in the known universe, so there is not a remote chance to solve this with shader combinations... The question was purely rhetorical. I just wanted to prove my point regarding the uniform's content management vs already provided setDefines("LIGHT0", osg::StateAttribute::OFF). I didn't expect all that. Sorry for the fuzz :) BTW, I'm not planing to toggle all possible on/off combinations just to see all the permutations, the normal graph usage is what I'm after. Normal graph usage might exactly trigger a lot of combinations. My point is not that theoretical if you take into account that basically everyone could have used the feature if it was part of the core, thus the example is a practical one :-) I didn't want to prove anything here, I simply wanted to point out some practical problems. I know and I'm grateful for that. Anyway, based on feedback, I already ditched the idea and I'm now looking into alternative possibilities, mainly if shader composition can be extended in a nonintrusive way. Exactly, that was my intention, to add a higher degree of complexity and hopefully solve some problems that "turing-complete" language can't. Turing complete solves all computable problems ;-) I do understand your motivation, but I still don't see the gain really. I've presented some alternative ways to solve your problem, as I came across some of those challenges too. The idea Robert mentioned might be a good one, basically we could use some kind of callback to let the user-code preprocess the shader, wait actually we can already do this, when it is loaded via a LoadCallback :-) Actually I'm preprocessing my shader code when it's loaded to perform "include" and automated shader-define setup, so this might work for your "loop" too. That would defeat the purpose of the #pragma(tic) shader composition. You may then as well pre-parse #pragma import_defines and #pragma requires and pre-generate all the shader permutations. The purpose of #pragma(tic) shader composition is shader generation based on current define set (see the osg::State). Yes and? I'm parsing include hierarchies and therefore need to add the defines found there to the #pragma import_defines. The bulk work done by the osg::State is to determine if a new program needs to be compiled based on the set of defines. My composition is purely to keep the shader code maintainable and reusable. Currently some of the "Ubershaders" have 20-30 defines, which seriously don't want to write in the the import_defines by hand. Again I simply wanted to point out some possibilities to get you your loop-mechanism. I see. Thank you for that, too. Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Nick, On 14.1.2016 15:31, Trajce Nikolov NICK wrote: Hi Robert M. I went through this thread fast and I see you are trying (at least your show case) is lighting and use of shader composition. The approach you are taking is what I was using too, some years ago. But there are other methods that does not require any mods and will work just fine with the existing shader composition features. You can for example encode all the light attributes into a texture buffer object (think of this as an image where each float texel is one light attribute like color, etc). Frankly, I never thought about multi-light problem this way. I wonder if such technique can be generalized enough, e.g. hidden behind the scenes, so the user of the lighting framework doesn't have to deal with the texture objects. My guess is yes, but of course, I should look into technical merits of the implementation first. Have a look at this, it is Forward+ implementation in opensource project https://www.youtube.com/watch?v=beSkETJ_vgY impressive! We are releasing a new version with F+ lighting available these days, so you might want to keep an eye on it. Looking forward. Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Sebastian , On 14.1.2016 15:47, Sebastian Messerschmidt wrote: Am 14.01.2016 um 15:01 schrieb Robert Milharcic: Hi Sebastian, First of all, the lightning shader only illustrates one of the cases where (optionally) repeating a code block containing substitution parameter can be useful. I used the multi-light lightning as an illustration only. First, thank you for your input. Yes, that is more or less the same approach I'm currently using. The downside of this approach is that it requires additional nontrivial code logic for the uniform array management (u_LightColor) and that is why I started to look at the alternatives. What could be more complicated there than to setup individual uniforms? Sorry this doesn't pass as a valid argument. If you have to hold the number of used lights somewhere you can hold a reference to the uniform as well. Sorry, but that is not what I had in mind. The problem here is the management of the array uniform's content and not the reference to it or the light count etc. Let say I only want to disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", osg::StateAttribute::OFF). What will you do? Let's say you have a fixed maximum on N, than you create a UBO/Array of this size and provide a count-uniform for the maximum valid entries. If a light gets disabled, you simply remove it, copy it to the back and set your count to N-1. In the shader you simply loop from 0 to count instead of N. That might break compiler optimization, but it won't hurt too much I guess. When using the setDefine, OSG will have to issue a recompile of this new variant, which will degrade performance if all combinations are needed. Assume 16 Lightsource, that will produce 65536 possible shader programs ... and that is only 16, not 500, or 1000 ... Having 1024 individually switchable Lightsources would totally wreck your idea of having an alternative to my solution. 2^1024 might exceed the numbers of atoms in the known universe, so there is not a remote chance to solve this with shader combinations... The question was purely rhetorical. I just wanted to prove my point regarding the uniform's content management vs already provided setDefines("LIGHT0", osg::StateAttribute::OFF). I didn't expect all that. Sorry for the fuzz :) BTW, I'm not planing to toggle all possible on/off combinations just to see all the permutations, the normal graph usage is what I'm after. There is also an upper limit for the size of the array that needs to be taken into account. At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1] or Shader Storage Blocks[2] which support If this is not enough for your light-count you will probably hit performance problems first. Yes, that is true. The upper limit is not a problem for this specific multi-light problem. Even so, UBOs support in the order of ten-tousands. If this is still isn't enough, a texture will provide maximum space. Might be your example, but the number of individual uniforms is less than that. And putting a heap of uniforms into the stateset will fasten the handbrake on the CPU side. Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware). That's an assumption of yours. Usually constant folded loops with single return and without break, continue-statements are unrolled by the compiler. I'll accept performance comparisons however ;) Yes, you are right about that. The constant loop will most probably be unrolled by the compiler. Of courses, that is another assumption on top of the previous assumption :) On the other hand, my suggestion fits well into existing pragmatic shader composition logic and probably has less downsides. Downside is that you're trying to invent a meta-language here out of reasons that I commented on. The downside of your approach is a preprocessor language with no clear advantages over the tools already at your disposal. So to say, the current language is already turing-complete and you're trying to put some syntactic sugar on top, which adds some high degree of complexity to the parser and to the shader-code. Exactly, that was my intention, to add a higher degree of complexity and hopefully solve some problems that "turing-complete" language can't. Turing complete solves all computable problems ;-) I do understand your motivation, but I still don't see the gain really. I've presented some alternative ways to solve your problem, as I came across some of those challenges too. The idea Robert mentioned might be a good one, basically we could use some kind of callback to let the user-code preprocess the shader, wait actually we can already do this, when it is loaded via a LoadCallback :-) Actually I'm preprocessing my shader code when it's loaded to perform "include&quo
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
On 14.1.2016 15:20, Robert Osfield wrote: Hi Robert M. et. al. I don't have any answers/recommendations at this stage but one first reading the proposal has relative to traditional C/C++ features seems a bit out of place. #pragma(tic) shader composition currently have a very close mapping to C macro's, my hope has always been that because of this close mapping it'd be quick to pick up and use - this is one of the key reasons why I went for this approach to shader composition. This makes me wonder if C/C++ features itself might be able to inspire any proposed extensions to #pragma(tic) shader composition. Robert. Hi Robert O. If I'm not mistaken, the #pragmadirective is used by the C/C++ preprocessor for providing additional information, beyond what the language itself can offer. I thought this was the main inspiration for #pragma(tic) shader composition. Anyway, based on feedback I'm now convinced that my proposition isn't that useful as I thought :) and on that note, I rest my case. Cheers Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Sebastian, First of all, the lightning shader only illustrates one of the cases where (optionally) repeating a code block containing substitution parameter can be useful. I used the multi-light lightning as an illustration only. First, thank you for your input. Yes, that is more or less the same approach I'm currently using. The downside of this approach is that it requires additional nontrivial code logic for the uniform array management (u_LightColor) and that is why I started to look at the alternatives. What could be more complicated there than to setup individual uniforms? Sorry this doesn't pass as a valid argument. If you have to hold the number of used lights somewhere you can hold a reference to the uniform as well. Sorry, but that is not what I had in mind. The problem here is the management of the array uniform's content and not the reference to it or the light count etc. Let say I only want to disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", osg::StateAttribute::OFF). What will you do? There is also an upper limit for the size of the array that needs to be taken into account. At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1] or Shader Storage Blocks[2] which support If this is not enough for your light-count you will probably hit performance problems first. Yes, that is true. The upper limit is not a problem for this specific multi-light problem. Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware). That's an assumption of yours. Usually constant folded loops with single return and without break, continue-statements are unrolled by the compiler. I'll accept performance comparisons however ;) Yes, you are right about that. The constant loop will most probably be unrolled by the compiler. Of courses, that is another assumption on top of the previous assumption :) On the other hand, my suggestion fits well into existing pragmatic shader composition logic and probably has less downsides. Downside is that you're trying to invent a meta-language here out of reasons that I commented on. The downside of your approach is a preprocessor language with no clear advantages over the tools already at your disposal. So to say, the current language is already turing-complete and you're trying to put some syntactic sugar on top, which adds some high degree of complexity to the parser and to the shader-code. Exactly, that was my intention, to add a higher degree of complexity and hopefully solve some problems that "turing-complete" language can't. An alternative for you is to manage this part yourself by simply overriding the parts managing the define-states. Maybe Robert O. can fill in on the details here. Cheers Sebastian Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
Hi Robert Osfield, On 14.1.2016 10:10, Robert Osfield wrote: Hi Robert M, et. al, I understand the motivation the proposal but it does look like it'll complicate the parsing significantly so am inclined to suggest we look at the problem at look for easier ways to implement it. Actually, while I was waiting for a feedback I made a proof of concept implementation which turns out to be relatively straightforward task. For the parser part I have to add only a few more lines (excluding sanity checks): void Shader::_computeShaderDefines() { ... if (keyword == "import_defines") _parseShaderDefines(str, _shaderDefines); else if (keyword == "requires") _parseShaderDefines(str, _shaderRequirements); else if (keyword == "repeat_begin") { ShaderDefines shaderCodeBlockIdentifers; _parseShaderDefines(str, shaderCodeBlockIdentifers); ShaderCodeBlock shaderCodeBlock; shaderCodeBlock._begin = eol; shaderCodeBlock._end = std::string::npos; shaderCodeBlock._identifier = *shaderCodeBlockIdentifers.begin(); _shaderCodeBlocks.push_back(shaderCodeBlock); } else if (keyword == "repeat_end") { ShaderCodeBlock& shaderCodeBlock = _shaderCodeBlocks.back(); shaderCodeBlock._end = _shaderSource.find_last_not_of(" \t", pos - 8); } ... } In terms of code bloat in shaders, the #pragma(tic) shader composition ensures that the final code passed the OpenGL will have all the unimplemented paths removed so performance won't be an issue. For developers code bloat in shaders is an potential issue, one thing you do to help would be to wrap up all the lighting calls into a small set of functions that are called from the main, these functions are implemented in separate shaders that handle all the different code paths so at least the complexity is kept in one place and can be reused easily. Agreed. A second possibility would be to have developers auto generate shaders so avoid creating bloated shaders directly. A third approach might be to have the ability to provide a custom parser to the OSG so that it can handle custom syntax that developers feel suits their needs better than the default set of features provided by the core #pragma(tic) shader composition. Third approach is the approach I like most. I wonder what others have to say about this, though... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pragmatic shader - a new #pragma directive proposition
On 14.1.2016 9:52, Sebastian Messerschmidt wrote: Hi Robert, This seems more complicated than needed. Why not pass the number of lights as a compile time constant #pragma import_defines (NUM_LIGHTS) shader_state->setDefine("NUM_LIGHTS",12); and use uniform arrays: uniform vec4 u_LightColor[NUM_LIGHTS]; for (int i = 0; i < NUM_LIGHTS;++i) { light+=calcLight(u_LightColor[i], ...): } I feel your approach will bloat the preprocessor code path and will complicate the use. Hi Sebastian, First, thank you for your input. Yes, that is more or less the same approach I'm currently using. The downside of this approach is that it requires additional nontrivial code logic for the uniform array management (u_LightColor) and that is why I started to look at the alternatives. There is also an upper limit for the size of the array that needs to be taken into account. Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware). On the other hand, my suggestion fits well into existing pragmatic shader composition logic and probably has less downsides. Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Pragmatic shader - a new #pragma directive proposition
Hi all, With the pragmatic shader one could implement multiple lights and other repetitive constructs like this: -- start of shader code -- #pragma import_defines ( LIGHTING, LIGHT0, LIGHT1 ) #ifdef LIGHTING #ifdef LIGHT0 uniform vec4 u_LightColor0; #endif #ifdef LIGHT1 uniform vec4 u_LightColor1; #endif varying vec4 basecolor; void light( in vec4 lightColor, inout vec4 color ); #endif void main(void) { basecolor = gl_Color; #ifdef LIGHTING #ifdef LIGHT0 light( u_LightColor0, basecolor); #endif #ifdef LIGHT1 light( u_LightColor1, basecolor); #endif #endif gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; } -- end of shader code -- ... and to enable both lights: stateset->setDefine("LIGHTING"); stateset->setDefine("LIGHT0"); stateset->setDefine("LIGHT1"); The problem with this approach is that nobody really knows in advance how many more lights will be needed. Moreover, the shader can get heavily bloated when more and more lights are added. As a solution I would like to propose a new #pragma construct: #pragma repeat_begin( DEFINE_IDENTIFIER${SubstitutionParameter} ) (shader code block) #pragma repeat_end() ... and the shader code supporting arbitrary number of lights would then look like this: -- start of shader code -- #pragma import_defines ( LIGHTING, LIGHT${Member} ) #ifdef LIGHTING #pragma repeat_begin( LIGHT${Member} ) uniform vec4 u_LightColor${Member}; #pragma repeat_end() varying vec4 basecolor; void light( in vec4 lightColor, inout vec4 color ); #endif void main(void) { basecolor = gl_Color; #ifdef LIGHTING #pragma repeat_begin( LIGHT${Member} ) light( u_LightColor${Member}, basecolor); #pragma repeat_end() #endif gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; } -- end of shader code -- ... where ${Member} is a substitution parameter and LIGHT is define identifier. Then with: stateset->setDefine("LIGHTING"); stateset->setDefine("LIGHT${0}"); stateset->setDefine("LIGHT${1}"); stateset->setDefine("LIGHT${5}"); ... where ${0}, ${1}, ${5} are substitution values, osg would produce following shader code: -- start of shader code -- #define LIGHTING #define LIGHT0 #define LIGHT1 #define LIGHT5 #ifdef LIGHTING uniform vec4 u_LightColor0; uniform vec4 u_LightColor1; uniform vec4 u_LightColor5; varying vec4 basecolor; void light( in vec4 lightColor, inout vec4 color ); #endif void main(void) { basecolor = gl_Color; #ifdef LIGHTING light( u_LightColor0, basecolor); light( u_LightColor1, basecolor); light( u_LightColor5, basecolor); #endif gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; } -- end of shader code -- Before I do any coding I'd like to know if proposed solution would be of any use to the osg community? Or maybe there is a better way? I'm currently solving these kinds of problems with uniform arrays, but unfortunately, the uniform array has its own max number of elements and the management code of such approach tend to be complicated... Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maximizing rendering throughput
On 23.10.2015 13:46, Robert Osfield wrote: Hi Robert, On 23 October 2015 at 12:36, Robert Milharcic wrote: First of all, I didn't know that cull and draw traversal can execute in parallel on a single scene. I always thought that cull and draw can only execute sequential (serial) in all available threading models. Anyway, what I know for sure is that update and draw traversal can indeed execute in parallel within some threading models, and that is the reason why we need DYNAMIC variance, to tell drawing thread it must process dynamic elements first, and then immediately allow execution of the update traversal in a main thread while STATIC elements are still being rendered in a draw thread. I also suspect that next frame cannot start before all the static+dynamic elements are rendered. If I'm correct on this one, then few DYNAMIC elements should not affect frame rate at all, because there is plenty of time to do the processing while STATIC elements are still being rendered. With the DrawThreadPerContext and DrawThreadPerContextCullThreadPerCamera threading models the static part of the rendering can be done in parallel with the next frame. You guess this correct. The one thing I'd add is that the OSG itself doesn't attempt to sort DYNAMIC objects so that are drawn first. You can set up your StateSet::RenderBinDetails to force the dynamic objects to be drawn first, but you can only do this for objects that don't affect the rendering of other objects, or are affected by what is the fame buffer already. In the case of text it has to be placed in the depth sorted bin which is drawn after the main opaque bin, so if there are text objects set to DYNAMIC then you stop the next frame from start till the end of dispatch of the last depth sorted dynamic object. This may well be very near the end of the draw dispatch so you come pretty close to nullifying all the capacity for running the draw thread in parallel with the next frames' update and cull traversals. This is likely the situation for Sebastian. Using double buffering of Text object's is probably the best way to avoid updating a Text object while it's being drawn, allowing the Text DataVariance to remain STATIC. Such double buffering could be done a custom Node that has two Text objects, one for current frame being updated, and one for the previous frame still being rendered. Robert. Hi Robert Osfield, Thank you very much for the more in-depth explanation. I pretty sure that this additional info can benefit Sebastian and others as well(including me). Cheers, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maximizing rendering throughput
On 22.10.2015 18:36, Sebastian Messerschmidt wrote: Hi, I have a couple of elements in the scene which data variance is set to DYNAMIC to change them thread safe. This will effectively kill performance as cull and draw are no longer executed in parallel. So if I'd set those elements to STATIC, where is the safe place to update them? For instance I have some osg::Text which has to be changed every frame. Is it safe to change it in between the update and renderingTraversals? Also, what about updateOperation? Is considered to modify drawables from there? Cheers Sebastian Hi Sebastian, First of all, I didn't know that cull and draw traversal can execute in parallel on a single scene. I always thought that cull and draw can only execute sequential (serial) in all available threading models. Anyway, what I know for sure is that update and draw traversal can indeed execute in parallel within some threading models, and that is the reason why we need DYNAMIC variance, to tell drawing thread it must process dynamic elements first, and then immediately allow execution of the update traversal in a main thread while STATIC elements are still being rendered in a draw thread. I also suspect that next frame cannot start before all the static+dynamic elements are rendered. If I'm correct on this one, then few DYNAMIC elements should not affect frame rate at all, because there is plenty of time to do the processing while STATIC elements are still being rendered. You might also want to have a look at osgBullet project where calculations are done in its own thread and then the results are synchronised with a scene graph in an update traversal through a triple buffering mechanism. I also did a benchmark recently that shows what is the effect of different threading models on a geometry intensive scene. If someone is interested in results let me know... Best Regards, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using a custom StateAttribute
On 18.10.2015 22:58, Jannik Heller wrote: To me it seems the feature advertised in docs of creating your own StateAttributes simply isn't possible, just because of this one function returning enum instead of int, which would be an easy fix. Am I missing something here? Probably not. The underlying integral type for the enum Type could be (and probably is) int8_t. That implies that possible values for the user type should be within range +- 127 or the conversion to Type will be undefined. Best Regards Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on how to best inject behavoir regarding FBOs
On 9.8.2015 17:04, BjXXrn Blissing wrote: Hi Robert, Well, I was hoping to be able to do the integration without modifications to OSG. If such modifications proves to be necessary, then I agree with Jan that we should wait for v0.7 to see if that integration is easier. It seems unnecessary to change OSG for a problem that may disappear in later Oculus SDK versions. But I am happy to report that I have a working, flicker free solution. Although I had to make a rather cumbersome call inside my pre draw camera callback to get the FBO handle: Code: osg::Camera* camera = renderInfo.getCurrentCamera(); osgViewer::Renderer *camRenderer = (dynamic_cast(camera->getRenderer())); if (camRenderer != NULL) { osgUtil::SceneView* sceneView = camRenderer->getSceneView(0); if (sceneView != NULL) { osgUtil::RenderStage* renderStage = sceneView->getRenderStage(); if (renderStage != NULL) { osg::FrameBufferObject* fbo = renderStage->getFrameBufferObject(); GLuint fboHandle = fbo->getHandle(ctx); } } } This also forced me to link with osgUtil. I don't know if there is a simpler way of getting the FBO handle, which does not involve osgUtil? Best regards Björn Hi Björn, If you need low level manipulation of the FBO, it migh be best to simply create one that is fully independent/transparent to the osg (as opposed to fully automated high-level camera attachment). Having said that, you could simply create new FBO, in let's say, CustomCamera constructor: CustomCamera::CustomCamera() { //usual camera setup for rtt //... osg::Texture2D* texture = createTexture(); //attach(osg::Camera::COLOR_BUFFER, texture); _fbo = new osg::FrameBufferObject; _fbo->setAttachment(osg::Camera::COLOR_BUFFER, osg::FrameBufferAttachment(texture)); setPreDrawCallback(new BindFboPreDrawCallback(_fbo.get())); setPostDrawCallback(new UnBindFboPostDrawCallback); } class BindFboPreDrawCallback : public osg::Camera::DrawCallback { public: BindFboPreDrawCallback(osg::FrameBufferObject* fbo) : _fbo(fbo) {} virtual void operator () (osg::RenderInfo& renderInfo) const { _fbo->apply(*renderInfo.getState()); //bind FBO } protected: osg::ref_ptr _fbo; }; class UnBindFboPostDrawCallback : public osg::Camera::DrawCallback { public: virtual void operator () (osg::RenderInfo& renderInfo) const { renderInfo.getState()->get()->glBindFramebuffer(osg::FrameBufferObject::READ_DRAW_FRAMEBUFFER, 0); } }; You can the manipulate CustomCamera's owned fbo or reattach textures at any suitable stage ... P.S.: You may also need to call _fbo->resizeGLObjectBuffers(maxSize) and _fbo->releaseGLObjects(state) when appropriate. Best Regards, Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Robert, I have just unpacked the zip file, but am not sure yet what I'm going to be looking at. These are mods that provide what functionality, what should I be expecting the example to do? The idea here is to load any osg supported node file and then convert all the FFP StateAttributes to shaders. For example: osg::ref_ptr node = osgDB::readNodeFiles(arguments); and then with ... osgEx::ShaderComposerHelper sch; sch.apply(node.get()); ... you can convert all FFP attributes found in scene to shaders. Then the shader composition must be enabled: osgViewer::ViewerBase::Windows windows; viewer.getWindows(windows); for(osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr != windows.end(); ++itr) { (*itr)->getState()->setShaderCompositionEnabled(true); (*itr)->getState()->setUseModelViewAndProjectionUniforms(true); (*itr)->getState()->setUseVertexAttributeAliasing(true); (*itr)->getState()->setShaderComposer(new osgEx::ShaderComposer); } .. and at this point all you have are one or more shader programs and then the viewer can be run as usual. At the time, I wasn't able to find node file that containing all the various FFP attributes, so the example is a bit crowded with the code for the test scene . If you are trying to compile the example, then you will first need to checkout SVN revision 13962 and then overwrite the files and enable OSG_EXPERIMENTAL option in cmake. You can find complete FFP emulation shader in examples/osgshadercomposerhelper/ShaderInjections.cpp.glsl, which is the main source to feed the shader composer. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Robert, I was amazed by the simplicity of the new pragmatic shader composition - but yet it is so powerful. Well done! So, I was making good progress porting old shader composition code to pragmatic one until I hit the wall. The problem is, I don't see any obvious way to extend the current pragmatic shader composition API. If I may, I would suggest two things for consideration: 1. Add a new layer of abstraction for StateSet's define API, lets say class object ShaderDefine that we can subclass. The ShaderDefine (or any other suitable name) would contain std:string _defineName, std::string _defineValue and at least a less operator, since you are inserting definition into map, and virtual void apply(State&) const {}. Of course, the apply would then be called from State::applyDefineList() giving the user an opportunity for define's customization. So the new StateSet::setDefine() would look something like this: setDefine(ShaderDefine*, StateAttribute::OverrideValue);. Also, with the proposed abstraction it would be easier to write serialization support. 2. The greatest strength of old shader composer is ShaderComposer::getOrCreateProgram(). As others have already mentioned, this is the point where we used to gain control over the program composition. I'm personally using this control point for things like program->addBindAttribLocation/addBindFragDataLocation/addBindUniformBlock and for some other sanity checks. It would be great if we can somehow install a callback or overload some member to regain the control of the program composition. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader composition
On 29.1.2015 0:23, Trajce Nikolov NICK wrote: I read the shader composition code and the used classes - which are really without any documentation:-). Can someone give a fast intro into this, the sample for example? Thanks a bunch as always Hi Nick, I once did some experimental coding on shader composition. The idea was to emulte all the FFP attributes with shaders and possibly extend the composition with custom shaders. Although the code is working and it produces optimal shaders with zero branching or defines, I have never had time to polish it up and send it for a review. I could post the sample I used for testing, if you are interested. The bad news is that it requires some osg core modifications to work properly. I can send those, too. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem replacing shader built-ins (gl_EyePlane)
On 7.1.2014 22:12, Garrett Cope wrote: I am using the VDSM implementation and passing in the 4 planes as found in assignTexGenSettings(...), but they seem to be different than what is actually found in the built-ins during shader execution. I am guessing there is some sort of modelview transformation happening, but having trouble with it. Any ideas on how to recreate these planes for passing into the shader would be appreciated. Hi Garrett, If I remember correctly all the built-in gl_EyePlaneX planes are pre-multiplied with the inverse model-view matrix. Also, if you need projective texture fetch you will need to divide generated texure coordinate st with q component (tex_coord.st/tex_coord.q) or do the fetch with a textureXDProj sampler. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Model attached to Camera
On 14.11.2013 11:32, Trajce Nikolov NICK wrote: It doesn't look right. What is wrong with this code? Also, there is some delay (when I don't apply the orientation just for debug), the model when attached is sort of delayed following the camera. Any hints? Hi Nick, I'm just guessing here, but if model is delayed, it probably means that camera's view matrix wasn't updated yet. If I remember correctly, Viewer will update its camera by calling cameraManipulator->updateCamera() somewhere in the update traversal too... so, maybe node callback is called before updateCamera()? Maybe you could cast camera->getView() to osg::Viewer::View and then call getViewerBase(), cast it to proper Viewer and call viewer->getCameraManipulator()->updateCamera() ... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compatibity profile
On 5.10.2013 20:15, Sajjadul Islam wrote: Code: #version 400 in vec3 VertexPosition; in vec3 VertexColor; out vec3 Color; void main() { Color = VertexColor; gl_Position = vec4(VertexPosition,1.0); } Please try it on your end and let me know!! Hi Sajjadu, I can't try your code at the moment, but from what I can tell, the vertex shader is missing : uniform mat4 osg_ModelViewProjectionMatrix; and then in vertex shader main use: gl_Position = osg_ModelViewProjectionMatrix*vec4(VertexPosition,1.0); The osg_ModelViewProjectionMatrix, osg_ModelViewMatrix and others are automatically set by the osg. Also, don't forget to call: gc->getState()->setUseModelViewAndProjectionUniforms(true); Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compatibity profile
On 4.10.2013 13:17, Sajjadul Islam wrote: Hi Forum, I know that this topic is widely discussed here to run shading language 4 with OpenGL 3 and onwards using the compatibility profile. I checked the osgsimplegl3 and osgvertexattrib array example. Then i try to compile the a simple application with a pass through shader only , but i am having the following error: Code: Got an X11ErrorHandling call display=0x9c41880 event=0xb3fadf2c GLXBadDrawable Major opcode: 135 Minor opcode: 11 Error code: 146 Request serial: 9503 Current serial: 9503 ResourceID: 73400323 I am also attaching the code snippet for your kind review: Code: Hi Sajjadul, 1. add some window dimensions to the traits like: traits->x = traits->y = 20; traits->width = 800; traits->height = 600; 2. set viewport to the camera camera->setViewport(0,0,traits->width,traits->height); 3. you may also want to enable gc->getState()->setUseModelViewAndProjectionUniforms(true); Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 24.9.2013 14:40, Aurelien Albert wrote: Yes, and I think this is what I need : - a standard uniform list, which contains uniforms setted from regular osg::Uniform instances - a "comes-from-stateAttribute" uniform list, in the same way there is "associated modes" with some StateAttributes In my opinion, theses uniforms are not really linked to the ShaderComposition system, but complementary : sometimes you just want to push some "StateAttribute-associated" uniforms in the state. Hi, I think I now understand what you are trying to do, but I don't understand to what purpose? What would be the benefit of having StateAttribute associated uniforms pushed into state? Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 24.9.2013 9:05, Aurelien Albert wrote: I know this is more like a "workaround", but it is really usefull to be able to write StateAttributes classes which manage and apply their own uniforms. To solve my problem described in this post, my guess is I have to replace the "_currentShaderCompositionUniformList" with a stack in which we can "push" and "pop" uniforms when StateAttributes are "pushed" and "poped". Hi, If you do change the list to stack so you can push/pop uniforms you will end up redoing standard uniform handling but this time with a parallel uniform list. In my opinion the usage scenario with osg::ShaderAttribute / coposition uniforms is: Traverse graph, push and merge StateSets down to the Drawable where osg::ShaderAttribute(s) / coposition uniforms are to be set. It was my first attempt to do it like this but I later changed my aproach and rolled out my own custom shader attribute. I call it ShaderComponentAttribute, where I store a map of uniforms that were applied at parent (owning) StatSet. When ShaderComponentAttribute is removed, it also removes its managed uniforms. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 24.9.2013 8:40, Aurelien Albert wrote: - Node A : Shader Program + Shader Composition Uniforms Child node B : nothing Child node C : Shader Program In this case, Shader Composition Uniforms are properly applied on the Shader Program from node A, but not on shader program from node C Hi, I think you should simply call standar StateSet::AddUniform() at Node A so that every node below can inherit them. I think composition uniforms are good only if used in conjunction with osg::ShaderAttribute set to StateSet at leaf node. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 23.9.2013 23:24, Aurelien Albert wrote: Thanks for the sharing offer, I'm interested ! I think I've made some progress in the analysis of my problem, could you just test the following inside your experimental "shader composition" project ? (I would like to know if you have any side effects.) in osg/State.cpp : in the method : State::apply(const StateSet* dstate) comment the following line : _currentShaderCompositionUniformList.clear(); Hi Aurelien, I'm using StateSet::AddUniform() but I changed them to state::applyShaderCompositionUniform() and commented out currentShaderCompositionUniformList.clear() . Everyting works like before but I spoted one side effect: the currentShaderCompositionUniformList is now growing and composition uniforms gets applied to non-related programs that doesn't need them. In other words, comenting out clear() will result in redundant calls to Uniform::apply(). Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 23.9.2013 12:51, Aurelien Albert wrote: I've spotted the problem source : in void State::apply(const StateSet* dstate), there is this line : _currentShaderCompositionUniformList.clear(); So all shader composition uniforms are cleared at each StateSet apply. I've tried to comment this line and everything seems to work. Since I don't really understand the shader cmoposition uniforms system, can you give me some advices on this issue ? Hi Aurelien, I'm almost done with my experimental "shader composition" project. So far I was able to port 3/4 of FFP attributes to the shader compositor. I've designed ShaderComposerVisitor that will populate graph with shader attributes, either by replacing existing FFP attributes (for core profile and ES 2.0) or add them to coexist with existing FFP attributes to provide fallback for old hardware. I wasn't able to pull it through with osg::ShaderAttribute or with composition uniforms (having current state-set's local scope), instead I had to roll my own ShaderComponentAttribute based on osg::ShaderAttribute that is able to manage standard uniforms and ShaderComponent and apply standard osg matrices if requested. I've also made a few nonintrusive changes to the osg core to support RenderStage scope uniforms to be able to handle position state attributes properly. If there is some interest I could send all the stuff to the submissions at the end of this week to at least hang in there until somone else find a better solution. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader composer and position state
On 4.9.2013 15:39, Robert Osfield wrote: Hi Robert, When implementing the osg::ShaderComposer functionality I had in mind that ability to have a custom StateAttribute/ShaderAttribute::apply() compute the view dependent uniform state and apply this to the osg::State. The apply() method would get the modelview matrix from the osg::State and apply this to the local uniform before passing it on to osg::State. Might this work for you? No, I don't think so. I'm basically trying to implement a special uniform or maybe custom shader attribute, having a global scope, but to be set localy at the node or stateset. Special uniform would then be multiplied with a local modelview matrix and applied to all programs. This is analogus to position state handling already implemented for FFP (LightSource/Light for example). Best Regards Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shader composer and position state
Hi all, My goal is to replace shader generator with shader composer, so I spent a few days playing with it. It proved to be very flexible and powerful tool but unfortunately, it lacks the support for a key feature I would consider necessary, and that is support for the "position state". Putting it differently, shader composer is "blind" for position state attributes (Light, ClipPlane, TexGen) stored within LightSource, ClipNode and TexGenNode. I was able to workaround the problem with cull calbacks or with custom cull visitor where I'm able to identify "positioned uniform" multiply it with model-view matrix and then force shader composer to accept the uniform and ShaderComponent attached to the state attribure. Unfortnatelly, this workaround introduced some unnecessary code complications and problems with uniform management and that is why I strongly feel that the solution should be integrated into OSG core. I believe the implementation of such a feature should be straightforward task and since I might be able to post the core solution @submissions for a review, I am asking you for advice on how user interface should look. I have two ideas for now: 1. easy to implement solution dedicated to LightSource, ClipNode and TexGenNode. In addition to LightSource::setLight we could introduce two new methods: LightSource::addPositionedUniform(name, VecX) that will be collected into PositionalStateContainer and get special treatment with model-view matrix before applied at RenderStage and LightSource::addUniform(osg::Uniform*) to set other non-poisitioned uniforms that won't be multiplied but applied in a same way before any other attribure. 2. general soution by introducing two new types of uniforms: osg::PositionedUniform and "global? scene?" uniform, Both can be set at any StateSet and will be applied at RenderStage before any other attribure. 3. both solutions: First dedicated and after that general solution which will replace internal logic of LightSource and others leaving the interface as is. 4. ? Best Regards Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing material of geodes/drawables during rendering - crash
On 29.8.2013 15:07, Glenn Waldron wrote: For rendering, data variance only applies to Drawables and StateSets, not to Nodes. Data variance on Nodes is only honored by the osgUtil::Optimizer. So if you want to change your materials at runtime in multi-threaded mode, set the StateSet d.v. to DYNAMIC. Yes of course, my bad. Although data variance can be set on any osg::Object, it is only feasible to set it on drawables and state sets. Anyway, DYNAMIC variance will force the frame to wait till the dynamic draw is complete. Thanks for the correction Glenn. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing material of geodes/drawables during rendering - crash
On 29.8.2013 10:30, Peter Bako wrote: Hello guys. What is the correct way to change materials during rendering? What callbacks should I use, update callback? Sometimes I get a crash and I assume it is becasue of changing the material. Should I use special updateCallback on every geode/geometry I am changing, or it is enough to use the callback on a parent and change the state attributes also on children? Should the data variance be DYNAMIC on these nodes? Hi Peter, If I'm not mistanken, DYNAMIC variance has to be set only at the Node(s) associated with the state set (containing material state attribute) you want to modify. Then you can change material before or after frame, in update or event traversal, or you can attach update operation to the viewer/view with addUpdateOperation/removeUpdateOperation . Changing variance to DYNAMIC will introduce some performance penalty. If this is unacceptable you can always use "clone state set trick". You simply clone state set, change it, and then assign new stateset and update its parents. Old state set will be deleted by ref_ptr when no longer needed. This will prevent disruption of the rendering traversals. See how it is done in StateSetManipulator::clone() in osgGA module. If I'm wrong please someone correct me :) Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] regular osg-models result in notifications with osg built for opengl-3.x / opengl-es-2.0 support
On 26.8.2013 22:32, deniz diktas wrote: Is there a method or utility (maybe some visitor) inside osg that can modify the models so that the rendered model is consistent with opengl-3.x and opengl-es2.0 features, and that these notifications are disabled? Hi Deniz, The short answer is: To my best knowledge, and i might be wrong, osg doesn't provide utility or visitor that can remove fixed pipeline state attributes from the graph or visitor that is able to output core opengl or ES2.0 compatible shaders to be used as a replacement for the fixed pipeline state attributes. Anyway, you might want to have a look at the osgshadergen example to see how to do it with osgUtils:ShaderGenVisitor but I believe it won't produce opengl 3 core or ES 2 compatible shaders. You can of course modify ShaderGenVisitor source... Also, there is osg::ShaderComposer you might want to have a look at, designed to solve problems like one you are describing. The idea here is to attach "shader componet" to any? fixed pipeline state attribute and then let osg automatically compose final shader program for you. The bad news here is that shader composer isn't finished yet, I believe. Of course, you can have a look at the osgshadercomposition example ... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader composing related link
On 5.8.2013 15:23, Sergey Kurdakov wrote: en sourced so maybe it might be of some interest to look at. Best regards Sergey Very Interesting indeed. One more thing is needed though, the osg implementation of the nvFX interfaces (currently implemented for GL, D3D, CUDA and OPTIX) . On the other hand, Wang Rui's effect compositor looks cleaner, more osg-ish and maybe easier to extend... In any case, a decent effect framework is needed now more then ever. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt5 integration first try
Hi Martin, in reference to my submission here: http://forum.openscenegraph.org/viewtopic.php?p=54555#54555 as I said, I simply submitted Vitezslavs patch. I can certainly try to remove the extra hooks from the osg main classes. The moveToThread command must be called with the Qt widget and the Qt graphics thread before makeCurrent is called the first time. Maybe there is a way to achieve multithreaded rendering in a non-intrusive way by simply calling both new members (moveToThread and moveBack) from GraphicsWindowQt itself. We could overload GraphicsContext::setGraphicsThread and GraphicsContext::releaseContextImplementation with something like this: void GraphicsWindowQt::setGraphicsThread(osg::GraphicsThread* gt) { if (gt) { moveToThread(gt); } osgViewer::GraphicsWindow::setGraphicsThread(gt); } bool GraphicsWindowQt::releaseContextImplementation() { existing stuff here ... // move context back to main thread if (_widget->context()->thread() != qApp->thread()) { moveBack(); } return result; } Of course, setGraphicsThread should be made virtual if not already. Another thing I just realized: The code will only work when CMake option BUILD_OPENTHREADS_WITH_QT is set! Otherwise the static_cast in GraphicsWindowQt::moveToThread will fail. How can I solve this? For multithreading to work with Qt5 it seems we need the render threads to be QThreads. Maybe add a flag to OpenThreads/Config and #ifdef against that? Flag is ok ... or maybe we could add new api to OT, an api that can return string like "qt", "win32", "pthreads", "sproc", "c++11"... , benign but useful ... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MousepressEvent not able to capture from osg::Viewer by Qt
On 8.5.2013 10:16, Sujan Dasmahapatra wrote: Thanks Robert. It is working fine... On the left mouse press I am showing a message using QMessagBox. But on the middle mouse press was having pan and right mouse press was having zoom in zoom out. How can I retain those functionalities. With this these functionalities are gone. void CSGraphicsView::mousePressEvent(QMouseEvent *e) { if(e->button()==Qt::LeftButton) { QMessageBox msg; msg.setText("Mouse pressed"); msg.exec(); } } Call base class implementation in a case where you need to retain original functionality: void CSGraphicsView::mousePressEvent(QMouseEvent *e) { if(e->button()==Qt::LeftButton) { QMessageBox msg; msg.setText("Mouse pressed"); msg.exec(); } else GLWidget::mousePressEvent(e); } Also, calling frame on paintEvent might not be enough. You should also call frame on every user input, on all mouse and keyboard events for example... or you can mount a QTimer and make it call frame at some interval. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MousepressEvent not able to capture from osg::Viewer by Qt
On 8.5.2013 7:04, Sujan Dasmahapatra wrote: I am trying to implement a mouse press event with QT and OSG but unable to do it. Pls help. Below is my ViewerWidget class which is derived from QWidget and osg::CompositeViewer..In the constructor I got gView which is a osg::GLWidget, I am trying override mousePressEvent but when I click message not coming. What I am doing wrong pls help.. [snip] osg::Camera* ViewerWidget::createCamera( int x, int y, int w, int h, const std::string& name, bool windowDecoration ) { osg::DisplaySettings* ds = osg::DisplaySettings::instance().get(); osg::ref_ptr traits = new osg::GraphicsContext::Traits; traits->windowName = name; traits->windowDecoration = windowDecoration; traits->x = x; traits->y = y; traits->width = w; traits->height = h; traits->doubleBuffer = true; traits->alpha = ds->getMinimumNumAlphaBits(); traits->stencil = ds->getMinimumNumStencilBits(); traits->sampleBuffers = ds->getMultiSamples(); traits->samples = ds->getNumMultiSamples(); osg::ref_ptr camera = new osg::Camera; camera->setGraphicsContext( new osgQt::GraphicsWindowQt(traits.get()) ); camera->setClearColor( osg::Vec4(0.2, 0.2, 0.6, 1.0) ); camera->setViewport( new osg::Viewport(0, 0, traits->width, traits->height) ); camera->setProjectionMatrixAsPerspective( 30.0f, static_cast(traits->width)/static_cast(traits->height), 1.0f, 1.0f ); return camera.release(); } I don't know why this code didn't crash, I think it should. Anyway, you should create an instance of the CSGraphicsView somewhere within createCamera: CSGraphicsView* gView = new CSGraphicsView; gView->setGeometry(x, y, w, h); traits->inheritedWindowData = new osgQt::GraphicsWindowQt::WindowData( gView ); ... or you can pass an instance of the CSGraphicsView to the osgQt::GraphicsWindowQt constructor. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector "distance" and Transform
On 4.3.2013 11:05, Andreas Roth wrote: hanks to Aurelien for the work-around. Hi Andreas, That is of course my personal opinion, but i think PolytopeIntersector is overkill for most, if not all usage scenarios plus it doesn't work correctly on a scaled geometry. I simply took LineSegmentIntersector renamed it to IntersectorPrivate, added some sensitive area along picking vector, added suport for lines, points etc... As I remember it, it was pretty straight foward task... I'm not saying my solution is perfect nor thoroughly tested but it works well for our needs. Of course if someone would like to see what I did I can paste code here... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLWidget resizeEvent
On 6.3.2013 9:36, Gianni Ambrosio wrote: Hi Robert, then there is something missing somewhere or a mistake from my side. I derived from osgQT::GLWidget to have a QGLWidget to insert in my GUI. The usual way to get to the osgQT::GLWidget is something like this: osg::ref_ptr gwQt = new osgQt::GraphicsWindowQt( traits.get() ); camera->setGraphicsContext( gwQt.get() ); osgQt::GLWidget* glWidget = gwQt->getGLWidget(); // insert glWidget into GUI here If you must derive from osgQT::GLWidget then you will need to pass your custom GL widget to the GraphicsWindowQt constructor through GraphicsContext::Traits::inheritedWindowData or call GraphicsWindowQt constructor with your custom widget: traits->inheritedWindowData = new osgQT::GraphicsWindowQt::WindowData( myCustomGLWidget ); osg::ref_ptr gwQt = new osgQt::GraphicsWindowQt( traits.get() ); // osg::ref_ptr gwQt = new osgQt::GraphicsWindowQt( myCustomGLWidget ); camera->setGraphicsContext( gwQt.get() ); // insert myCustomGLWidget into GUI here I would first check if GLWidget/GraphicsWindow/Camera setup is done correctly. When the application starts I basically add an osgWidget::Widget (or even a osgWidget::Label) to an osgWidget::WindowManager. The problem is that all widgets have a small size even if the resizeEvent implementation of osgQt::GLWidget is executed. Only when I resize the Qt window containing the osgQt::GLWidget and the resizeEvent in executed again, the widgets are correctly resized. On the other side if I resize the Qt window "before" adding widgets to the osgWidget::WindowManager then, in this case, widgets are correctly shown immediately. I'm sorry but at the moment I don't have a simple example. If the GraphicsWindowQt *did pick the resize event* maybe all you need is to call viewer->frame() for the events to be processed by the osg. Also try with viewer->setRunFrameScheme(ON_DEMAND). This will prevent osg to discard accumulated events picked outside the predefined time frame. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLWidget resizeEvent
On 5.3.2013 16:12, Gianni Ambrosio wrote: Hi All, I'm experiencing an issue that seems related to the size of a osgQt::GLWidget. Since my case it is pretty hard to explain, first of all I would like to know if it is correct to completely override the QGLWidget::resizeEvent(QResizeEvent*) implementation. In fact, in a previous implementation of an AdapterWidget (derived from QGLWidget and embedding a osgViewer::GraphicsWindow) resizeGL(w, h) was reimplemented instead of resizeEvent(). Both methods are virtual of QGLWidget but resizeGL() is called by QGLWidget::resizeEvent(). The latest also does something more: Code: void QGLWidget::resizeEvent(QResizeEvent *) { Q_D(QGLWidget); if (!isValid()) return; makeCurrent(); if (!d->glcx->initialized()) glInit(); resizeGL(width(), height()); if (d->olcx) { makeOverlayCurrent(); resizeOverlayGL(width(), height()); } } That means osgQt::resizeEvent() implementation overrides the original code of QGLWidget. Is that really not necessary and can be correctly skipped? I'm just guessing here but i think the QGLWidget's resizeEvent was intentionally suppressed by the author to prevent the execution of the makeCurrent() call. It is probably done so to avoid crashes when running osg in multi-threaded threading model. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] qtOsg EventHandler issue
> 1 - The program starts with no scenario windows > 2 - I can add or remove Windows with a new/open file operation. > 3 - for the first window to be opened everything works perfect regarding > events ( mouse click, mouse press, drag, etc ). > 4 - For all the others i have to wait a time till the event handler starts to > work. Sometimes, It takes more than 5 seconds. > > Do i have to force some call to make the current window active together > with its current viewer's event handler ? > > When using osg 2.9.15 i had no trouble with this. > > Now I'm using osg 3.0.1 > Try with ON_DEMAND frame scheme: setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); Why? In the viewer event traversal there is a line: double cutOffTime = (_runFrameScheme==ON_DEMAND) ? DBL_MAX : _frameStamp->getReferenceTime(); Your app is waiting because osg cannot pull all queued events within a period of cutOffTime. Sometimes many frames are needed to process all accumulated events to get to your mouse/keyboard events. You can also leave default frame scheme as is and clear osg event queue yourself. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Collada plugin
As Jean-Sebastien already said, If the dae plugin is linked against, for example, msvcr90d.dll, then it is generally good idea to link all its dependant dlls to the same runtime (msvcr90d.dll). That usually means you will have to recompile collada and all its external libs from source. Of course, it is posible that the problem is elsewhere... Robert Milharcic > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Héctor Martínez > Sent: Friday, September 09, 2011 12:15 PM > To: 'OpenSceneGraph Users' > Subject: Re: [osg-users] OSG Collada plugin > > Hi, > > I am still having the same problem. Does somebody have any idea of what is > happening? > > Thank you. > > Héctor > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Héctor > Martínez > Sent: miércoles, 24 de agosto de 2011 9:29 > To: 'OpenSceneGraph Users' > Subject: Re: [osg-users] OSG Collada plugin > > Hi Jean-Sebastien, > > thank you for your response. It is possible that I am missing something, but > it seems that every library is in debug mode. I have checked with > Dependency Walker the libs and I have all the debug dependencies in the > folder. I have exported one single cube with Blender, just to check that > there are no problems with textures and the same problem is happening. > > If I try to run the application from command line instead of from Visual > Studio, this is the error that I find: > > HEAP CORRUPTION DETECTED: after Normal block (#37612) at > 0x0047CF58. > CRT detected that the application wrote to memory after end of > heap buffer. > > And I have seen that the messages in the command line goes a bit further > than in VS: > ReaderWriterDAE( "OSG/box.dae" ) > URI loaded: OSG/box.dae > Adding parent0039C498 > Adding parent0039C498 > > Maybe those lines can be helpful to see where the problem is... > > Héctor > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean- > Sébastien Guay > Sent: martes, 23 de agosto de 2011 15:35 > To: OpenSceneGraph Users > Subject: Re: [osg-users] OSG Collada plugin > > Hi Héctor, > > > I am having some problems to load collada files into my project. I > > have used the collada dom lib (libcollada14dom21) to build the plugin. > > > > The line that is throwing the breakpoint is: > > > > osg::ref_ptr model = osgDB::readNodeFile(modelFilePath); > > This line will be loading the collada plugin, as well as the collada DOM DLLs > and others the plugin depends on. So if that line is making your app crash, I > would suspect the common gotcha about linking debug and release > together (or in general, different runtimes). > > So check your compile settings and make sure all your libs and DLLs (even > the collada ones and its dependencies) are differentiated between debug > and release, and that they all match in the linker settings. > > Hope this helps, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.dyndns-web.com/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
> -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi > Sent: Thursday, September 08, 2011 11:55 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling > > > rmilh wrote: > > > > Sorry, I opened snoman.wrl found under sample models in source > distribution and *it does not animate* only static gemoetry is shown . I also > tried orbit3.wrl, still no animation. > > > > > So, you can really see the snowman, but there is no animation? > That is correct. I executed the comman line and I can see snowman but play button does nothing. I also tried collada plugin (dae) (osganimationviewer.exe Seymour_anim2.dae) and the animation worked. If you are looking for plugin that can handle animation then I suggest you try collada plugin. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
> -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi > Sent: Thursday, September 08, 2011 10:38 AM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling > > I don't have this code in ReaderWriterVRML2.cpp! > Do you confirm me that osg VRML plugin doesn't play a vrml like an > animation, but it only "navigate" through nodes searching for properties? > Sorry, I opened snoman.wrl found under sample models in source distribution and *it does not animate* only static gemoetry is shown . I also tried orbit3.wrl, still no animation. BTW, if you use x64 os jo have to put keys under Wow6432Node (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\OpenVRML\OpenVRML). Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
> -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi > Sent: Wednesday, September 07, 2011 2:44 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling > > > openvrml-dl project was built correctly. > I added a dependency to openvrml-dld.lib to openvrml project too. Now the > osgviewerd.exe can fing the wrl plugin, but it gives me this error in > http://imageshack.us/photo/my-images/685/errorosg.jpg/ > This error indicates that you didn't build vrml97.dll node or the node cannot be found. The search paths can be put into registry under HKEY_LOCAL_MACHINE\SOFTWARE\OpenVRML\OpenVRML: NodePath ... the path to .dll nodes Datadir ... data dir must contain component subdirectory with component xml files ScriptPath ... can be empty I also had to comment out following lines in ReaderWriterVRML2.cpp: /*std::string unixFileName = osgDB::convertFileNameToUnixStyle(fileName); #ifdef WIN32 if(unixFileName[1] == ':') // absolute path fileName = "file:///" + unixFileName; #else if (unixFileName[0] == '/') // absolute path fileName = "file://" + unixFileName; #endif else // relative path fileName = unixFileName;*/ Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
I don't have VS2010. My libs and dlls are build with VS2008. What does the compiler say when yout try to build openvrml-dl project? Maybe the main project openvrml is missing a dependency to the openvrml-dl.lib. > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi > Sent: Wednesday, September 07, 2011 1:13 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling > > I think there is also another problem: probably the openvrmld.lib that I > compiled has an error. > Is it possible to have the openvrml.lib, openvrmld.lib and .dll ? > > > Thank you! > > Cheers, > Paolo > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=42485#42485 > > > > > > ___ > 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 + QT and QTabWidget: Disappearing scene graph
You might need to change how and when the osg viewer frame() is called. You migh also need to apply new osgQt patch waiting at submissions. I'am pasting modified osg Qt viewer example with more general frame update solution: #include #include #include #include #include #include #include #include #include class ViewerWidget : public QWidget, public osgViewer::CompositeViewer { public: ViewerWidget(osgViewer::ViewerBase::ThreadingModel threadingModel=osgViewer::CompositeViewer::SingleThreaded) : QWidget() { setThreadingModel(threadingModel); QWidget* widget1 = addViewWidget( createCamera(0,0,100,100), osgDB::readNodeFile("cow.osgt") ); QWidget* widget2 = addViewWidget( createCamera(0,0,100,100), osgDB::readNodeFile("glider.osgt") ); QWidget* widget3 = addViewWidget( createCamera(0,0,100,100), osgDB::readNodeFile("axes.osgt") ); QWidget* widget4 = addViewWidget( createCamera(0,0,100,100), osgDB::readNodeFile("fountain.osgt") ); QWidget* popupWidget = addViewWidget( createCamera(900,100,320,240,"Popup window",true), osgDB::readNodeFile("dumptruck.osgt") ); popupWidget->show(); QGridLayout* grid = new QGridLayout; grid->addWidget( widget1, 0, 0 ); grid->addWidget( widget2, 0, 1 ); grid->addWidget( widget3, 1, 0 ); grid->addWidget( widget4, 1, 1 ); setLayout( grid ); //connect( &_timer, SIGNAL(timeout()), this, SLOT(repaint ()) ); //_timer.start( 10 ); setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); _timerId = startTimer(0); } virtual ~ViewerWidget() { if (_timerId != 0) killTimer(_timerId); } QWidget* addViewWidget( osg::Camera* camera, osg::Node* scene ) { osgViewer::View* view = new osgViewer::View; view->setCamera( camera ); addView( view ); view->setSceneData( scene ); view->addEventHandler( new osgViewer::StatsHandler ); view->setCameraManipulator( new osgGA::TrackballManipulator ); osgQt::GraphicsWindowQt* gw = dynamic_cast( camera->getGraphicsContext() ); return gw ? gw->getGLWidget() : NULL; } osg::Camera* createCamera( int x, int y, int w, int h, const std::string& name="", bool windowDecoration=false ) { osg::DisplaySettings* ds = osg::DisplaySettings::instance().get(); osg::ref_ptr traits = new osg::GraphicsContext::Traits; traits->windowName = name; traits->windowDecoration = windowDecoration; traits->x = x; traits->y = y; traits->width = w; traits->height = h; traits->doubleBuffer = true; traits->alpha = ds->getMinimumNumAlphaBits(); traits->stencil = ds->getMinimumNumStencilBits(); traits->sampleBuffers = ds->getMultiSamples(); traits->samples = ds->getNumMultiSamples(); osg::ref_ptr camera = new osg::Camera; camera->setGraphicsContext( new osgQt::GraphicsWindowQt(traits.get()) ); camera->setClearColor( osg::Vec4(0.2, 0.2, 0.6, 1.0) ); camera->setViewport( new osg::Viewport(0, 0, traits->width, traits->height) ); camera->setProjectionMatrixAsPerspective( 30.0f, static_cast(traits->width)/static_cast(traits->height), 1.0f, 1.0f ); return camera.release(); } virtual bool event( QEvent* event ) { if (event->type() == QEvent::Timer) { if (static_cast(event)->timerId() == _timerId) { frame(); return true; } } return QWidget::event(event); } //virtual void paintEvent( QPaintEvent* event ) //{ // frame(); //} protected: int _timerId; }; int main( int argc, char** argv ) { osg::ArgumentParser arguments(&argc, argv); osgViewer::ViewerBase::ThreadingModel threadingModel = osgViewer::ViewerBase::CullThreadPerCameraDrawThreadPerContext; while (arguments.read("--SingleThreaded")) threadingModel = osgViewer::ViewerBase::SingleThreaded; while (arguments.read("--CullDrawThreadPerContext")) threadingModel = osgViewer::ViewerBase::CullDrawThreadPerContext; while (arguments.read("--DrawThreadPerContext")) threadingModel = osgViewer::ViewerBase::DrawThreadPerContext; while (arguments.read("--CullThreadPerCameraDrawThreadPerContext")) threadingModel = osgViewer::ViewerBase::CullThreadPerCameraDrawThreadPerContext; QApplication app(argc, argv); ViewerWidget* viewWidget = new ViewerWidget(threadingModel); viewWidget->setGeometry(
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
1. use any open vrml library 0.18.x 2. set environment variable BOOST_ROOT to point to the root of the boost. (needed for cmake to set boost entries automatically) 3. you will have to replace the outdated content of \src\osgPlugins\vrml\CMakeLists.txt with this: FIND_PACKAGE(Boost 1.40.0 COMPONENTS thread) IF(NOT Boost_FOUND) RETURN() ENDIF() INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS}) LINK_DIRECTORIES(${Boost_LIBRARY_DIRS}) INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR}/openvrml) IF (WIN32) INCLUDE_DIRECTORIES(${JPEG_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${PNG_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${ZLIB_INCLUDE_DIR}) SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY JPEG_LIBRARY PNG_LIBRARY ZLIB_LIBRARY) SET(TARGET_EXTERNAL_LIBRARIES Ws2_32.lib) ELSE() SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY) ENDIF() ADD_DEFINITIONS(-D OPENVRML_USE_DLL) SET(TARGET_SRC IndexedFaceSet.cpp Primitives.cpp ReaderWriterVRML2.cpp ConvertToVRML.cpp ) SET(TARGET_H ReaderWriterVRML2.h ConvertToVRML.h ) end var setup ### SETUP_PLUGIN(vrml vrml) 4. rerun cmake and set vrml and/or boost related entries Robert Milharcic -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi Sent: Friday, September 02, 2011 3:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] [osgPlugins] VRML plugin: help in compiling Hi, I followed the instructions for VRML plugin, but I wasn't able to compile it with openVRML 0.14. Then I downloaded openVRML 0.18 & Boost 1.46, but I wasn't able to compile openVRML in order to use the .lib in the VRML plugin in OSG. The error are like this: "Error 536 error LNK2019: riferimento al simbolo esterno "void * __cdecl openvrml::local::dl::sym(struct HINSTANCE__ *,class std::basic_string,class std::allocator > const &)" (?sym@dl@local@openvrml@@YAPAXPAUHINSTANCE__@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) non risolto nella funzione _openvrml_open_node_module ...\Projects\openvrml-0.18.8\src\libopenvrml\node_metatype_registry_impl.obj openvrml" There are 14 errors like that. In the recent past, I tried to compile openVRML also in Linux Ubuntu, but I coudn't do it. Thank you! Cheers, Paolo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42382#42382 ___ 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] (Qt) single GraphicsWindowQt completely filling parent widget
When the child widget completely fills a parent widget the QPaintEvent is no longer send to the parent. If you have something like this: connect( &timer, SIGNAL(timeout()),myParent, SLOT(update()) ); virtual void MyParent::paintEvent(QPaintEvent* event) { osgViewer->frame(); } ... the frame will never be called. Robbert Milharcic -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of jamie robertson Sent: Wednesday, August 31, 2011 12:00 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] (Qt) single GraphicsWindowQt completely filling parent widget Hi, For some reason I'm struggling to get a GraphicsWindowQt (GraphicsWindowQt ::getGLWidget) to completely fill a parent widget. I've tried various ways and always seem to fail (the GraphicsWindowQt isnt displayed) unless there is a non zero margin on a layout, in which case it works as expected. It's the same for setting the mainwidget of a qmainwindow, it doesnt appear unless I set a non zero margin. I can simply reproduce the problem in the osgviewerqt example with the following modification: Code: QGridLayout* grid = new QGridLayout; grid->setSpacing(0); grid->setMargin(0); Setting either the margin or spacing to something other than zero displays the viewers ok. Anyone encountered this before? Im using osg 3.0.1, windows7. Thanks, Jamie Robertson[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42314#42314 ___ 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] draw callbacks
You can use osgFX node kit framework to implement described capping tehnique. You do that by inheriting osgFX::Effect class. In your derived class you have to override/implement virtual bool define_techniques() member of the osgFX::Effect class like this: bool CappingEffect::define_techniques() { CappingTechnique* technique = new CappingTechnique(this); addTechnique(technique); return true; } CappingTechnique must inherit from osgFX::Technique. In the derived class you will have to implement virtual bool validate(osg::State&) const, virtual void define_passes() and optionally virtual osg::Node* getOverrideChild(int pass) like this: bool CappingTechnique::validate(osg::State&) const { return true; } bool CappingTechnique:: define_passes() { // pass #1 { osg::ref_ptr ss = new osg::StateSet; ... setup states for stencil operation addPass(ss.get()); } // implement pass #2 { osg::ref_ptr ss = new osg::StateSet; ... setup states for solid color draw addPass(ss.get()); } } You can optionally implement getOverrideChild (int pass) to supply some other graph for a particlular pass. You then add your group to the CappingEffect (the osgFX::Effect inherits from osg::Group node) and CappingEffect to the camera. Robert Milharcic From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Javier Taibo Sent: Thursday, September 02, 2010 1:09 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] draw callbacks Hi, I have some solid geometry clipped by some clipping planes in an OSG application. I am trying to use the capping technique described in chapter 10 of the Red Book using the stencil buffer. I have successfully implemented this technique in raw OpenGL, but I would like to use it whithin the OSG application. The technique is based on storing on the stencil buffer the regions that are "open" and then in a later pass draw a solid color in these regions. I have put the clipped geometry under an osg::Camera node with the stencil function configured. To do the second pass (the one that draws the caps in the regions marked in the stencil), I am trying to use a post-draw callback with the OpenGL calls (saving and restoring the states to avoid breaking things). The problem is that I need to set the NESTED rendering order to see all the scene graph, and when I do it, the post-draw callback is not called anymore. I do not have full control over the application, so the solution I am looking for has to be "transparent" to the rest of the scene graph. I must activate this behaviour to a group in the scene graph without breaking anything outside this branch. What is the best way to do it? camera post-draw callbacks? rendering bins? any other? I am not very familiar with render passes in OSG, so the way I am trying is probably not the best way. I would appreciate any suggestion, advice or pointer to any related documentation or source code. Thanks in advance. Javier Taibo. <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org