How do I manage a WebGL array buffer, and how hard is it to convert to clipspace without using three.js?
Why the hell would you not want to use an abstraction library like three.js?
unless you're doing a tech demo there's no point.
manipulating vertex buffers etc is a massive pain in the ass unless you know exactly what you're doing.
>>55535354
What I want to do requires very precise control over geometry.
>inb4 thread derails into "wah don't do this it's hard"
>>55535029
What am I looking at here?
It looks lewd
>>55535402
In what aspect do you want control over geometry? like custom z buffers or something? or you want to do something like model a solar system using doubles instead of floats?
If possible, you'd be better off hacking in a solution and using an library. There's other libraries rather than three.js
>>55535457
I'd need level-of-depth for custom objects.
Is a Z-buffer a third dimension of clipspace, and can three.js or WebGL handle it well when a model overlaps itself?
>>55535541
Sorry, but i've only fucked around with some basic demos using three.js
does this look like it could suit what you want?
http://threejs.org/examples/webgl_camera_logarithmicdepthbuffer.html
>>55535628
Not at all what I'm talking about.
What I'm talking about can be explained with this zig-zag:
As can be seen, even if it takes up a small screen space, when viewed from such an angle that it fits within the screen at least half the faces are visible even if they are 90% obscured.
What I'm concerned about is that even if entirely hidden faces don't take a toll on the GPU (I don't know if they do or not), will forms such as these be able to put massive tolls on the GPU?
>>55535839
If you're worried about clipping, I wouldn't even think about it. So much of that is done in the pipeline you're always better to go with well defined software stacks. if there's a gain to be made, someone way smarter would have tackled it already.
>>55535839
No, fragments that fail the depth test are not put through the pipeline, in other words, your fragment shader is not run for that pixel.
>>55535839
Or maybe you mean the whole face rather than the fragments? as in will your vertex shader run for those faces if 100% obscured?
I don't know, I think that is called occlusion culling, you may want to look into that.
>>55536041
Z-culling it seems, although occlusion culling might also be a name.
WebGL probably handles it natively already though, I don't think I'd even need three.js for it.
>>55536063
No I'm pretty sure occlusion culling and z-culling (more known as z-buffering or depth buffering) are two different things.
depth buffering prevents fragments from being rendered over other fragments when they are not actually in front of them.
Occlusion culling is where the whole vertex is not put through the pipeline (i.e. not rendered at all) if it's 100% obscured.
>>55536063
And yes, open/webgl handles depth buffering for you, as long as you enable it and clear it every frame.
>>55536086
And it seems that the term for not rendering fragments that are behind the depth buffer is "early z culling".
>>55536096
Depth buffering yes, but what about z-culling?
>>55536135
>but what about z-culling?
z-culling is a result of depth buffering, so yes.
>>55536155
It uses depth buffering, but are you sure it's necessarily a result?
Like, if I enable depth buffering, does that automatically activate early z culling too?
Also, I'm having a hard time telling if early z culling guarantees that pixels will only be rendered once per frame, all the explanations are pretty hand-wavey.
>>55536173
As far as I know, in OpenGL core profile 3.3, depth buffering prevents a fragment from being *rendered* (not just not shown, but not rendered at all) if it fails the depth test.
I'm pretty sure that is z-culling.
I've never used webgl, but I assume it is the same story there.
You will need to look it up yourself.
>>55536203
That's good, because I want to use me some performance-costly as fuck fragment shaders.
Can you use more than one fragment shader in a program by the way?
Once I'm actually somewhat competent with WebGL I'll probably test to see if putting lots of things in front of each other gives me decent or terrible performance, by the way.
>>55536236
>Can you use more than one fragment shader in a program by the way?
I'm kind of new to OpenGL too, so take whatever I say with a grain of salt, but no, I don't think you can.
You need to have multiple shader programs and call glUseProgram to switch to a shader program when rendering an object that uses it.
This obviously has some overhead, so it might be a good idea to order your objects by shader program, so you don't have do nearly as much shader program switches per frame.
>>55536275
How would it compare in efficiency to just merging all your fragment shaders into one and having a variable passed by the vertex shader determine which function in the fragment shader is called?
Wish I knew how the compiler optimised now actually, because if it's a very efficient compiler then I might be able to do something like list 100 materials in a fragment shader and then materials that are at 0% prevalence will not be factored in for the sake of efficiency.
>>55536338
I'm not sure how efficient that is, I did do that once, I was told not to and that the GPU is not good at branching.
