|
Post by DJLinux on May 30, 2011 12:47:26 GMT -5
|
|
|
Post by shadow008 on Jun 2, 2011 9:53:18 GMT -5
That program is AMAZING! Why didn't I think to google something like that earlier XD? It helped me fix the specular component problem I had with bump mapping. And I was also able to test a phong shader that I found on the webz, which I haven't actually tested in B4GL yet. Alright, fixed the phong shader, and the bump map shader had an annoying issue that took a few minutes to find, but its fixed ;D Threw them both in one. Here ya go! dl.dropbox.com/u/5319168/Normal%20Mapping-Specular.zip
|
|
|
Post by shadow008 on Jun 26, 2011 19:49:17 GMT -5
Here's the composition of shaders I made. Implements: -Normal mapping -Phong shading -Bloom effects (Fake HDR) DOWNLOADIn the program, change UseBloom to FALSE to see the DRAMATIC effect that bloom has on the render rate. The main bottleneck is actually rendering the orthographic plane... I knew B4gl was mostly fill limited, but this is HORRIBLE! Would FBO's be faster? B4gl doesnt support them but... Anyways, back to the issue. Is there a faster way to do this? It would be possible to actually implement the bloom shader straight into the other rendering shaders, but that seems pointless... Besides, this is sorta the way its usually done. What about glReadPixles? Would that be faster then glCopySubTexImage2D? Even though the program is rasterizing the ENTIRE thing full resolution, there really isnt much a difference between that and a lower resolution, and the bottleneck still remains. Also, the bloom shader as is, is quite slow itself. This one samples the four outer "rings" of pixles closest to it (and wraps around the texture. If you put the light next to the edge, you'll see it) and blends the colors together, then samples the light intensity and blurs the pixle based on the intensity where more intense = more blur. I cant find the site, but one place suggested cubing the current pixle color to make the intense pixles REALLY intense, and the dim pixles REALLY dim (in comparison). Afterwords, just filtering the dim areas out and enlarging the texture to make the bright areas bigger. Then finally blend the two textures. Didn't feel like trying that because it still seems slow... I'm compuzzled 
|
|
|
Post by DJLinux on Jun 27, 2011 6:58:25 GMT -5
A have done a short look to your shaders looks good so far. I must do an deeper view on your bloom part curently if enabled i don't see it the whole scene sems to be under the bottom edge of the window. Get the Texture in Basic4GL can't be the right way (so far i know) you can try the OpenGL Plugin may be glRead/Write pixels are a faster workaround. Again i must do an deeper view on it may be on sunday. Joshy
|
|
|
Post by shadow008 on Jan 22, 2012 14:36:04 GMT -5
Thar! I was meaning to upload this ages ago, but I constantly forgot. So anyways, this blur shader uses Gaussian blur separated into two different passes, 1 horizontal and 1 vertical, which is MUCH faster. Along with blurring the extracted bloom texture, if you comment out these lines in Shaderpack/bloomshader.inc: 'FILTER BRIGHT AREAS FROM SCENE ... GetScreenBuffer(Bloom_Texture) glUseProgram(BloomExtractShader) Shader_Location = glGetUniformLocation(BloomExtractShader, "IntensityThreshold") glUniform1f(Shader_Location, BloomIntensity) glBindTexture(GL_TEXTURE_2D, Bloom_Texture) DrawScreenTexture() ...
you can get raw scene blur, which looks really cool  I should also note that frame rate is DIRECTLY proportional to your resolution. If your getting terrible frame rates using this, lower your resolution. I get ~11 fps at 1920x1080 and ~80 fps at 640x480 (both full screen). And full screen is faster than windowed mode. So here ya go! dl.dropbox.com/u/5319168/Shader%20Demo.zip
|
|
|
Post by shadow008 on Feb 14, 2012 15:17:48 GMT -5
glVertexAttribPointer? I noticed that it wasn't showing up as a function in the plugin's function list. So i check the source code... it seems to be implemented, or maybe commented out? In GLSLPlugin.bas there is everything there for it to be a function, but its not... there? Im confused 
|
|
|
Post by DJLinux on Feb 20, 2012 19:17:21 GMT -5
www.opengl.org/wiki/GlVertexAttribPointerYou don't use VBO's in Basic4GL! You can read the values of a Basic4GL struct from Plugin but you need the native address (pointer) of the Basic4GL struct. Copy a struct to the plugin and than use the pointer with GLSLang makes no sence here (you will lost the performance) Joshy
|
|
|
Post by shadow008 on Feb 21, 2012 15:15:20 GMT -5
Ok ok... That actually makes sence. Well this is going to be interesting... My Collada loader (actually, the collada format in general) is solely optimized for specifically using VBO's. It uses interleaved indicies to allow for stuff like multitexturing and bone weights. I was going to use that to bind bone matricies and weights for animation and use glDrawElements to render everything using a custom shader, but the interleaved index part... But since that cant be done the way i thought it was going to be done, im at a loss as to how to pull this off now... Using immediate mode in a display list wouldnt work because the matricies are constantly changing, though the weights stay the same. And going immediate mode without a display list would be too slow... glVertexAttrib3f maybe??
Any suggestion here? I dont know what to do now... Might have to get fancy with code here.
Also, out of sheer curiosity, what does glEnableVertexAttribArray do if glVertexAttribPointer isnt avaliable?
|
|
|
Post by DJLinux on Feb 27, 2012 6:42:42 GMT -5
you can render interleaved arrays with the OpenGL plugin. Take a look to short test in "interleaved.gb"
Joshy
gl_c4f_n3f_v3f gl_c4ub_v2f gl_c4ub_v3f gl_n3f_v3f gl_t2f_c3f_v3f gl_t2f_c4f_n3f_v3f gl_t2f_c4ub_v3f gl_t2f_n3f_v3f gl_t2f_v3f gl_t4f_c4f_n3f_v4f gl_t4f_v4f
|
|
|
Post by shadow008 on Feb 28, 2012 15:01:39 GMT -5
Hmmm....
From what I've picked up doing some research on it, it seems as though glInterleavedArrays organizes arrays like so (omitting the parts that dont concern me):
Lets use an example like gl_t2f_n3f_v3f
-There is an aggregate array of arbitrary values of tex coords/normals/verticies in an array like (...T1,T2,N1,N2,N3,V1,V2,V3...) <-- Which specifies a single vertex. -Index arrays are still standard. Offset is counted in the constant t2f_n3f_v3f - has an offset of 2+3+3=8 So index value of 0 will give the first 8 values in the aggregate array of values, an index value of 3 will give the values from 3*8(-1)=23 -to- 3*8(-1)+8=31 -The predefined constants from glInterleavedArrays (gl_c4f_n3f_v3f,gl_c4ub_v2f,gl_c4ub_v3f,ect) only define what each INDEX defines... This is where I have problems.
I have separate arrays for tex coords, normals, verticies, ect. But I have my INDICIES as the aggregate array. Sort of like so:
Verticies(#,#,#,....) Normals(#,#,#,....) TexCoords(#,#,....) Indicies(VertIndex,NormalsIndex,TexCoordIndex, repeat,....)
Where each index value refers to the value +offset in the respected array RATHER THAN One index refering to the value of ALL the arrays.
So the traditional way would be to do something like: Index value of like.... 3 would mean to use: Index(3...) Vertex(3*offset -to- 3*offset*3+3) Normal(3*offset -to- 3*offset*3+3) TexCoord(3*offset -to- 3*offset*2+2)
What I need is: Index(3,12,1) Vertex(3*offset -to- 3*offset*3+3) Normal(12*offset -to- 12*offset*3+3) TexCoord(1*offset -to- 1*offset*2+2)
If I have the wrong idea here by all means, please correct me. But I dont see any traditional way of doing what I want.
ON TOP OF THAT! I want to be able to pass bone weights and bone indicies to the shader, which I SUPPOSE I could fake by passing them through the color pointer in an array like (BoneIndex1,BoneIndex2,BoneWeight1,BoneWeight2) and just changing that in the shader.
I... I dunno :\
|
|
|
Post by DJLinux on Feb 29, 2012 15:20:39 GMT -5
If you read your colada file it's up to you how you will use interleaved arrays.
By the way pre compiled OpenGL lists are faster then VBO's or any kind of interleaved arrays. VBO's and arrays are in the memory of your application (CPU memory) but compiled OpenGL lists are in GPU memory.
glMatrixMul(position_rotation_scale_matrix):glCall(list) 16*4 + 1*4 = 20 bytes transferred from PC memory to the GPU memory.
Interleaved array or VBO's makes only sense if you need to animate individual vertices's. An ocean of heavy waves are an good example.
For skeleton animations (bones and joints) i would use OpenGL lists.
And yes you can use all OpenGL primitives for faked missing params in your shader code.
Joshy
|
|
|
Post by Darkjester on Mar 1, 2012 15:46:18 GMT -5
By the way pre compiled OpenGL lists are faster then VBO's or any kind of interleaved arrays. VBO's and arrays are in the memory of your application (CPU memory) but compiled OpenGL lists are in GPU memory. This is not entirely accurate, both use gpu memory to store geometry information just thought i would clear that up  , as for the animation using display lists, are you saying that each bone is a seperate display list? i realize this is faster, but visually wouldnt it be worse since all the vertices arent contiguous? -darkjester
|
|
|
Post by shadow008 on Mar 1, 2012 20:36:52 GMT -5
Darkjester:
No, each bone is NOT a separate display list. I intend to utilize skeletal animation the way it's normally done, where I have a mesh w/ bone weights and a separate skeleton made up of bones which in turn are made up of matrices. And then translate each vertex according to the bones that influence it. This plugin allows for vertex attributes via glvertexattrib(1/2/3/4)f So i can easily upload bone index's and weights no problem per vertex in my display list. And since bone weights and bone index's stay constant per vertex, this is the easy part. THE biggest problem I can think of right now is... how am I supposed to upload the bone matrices? Say i have 10 bones. Each one has its own matrix, and I have no idea how to upload an array of matrices to the shader. I'd prefer to do animation on the GPU using the vertex shader, but with no means of uploading the matrices...
DJLinux, is there any reason you omitted glUniformMatrix4fv() and similar functions when making this plugin? Is it just too resource expensive to be worth the time using? Or did it just not seem necessary?...
|
|
|
Post by DJLinux on Mar 2, 2012 6:00:40 GMT -5
download the plugin i added: glVertexAttrib4fv() and glUniformMatrix4fv() for you. Joshy 'void glUniformMatrix4fv(GLint location, GLsizei count, GLboolean transpose, const GLfloat * value); DPF(glUniformMatrix4fv) dim as integer count = GIP(3) if count<1 then return dim as single ptr p=allocate(sizeof(single)*16*Count) GFA2D(1,p,count*4,4) gInterface.glUniformMatrix4fv(GIP(4),count,GIP(2),p) deallocate p end sub
' void glVertexAttrib4fv(GLuint index, const GLfloat * v); DPF(glVertexAttrib4fv) dim as single ptr p=allocate(sizeof(single)*4) GFA(1,p,4):gInterface.glVertexAttrib4fv(GIP(2),p) deallocate p end sub
|
|
|
Post by shadow008 on Mar 2, 2012 21:39:37 GMT -5
Hey DJLinux, there are 2 counts of "glVertexAttrib4f" and no "glVertexAttrib4fv"
Thought I'd just leave that here...
|
|