views:

157

answers:

5

I am currently learning GLSL. It would seem that once you learn one of the shader languages, learning one of the others would not be too difficult. Is it something analogous to learning a widget toolset like wxWidgets and then switching to Qt? Once you get the idea of what is happening within one widget toolset, another toolset will do something similar since they are ultimately doing almost the same thing at some point? What are your experiences with going from one shader language to another?

+6  A: 

Cg and HLSL are almost the same (same builtin function names). GLSL looks and feels a bit different (i.e. mix instead of lerp, use of a main-like function), but the overall transition is still easy. The only differences are in the details and in the respective APIs (i.e. stuff like matrix storage order).

Switching between shading languages is way easier than switching between GUI toolkits…

Alexander Gessler
A: 

the origin of directx 3d lies in opengl. microsoft reprogrammed the opengl api to a certain point, because of this the languages should be similiar.

M3t0r
TBH the ARB have been consistently behind microsoft ont he introduction of all these technologies. GLSL was part of the modification brought in by 3D Labs into OpenGL 2. Furthermore the driving forward of GL has been as a direct result of Microsoft telling graphics card manufacturers what the next API level is (Even if they do back down on certain parts at times). Open GL has thus far only been able to react to trends in graphics cards. MS have the clout to try, at least, to define the way things are going.
Goz
@Goz that's only sort of true, NVIDIA exported lower level shader functionality to OpenGL before DirectX could support it, basically whenever the hardware manufactures make something new they can export it to OpenGL as an extension right away, while DirectX has to wait for MS to bump the API. The NVIDA shader stuff wasn't as easy to code for as HLSL/GLSL but it WAS there pretty much from the moment the cards that supported it shipped. (This is where OpenGL shines, it was designed with vendor extensions in mind, DirectX wasn't)
Spudd86
@spudd: while i get your point GL has done little to drive forward innovation. They almost did. The original GL3 spec would have done just that but Khronos, like everyone before them, bottled it. The extension functionality is a huge bonus but it is, equally, GL's biggest weakness. It detracts from the cross-platform-ness of it all by forcing people to write card specific code paths. If you need to do that why not just write platform specific code paths? As it is I personally have a DirectX, OpenGL and OpenGL ES code path in my engine. Its not that hard but god it makes life easier :)
Goz
@Goz, yep everyone was disappointed with GL3 (Especially NVIDIA I think), but I think the plan is that GL3 serves as a stepping stone (dropping lots of old crud, cleaning things up, etc) then they do the nice stuff incrementally, IIRC GL3.2 is a step towards the original GL3 plan, so there's hope yet that OpenGL could get to the point of being the leader again :)
Spudd86
+3  A: 

HLSL has some differences from GLSL. Nothing too different from what I've read. There are some translation tools out there. There is a SourceForge project HLSL To GLSL tool. Also, I believe that the NVidia Cg toolkit can generate HLSL or GLSL.

Walt Ritscher
+1  A: 

In my slightly limited experience, I'd agree with everyone here that they are very, very similar and it's not a problem to switch between them. However, do beware that, as seems to be the case with most OpenGL/DirectX clashes, I find HLSl to have a few more nice convenience functions that make it a little more fun to use. I'm talking small things, like saturate, here. However, beyond minor structural differences, like passing around inputs, the basic concepts are one hundred percent the same.

Enjoy! Shaders are a lot of fun.

Perrako
+1  A: 

You are right - GLSL/HLSL/Cg shading languages are subset of C programming language, so they are very similar.

0x69