Repository navigation
Let's chat about WebGL #72
Description
Activity
I wouldn't have a problem with Isomer being a simple wrapper for WebGL, simply because I don't understand WebGL all that well, but I have a desire to create things that involve it, haha.
My particular use-case for a project I have in mind is a 3D world that is first or third person (haven't decided). I know Isomer is isometric (duh), so I wouldn't mind that as well. Perhaps those users of Isomer with actually projects in use could contribute better.
I guess I have a unique perspective here, since I'm a huge fan of "as small as possible". My CSS framework, Min, is only 995 bytes (https://github.com/owenversteeg/min)
As such, I love Isomer's current path (of being 9kb) - it fits exactly with my development style.
At the same time, I agree with you that using WebGL would be great since it would allow some features I've been really interested in. I'm torn, really.
For now I'm leaning towards staying with the current path. 1MB of code seems kind of ridiculous to me. Another option might be a WebGL fork - since it seems the codebase would shrink drastically going to Three.js, this may not be difficult to maintain as a separate project from Isomer.
Side note: I'd also be interested to see how switching to WebGL would change the browser support.
Reacted by Jannis and Ian HunterI think the great thing about Isomer is that it is so easy to use. And you can create simple isometric graphics in the browser without understanding anything about what is really going on and it just works.
So in my opinion isn't it better if we keep just the API that simple so everyone can use. And choose there own renderer like webgl / canvas / svg or whatever (Everyone could write their own).
If we go that way we could create multiple bundles or plugins or whatever the implementation will be.
And so we could support multiple browsers and let people switch to webgl if the browsers support that.The only con in this approach that is the higher maintenance to keep everything up to date and can use the new features.
@jbovenschen I like the idea of having them choose their own renderer! @rcmaniac25 had pointed that out in another issue I believe.
My last comment was indeed about this.
It may be a bit more work, but if someone wants to add a feature, they have to add it to all render systems. The end result is everything but the renderer becomes a container for the information, and the renderer does the work.
As mentioned, a WebGL / Canvas / SVG / is just an extra file. Isomer can have a basic WebGL / Canvas one, possibly with WebGL as a separate build so as to not produce the 1 MB min.js that someone might only use Canvas for.
I'd love to see more advanced features in Isomer, like shadows etc, but not at the cost of taking a 1MB dependency. I vote to keep it simple. Follow the Unix philosophy - do one thing, and do it well.
So in my opinion isn't it better if we keep just the API that simple so everyone can use. And choose there own renderer like webgl / canvas / svg or whatever (Everyone could write their own).
I'm in favor of this way, especially for performance reasons. My proposal is to split Isomer into two parts first.
- a minimal renderer only capable of rendering the stuff that Isomer supports (and nothing more)
- a "wrapper", abstracting from the very basic drawing methods of the renderer to shapes, etc
Because of a few additional abstraction levels, the bundle would be a bit larger than now, maybe 15KB to 20KB. But essentially, this is a mandatory step on the path towards WebGL-based rendering.
Telling from my humble experience, I am worried that this step will introduce a lot of abstraction. Whenever I modularized some existing code, I had a subconscious desire to overengineer it. So in case you guys decide to do that, be careful with unnecessary abstraction. (;
Once the codebase is split into rendering and an abstracting wrapper, the are many new exciting possibilities, for example rendering to SVG. Even though this seems very nice, we have to be careful to not end up with a bloated Swiss army knife like Three.js.
If you decide to not create your own WebGL wrapper but use Three.js instead, I'm against it.
If you decide to support WebGL and don't want to write all the GLSL stuff by yourself but Three.js is (way) too heavy, then some other lightweight alternatives might be interesting.
I have just quickly looked through the Readmes, but
kevinroast/phoria.js,tsherif/gl-utils,ttencate/gladderand especiallygreggman/twgl.jsseem to be fitting helper libraries.Reacted by Dominik FrankowiczRegardless of what wrapper is written, it can be replaced. If it starts with Three.js, then that's one. If you want to add a WebGL one, or use one of your mentioned libs, that's two, three, four, etc. A Canvas one should be standard and included by default.
For abstraction, it could be as easy as a small dictionary of
drawingSurface = wrappers['canvas']with a set of specific functions. Or you could go as complex as dynamically choosing methods and initialization of components as needed based on what is done. But again, that's up to the wrapper. You may haveIsomerWebGLWrapperand someone else might haveIsoFast3D. That's the key behind the abstracted wrapper method that I think most have wanted.I think after experimenting with something like a plug and play API. That we need more like a predefined API. What needs to be in the low level API and wich parts need to be loaded through the parts provided by that low level API. So it could be all utilized in all wrappers.
So maybe we need a new issue to define the low level API of isomer? @jdan?
@jbovenschen sounds great!
Depth sorting would be a great feature, as currently, we have to do it ourselves.
WebGL isn't really needed for this though.
I just started using isomer ( but been doing 3d web stuff for a while) , so I am looking at this issue with hopefully fresh impartial eyes.
- The main draw or benefit for me was the size and lack of complexity, minimum effort maximum results !
- The main drawback so far has been the lack of some features.
- I am also a little worried by the lack of active development, is this a necessary library in the age of three.js ? ( I think it could be)
Minimum size, simplicity and a few great choice features would be a decent goal.
As for features; depth sorting, shadows and interaction are on my wish list, additionally from what I have used it, some convenience features (shape.position and maybe a native way of dealing with a full screen canvas like some chart libraries do -chart.js -chartist for instance) would be nice) , in the end from a consumer point of view, I would love to have a simple library from which to make isometric games and data abstractions.
As for architecture, a 10 fold increase : isomer.min around ~ 90kb would still be a tiny library in comparison to three.js.
And finally, and this could be another issue, I think the buy now is hurting more than it is helping the project.
Sorry for the mess at first, Just some trouble with adding a comment on my mobile phone :(.
Personally i still think adding Three.js would make the project to bloated. (To many unused code). Adding little libraries from stack.gl like @jdan earlier mentioned, will just do the hard parts of webgl. And we can still keep the project small. I did started some kind of custom render API, a while ago. If you are interested in this we could possible chat about it. :)
I would love to use this project's API to produce isometric animations in whatever technology. If WebGL is the best for the job, then it should use WebGL... it shouldn't matter in my opinion.
I tried to get going with isometric graphics in WebGL a few times, but it isn't really the most straightforward of APIs. Your API is nice.
I'll make an issue about this - I'd like to hear everyone's thoughts. Don't hold back!
I've spent a few hours on a new
threejsbranch for Isomer, for a number of reasons. Mainly, WebGL does a few things very wellSome downsides?
isomer.min.jsis currently 9KB. With threejs that shoots up to almost a 1MB.There's a certain novelty in having Isomer so small, and translating lots of complicated 3D things into simple 2D canvas operations. I think those are some of the more attractive bits of this library, and by attempting to bring in WebGL I'm going against that.
So what do I actually want to do with Isomer?
I don't know! The original intent was to make cute little pictures, and I think that still holds true. But does the library need to be small to do that?
If we attempt to make Isomer this super powerful thing with an awesome foundation, are we encouraging a different use-case than what we originally intended? Is that okay?
So - I'm perplexed. I want Isomer to be small, but I want it to be correct. That is, I want Isomer to have these great features that come for free with a WebGL backing, but I don't want all the other stuff that I don't need. This isn't an attack at Three.js specifically, but WebGL in general!
In an ideal world? We would be using WebGL without compromising our small code size and speed. Does something like stack.gl make that possible? I remain skeptical.