Re: [osg-users] OSG will not work on OpenSUSE 13.2 with the AMD driver on Radeon
Hi Nick, Have you been able to sort the problem? I haven't used SUSE for over a decade, and don't have Radeon card so can't help on the specifics - I use Kubuntu + NVidia for day to day dev work. I was hoping other might chip in but it's been a bit of ghost town on the mailing list/forum this last week. Is the forum down? If you haven't yet resolved the problem then trying out other OpenGL applications would a good place to start. Checking the support/forum discussions for SUSE and Radeon would also be an avenue to explore. Robert. On 9 February 2015 at 19:20, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community, I spent the whole day today trying to make it work and I need your help since I am new to Linux development. My driver is from here https://en.opensuse.org/SDB:AMD_fglrx and when I run glxinfo I get this: name of display: :0 X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 19 (X_GLXQueryServerString) Serial number of failed request: 12 Current serial number in output stream: 12 The system I use is hybrid with one intel and one radeon card and I am clueless how to setup X11 for this configuration Anyone can share some nowhow, hints? As always, thanks a bunch! Nick -- trajce nikolov 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
Re: [osg-users] OSG will not work on OpenSUSE 13.2 with the AMD driver on Radeon
Hi Robert, thanks for the ping. No, I didn't fixed it. It is driver issue and I went through all the forums I found online with no good result. The driver available seams to be somewhat very new so and there are bugs reported. I was hoping maybe someone from the community have some experience with. I will wait on some more stable one. In mean time I moved the dev to another DELL system with NVIDIA. All the geometry shaders work there just fine. So I am good but I will follow this issue since the project I work on is cross-platform so it will be shame if I don;t make it work on the specified system. Thanks again ! Nick On Sat, Feb 14, 2015 at 12:42 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Nick, Have you been able to sort the problem? I haven't used SUSE for over a decade, and don't have Radeon card so can't help on the specifics - I use Kubuntu + NVidia for day to day dev work. I was hoping other might chip in but it's been a bit of ghost town on the mailing list/forum this last week. Is the forum down? If you haven't yet resolved the problem then trying out other OpenGL applications would a good place to start. Checking the support/forum discussions for SUSE and Radeon would also be an avenue to explore. Robert. On 9 February 2015 at 19:20, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community, I spent the whole day today trying to make it work and I need your help since I am new to Linux development. My driver is from here https://en.opensuse.org/SDB:AMD_fglrx and when I run glxinfo I get this: name of display: :0 X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 19 (X_GLXQueryServerString) Serial number of failed request: 12 Current serial number in output stream: 12 The system I use is hybrid with one intel and one radeon card and I am clueless how to setup X11 for this configuration Anyone can share some nowhow, hints? As always, thanks a bunch! Nick -- trajce nikolov 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 -- trajce nikolov nick ___ 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, Hi all I also implement a shader composition framework for a client, based on osg shader composition, so remove it will be a big loss. My implementation handle OpenGL version, some pragma (optimize and debug), generate a main function for vertex and fragment shader based on what is found in shaderComponent list. So change from previous shader composition to new one will not be straight forward. some thought about new shader composition 1) OpenGL Shading Language specification 3.3 Preprocessor : #pragma allows implementation dependent compiler control so pragma requires and import_defines should be use by shader compiler, replace them by osg_requires and osg_import_defines could be prevent futur pragma collisions. Thought ? but pragma is an elegant way to insert information directly in shader code. well spot !!! 2) Define a main function with all possibility and use define to choose the ones to enable and the ones to not will make a really complex shader, imagine, you optionally use - instancing - bump/deplacement mapping - vertex blending - material/texture/multi-texture - lighting/shadow - fog - physic - one/multi fragment output You will be quickly crazy. The one that work with SpeedTree Shader knows what I am talking about. This is why I prefer your previous approach that inject code found in StateAttribute in final program. It is also less intrusive. If i need to insert a new shader component in the program, no need to change main shader. More over, I introduce some new ShaderAttribute like camera to define where fragment shader output have to go, or drawable to define which vertex shader input are available, Instance to optionally use draw instance, ... so don't remove ShaderAttribute. With modern OpenGL and depreciated data like fog, light, ... we need a way to introduce our custom attribute. I create a nodekit osgLighting just to manage different light source. I have 5 different light source (sun, car, streetlight, ...) that all use shaderAttribute to define data that compose the light and shader that use this data. So don't remove shaderAttribute this is really a good idea you have here !!! 3) On a performance point of view, it will be a good thing to use subroutine to enable/disable feature. Many different path in shader composition result in many different program. And so many change of program in one frame, perhaps use the program A, then the program B, then the program A again... This is the main problem I currently have in my shader composition implementation. 4) I always think that lack of define injection in shader is a drawback in osg. With your function and name convention, this will be difficult to add this feature. Replace import_define by import_module will fix this. Because we talk about shader module, lighting, fog, bump mapping, shadow ... all of this could be define as shader module. I really think that shader composition is a big piece of software, really usefull, and really complex. I think we need a debate about this with all user that have already try to implement a shader composition. Clearly define our needs (have reusable module, keep code in shader files, use OpenGL feature to improve performance like subroutine, pipeline object, ...), debate about solution, propose implementation... This problem is really new and so few research has be done an the subject. I did my first implementation in octobre 2010 I have used my shader composition in many way. Found some cool stuff and other bad about my design. I look for existing solution on internet, I found some one like libsh http://libsh.org/ but not easy and clean way to solve it. Recently i found CosMo http://www.vrvis.at/publications/pdfs/PB-VRVis-2014-001.pdf that did the job in many way like my implementation, but more deeply in abstraction of the code. They don't think in term of shader but in term of pipeline graphics, shader composition will decide which code put in vertex/ tessellation/geometry/fragment shader. I also do this but it's clearly not a good idea. You propose a clean and (perhaps too) easy way to do the job. This is fresh. This is nice to have a new view on this complex problem. So, Robert, Other, we need to talk about this to create a robust, clean and easy way to do shader composition. Thought ? My 2 cents David 2015-02-13 19:01 GMT+01:00 Robert Osfield robert.osfi...@gmail.com: Hi All, Attached is a screenshot of running (clock.osgt is in OpenSceneGraph-Data): osgshadercomposition clock.osgt A very simple example that provides a single osg::Program that have five different shader combinations used on the same subgraph to produce different results. From left to right they are: 1) White unlit box - is the default implementation with no define's supplied from osg::StateSet's so no texturing or lighting 2) White lit box - GL_LIGHTING define is provided to the shaders via the stateset-setDefine(GL_LIGHTING); 3) Textured unlit box,
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi David,
On 14 February 2015 at 14:24, David Callu led...@gmail.com wrote:
I also implement a shader composition framework for a client, based on osg
shader composition, so remove it will be a big loss.
My implementation handle OpenGL version, some pragma (optimize and
debug), generate a main function for vertex and fragment shader based on
what is found in shaderComponent list. So change from previous shader
composition to new one will not be straight forward.
Is there a chance you could create an example that illustrates how you are
using the old osg::ShaderComposition framework? This will be give me a
better idea of what could be done to ease the transition/what parts of the
existing framework will need to be maintained.
I am keen to avoid the OSG littering up with lots of dead end bits of code.
some thought about new shader composition
1)
OpenGL Shading Language specification
3.3 Preprocessor :
#pragma allows implementation dependent compiler control
so pragma requires and import_defines should be use by shader
compiler, replace them by osg_requires and osg_import_defines could
be prevent futur pragma collisions. Thought ?
Right now I would prefer to avoid adding the osg_ prefix as it's a bit
clumsy, and the approach needed be OSG specific.
I am consider other additions as well - such as having shaders be able to
request the linking of other shaders - so the app could link a single main
shader that pulls in the rest of the shaders to be linked to the program.
Another possible addition would be to have osg::Program settings
controllable via #pragmas. Right now I want to keep things simple though.
2)
Define a main function with all possibility and use define to choose the
ones to enable and the ones to not will make
a really complex shader, imagine, you optionally use
- instancing
- bump/deplacement mapping
- vertex blending
- material/texture/multi-texture
- lighting/shadow
- fog
- physic
- one/multi fragment output
You will be quickly crazy. The one that work with SpeedTree Shader knows
what I am talking about.
The new shader composition framework doesn't add complexity where none
exists. If there are many different combinations that need to be supported
then this complexity will be reflected in the shaders, but at least the
developer will be able to see it directly and account for the possibility
of different combinations.
One isn't tied to one uber osg::Program that manages all the possible
combinations. One also can use the define's to inject code, more info below.
This is why I prefer your previous approach that inject code found in
StateAttribute in final program.
It is also less intrusive. If i need to insert a new shader component in
the program, no need to change main
shader.
The way to you implement code injection right now was illustrated in a
small way in the example I gave in my previous email, and provided in the
svn/trunk version of the osgshadercomposition example. This example
injects a marco function that modifies a vertex. You don't have to use it
this way instead you can do the following, in the GLSL shader you'd have:
#pragma import_defines( INJECTION_POINT_1, INJECTION_POINT_2 )
...
INJECTION_POINT_1
void main(void)
{
...
INEJECTION_POINT_2
..
}
Then in the StateSet you'd pass in the code to inject via:
stateset-setDefine(INJECTION_POINT_1, varying vec4 position;)
stateset-setDefine(INJECTION_POINT_2, position = gl_Vertex;)
The strings you pass in can be multi-line as long as the driver supports
multi-line #define as C and C++ do.
Right now if you nest a setDefine(defStr, valueStr) in the scene graph
it'll replace entirely any previous value but perhaps we could generalize
things further to allow one to prepend or append the valueStr to any
already defined in StateSet above that point the scene graph. This would
add complexity though, so unless it's really shown to be needed I'll wait
till it is.
More over, I introduce some new ShaderAttribute like camera to define
where fragment shader output have to go,
or drawable to define which vertex shader input are available,
Instance to optionally use draw instance, ... so don't remove Shader
Attribute. With modern OpenGL and depreciated data like fog, light, ...
we need a way to introduce our custom attribute.
Unifoms should be able to take over at least part of the attribute role.
In the case of fallbacks for things like osg::Light/glLight we'd need these
atttributes to provides one or more Uniforms when they are needed. It
could be that ShaderAttribute might still have a roll to play in this. The
code injection side is something that would need to be looked at if we are
removing the old osg::ShaderComposition framework.
Something I have used in the osgTerrain::DispalcementMappingTechnique to
have a custom Drawable check the value of a Define by querying osg::State
and then having the Drawable choose between different data to send to
OpenGL, in
[osg-users] Flight Sim Cockpit Frame
Hi, There is an osg example, osgsimulation, that shows a plane flying above the earth. I am building a simple flight simulator and would like to put a cockpit frame around the view so it would look like the plane in osgsimulation is being followed by a 2nd plane. What is the best way to frame a view with a graphic so it does not obstruct the movement of the earth or the plane? Is there an example of such a frame? Can a single graphic be used as the cockpit with a transparent center for the leading plane and terrain? Thank you very much! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62678#62678 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
