Model barriers with functions to get rid of the blob of minified geometry code. #9
Conversation
|
I have poked at creating some abstract definition language to generate both the collision and the shader programs, but I've not gotten too far yet. Once I get a glsl optimizer integrated into the build system I might be able to stomach having the shader be automatically generated. |
|
Would be interesting to define set operations on functions that return the distance from an edge. That would give you a way to render perfect borders and to find collisions with missiles with non-zero diameter. With GLSL it might not even perform that atrociously. (Also have changed the license from All Rights Reserved to the AGPL so that you can redistribute any changes you make) |
|
Also missed your first reply. I like it! |
|
One way we could use the same source for both is to modify the collision functions to output signed distance values. This would reduce the complexity of the shaders considerably, so we could possibly afford to do non-aliased rendering even on cheap devices. One concern might be the quality of the visual output though. not sure what kind of resolution the SDF would need. |
|
In any case I can't go with my existing GLSL approach, because there are OpenGL stacks (mostly on ARM SoCs) which just outright crash while compiling my shader, and tend to bring the whole browser down with them(PowerVR SGX on iOS and Adreno 2xx on Android). |
|
I think we are both thinking the same thing with the signed distance fields. No sure what the error is but I think the shader approach is worth persuing if at all possible (even if you have to wait for browsers to catch up). |
|
To clarify, I mean that my particular shaders crash some OpenGL implementations, rather than shaders in general. |
|
Have had an experiment with doing set operations on distance fields. Have a look at: https://www.shadertoy.com/view/MlXSDH ealised that it's actually quite difficult to do corners correctly so I've cheated and used an approximation that gives hard corners rather than rounded ones. I've tried to implement |
|
I think it might be a good idea to prepare the distance field onto a texture ahead of time, and write one shader that samples from the texture. The shader on that shadertoy crashes chrome on my phone, and safari on one of my iOS testing devices. |
|
Another good opportunity I forgot to take with my existing shader approach is antialiasing. |
|
One nice thing about GLSL is we can mix textures in, though I personally prefer the clean look. |
|
Hi - Made any more progress? Was going to dismiss pre-compiling the distance field because of pixelation when you get close to the barriers but it occurs to me that what you would actually get would be a local aproximation of the curve of the same order as the interpolation. Sharp corners will be rounded and you might end up with weird waves but otherwise it could work. |
|
@bwhmather valve has a technique where you polarize the field into two (or I guess technically potentially more) fields, which dramatically improves the fidelity of the test on sharp corners, I'm not sure how they do that though. |
|
I'm poking at the precomputed SDF approach right now, most phones' WebGL stacks don't support floating point texture extensions, so I'm trying to find a good way to compress the distance field into an unsigned fixpoint. Other than that not a lot more progress. |
|
As of xorgy/mg3d@92ba106 I have your sdf functions at parity with my other approach, I'm going to finish modeling the barriers, then make some JSON structure/DSL for defining the distance functions. Then make a javascript-based interpreter for it to do collision. |
|
Excellent. It's silky smooth even on my phone. |
These barriers are fairly elegant, so we don't really need all of that geometry code to model collision.