If not, is it planned?
The idea is to skip new WebGPURenderer, new Scene, new Mesh, etc, and use only TSL for scene description and rendering; everything abstracted behind TSL nodes.
I’m thinking this would make it possible/easier for community to provide alternate backends to have entire TSL scenes render with Playcanvas, Babylon, etc.
I’m not sure that would be a good idea. I understand the intention, but TSL is becoming everything language then, and less “shading” language.
I’m a believer in DSLs ( domain-specific languages ), that is - a language made for a specific purpose can be excellent and precise, but the more general you go, the more compromises you have to make along the way, and more complexity you end up dragging in.
It’s an interesting idea though, composing an entire application out of nodes, reaching all the way through to shading.
As for portability, unless you language is quite low level and has very few base constructs, it will be very hard to make portable. There are, for example, many file formats that don’t work anywhere but one specific piece of software. The reason is - that format was made for that software, and even if you have a very similar other piece of software with same goals in mind - it will not fit, either at all, or mostly.
Some formats are made portable from ground up, such as GLTF, for example. But they have to make compromises, and even then, certain biases show through.
If you wanted to have a language that takes advantage of everything three.js has to offer, and everything three.js is good at, AND do it in a way that three.js is optimized for - it would be a language that fits other engines poorly, I believe
If you don’t like it don’t use it, but please don’t derail the thread on the first post? I like TSL, I don’t consider TSL harmful but helpful.
This is a neat idea, and it’s the first time I’ve heard it mentioned around here. Theoretically it seems like it’s totally doable. I’ve never heard any of the three.js maintainers mention it though so it’s probably not planned.
Maybe TSL needs to become its own project separate from three.js entirely!
Sorry, I’ll be more precise.
To elaborate on the first point, TSL (used to, at least) stand for “Three.js Shading Language”. Then, if we use TSL for doing things other than shading - the scope is re-defined.
Hope that’s more clear, never intended to detail anything.
My point, that might have been seen as “detailment” is that if you like that idea - it might be more productive to push for something new from ground up, or a substantial re-design of TSL, like TDL (Three.js Description Language) or TSL 2.0 or some such. But it’s an interesting idea, like I said, I’d love to see it happen.
Pardon my ignorance, but what is the ask here? Isn’t the scenegraph already very similar? We want a dag instead of a tree?
You’re glazing past entertaining how the idea could even be possible, by limiting yourself to the current limitations, and to facts that are inconsequential such as naming. Just because it has “Shading” in the acronym doesn’t mean it is technically set in stone forever. And TSL supports plain JS nodes, so its naming is already bypassed by what it can already do today. Probably just a few tweaks and it could be super generic.
Anyway, I am spending too much time battling how to not achieve something by replying to comments that are so opposed to TSL. Why bother? Aren’t there more interesting activities to spend time on like writing plain WebGPU?
I know you make really cool stuff, so don’t waste your time battling this idea, go make even more cool stuff. Time is ticking.
At this point I could just copy TSL in a weekend with AI then make TSL do whatever I want. So it’s just a matter of when I actually want it enough, if ever, and it may even be easier when AIs get even better and cheaper.
So, I’ll just be back if I ever do it, if I find out that someone else did it, or if I find something outside of Three.js that achieves it just to share it.
I can understand the frustration, but in any project the scope is important. Three.js, for example, is a graphics library, it’s not a graphic “engine”, and it’s not a physics library.
I’m hoping to help by pointing out dangers from the start, I could say how I envision the future for TSL in the direction you describe, but I don’t see honestly a good future within what TSL is currently, that’s both a bias and prior experience on my part. I am aware of that, and for the sake of keeping things balanced I abstain.
I appreciate it. It’s actually related, for me. Three.js has been moving more and more in the direction of enabling ideas, proving a fast path, and I think your idea with describing entire scenes, or even experiences with just nodes is a very elegant and natural continuation of that general philosophy
And I would personally encourage you to do it. I love programming languages and graphs in particular, if nothing else - the journey will be a fun adventure, I belive.
I would advise looking at existing node-based “everything” languages too, as there’s a lot to be learned from those broad shoulders of giants past.
A humble reminder that names also have historical value. Just one example: initially shaders were used only for shading. Nowadays they do much more, but the name shader got coined.