Goliat
|
 |
«
Posted
2006-07-05 18:41:12 » |
|
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
|
 |
«
Reply #1 - Posted
2006-07-06 08:25:34 » |
|
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
|
 |
«
Reply #2 - Posted
2006-07-06 10:32:47 » |
|
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 ?
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Games published by our own members! Check 'em out!
|
|
|
Goliat
|
 |
«
Reply #4 - Posted
2006-07-07 11:58:30 » |
|
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
|
 |
«
Reply #5 - Posted
2006-07-07 12:14:17 » |
|
..., 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
|
 |
«
Reply #6 - Posted
2006-07-08 09:13:56 » |
|
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
|
 |
«
Reply #7 - Posted
2006-07-08 19:58:28 » |
|
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
|
 |
«
Reply #8 - Posted
2006-07-08 23:19:39 » |
|
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
Junior Devvie  
Java games rock!
|
 |
«
Reply #9 - Posted
2006-07-14 02:14:55 » |
|
cant view your reference image.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Amos Wenger
|
 |
«
Reply #10 - Posted
2006-07-14 10:04:31 » |
|
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.
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Goliat
|
 |
«
Reply #11 - Posted
2006-07-14 10:34:02 » |
|
@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
|
 |
«
Reply #12 - Posted
2006-07-14 11:22:52 » |
|
@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 ?
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Marvin Fröhlich
|
 |
«
Reply #13 - Posted
2006-07-14 13:06:09 » |
|
...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
|
 |
«
Reply #14 - Posted
2006-07-17 08:21:43 » |
|
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
|
 |
«
Reply #15 - Posted
2006-07-21 20:50:25 » |
|
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)
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Goliat
|
 |
«
Reply #16 - Posted
2006-07-22 14:15:23 » |
|
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
|
 |
«
Reply #17 - Posted
2006-07-23 10:23:08 » |
|
I'm just trying to use your patches. Can you tell me how to do this (in Exclpise 3.2)?
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #18 - Posted
2006-07-23 12:48:25 » |
|
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
Junior Devvie  
Java-positive...
|
 |
«
Reply #19 - Posted
2006-07-23 18:54:04 » |
|
@ 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
Junior Devvie  
Java-positive...
|
 |
«
Reply #20 - Posted
2006-07-23 20:36:32 » |
|
@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
|
 |
«
Reply #21 - Posted
2006-07-23 22:18:25 » |
|
@ 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
|
 |
«
Reply #22 - Posted
2006-07-23 22:39:23 » |
|
@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
Junior Devvie  
Java-positive...
|
 |
«
Reply #23 - Posted
2006-07-24 00:16:01 » |
|
Thanks, Marvin! Now works perfect!  Bohdan.
|
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #24 - Posted
2006-07-24 10:28:56 » |
|
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
|
 |
«
Reply #25 - Posted
2006-07-24 19:59:52 » |
|
@ 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 
|
|
|
|
|