|
|
GLSL and CI learning I want to start learning how to write GLSL and CI codes and have some questions which I think you guys here can answer properly: 1- Should I learn OpenGL coding first or could I go straight to these matters. 2- I know there is the yellow book but I hoped you guys can recommend some online links first (I live in Iran and do not have access to hardcopy books easily) by the way I must mention that for now I want to use these in QC patches so anything outside of QC capabilities is not necessary right now! thanks in advance for your advices, Cheers!
|
the ci and glsl stuff was very intimidating at first. its not really the syntax as it is similar to c or what ever but the specific data types and how they effect the pipeline was a bit confusing at first. the developer examples are a good start if you want to dive in etc...
the orange book or yellow book examples didn't help me to much because i didn't read or buy the book but i here the gpu gems book is pretty good. i have been determined to figure it out in a non qc context because most examples and tutorials on the net i couldn't copy directly to qc. so by figuring it out in a non qc context like the for the iphone i got a better understanding of it but even more overwhelming at first.
im sure you have been to this place.. http://www.lighthouse3d.com/opengl/glsl/
i found it useful to go through these tutorials. even after these tuts i found it a bit frustrating in qc because most of these things are in the developer examples all ready and because i really wanted to be able to create my own texture maps and shading networks from my head (like in maya) and it was still a bit vague after doing the toon shader tutorial.
there are some guys on here like _tb vade, chris, etc... that are really creative with glsl.
after putting in effort to learn open cl. glsl made a whole lot more sense to me. basically the glsl reference is your best guide for using it in qc. the language itself isn't incredibly large as far as word count, but still having a reference to the built in functions helps me.
if you know how to build a shader in a 3d software package then try and replicate that in glsl. starting from step one. if you know what it is your trying to accomplish it makes getting to the last step is a lot easier. all the in between things will fall in place, and you will learn the code for the specific task.
Thanks dust for the reply! I've started the lighthouse3d tutorials since 2 days ago and I must say they are really good! simple and clear. do you know which volume of GPU GEMS talks about GLSL by the way? (I think there are 3 volumes) I've seen toneburst's examples and he's truly the guru. I will examine them carefully after I read some tuts online :)
by the way I just did my first GLSL test in QC. it works in QC but makes VDMX crash. I can't debug the problem and will be more than happy if you checked it as well.I'm gonna attach it.
thanks again mate!
have no idea, i just keep coming across the gpu gems book in references and stuff but have never purchased it as i have books for college i need to buy. yeah i think about revisiting some of tb's glsl shaders now that i have a better understanding of glsl so i know what you mean.
as per vdmx it seems like an awesome software. i played with the demo awhile back but i don't have it. i have been trying to get a professor of mine to get me a copy as he knows the guy who makes it. i think he said his name was david or something but he hasn't delivered yet. he did get me boris's modul8 however, but i all ready had a copy of that so im not really sure why it would crash vdmx.
you seemed to publish your ports and declaring your splitter datatype correctly. my system has x code 4 on it so things are weird for me. i get backtrace errors when i open any vdmx patch, so i'm not the right person to ask. i would test however with glsl grid and not a gl spline to see if its an issue with the plugin and vdmx. then try without the iterator inside the glsl patch. not really sure but it seems to me maybe that might be the problem ?
so looks interesting though i like the noise function. i could see this patch making some cool visuals with audio input.
The Orange Book has been most useful to me in learning GLSL.
cheers dust! I will test the comp without the spline iterator and with GLSL grid instead and will report back. You should buy VDMX if you're into VJing with QC, it's not that expensive (200$ for students which gives you 3 licenses you can share with friends:)) )it's a little buggy but hopefully the public alpha version will correct the bugs. cheers for the compliment!! :))
Hello george! one question: 1-do I need to read the OpenGL book (The red book) first or can I dive into the orange book straight a head (does it have a fair introduction and basics as well as advance materials)?
I just checked my comp with nothing but a GLSL grid inside the GLSL patch, it crashes VDMX again :(( any helps in debugging the comp (if it is the comp) will be highly appreciated.
I'd read the Red Book as background, perhaps, but really it's not necessary. The LightHouse3D tutorials and the Orange Book should get you started. Be aware that there are some things in there that basically can't be done in QC though, because of various limitations of the environment.
As for OpenCL, I'm still struggling with it, to be honest. Some things about it I just can't get my head around. There were some links in another post recently that you might find useful. I should follow them myself, probably. Personally, I'd recommend learning GLSL first, then tackle OpenCL. Maybe I'm just saying that because that's the way I did it, though.
a|x
Hello Toneburst! Thanks for your suggestions. Another resource is YOUR GLSL examples ofcourse. I've started the Orange Book already and it's a very thorough book indeed. One more question: There are some built-in variables that the book does not discuss deeply as if the reader should know them already. for instance I have an idea what "gl_vertex"is but couldn't find a proper reference neither on the book or online. is that were I the Red Book comes into play? By the way I meant CoreImage by CI, not OpenCL. I know it's too early for me to start OpenCL yet. Cheers for your help!
Oh, I missed that. I agree with toneburst basically.
GLSL, as a whole, is more complex than it is represented as in QC. It can be really complex.
OpenCL is challenging because one has the hurdle of having to envision things happening in a parallel way, and figure out how to fiddle with sizes and groups so that you can set things up to do so. It's not always very obvious. It's very deep when it comes to different functions. Some CG shader language stuff that I've done after being introduced to OpenCL have actually shed some light on OpenCL and GLSL for me, but I'm not necessarily saying it would work that way for everyone. I've burnt some serious time figuring out some stuff with OpenCL, but I have to say that I've been really satisfied with the end results many times, so I'm hot on it at the moment.
I think there's overlap of course, but depending on what problem one needs to solve, they both have their advantages and weaknesses.
It feels like their could be some GPU accelerated language that made things less tedious though. I mean, it seems like I should be able to LERP between the vectors of two structures with different index counts/size without such a pain in the butt. I understand why OpenCL handles stuff the way it does, but it doesn't necessarily make things easy to code all of the time.
Though, on the other hand, it's pretty simple when you jettison fixed-function crap (which, unfortunately, QC doesn't allow you to do :/).
ok, here are 2 structures of 1-vectors with differing sizes:
1, 1, 1, 1and0,0LERP at 0.5. what's the resultant output (and show your work)? When you can sort that out, by all means make a new GPU language that does this automatically. :)
My semantics were poor. I don't mean that one wouldn't have to specify values for the "missing indices" of the shorter size structure in one way or another.
I mean that if I want to do operations on structures of differing length, I feel it would be nice to be able to have some very easy way setting a default value for each index that "wasn't there" for the short structure. There may in fact be a really easy way to do that with OpenCL that has eluded me. I'm not saying it isn't possible to handle, but it just feels harder than it has to be.
For instance, when I had that thing where I was loading different DAE's subsequently, getting the vertex structures, and then smoothing between different structures using QC and the iterator, it's exceedingly easy to dictate what will happen if the structure count is less... boom, less iterations. This feels more onerous to handle in the CL kernel.
This is a QC shortcoming. GL textures, for example, have edge behavior (for when you read off the edge) -- they can clamp to edge (read the edge pixel), repeat (pretend the texture tiles infinitely), mirror repeat (a variation on infinite tiling), clamp to border (a fixed defined color), any maybe a couple other exotic cases.
CL similarly has provisions when dealing with Samplers.
I guess treating vertices as 1D textures (that are really long) would allow you to make use of this. I don't think mem objects have such provisions though (which is unfortunate). 2D vertex textures would probably also work, provided you didn't depend on the 2D-ness for anything in particular.
Huh, that's interesting. Isn't QC CL 1.0? It looks like those are still basically available in 1.0, just slightly different.
Treating them as 1D textures seems sort of awkward...I'm not 100% sure I understand what you're suggesting either. Do you mean to convert a 4 lane structure to a 1 lane structure to do the operation, then convert back at some point? I didn't realize there was such a thing as a 1D texture in OpenCL 1.0... it's not a data type, but I think you're just meaning to convert to a 1 lane structure. Then I'm going... how does that turn to image type data that image sampler rules apply to? I think you threw me for a couple loops there.
oh, right -- go figure I'd pull the latest spec instead of the one currently available :/ this functionality should be there too (though I haven't checked).
Not a 1D texture (since QC doesn't support those), but a 2D texture with just 1 row of pixels. Really, the dimensionality is unimportant (1D, 2D, even 3D textures) -- you just want the vertex data (a structure) in a format that will allow CL's sampler clamping stuff to take effect (Images).
Essentially, you need to treat XYZW (vertex) data as RGBA (texture) data.
The tricky part (and I'm not sure it's trivially possible) is getting vertex structure data into a texture and back. In GL circles, render to vertex array/vertex buffer demos do this, but doing it in QC is almost certainly more trouble than I'd like to fight with.
OK, that makes sense. The 1D texture thing was throwing me off, because I couldn't figure out how that was available in QC, or Open CL 1.0 even(?). 2D texture, 1 row of pixels makes sense. Awesome.
I think the only method that isn't available is the mirrored one, and that you have to write CLK, not CL. I may be wrong on that.
It's not too hard to convert structure info to an image output... I'm not so sure about back and forth in the same kernel or anything. It's not anything I've really given much thought, beyond you bringing it up just now, and the thoughts that has led to.
I guess for anything I've needed to do so far, it hasn't been too hard to figure out a way to make the structures equal before they reach my kernel, or to get the size of the lesser structure, and have the kernel work upon that. I was setting up something last night to do something basically like I was talking about in a response earlier on this thread, where two structure sizes are compared, and for the one that doesn't have as many indices, to assign a value of 0.,0.,0.,0 to each vector, and it seemed doable, I just ran out of steam and went to bed. I haven't had time to pick up on it again yet.
Without reading this topic, I found another links http://www.clockworkcoders.com/oglsl/tutorial2.htm
This one,
When I make a teapot and put the GLSL shader on it, then past that code into the the vertex shader, nothing happens...
Here is the code in functioning form. It seemed to work ok from the start for me, so maybe it was just a matter of a missed semicolon or something that was keeping it from starting.
Leaving the QC default frag shader code leaves the shader so that there is an image input. That doesn't keep the shader from working though. I eliminated for this upload.
Two reasons:
1- In the default GLSL patch, a texture is stated. Without this texture the Shader has got no "sampler2d" to perform the "texture2d" command. So the gl_Color is multiplied by a vec4(0,0,0,0) which is color black, so the result is black.
So, firstly use this code in the fragment shader:
void main()
{ gl_FragColor = gl_Color; }
2- You must also state the gl_FrontColor in the vertexx shader, so add this line to your vertex shader:
gl_FrontColor=gl_Color;