Hi there! This is not trying to be a three.js replacement, scenes with huge polygon counts naturally should render in canvas.
For me, the interesting case is smaller low-poly or voxel scenes where loading a full 3D stack may be overkill, and where keeping the scene in DOM/CSS gives you easier integration with normal layout, styling, events, etc. Once you have the HTML, you don't even need to load the library to render a static model.
Also, part of the experiment is testing the browser’s limits and getting a clearer sense of where this approach works, where it breaks down, and what the tradeoffs are.
ha, so you could run this on the server and send down a page with no javascript at all? (with, i assume, a static camera only.) that's fun. i mean, you could also just render the model to an image at that point, but still, this is neat.
You can have a dynamic camera with 3D CSS only and no JS. The trick is move the scene instead of the "camera". CSS Doom uses this technique (although unlike the project I'm working on, it relies heavily on JS for the interaction logic).
I'm all for experimentation but getting rid of JS in this case almost certainly results in worse performance. You're trading a bit of load time for significantly slower runtime/rendering.
Huh.... why would a CSS animation of a transform be slower than JS? This is strictly for the "CSS transform" case ofc - obviously pure webgl would be way faster.
I'm having a hard time seeing it. My experiments with CSS animation have always performed much better in CSS than JS (again, excluding it being pure webgl/canvas JS).
And ofc there's the nice bonus that it works if I haven't chosen to trust and whitelist their website for JS yet.
Oh. Sure, that is pretty obvious. A triangle in webgl is so much more lightweight than building it out of DOM elements but this was more about "if one is going to use this CSS system, why not support a pure CSS viewing mode" - which right now, it does not - rotation requires JS and is pretty stuttery. I was thinking it should actually be a bit smoother if there was a "toggle on/off rotation using a CSS animation" option. Plus, something like that could easily be done in pure CSS if JS was disabled, which would make the output all the more accessible and offer a good usecase.
It could also be helpful in scenarios where JS is restricted - emails? iframes? bulleting board user content? Dunno. Trying to come up with some that aren't just "nemo was running umatrix and doesn't trust your site just yet"
well, people do in fact still do that. or APNG or WEBP.
But, all I was focused on was the initial comment was on if you were going to use this particular tool, it'd be nice if it had a pure CSS rotate mode, which makes a fair amount of sense given "working without JS" is probably one of the few significant use cases anyway (unless, you reeeeeally need your model to be tightly integrated into the DOM for some reason).
So, saying that CSS would be worse than JS as a feature for this project did not really make sense. We weren't talking about "should the project even exist"
(I feel it should and it's awesome ;) )
Thank you for the insight! I think rotating the tile images is key. Since I’m using CSS Grid for positioning, there are some limitations around overlap like the one you mentioned, but it should be solvable. I’ll keep working on it to bring it closer to the standard behavior.
Two games in a row now I have gotten to a point where the last two pieces are ontop of eachother. I think this is perfectly fine, but seems to happen a little too often. Or I was just very unlucky.
Definitely! I'm planning for more landscape features for next versions. I think rivers will be a great addition, and waterfalls/rapids sound really interesting too. In the end it's a matter of adding a few classes and designing some sprites.
For me, the interesting case is smaller low-poly or voxel scenes where loading a full 3D stack may be overkill, and where keeping the scene in DOM/CSS gives you easier integration with normal layout, styling, events, etc. Once you have the HTML, you don't even need to load the library to render a static model.
Also, part of the experiment is testing the browser’s limits and getting a clearer sense of where this approach works, where it breaks down, and what the tradeoffs are.
Cheers!
reply