If I use #version 150 compatibility, do I still have to explicitly do the in
out specifications, such as declaring out gl_FragColor in the frag shader?
No, as I already said: You can use the old syntax and mix it with the
new one.
You absolutely don't have to use the layout, in, out things in this
profile.
Why don't you go ahead and write some simple shader program and see when
it fails? This way you will learn much more than asking about every
little potential problem ;-)
cheers
Sebastina
SMesserschmidt wrote:
Hi Ethan,
Hello Sebastian,
I read up on the differences between glsl 1.2 and 1.5 and then scimmed through
the official GLSL 1.5 specification document. I then grepped the osg src and
examples directories to see if I could find any #version 150 shaders (I could
not). Are there any reference/example implementations of GLSL 1.5 shaders with
OSG? I ask because it looks like GLSL 1.5 requires you to be more explicit
with declaring inputs and outputs, including needing to pass things like the
modelviewmatrix etc into the vertex shader as uniforms. Is this easily done?
Examples? Do I have this assumption wrong? Thanks again, I promise I'm
working hard on my end and not just fishing for easy answers
Simply go with the #version 150 compatible
It allows to use the built-in uniforms and varyings. So
gl_ModelViewMatrix and gl_Vertex etc. are still valid tokens.
This is less painful than doing the hard-core way. If you want to really
really go this way you have to setup vertex attribute aliasing in OSG,
but then you will really have to do a lot of things using visitors and
so on. So for starting, simply go with the compatibility profile and use
in/out only on your varyings.
cheers
Sebastian
SMesserschmidt wrote:
Hi Ethan,
Thanks again, it looks like I need to get up to speed with using "in" and "out"
vs attribute and varying since I cut my teeth on older tutorials and apparently attribute and
varying are officially deprecated and are supported through compatibility mode. I'm not used to
needing historical context and having so many deprecated variables and different extensions to
worry about like with GLSL. GLSL-land is a bit of a wild place to be!
Don't worry. You can also use varying safely. Just remember to use
something like #version 150 compatibility at the beginning of your shaders.
However, it is better to get used to the new in, out as they are making
it much clearer what is input and what goes out your shader stage.
cheers
Sebastian
-Ethan
SMesserschmidt wrote:
Hi Ethan
Thanks Sebastian,
I have in fact looked through every geometry shader tutorial I could find and
have tried to implement a simple pass-through sahder identical to the one you
posted, but when I add the geometry shader I just get a black screen with no
OpenGL error messages, and if I remove the geometry shader and keep the vertex
and frag shaders I get my normal scene. I'm not sure if maybe I'm missing
passing through texture coordinates or something of that nature...?
Ok, you of course have to pass all your varyings through the geometry
shader. Thats the burden for using a geometry shader: you will have to
replicate the default funtionality.
For example:
Vertex shader:
out vec4 v_color;
v_color =gl_Color;
in geometry shader:
in vec4 v_color[];
out vec4 g_color;
g_color = color[i]; //i = vertex number
and then finally in your fragment shader you can access:
in g_color
cheer
Sebastian
-Ethan
SMesserschmidt wrote:
Hi Ethan,
Thanks, that makes sense that it would just be rendering a quad and that the
original scene geometry would be lost. However, the GLSL geometry shader only
accepts primitives of the type point, line, or triangle->is it perhaps
rendering two triangles to the geometry shader to make up the quad? How would I
even go about determining since there's no debugging available?
But back to what I'm trying to do, I'm trying to use a geometry shader to
calculate the min, max, mean, std dev, and histogram of an RTT texture. Fellow
osg forum member Aurelius has advised me that he has working code that does
this using geometry shaders and pointed me to:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch41.html
and
This seems rather complicated for a starter. Also it requires feedback
buffers which I never got working in OSG, so there might be some more
obstacles here.
http://developer.amd.com/wordpress/media/2012/10/GPUHistogramGeneration_I3D07.pdf
but the first example only has Cg code and not GLSL, and the second example is
a paper that describers an algorithm but doesn't have any src. These are both
potentially great resources, but I'm struggling to just get a basic
pass-through geometry shader working to get some sort of starting point.
Geometry shaders are really simple. You simply need to know your input
primitives.
A very basic geometry shader looks like this:
#version 400
layout(triangles) in; //we receive triangles
layout(triangle_strip, max_vertices = 3) out;
void main()
{
for (int i = 0; i < 3; ++i)
{
vertex = gl_in[i].gl_Position;
gl_Position = vertex;
EmitVertex();
}
EndPrimitive();
}
But seriously, there are examples in OSG touching geometry shaders and
there are plenty of tutorials about glsl and shaders.
cheers
Sebastian
As a side note, I am also considering using a compute shader since this would be the more
natual fit for this type of algorithm while the geometry shader method is more of a
"hack" that goes against the original intention of the geometry shader, but I'd
be happy using either method, I'm just trying to get some traction on either of them.
-Ethan
SMesserschmidt wrote:
Am 18.11.2013 15:32, schrieb Ethan Fahy:
Hello,
Preface: I realize this question comes about because I've never really learned
OpenGL/GLSL from the ground up and am likely missing some simple concepts, but
I mostly have been coasting by at the osg middleware level and have been doing
OK so far.
If I want to do some simple post-processing I can create a render-to-texture camera and
render to the framebuffer. I can attach a texture to the framebuffer and then create
another "screen" camera to render that texture to the screen. I can add a GLSL
shader program to this texture so that before the texture gets rendered to the screen it
gets an effect added to it using the shaders.
When I use shaders attached to 3-D model nodes in the scene itself, the meaning of
the vertex and frag shaders is easy to understand->the vertices of the 3-D
model are the vertices referenced in the vertex shader. However, When I render my
scene to a texture and then do a simple pass-through vertex and frag shader combo,
what is the meaning of the vertices in this scenario? I had assumed that once you
render your scene to a texture, all knowledge of the original scene's geometry and
vertex locations has been lost, is this true? If so, then what vertices am I
dealing with? It's easy enough to follow along with examples and to use a simple
pass-through vertex shader, but I'd like to understand this better because I now
want to insert a geometry shader in between the vertex and frag shaders and again
I'm not sure whether to use point, line, or triangle in my geometry shader as the
primitive type because I thought that the geometry and primitives of the or
igin
al s
cene
wou
ld
b
e lost after rendering to texture.
Usually when doing the post-processing pass you will be rendering to a
fullscreen quad. So the vertices you are dealing with are those of the
quad you are rendering too.
And yes, If you don't any further actions, rendering to texture will not
preserve the information on your orignal vertices etc.
The question is what you want to achieve. A geometry shader inbetween
your postprocessing pass will work on the quads vertices.
Maybe you should elaborate which kind of post processing you want to
achieve, so we can help you here.
What am I missing here? Any clarification is most welcome.
-Ethan
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57281#57281
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57285#57285
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57298#57298
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57303#57303
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
:)
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57323#57323
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57325#57325
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
