Shader Programs finally

[Goliat]

today i tried to create a simple vertex shader ... and although i finally got around compiling some glsl code with nvidias cg compiler i'm not quite happy with the results

first: nvidias compiler creates wrong 'machine code' (or however those compiled shaders are called)
i found a very simple example on wikipedia.com:

1   2   3   4

void main(void) {     gl_Position = ftransform(); }

which should be the simplest vertex program around ... using the cg compiler ( with -oglsl -profile arbvp1 parameters ) i get this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19

!!ARBvp1.0 # cgc version 1.4.0000, build date Sep 26 2005 22:13:28 # command line args: -v -oglsl -profile arbvp1 # source file: wave.cg #vendor NVIDIA Corporation #version 1.0.02 #profile arbvp1 #program main #semantic gl_ModelViewProjectionMatrixTranspose #var float4 gl_Vertex : $vin.POSITION : POSITION : -1 : 1 #var float4 gl_Position : $vout.POSITION : HPOS : -1 : 1 #var float4x4 gl_ModelViewProjectionMatrixTranspose :  : c[1], 4 : -1 : 1 PARAM c[5] = { program.local[0..4] }; DP4 result.position.w, vertex.position, c[4]; DP4 result.position.z, vertex.position, c[3]; DP4 result.position.y, vertex.position, c[2]; DP4 result.position.x, vertex.position, c[1]; END # 4 instructions, 0 R-regs

which doesn't contain any error ... but isn't the correct result
the correct version (and the one that is displaying stuff onscreen) would be:

1   2   3   4   5   6   7

!!ARBvp1.0 PARAM c[4] = { state.matrix.mvp }; DP4 result.position.w, vertex.position, c[3]; DP4 result.position.z, vertex.position, c[2]; DP4 result.position.y, vertex.position, c[1]; DP4 result.position.x, vertex.position, c[0]; END

any idea if i just have to change some parameters of cgc ?

second: why do i even have to compile the glsl stuff myself?
i searched the web and found some pages that tell the user to let opengl compile the glsl source directly using the method void glCompileShaderARB(GLhandleARB program);



last: i have used this shader stuff for the first time today ... so if i have made a capital fault in my approach ... please point me at it 

Golly

[Niwak]

First question ; NVidia compiler creates a valid program. You just have to bind your transposed model view projection matrix to the program local parameter n° 1 and everything will work fine. It is stated in the comment ;

1	#var float4x4 gl_ModelViewProjectionMatrixTranspose :  : c[1], 4 : -1 : 1

Second question ; You need to compile the GLSL code yourself because Xith3D doesn't support high level shader but only assembly ones.

Last question ; my own point of view is that using assembly shaders is an entirely deprecated way of using shaders. So if you really want to use shaders either add support for high level shaders to Xith3D or don't use Xith3D.

       Vincent

[Amos Wenger]

Last question ; my own point of view is that using assembly shaders is an entirely deprecated way of using shaders. So if you really want to use shaders either add support for high level shaders to Xith3D or don't use Xith3D.

How hard is it ?

Games published by our own members! Check 'em out!

[Goliat]

may i point you at this fine piece of html code: http://www.lighthouse3d.com/opengl/glsl/index.php?ogloverview

the opengl part doesn't look hart ... although i have no deeper knowledge of opengl :/

[Goliat]

i guess i have implemented glsl support for xith3d ... i'm astonished about myself ... 0o

i'd commit it to the toolkit but it relies on some changes in the core ... and i'm not sure if it works completly ... so i'll play around with it some time today, implement the lwjgl parts (i've done jsr231 first) and post a patch this evening or tomorrow ...

maybe i'll catch arne today ... than i'll send him my stuff

greetz goliat

EDIT: i just noticed there is no way to specify parameters ... but i guess it won't take long to implement that ... now i'll be of to my parents ... cya guys

EDIT2: just one last question ... does xith uses opengl 2.0 functions? or the ARB stuff?
i used the ARB way ... should i?

[Marvin Fröhlich]

..., implement the lwjgl parts (i've done jsr231 first) and post a patch this evening or tomorrow ...

Is it a difference? Did you notice the least changes in Canvas3DWrapper, RenderLoop and Xith3DEnvironment. There should be no need to do anything different for LWJGL.

[Goliat]

don't get me wrong ... but afaik those classes are merely wrappers for the canvas and the renderer abstraction ...
to implement glsl support i had to extend some of the renderers classes directly (actually RenderPeerImpl and ShapeAtom) and had to add a new (xith) shader to the renderers

as to progress: i spend last day at my parents so i had no more time to do stuff ... but there isn't much left todo ...

-> Flo

oooookey ... i've finished my work ... it is a complete glsl implementation for xith3d ... (ok ... there's one thing missing but xith users couldn't use it anyway)
i've attached a patch that was created against the current cvs tree ... usage is very simple (add GLSLVertex and GLSLFragment shaders to a GLSLShaderProgram and put this into Appearance), but i'll create some demos today or tomorrow ...
one thing is missing: attribute variables .. these allow users to set shader variables for every fragment if necessary ... but this isn't possible in Xith as there is no way to interfere with the render pipeline ... use uniform variables instead that should be sufficient

just one thing: i put stuff into the scenegraph package ... but i believe that it would be better to create a new package xith.scenegraph.glsl to store my stuff so i could discard the GLSL prefix

-> Flo again

[Marvin Fröhlich]

I didn't have a look at your glsl implementation so far. But anyway: Good work! And I'm very for creating a subpackage, since I'm for splitting several packages into subpackages. But this big step will come in version 2.0.

[Goliat]

im all for some design cleanup ... and i would suggest making the core more modular ... the thing is a whole mess ...

just my opinion
-> Flo

[hawkwind]

cant view your reference image. 

Games published by our own members! Check 'em out!

[Amos Wenger]

im all for some design cleanup ... and i would suggest making the core more modular ... the thing is a whole mess ...

just my opinion
-> Flo

Post your ideas, we're listening 
"Modular" is an attracting word for me, now the question is how to achieve that.

[Goliat]

@hawkwind sorry ... it's not image :/ ... its a zipped patch file against the cvs tree ... but i guess after all those changes it doesn't work anymore

@blusky i guess it would be good to have several layers of functionality ... both in the core and the toolkit ... first layer would be the renderer system ... so you could use the abstracted renderer layer without any scenegraph functionality ... for example as a base for other engines
i haven't tried to acomplish this ... but i don't believe it would be possible at the moment due to dependencies on other parts of xith ... which in my eyes is a sign of bad source organisation ...
once the renderer is isolated we should assign some people to analyse this subsystem ... optimize it for performance and try to make it a more general rendering subsystem ...

same thing goes with the sound system (although i have never used it)

with a isolated renderer it should be possible to have several module accessing it in one program, example: the scenegraph (which in my eyes provides most xith functionality), and a (not yet existing) gui system. Each one having the same access to the renderer.
In my eyes the reason there is no such gui system is the fact that xith rendering is bound to work over the scenegraph ... it would be much easier to have direct access to the renderer ( scenegraph rendering finished -> switch to parallel and render some images over the whole thing )

so far
Flo

[Amos Wenger]

@blusky i guess it would be good to have several layers of functionality ... both in the core and the toolkit ... first layer would be the renderer system ... so you could use the abstracted renderer layer without any scenegraph functionality ... for example as a base for other engines
i haven't tried to acomplish this ... but i don't believe it would be possible at the moment due to dependencies on other parts of xith ... which in my eyes is a sign of bad source organisation ...
once the renderer is isolated we should assign some people to analyse this subsystem ... optimize it for performance and try to make it a more general rendering subsystem ...

same thing goes with the sound system (although i have never used it)

with a isolated renderer it should be possible to have several module accessing it in one program, example: the scenegraph (which in my eyes provides most xith functionality), and a (not yet existing) gui system. Each one having the same access to the renderer.
In my eyes the reason there is no such gui system is the fact that xith rendering is bound to work over the scenegraph ... it would be much easier to have direct access to the renderer ( scenegraph rendering finished -> switch to parallel and render some images over the whole thing )

so far
Flo

Which direct implications do you see : what should be done first.. Try to make the renderer a separate project and remove any dependencies ?

[Marvin Fröhlich]

...and a (not yet existing) gui system. Each one having the same access to the renderer.
In my eyes the reason there is no such gui system is the fact that xith rendering is bound to work over the scenegraph ... it would be much easier to have direct access to the renderer ( scenegraph rendering finished -> switch to parallel and render some images over the whole thing )

Do you know the new HUD system? Isn't this the GUI system you are talking about? OK... it doesn't have very many Widgets, but it is growing. And this switching from projection to parallel exists in the xith toolkit. See org.xith3d.test.ui.HUD3DTest

Marvin

[Goliat]

Which direct implications do you see : what should be done first.. Try to make the renderer a separate project and remove any dependencies ?

not necessarily a seperate project but a seperate unit ... i don't know for sure ... but i believe nobody from the community can tell how everything inside the renderer works (i got very confused when i implemented shader support) ... seperating it would make at least this part much easier

another thing that would be possible would be to split the scenegraph stuff in two parts, not like qudus suggests (create a new branch and leave an old, (unsupported?), but java3d compilant branch behind) but two packages in the main branch one java3d compilant, one with xith3d specific patches
(actually there should be 3 packages in this case ... one scenegraph-base which would hold common elements between the xith3d and the java3d interface)

@marvin: no i had no need for a hud system, and ,although this doesn't mean the new system is bad, i believe using a scenebased solution for 2d and maybe  10 quads is overkill ... (actually i read some threads here on java-gaming.org where they suggest to use a pure ogl implementation for 2d games)

so far ... Flo

[Amos Wenger]

I heard that Arne was the one who would commit Goliat's work on GLSL support. How is it going ?

I think a 0.9 release would be fine soon (with some Java3D compatibility added, such as wrappers and all that thingies).

EDIT: Added "Goliat's work" for clarity's sake (thanks Qudus)

[Goliat]

actually i haven't heard anything from arne currently ...

but i'll attach 'my work'  as to patches against the current cvs tree so anyone with access can commit this ...

i have included a 'shader loader' ... which is in fact just a copy of the textureloader changed to support shaders (with caching and stuff)
but you can create the shaders yourself if you want

using shaders is easy to ... just create a GLSLShaderProgram, add GLSLVertexShaders and/or GLSLFramentShaders, add the program to your appearance with setGLSLShaderProgram ... enjoy ... i included a (very simple) demo for reference

as a last note i must mention that i won't support this patch ... i'm sorry ... and there won't be any updates to this too ...
but this stuff 'as is' is pretty usable ...

So far ... Flo

(the txt files in the attachment are in fact eclipse compatible patch files)

[Marvin Fröhlich]

I'm just trying to use your patches. Can you tell me how to do this (in Exclpise 3.2)?

[Marvin Fröhlich]

OK. I found out, how patches work in Eclipse. I've just applied the two patches. Well, parts of the core patch I had to do by hand, since it was not against the last version. But I think, i should be fine.

I've tried to run the new WaverTest, but there's a bug in it. Unfortunately I have no time today to fix it.

[bohdan]

@ Marvin :
Maybe this is a bit off topic but since it is regarding Shader classes only I will put it here.
There are some plain calls "if (CanvasPeerImpl.DEBUG_GL)" left in "jsr231.GLSLShaderProgramShaderPeer" and "jsr231.VertexProgramShaderPeer" and causing "NullPointerException"....

Bohdan.

[bohdan]

@Goliat:
My celtic videocard (Riva TNT2) doesn't seem to support "GL_ARB_fragment_shader" and xith is crashing on "glUseProgramObjectARB(..)".
How can I switch GLSL support off? There I see method "checkOnce( GL gl )", but it doesn't seem to be finished yet (maybe...)?

Bohdan.

   

[Marvin Fröhlich]

@ Marvin :
Maybe this is a bit off topic but since it is regarding Shader classes only I will put it here.
There are some plain calls "if (CanvasPeerImpl.DEBUG_GL)" left in "jsr231.GLSLShaderProgramShaderPeer" and "jsr231.VertexProgramShaderPeer" and causing "NullPointerException"....

Thanks, they came in with the patch and they existed in the LWJGL version, too. Now even the WaverTest is working

[Marvin Fröhlich]

@Goliat:
My celtic videocard (Riva TNT2) doesn't seem to support "GL_ARB_fragment_shader" and xith is crashing on "glUseProgramObjectARB(..)".
How can I switch GLSL support off? There I see method "checkOnce( GL gl )", but it doesn't seem to be finished yet (maybe...)?

Please try it once more. There actually was a static boolean field for that purpose. I commented it out, because it was never read. Now I've reactivated it (also in LWJGL) and added a check around the glUseProgramObjectARB(..) call. Please check, if it works for you now.

[bohdan]

Thanks, Marvin! Now works perfect! 

Bohdan.

[arne]

sorry, I was this week not at home - so I was only rarely online - and Goliat wanted to send me the new patch, so I didn't commited the old one.

@Goliat: At least I found some time to do those joode changes, but I got stuck with the Spaces. The idea works fine, if all Geoms extend Geom and not each other, as it is the case, with Spaces. - nah anyways here is not the correct place to discuss that - I'll make a post in physics

[Goliat]

@ bohdan: sorry must have forgotten that about being happy that shaders worked
@ Qudus: thanks for submitting the stuff ... and for the quick fix

@ arne: ... no it isn't