Re: [osg-users] Modern GLSL and OSG

[Garth D]

Hi Jan,

On 28/09/15 17:36, Jan Ciger wrote:

On Sun, Sep 27, 2015 at 9:28 PM, Garth D
 wrote:

As a side note, I have to say that I am really liking the ability to hang
Uniforms off arbitrary parts of the scene graph- generally on Geometry or
Groups depending on the scope that I need the Uniform to cover. It's really
a very nice design.



Uniforms are parts of the OpenGL state, same as e.g. bound textures,
shaders or lighting settings. If I grossly simplify things, the "only"
thing that OSG does is to manage this state for you - adds and removes
bits from the state depending on which part of the scene graph is
being drawn, all the while to make sure to minimize the amount of
these state changes (changing state of the driver is relative
expensive operation). It is one of the basic purposes of a scene
graph.


In the project I am working on the geometry is laid out in such a way 
that there are different levels of Groups under which certain Uniforms 
always hold the same value. It works really nicely with such a system.


Cheers,
Garth

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

On Sun, Sep 27, 2015 at 9:28 PM, Garth D
 wrote:
> As a side note, I have to say that I am really liking the ability to hang
> Uniforms off arbitrary parts of the scene graph- generally on Geometry or
> Groups depending on the scope that I need the Uniform to cover. It's really
> a very nice design.


Uniforms are parts of the OpenGL state, same as e.g. bound textures,
shaders or lighting settings. If I grossly simplify things, the "only"
thing that OSG does is to manage this state for you - adds and removes
bits from the state depending on which part of the scene graph is
being drawn, all the while to make sure to minimize the amount of
these state changes (changing state of the driver is relative
expensive operation). It is one of the basic purposes of a scene
graph.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Garth D]

Hi Jan,

Thanks again for sharing your thoughts on the subject. :)

On 26/09/15 19:46, Jan Ciger wrote:> On Sat, Sep 26, 2015 at 5:02 AM, 
Garth D

>  wrote:
>>
>> My original motivation was to move to using "modern" OpenGL (ie. 
avoiding
>> anything deprecated) because I didn't want to be in the situation 
where I
>> started relying on something that was likely to be removed in the 
future.

>
> Well, I don't think you need to worry about that too much.

Yeah, I'm pretty-much past this one now. :)

> Yes, the
> "old school" OpenGL is marked as deprecated and removed from the Core
> profiles (and OpenGL ES 2.0 doesn't support it at all). However, at
> least Nvidia (AMD/Ati probably as well) has declared that they are
> going to support the legacy profiles for indefinite future.
>
> The reason is that the code is already in the driver and costs them
> essentially nothing (the old APIs don't change) and also the ton of
> old code that uses it. That's also why the OpenGL 3 was felt to be
> such a letdown and not a radical departure in a new direction - there
> are simply too many CAD and visualization companies with decades old
> codebases that would stop working overnight with a new driver and
> there is no business willpower to rewrite that because it works well
> enough. Moreover, I am pretty sure that even today you will find major
> CAD systems doing atrocities such as using direct mode (glBegin/glEnd)
> somewhere in their code ...

That certainly makes sense. I had wondered at the time how successful 
the deprecation would be. I could see it being successful if a popular 
compatibility layer library emerged and gained widespread use, but I 
don't think this really happened. This seems to mean that the bulk of 
the compatibility support is instead retained at the driver level, which 
is as you note.


>> Additionally, I have a need that I know is not going to be handled 
very well
>> in the fixed-function pipeline. From experience I know that whilst 
the FFP
>> is neat for simpler tasks, it feels like a massive burden as the 
needs get

>> more complex.
>>
>> A last goal was as a learning exercise. The aim was to rely on shader
>> functionality a bit more strictly than minimally necessary, as a 
means of
>> taking care of the glaring (and increasingly hard-to-explain 
professionally)

>> hole in my 3D knowledge.
>
> By all means, that is a good reason. Also if you decide to develop on
> mobile, you won't have much choice there.

Yes, this is much clearer to me know.

As a side note, I have to say that I am really liking the ability to 
hang Uniforms off arbitrary parts of the scene graph- generally on 
Geometry or Groups depending on the scope that I need the Uniform to 
cover. It's really a very nice design.


Thanks again!

Cheers,
Garth

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

Hello,

On Sat, Sep 26, 2015 at 5:02 AM, Garth D
 wrote:
>
> My original motivation was to move to using "modern" OpenGL (ie. avoiding
> anything deprecated) because I didn't want to be in the situation where I
> started relying on something that was likely to be removed in the future.

Well, I don't think you need to worry about that too much. Yes, the
"old school" OpenGL is marked as deprecated and removed from the Core
profiles (and OpenGL ES 2.0 doesn't support it at all). However, at
least Nvidia (AMD/Ati probably as well) has declared that they are
going to support the legacy profiles for indefinite future.

The reason is that the code is already in the driver and costs them
essentially nothing (the old APIs don't change) and also the ton of
old code that uses it. That's also why the OpenGL 3 was felt to be
such a letdown and not a radical departure in a new direction - there
are simply too many CAD and visualization companies with decades old
codebases that would stop working overnight with a new driver and
there is no business willpower to rewrite that because it works well
enough. Moreover, I am pretty sure that even today you will find major
CAD systems doing atrocities such as using direct mode (glBegin/glEnd)
somewhere in their code ...

> Additionally, I have a need that I know is not going to be handled very well
> in the fixed-function pipeline. From experience I know that whilst the FFP
> is neat for simpler tasks, it feels like a massive burden as the needs get
> more complex.
>
> A last goal was as a learning exercise. The aim was to rely on shader
> functionality a bit more strictly than minimally necessary, as a means of
> taking care of the glaring (and increasingly hard-to-explain professionally)
> hole in my 3D knowledge.

By all means, that is a good reason. Also if you decide to develop on
mobile, you won't have much choice there.

Regards,

Jan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Garth D]

Hi Jan,

Many thanks for the additional information. :)

On 25/09/15 17:48, Jan Ciger wrote:

On Fri, Sep 25, 2015 at 2:01 AM, Garth D
 wrote:

Thankyou for the suggestion. :)

I have to admit being unsure how to set the specific context at present.

 From what I've read, there'd need to be a glXCreateContextAttribsARB call
somewhere to create the GL3 context under Linux- and there doesn't seem to
be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek
at 3.4.0) suggests that perhaps this support is only available on a Windows
build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However,
glVersion=4.4 appears in my log during a build.


The cmake variables are meant to be set by the developer, see the
instructions here:

http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/72253

It is possible that GL3 support is still available on Windows only,
but even if that is the case, it shouldn't be terribly difficult to
make it work in Linux too. The drivers and OpenGL implementations
certainly support it now.


Thanks. I thought this might be the case.


I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be
the best thing for me to concentrate at the moment. I might be better off
just using it where it helps and leaving a jump to "pure" modern GL until a
later date.


Well, it depends on what you want to do. Moving to the "modern" OpenGL
without the fixed pipeline functionality is a big jump, because
basically you don't have anything pre-defined by the library anymore.
No matrix stack (glPush/glPop), everything needs to be managed using
shaders, etc. The older functionality is easier to make display
something on the screen quickly, because there are fewer things to set
up. The newer stuff gives you much more flexibility, though.


Excellent, many thanks for the explanation and clarification.

My original motivation was to move to using "modern" OpenGL (ie. 
avoiding anything deprecated) because I didn't want to be in the 
situation where I started relying on something that was likely to be 
removed in the future.


Additionally, I have a need that I know is not going to be handled very 
well in the fixed-function pipeline. From experience I know that whilst 
the FFP is neat for simpler tasks, it feels like a massive burden as the 
needs get more complex.


A last goal was as a learning exercise. The aim was to rely on shader 
functionality a bit more strictly than minimally necessary, as a means 
of taking care of the glaring (and increasingly hard-to-explain 
professionally) hole in my 3D knowledge.


As I've been digging around the first goal seems less and less 
important, so my goals have been shifting somewhat. Going pure non-FFP 
is something I can handle down the track.


> Using OSG
> helps to hide this complexity, because OSG abstracts and manages many
> of these things for you, regardless of which OpenGL profile are you
> using.

Excellent. I couldn't tell if this was the case, or if OpenGL 3+ was an 
experimental thing in OSG, or how complete the OSG support for it was.


At this point I've made it over the initial hurdle of setting things up 
properly in OSG and getting the basics running, so I'm on to the meat of 
the task at this point- messing about with the shaders themselves.


Thanks for taking the time to write that up, it has clarified things 
considerably. Much appreciated. :)


Cheers,
Garth

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

On Fri, Sep 25, 2015 at 2:01 AM, Garth D
 wrote:
> Thankyou for the suggestion. :)
>
> I have to admit being unsure how to set the specific context at present.
>
> From what I've read, there'd need to be a glXCreateContextAttribsARB call
> somewhere to create the GL3 context under Linux- and there doesn't seem to
> be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek
> at 3.4.0) suggests that perhaps this support is only available on a Windows
> build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However,
> glVersion=4.4 appears in my log during a build.

The cmake variables are meant to be set by the developer, see the
instructions here:

http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/72253

It is possible that GL3 support is still available on Windows only,
but even if that is the case, it shouldn't be terribly difficult to
make it work in Linux too. The drivers and OpenGL implementations
certainly support it now.

> I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be
> the best thing for me to concentrate at the moment. I might be better off
> just using it where it helps and leaving a jump to "pure" modern GL until a
> later date.

Well, it depends on what you want to do. Moving to the "modern" OpenGL
without the fixed pipeline functionality is a big jump, because
basically you don't have anything pre-defined by the library anymore.
No matrix stack (glPush/glPop), everything needs to be managed using
shaders, etc. The older functionality is easier to make display
something on the screen quickly, because there are fewer things to set
up. The newer stuff gives you much more flexibility, though. Using OSG
helps to hide this complexity, because OSG abstracts and manages many
of these things for you, regardless of which OpenGL profile are you
using.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Christian Buchner]

NOTE: the current development version of ANGLE is targeting OpenGL ES 3.0,
if you want to be more up to date. I am not sure about its level of
completion and stability though.

Maybe you can find more complete (commercial?) virtualization solutions to
run the DX backend. Also maybe Wine is suitable for this. DirectX 9.0c
should be well supported by Wine (or its commercial counterpart Crossover).

Christian


2015-09-23 14:49 GMT+02:00 Christian Buchner :

>
> If you're using Windows you could try building OSG against ANGLE
> and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't
> accidentially fall back into using deprecated (fixed function) features
> because these have been stripped from the API.
>
> There would also be plenty of books about OpenGL ES 2.0 available - and
> you can immediately target mobile platforms (iOS, Android)
>
> Christian
>
>
> 2015-09-23 14:44 GMT+02:00 Garth D :
>
>>
>> Hi all,
>>
>> I was wondering if anyone can make some suggestions as to resources that
>> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific
>> focus on use with OSG.
>>
>> My existing GLSL knowledge is weak compared to my general 3D knowledge,
>> and mostly dates back to the early days of shaders. A lot of what I have
>> personally done with OpenGL and OSG has involved the fixed-function
>> pipeline, or things that map to it fairly closely.
>>
>> Thus far I've been digging around online for GLSL resources, but tend to
>> frequently find myself doing it the wrong way as I'm using features that
>> have since become deprecated. On the OSG side I tend to dig around in the
>> OSG examples and search the source to try to find the OSG equivalents to
>> OpenGL calls I see mentioned in the GLSL resources. I then put these
>> together and if I'm lucky something useful comes out. :)
>>
>> I think I'll figure things out eventually if I continue to crash around
>> blindly as I have been, but if anyone can suggest some better starting
>> points for GLSL use in OSG specifically, it would be much appreciated. :)
>>
>> Cheers,
>> Garth
>> ___
>> 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] Modern GLSL and OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/15 00:19, Garth D wrote:
> 
> Hi Christian,
> 
> Many thanks for the interesting suggestion. :)
> 
> My main development environment is Linux-based, with a secondary 
> virtualised Windows development environment. Due to the
> visualization (VirtualBox) I don't believe I can do much in the way
> of development with ANGLE due to its DX backend, at least with my
> current setup.

Um, wouldn't it be far easier to simply ask OSG to create an OpenGL
3.x/4.x core context instead? Then you don't have the legacy stuff
available and don't need to bother with hacks like Angle.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWBFOUn11XseNj94gRArP1AKDneqprlIWSFje9RJ6gGmgJuBCGFQCeN0hL
I2nYYPPFemO/2jo40R7PH14=
=V73u
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Garth D]

Hi Jan,

On 25/09/15 05:18, Jan Ciger wrote:> -BEGIN PGP SIGNED MESSAGE-
> On 24/09/15 00:19, Garth D wrote:
>> Many thanks for the interesting suggestion. :)
>>
>> My main development environment is Linux-based, with a secondary
>> virtualised Windows development environment. Due to the
>> visualization (VirtualBox) I don't believe I can do much in the way
>> of development with ANGLE due to its DX backend, at least with my
>> current setup.
>
> Um, wouldn't it be far easier to simply ask OSG to create an OpenGL
> 3.x/4.x core context instead? Then you don't have the legacy stuff
> available and don't need to bother with hacks like Angle.

Thankyou for the suggestion. :)

I have to admit being unsure how to set the specific context at present.

From what I've read, there'd need to be a glXCreateContextAttribsARB 
call somewhere to create the GL3 context under Linux- and there doesn't 
seem to be one. Skimming the source (I'm presently using OSG 3.2.1, but 
had a peek at 3.4.0) suggests that perhaps this support is only 
available on a Windows build. On the cmake side, OSG_GL3_AVAILABLE in my 
build is off. However, glVersion=4.4 appears in my log during a build.


However, I am probably fine even if I am not grasping things entirely at 
this point. It is something I can experiment with later on, probably on 
my existing Windows build environment. Whether I experiment with ANGLE 
from there or not is something I can weigh up from that point. Thanks 
for the additional input.


I also just noticed that my prior email used "visualization" rather than 
"virtualisation". Whoops. ;} I think I need to place a little less faith 
in spellcheck suggestions.


I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might 
not be the best thing for me to concentrate at the moment. I might be 
better off just using it where it helps and leaving a jump to "pure" 
modern GL until a later date.


Cheers,
Garth
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Christian Buchner]

If you're using Windows you could try building OSG against ANGLE
and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't
accidentially fall back into using deprecated (fixed function) features
because these have been stripped from the API.

There would also be plenty of books about OpenGL ES 2.0 available - and you
can immediately target mobile platforms (iOS, Android)

Christian


2015-09-23 14:44 GMT+02:00 Garth D :

>
> Hi all,
>
> I was wondering if anyone can make some suggestions as to resources that
> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific
> focus on use with OSG.
>
> My existing GLSL knowledge is weak compared to my general 3D knowledge,
> and mostly dates back to the early days of shaders. A lot of what I have
> personally done with OpenGL and OSG has involved the fixed-function
> pipeline, or things that map to it fairly closely.
>
> Thus far I've been digging around online for GLSL resources, but tend to
> frequently find myself doing it the wrong way as I'm using features that
> have since become deprecated. On the OSG side I tend to dig around in the
> OSG examples and search the source to try to find the OSG equivalents to
> OpenGL calls I see mentioned in the GLSL resources. I then put these
> together and if I'm lucky something useful comes out. :)
>
> I think I'll figure things out eventually if I continue to crash around
> blindly as I have been, but if anyone can suggest some better starting
> points for GLSL use in OSG specifically, it would be much appreciated. :)
>
> Cheers,
> Garth
> ___
> 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] Modern GLSL and OSG

[Garth D]

Hi all,

I was wondering if anyone can make some suggestions as to resources that 
are useful for learning GLSL in modern OpenGL (say, 3.0+) with a 
specific focus on use with OSG.


My existing GLSL knowledge is weak compared to my general 3D knowledge, 
and mostly dates back to the early days of shaders. A lot of what I have 
personally done with OpenGL and OSG has involved the fixed-function 
pipeline, or things that map to it fairly closely.


Thus far I've been digging around online for GLSL resources, but tend to 
frequently find myself doing it the wrong way as I'm using features that 
have since become deprecated. On the OSG side I tend to dig around in 
the OSG examples and search the source to try to find the OSG 
equivalents to OpenGL calls I see mentioned in the GLSL resources. I 
then put these together and if I'm lucky something useful comes out. :)


I think I'll figure things out eventually if I continue to crash around 
blindly as I have been, but if anyone can suggest some better starting 
points for GLSL use in OSG specifically, it would be much appreciated. :)


Cheers,
Garth
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Garth D]

Hi Christian,

Many thanks for the interesting suggestion. :)

My main development environment is Linux-based, with a secondary 
virtualised Windows development environment. Due to the visualization 
(VirtualBox) I don't believe I can do much in the way of development 
with ANGLE due to its DX backend, at least with my current setup.


Having said that, being able to limit a future port to the OpenGL ES 2.0 
API subset could be very useful indeed. It is likely that I would be 
looking at the feasibility of moving the project I am working on to 
mobile devices in the future, and this sounds like something that could 
be very useful to use while I am doing so.


Cheers,
Garth

On 23/09/15 22:19, Christian Buchner wrote:> If you're using Windows you 
could try building OSG against ANGLE

> and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't
> accidentially fall back into using deprecated (fixed function) features
> because these have been stripped from the API.
>
> There would also be plenty of books about OpenGL ES 2.0 available - 
and you

> can immediately target mobile platforms (iOS, Android)
>
> Christian
>
>
> 2015-09-23 14:44 GMT+02:00 Garth D :
>
>>
>> Hi all,
>>
>> I was wondering if anyone can make some suggestions as to resources that
>> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a 
specific

>> focus on use with OSG.
>>
>> My existing GLSL knowledge is weak compared to my general 3D knowledge,
>> and mostly dates back to the early days of shaders. A lot of what I have
>> personally done with OpenGL and OSG has involved the fixed-function
>> pipeline, or things that map to it fairly closely.
>>
>> Thus far I've been digging around online for GLSL resources, but tend to
>> frequently find myself doing it the wrong way as I'm using features that
>> have since become deprecated. On the OSG side I tend to dig around 
in the

>> OSG examples and search the source to try to find the OSG equivalents to
>> OpenGL calls I see mentioned in the GLSL resources. I then put these
>> together and if I'm lucky something useful comes out. :)
>>
>> I think I'll figure things out eventually if I continue to crash around
>> blindly as I have been, but if anyone can suggest some better starting
>> points for GLSL use in OSG specifically, it would be much 
appreciated. :)

>>
>> Cheers,
>> Garth
>> ___
>> 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] Modern GLSL and OSG

[Garth D]

Replying to myself with what I have managed to figure out so far to 
provide some information in case it comes up in a search. I can't vouch 
for the accuracy as this is still new to me. Anyway:


- Compile messages end up being sent through the osg::NotifyHandler 
mechanism.


- Shaders don't appear to be compiled immediately, but if you use them 
(by attaching an osg::Program to a osg::StateSet with 
setAttributeAndModes()), they end up being compiled and used at a later 
point.


- osg::StateSet::addUniform() with a osg::Uniform argument seems to be 
the way to specify uniforms.


- osg::Program::addBindAttribLocation() is a means of binding variables 
to a specific attribute index (output location), which you need for 
other calls. I believe location layout qualifiers in the shaders 
themselves can be used as well.


- osg::Program::getAttribBindingList() seems to only return the 
variables set with addBindAttribLocation(), and not ones specified in 
the shader itself. This might be a timing issue, perhaps the results 
change after the shaders are actually compiled and linked?


- osg::State::setUseModelViewAndProjectUniforms(true) can be used to 
automatically hook up variables such as "osg_ModelViewProjectionMatrix", 
which seems to be an OSG analogue to  "gl_ModelViewProjectionMatrix". 
This seems to be a useful bridge while trying to figure things out.


- The compile messages can be used to confirm the actual attribute 
indexes used.


- Variables that aren't used may be optimised out, which makes them 
unavailable.


- Using Geometry::setVertexAttribArray with the last argument set 
correctly (eg. BIND_PER_VERTEX) seems to be the way that you can pass 
texture coordinates to shaders. I'm guessing other information such as 
vertices and normals are handled similarly.


Hopefully this helps someone in a similar situation to the one I was in.

On 23/09/15 22:14, Garth D wrote:

Hi all,

I was wondering if anyone can make some suggestions as to resources that
are useful for learning GLSL in modern OpenGL (say, 3.0+) with a
specific focus on use with OSG.

My existing GLSL knowledge is weak compared to my general 3D knowledge,
and mostly dates back to the early days of shaders. A lot of what I have
personally done with OpenGL and OSG has involved the fixed-function
pipeline, or things that map to it fairly closely.

Thus far I've been digging around online for GLSL resources, but tend to
frequently find myself doing it the wrong way as I'm using features that
have since become deprecated. On the OSG side I tend to dig around in
the OSG examples and search the source to try to find the OSG
equivalents to OpenGL calls I see mentioned in the GLSL resources. I
then put these together and if I'm lucky something useful comes out. :)

I think I'll figure things out eventually if I continue to crash around
blindly as I have been, but if anyone can suggest some better starting
points for GLSL use in OSG specifically, it would be much appreciated. :)

Cheers,
Garth
___
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