I don’t know about HeroForge, but most 3D print bureaus like shapeways have some sort of 3D design features, limited as they may be. But for print bureaus, it often makes more sense to do the actual design on the back end, or else they end up as provides of free 3D editors, which makes no business sense. Lack of asset protection is another reason why client side 3D is of limited appeal to content creators.
1 Like
Yes, apart from the lack of advanced tools (e.g. game engines) it’s also a performance issue. JavaScript is very fast for a script language but it will never be as fast than optimized C++. Many important concepts for high performance programming like SIMD or Share Memory Programming are missing in JavaScript. SharedArrayBuffers is a first step to enable SMP but the entire concept is limited and not comparable to real SMP (at least from my point of view). Besides, using web workers introduces a higher thread management and communication overhead than with low-level threads (e.g. pthreads). And finally the platform independent WebGL API produces a higher overhead than native 3D APIs.
WebAssembly might improve the situation. But I think the entire WebAssembly approach is by far less accessible than JavaScript development. Having SIMD features in JavaScript and better SMP programming paradigms would be great step to improve the web platform for developing sophisticated, performance critical apps.
1 Like
I wouldn’t underestimate JavaScript, all modern engines with V8 leading the way are highly optimized and compile to machine code which gets optimized further with crankshaft. “Scripting language” rather gives the impression of slow Interpreters. There has been a lot bechmarks where JS still beats WASM, and i experienced it myself when i ported a dual contouring system to it what’s basically a perfect case for WASM, since it only get’s useful at heavy tasks.
Changing how a system is designed to make it more efficient for JS opens up much more than one would expect from it. It should be also mentioned that apps packed into containers with WebKit can get closer to native performance and generally enjoy more RAM and CPU than being in a full browser, besides having more access. The security issues are more than often limiting and make the progress for more features of JS or WebGL slow.
1 Like
In any event, JavaScript is a script language even if under the hood JIT compilers generate bytecode. The core of a game engine written in optimized C/C++ will definitely be a lot faster than any JavaScript code. Especially if the code runs on specific hardware like consoles which allows platform specific optimizations.
I have only referenced to WASM since the core of a web based 3D or game engine might be implemented with this technology at some point in order to get closer to native performance. For example WASM enables the usage of SIMD.
1 Like