I had an idea just now whilst reading through some tutorials with broken examples online. It feels like ‘wasted’ code/work as i’m sure with the correct tweaking these examples and code could be made to work again. Obviously asking people to continuously update their tutorials is unreasonable… BUT…
If you could ‘tag’ a three.js file as learning material. And then from within three.js core code, trigger a noob friendly information screen explaining why they’re seeing a black screen - something like:
This example has been tagged as learning material and did not run correctly.
Why did this happen?
[Insert explanation about revision system and how small syntax changes could break the whole thing]
Old revisions of three.js are using incorrect/dated syntax. Please see [link to relevant update log] to get this code working again.
It took me a little while to get to grips with why this was happening at all. So i just wonder if something as simple as this could just encourage new learners to push through that initial fear of seeing a tutorial with a broken example. The reality is its not that broken, but a black screen says the opposite.
I don’t know enough about three to really make out like my idea is feasible or not. But it seemed like a good idea and a solution to a problem without adding tonnes work? I might be wrong.
I personally think that live examples should not use URLs like https://threejs.org/build/three.module.js, since they automatically target the latest version of three.js. If certain migration tasks are not performed on a new release, things are going to break.
I’ve recently started to use jsdelivery since it allows like other CDNs to lock a specific version. So the following file:
will always point to the R114 release of three.js. This also works for all example files.
I think it’s a bit utopistic to assume all code examples every written are always migrated to the latest version of three.js. Using locked library version avoids breakage and still allows interested devs to migrate code.
I don’t think it’s appropriate to consider such a use case in the core. I would rather advice to notify moderators so broken code is removed or updated.
Yeah i agree. I was definitely not expecting working examples forever. I guess - just some kind of built in ‘documentation/fail safe’ that does nothing but address those initial Three.js confusion points felt like a good idea. But i can also see just using this cdn method does away with the problem in the first place and as it’s not a core function of three and so wouldn’t make sense to put it in core code.
This is how the examples work (also in the download) and you can try to update them to the latest revision yourself.
I just have the problem that a project which was started with revision 100 and then interrupted for about a year because of another project is not running (is black) with the current revision. So I need to see what changes are relevant to the project. It’s a bit of work…
And should I not find a thing, I ask here in this great forum.
Yeah I guess it’s all manageable - my thought was towards complete beginners and that one roadblock right at the start of their journey. And yes yes this forum has saved my bacon .
No I didn’t need one fixing. I genuinely just had the thought of ‘its a shame someone put work into this and it’s non functional’ - I’ll take you up on the offer when I get stuck!!
.