You guys know WebGL? #54
Replies: 3 comments 6 replies
-
|
Also, for now, can we activate the Wiki for this project? I want to start documenting stuff to make it easier to understand what the files do, and how you can, for example, create and edit a new tool, what the parameters do, etc. |
Beta Was this translation helpful? Give feedback.
-
|
lmao this one's gonna be hard to not convert my self-depreciation into outright self-flagellation simple answers first: wiki activated and depressingly empty, i was actually thinking that'd probably be a better spot for all my constant vanity readme updates anyway :D i've got extremely surface level understanding of graphics pipelines, i've dabbled in godot/blender/unity/zgameeditor/game maker studio/etc and actually wrote (read as: took an existing shader and completely violated every part of it to do something new and horrible) a few GLSL shaders for minecraft years ago, but as you've probably surmised, nope, never touched webGL but wow the last few days i've quite literally been face-desking over canvas and globalcompositeoperation
so my initial gut reaction is "god yes please anything that makes pixel level things faster and easier" lol that being said, i have no idea if it WILL make my stupid machinations faster or easier at all because of all the previously mentioned dumb dumb, but i gotta level with you - this repo has already demolished any expectations i had for it, like i was pretty happy with it fairly close to initial release and then you lovely kind generous brilliant attractive folks started submitting pull requests and this is something i can comfortably call a webapp now <3 i vote +1 YES WEBGL because at the very least i can at least learn from those who know more than i do :) |
Beta Was this translation helpful? Give feedback.
-
|
No worries. Everyone has to start somewhere. It is already pretty cool that you started this project and tackled this pretty big challenge to learn more about JavaScript/canvas! And don't worry, we won't be using, at least for now, anything complex in WebGL; just a basic color shader, 2D textures, and simple 2D square shapes floating in the 3D void. We will even use orthogonal projection, no weird camera FOV shenanigans. But pixel level things will actually still be using canvas because there is no easier way to actually do that. WebGL will be mostly a thing to display to the user and optimize the user interface for an infinity canvas, such as cursors and maybe another random thing. So, no help with that!No worries. Everyone has to start somewhere. It is already pretty cool that you started this project and tackled this pretty big challenge to learn more about JavaScript/canvas! And don't worry, we won't be using, at least for now, anything complex in WebGL; just a basic color shader, 2D textures, and simple 2D square shapes floating in the 3D void. We will even use orthogonal projection, no weird camera FOV shenanigans. But pixel level things will actually still be using canvas because there is no easier way to actually do that. WebGL will be mostly a thing to display to the user and optimize the user interface for an infinity canvas, such as cursors and maybe another random thing. So, no help with that! |
Beta Was this translation helpful? Give feedback.
-
|
Do we really need infinite canvas at all? For most of our needs, I think we can do well with our usual 2d canvas, no? |
Beta Was this translation helpful? Give feedback.
-
|
That is actually a good point. I have three different local branches each using a different strategy. The one I think would be simpler understand without impacting performance much is one that uses canvas elements stacked on each other with absolute positioning (granted, smaller than the current ones.) I can push this branch for testing if you find it reasonable. I just though this approach seemed kind of hacky originally, but now I'm warming up to it. |
Beta Was this translation helpful? Give feedback.
-
|
My attempts so far for WebGL use are working... but I think they are introducing quite a lot of complexity to the equation. And polishing the implementation would require quite some effort. |
Beta Was this translation helpful? Give feedback.
-
|
I'm only really planning on using webgl if there is a way to make it pratically seamless with the current implementation. For now I'm trying to use the dark arts of javascript proxies, and I may get somewhere with that. |
Beta Was this translation helpful? Give feedback.
-
|
From what I understand stacking canvases is a very valid way of doing things, not a hack. It makes so many things very simple. |
Beta Was this translation helpful? Give feedback.
-
|
Well, it seems it was a quite okay way of doing things. Just had to avoid modifying DOM properties and instead used CSS transforms: #60 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
So, I was thinking of some ways to proceed with the infinite canvas stuff, and I concluded that WebGL would be the most effective, performative and non-hacky way to do this.
The thing is, I don't know if it would be reasonable to make such a drastic change; You were clear that this is your first canvas project, and I'm not certain how familiar you all are with rendering pipelines (shaders and stuff, though we will be using a very limited subset of these). I want you all to be able to contribute to the development of this too, after all.
This would probably be done in three phases:
First phase - Basically nothing would change. We would still use all the current canvases normally, and they would be rendered to a WebGL texture and drawn on an [over overlay] canvas. While not much happened in the background, we would now have access to some cool WebGL features, such as easy camera and coordinate transform, allowing us to implement camera zoom and translation already, though still no infinite canvas. Not much of a performance impact is to be expected in this phase.
Second phase - Basic Optimization would be done to some processes. Most cursors are pretty static, and could be easily converted to a texture and just moved around the WebGL world for more efficient rendering. Some (looking at you, marching ants!) would probably still be better rendered on an overlay canvas over the WebGL one, but with some coordinate transformation.
Third phase - We can go nuts. Using textures and WebGL, we can easily make each canvas be of a different size to save space and do infinite canvasing, rotation transforms would be a cakewalk, and other cool things.
If you give me the go-ahead, I'll start working on the first phase of implementation. Shouldn't take too long, but certainly not a two-night job.
Beta Was this translation helpful? Give feedback.
All reactions