shader program
keith
possible shader combinations and then just switch between these linked
programs? I suppose twiddling programs during rendering is too slow?
And now to the Cg discussion. If the Cg approach to supporting both
DirectX and OpenGL is ill advised. How to achieve easy portability? I
hear the AMDs conversion program HLSL2GLSL is no good too. The only
alternative then is to translate all shaders by hand?
In what games/applications is Cg used then at all?
John Tsiombikas
> I'd like to ask whether you people create&link shader programs using all
> possible shader combinations and then just switch between these linked
> programs? I suppose twiddling programs during rendering is too slow?
It depends on what you want to do really. If indeed you need to have
different variations of the same basic shader to support different
light, fog, multitexture, etc settings, then yes, having a scheme in
place to generate shaders is an option. Also if you won't need all
possible combinations, lazily generating and caching them instead of
generating all of them at startup is probably a good idea.
> And now to the Cg discussion. If the Cg approach to supporting both
> DirectX and OpenGL is ill advised. How to achieve easy portability? I
> hear the AMDs conversion program HLSL2GLSL is no good too. The only
> alternative then is to translate all shaders by hand?
Why is it ill advised? Sure I prefer GLSL due to close coupling with the
OpenGL state machine, and other reasons (superior varying semantics? I
don't want to have to fiddle with which texture coordinate channel
carries what bit of information...). But if you need to write shaders
once and be able to use them in both OpenGL and Direct3D, then I think
Cg is ideal. You won't be able to exploit the close coupling between
OpenGL and GLSL anyway in a cross-API engine...
> In what games/applications is Cg used then at all?
In my previous work, we wrote a cross-API engine (a waste of time if you
ask me but anyway), and we used Cg for the reason I explained above.
--
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/
keith
>> And now to the Cg discussion. If the Cg approach to supporting both
>> DirectX and OpenGL is ill advised. How to achieve easy portability? I
>> hear the AMDs conversion program HLSL2GLSL is no good too. The only
>> alternative then is to translate all shaders by hand?
>
> Why is it ill advised? Sure I prefer GLSL due to close coupling with the
> OpenGL state machine, and other reasons (superior varying semantics? I
> don't want to have to fiddle with which texture coordinate channel
> carries what bit of information...). But if you need to write shaders
> once and be able to use them in both OpenGL and Direct3D, then I think
> Cg is ideal. You won't be able to exploit the close coupling between
> OpenGL and GLSL anyway in a cross-API engine...
Because Wolfgang said so. He predicted the coming death of Cg. Also, Cg
is supposedly slow on non-nvidia hardware.
> In my previous work, we wrote a cross-API engine (a waste of time if you
> ask me but anyway), and we used Cg for the reason I explained above.
A game engine? Any commercial releases? Can I see some screenshots?
fungus
> I'd like to ask whether you people create&link shader programs using all
> possible shader combinations and then just switch between these linked
> programs? I suppose twiddling programs during rendering is too slow?
>
Yes.
> And now to the Cg discussion. If the Cg approach to supporting both
> DirectX and OpenGL is ill advised.
Who says it's ill advised? Postings on message
boards are rarely neutral or well informed, try
it and see if it works for you and fits your needs.
--
<\___/>
/ O O \
\_____/ FTB.
Wolfgang Draxinger
> Because Wolfgang said so.
Not *because* I said so. It's the other way round: I say so, because I see
no future for Cg.
If you want to be cross-platform, the only choice is OpenGL anyway. If one
targets windows only to make use of DirectX only features, then HLSL is the
way to go.
Using Cg makes only sense if one wants to target OpenGL and DirectX and a
wide range of operating systems. Which means, that in the end only a smaller
subset of functionality of as cross-plattform OpenGL only design was
avaliable.
> He predicted the coming death of Cg. Also, Cg
> is supposedly slow on non-nvidia hardware.
I don't think that Cg will actually die, CUDA likewise. Cg already has GLSL
as compilation target, and CUDA probably will offer OpenCL as compilation
target. The question is, who wants to use a wrapper around a wrapper? I
think Cg and CUDA eventually will end up in a state of zombification.
For a long time I was a big fan of Nvidia, but during the last months they
made a whole set of strange decicions.
Wolfgang
John Tsiombikas
>> In my previous work, we wrote a cross-API engine (a waste of time if you
>> ask me but anyway), and we used Cg for the reason I explained above.
>
> A game engine? Any commercial releases? Can I see some screenshots?
Yes a game engine, although the project was cancelled at some point due
to lack of funds, so no commercial releases out of that. The game I was
working on was called "Theseis" from Track7 Games. There are videos on
youtube.
The 3D engine we were writing for that was a shader-only cross-API
cross-platform thing. We used Cg to have one set of shaders running on
all targets. We mostly side-stepped the multiple code paths issue
though, since our renderer was based on deferred shading. So
transparent-objects aside, everything was using the same shader and it
would work for any combination of lights etc.
And no, Cg isn't slow on non-nvidia hardware. It compiles to ARB
assembly or GLSL on OpenGL and DirectX pixel shader assembly / HLSL for
Direct3D, so it's exactly the same as all that.
The only disadvantage of using Cg in such a way, is as Wolfgang
mentioned that you have to support the lowest common denominator of
functionality. So no direct access to OpenGL state and such niceties. We
had our own uniform state management code that mapped our 3D engine
state to a set of uniforms accessed by "standard" names in our shaders.
A bit of a bother to set it up in the first place, but not that bad in
the end, and quite flexible.
I'll say it again, I thing writing cross-API engines is a pointless
thing. OpenGL is supported on all platforms.
keith
> On 2009-11-26, keith <johndo...@yahoo.com> wrote:
>> John Tsiombikas pravi:
>>> In my previous work, we wrote a cross-API engine (a waste of time if you
>>> ask me but anyway), and we used Cg for the reason I explained above.
>> A game engine? Any commercial releases? Can I see some screenshots?
>
> Yes a game engine, although the project was cancelled at some point due
> to lack of funds, so no commercial releases out of that. The game I was
> working on was called "Theseis" from Track7 Games. There are videos on
> youtube.
Not bad looking, but I don't like the story line too much :) I always
wonder how games like these lose steam. The game web page is still up,
strange.
> And no, Cg isn't slow on non-nvidia hardware. It compiles to ARB
> assembly or GLSL on OpenGL and DirectX pixel shader assembly / HLSL for
> Direct3D, so it's exactly the same as all that.
So Wolfgang was wrong about this.
> I'll say it again, I thing writing cross-API engines is a pointless
> thing. OpenGL is supported on all platforms.
I agree.
Wolfgang Draxinger
>> And no, Cg isn't slow on non-nvidia hardware. It compiles to ARB
>> assembly or GLSL on OpenGL and DirectX pixel shader assembly / HLSL for
>> Direct3D, so it's exactly the same as all that.
>
> So Wolfgang was wrong about this.
Did I say it was slow? Not that I remember. There's just no real good reason
for using Cg. Either you want be cross plattform, then you must use OpenGL
anyway, or you stick to a specific plattform-API to take leverage of it's
features and don't use a wrapper, which delivers only a small feature
subset.
Wolfgang