Global Illumination in WebGL
playcanv.as
playcanv.as
I first came across it working on a project where I needed to load and animate a number of complex .fbx character models. Spent loads of time trying to do this with three.js (in 2017) + all manner of converters to different formats. I tried every supported loader and they were all broken in various ways.
Then somehow I found playcanvas and had the models loaded and working flawlessly in a very short period of time. That experience extended to basically everything else I tried with the system—it's well polished.
The editor UI is very nice, and yet remains lightweight in a way where I still feel more like I'm working with something like three.js than e.g. Unity. I personally still prefer three.js for most projects I work on, but it would be a very good option for certain projects and I always keep it in mind. It's also open source: https://github.com/playcanvas
The downside is for the free tier you get their logo on your app, and you can't hide the source (and anyone can fork your project). On the up-side, the pricing was something like $15/month last time I checked.
For a very simple example, here's an asteroids game I spent a few days making with it: https://playcanvas.com/project/479850/overview/rocks (you can play or jump into the editor and modify from that link.)
But the analogy also falls apart in certain significant ways, e.g. PlayCanvas being open source and not actually tied to their servers or editor or anything (but don't get me wrong, it's not as easy to add into a standard project structure as `npm i three` either).
> but the cost and freedom of Three attracts lots of developers
There's definitely some truth to that, but I'd bet it's a very small fraction of three.js users who are even aware of PlayCanvas' existence, and that that lack of knowledge probably affects adoption ratios significantly.
I actually did another version 15 years ago, too—incidentally it was my first ever OpenGL app "JAVAsteroids": http://symbolflux.com/statichtml/oldprojects/javasteroids.ht...
Probably the true pioneer in the genre, although not 100% sure.
"Illumination technique used here is:
Realtime direct shadowmapping with time blended lighmaps for global illumination on: walls, ceiling and floor.
For furniture we use spherical harmonics L2 with spatial and time blending for ambient light.
Reflections made with time blended box projected cubemaps for image based lighting on physically based materials.
Post processing done with color grading by LUT (lookup tables) and vignette."
[1] https://redka.games [2] https://developer.playcanvas.com/en/user-manual/designer/
I'm very interested in moving video editing tools to the cloud where the heavy rendering can be offloaded and the browser can do lightweight work and scaled down approximations.
As a side effect you'd be able to use such an editor on Linux, which while not a central motivator, is compelling.
None of existing WebGL engines offers real GI.
edit: plus unity is basically free to use
edit: PlayCanvas has a free tier.
This is an especially pointless complaint when it comes to video games, because, from a purely economic standpoint, few programmers capable of writing production-quality global illumination should be working on games at all as opposed to getting a job doing something else. (This is a hard pill to swallow, but it is nevertheless true.) The market, especially the indie market, is oversaturated, and, as a result, most people who are highly skilled and involved in game development are, to varying degrees, in it for fun as opposed to money. Since game developers are doing it for fun, why not encourage them to do what they enjoy most?
Save yourself the pain and use Unity instead if your goal is to ship something.
This is especially important to keep in mind when it comes to smaller (be it indie or "AA") developers - the developers who write their own engines aren't trying to replace Unreal, these engines only support a tiny tiny fraction of the functionality that Unreal does and that is fine because that functionality is what these developers need. If anything, for a smaller developer that does not have the necessary developer manpower to mold an existing gargantuan engine like Unreal to their needs it can be a better choice to go with their own engine than try to understand and modify Unreal.
Writing your own engine is never your most important problem as an indie developer nowadays. It's not important at all.
If you have lost sight of that, then you've already failed.
My comment was about responses that compare custom engines with middleware engines-as-products like Unreal and Unity that imply that a custom engine has to provide at least as much as unreal and unity which is certainly not the case.
And my comment wasn't even about indies, this is the case with non-indie studios too - even AAA ones. In fact the previous AAA game i worked at used a custom engine that had zero networking support (outside of some debugging stuff) - because the games that the studio built were single player titles and thus they didn't need such a feature. This is something that an engine-as-a-product like Unreal or Unity cannot do, they have to care about multi player support even if many of the games they'll be used for are single player only, because some of their customers will also need to create multi player games.
It’s comes about because there are lots of people who say they want to make a game who are far more happy eternally twiddling their tech. Moving to Unity/Unreal/PlayCanvas etc. wouldn’t dampen that impulse just push it in different directions. It’s a bit of an empty page problem where it much easier to obsess about having the right starting conditions than it is to actually just start. Particularly as these people tend towards being more technically capable without a lot of design experience.
On the other hand Kerbal Space program is implemented in Unity, so maybe even off the shelf engines can handle that.
Every tool, engine, framework, has its strong and weak sides. That is why we have many options to choose from.
And it's engine is way too monolithic indeed. WASM still feels like a big hack.
Epic recently admitted that experiments with WebGL and Unreal were fun, but they are not misleading customers that it is path they are going to go. They clearly stated that WebGL target for AAA engines, is not a way. And they are very right. Unity doesn't admit that. They know how big is Web platform. But they have to do something major to really get into web, as currently they only mislead customers with promise. But commercially, Unity WebGL - is not an option, 98% of time.
I think the limitation here is the number of lights. They use shadowmaps for direct shadows. You can update shadowmaps interactively for a couple of light sources, but if you have dozens of lights, as is often the case with architectural scenes, shadow maps updating can become a bottleneck.
Hardware manufacturers should focus on things that really matter which is texture resolution and geometric detail.
As for texture resolution and geometric detail... improvements there are great as well. It's not a "one or the other" choice.
Not that any of this matters with regard to Playcanvas because there's no way to access the RTX's ray-tracing pipeline from WebGL.
https://vfxblog.com/2017/08/23/the-tech-of-terminator-2-an-o...
Clever hacks are not a replacement for the real deal.