12 ms·

Show HN: Unity like game editor running in pure WASM

644 points by TrevorSundberg 3y ago

In the wake of all the Unity nonsense, just wanted to toss the Raverie engine into this mix :) We’re building off a previous engine that we worked on for DigiPen Institute of Technology called the Zero Engine with a similar component based design architecture to Unity. Our engine had a unique feature called Spaces: separate worlds/levels that you can instantiate and run at the same time, which became super useful for creating UI overlays using only game objects, running multiple simulations, etc. The lighting and rendering engine is scriptable, and the default deferred rendering implementation is based on the Unreal physically based rendering (PBR) approach. The physics engine was built from the ground up to handle both 2D and 3D physics together. The scripting language was also built in house to be a type safe language that binds to C++ objects and facilitates auto-complete (try it in editor!) This particular fork by Raverie builds both the engine and editor to WebAssembly using only clang without Emscripten. We love Emscripten and in fact borrowed a tiny bit of exception code that we’d love to see up-streamed into LLVM, however we wanted to create a pure WASM binary without Emscripten bindings. We also love WASI too though we already had our own in memory virtual file system, hence we don’t use the WASI imports. All WASM imports and exports needed to run the engine are defined here: https://github.com/raverie-us/raverie-engine/blob/main/Code/Foundation/Platform/PlatformCommunication.hpp https://github.com/raverie-us/raverie-engine/blob/main/Code/... The abstraction means that in the future, porting to other platforms that can support a WASM runtime should be trivial. It’s our dream to be able to export a build of your game to any platform, all from inside the browser. Our near term road-map includes getting the sound engine integrated with WebAudio, getting the script debugger working (currently freezes), porting our networking engine to WebRTC and WebSockets, and getting saving/loading from a database instead of browser local storage. Our end goal is to use this engine to create an online Flash-like hub for games that people can share and remix, akin to Scratch or Tinkercad. https://github.com/raverie-us/raverie-engine https://github.com/raverie-us/raverie-engine

mdaniel 3y ago
heh, I got a kick out of there being a Project > Exit (bound to alt-f4!) which didn't actually exit anything but it thankfully did stop the tab from taking over my machine, so ... win-win?
- TrevorSundberg 3y ago
  Still a lot of hold overs from being a native app :P Good find though!
cgranier 3y ago
Having worked extensively with TDI Explore and Wavefront software on SGI machines, seeing this on my browser still blows my mind.
pineapple_sauce 3y ago
DPI is not correct on MacOS
- TrevorSundberg 3y ago
  Thanks for this info! I had a feeling that we weren't handling DPI scaling correctly, but don't have a Retina screen to test it on.
- TrevorSundberg 3y ago
  Just letting you know we put in a fix for DPI! https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/
Ashwinning 3y ago
Holy wow, opened this on my phone and it was like unity editor was running on mobile with a smooth 3D viewport! Gotta give this a shot on desktop later.
- TrevorSundberg 3y ago
  The mobile version needs a lot of work! But we'd love to support the full editor on phones eventually :P
kaliqt 3y ago
So I take it that this would be the highest performing + most customizable engine for web deployment due to its deep WASM nature? What about rendering, does it use WebGPU?
- meheleventyone 3y ago
  Poking the code it looks like it's based on an OpenGL renderer translating to WebGL2.
- TrevorSundberg 3y ago
  I'm sure there are higher performing engines out there, but it certainly should be easily deployed to any site. For rendering, this engine currently just uses WebGL. It was built on OpenGL originally (with a swappable renderer backend so we could target other 3d APIs). Eventually we may support WebGPU when support grows among the other browsers.
- raytopia 3y ago
  I'd guess Threejs or Babylonjs would be because they're web first but regardless super cool project!
meheleventyone 3y ago
This is super cool, it's great to see a pure WASM offering in this space. It does chug quite a bit on my M1 Mac Pro though!
deleted 3y ago
[deleted]
a2128 3y ago
This looks great! Some feedback - I clicked on the link and tried to find out if it's on GitHub. I looked in Help > About but it didn't seem to have much. Then I clicked on Help > Documentation and it brought me to a 404
- TrevorSundberg 3y ago
  Ah sorry about that, this is still a big work in progress. A lot of the old links have died so we're porting over things like documentation still. I'll add a back-link to the github!
notpushkin 3y ago
Very slow load in Firefox – stuck on “Downloading Runtime”. No error in console, and the .wasm file is stuck in the loading stage in the Network tab – a few minutes first time, 20 seconds now (with cache cleared). No such problems in Chromium. Weird! Overall though it's a cool project. Personally I would prefer if it was a desktop app as well (with better integrations and less overhead – and certainly with hi-res support!). Congrats on the launch!
- GabeIsko 3y ago
  Worked fine for me in Firefox.
  - notpushkin 3y ago
    Probably some very flaky issue then. My current ISP isn't very reliable, although everything else seems to work fine right now.
- TrevorSundberg 3y ago
  I haven’t done a lot of testing with Firefox, I’ll take a look!
sakras 3y ago
Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that played a galaga clone!). This Unity fiasco had me wondering how Zero was doing. Seems like it's going to have a resurgence! Super exciting!
- TrevorSundberg 3y ago
  That's so cool! Zilch was my baby, that makes me so happy :D
  - adamrezich 3y ago
    Zero/Zilch was great, and I wish DigiPen would've stuck with it! I heard that these days, they don't even have students make games from scratch anymore, and everyone just uses Unity or Unreal instead—any idea if that's true? it would be a bummer if it were, because striving to make a cool engine (especially once Zero was there as something to aspire to!) was like the best and most useful part of my time at DigiPen. glad to see the spirit of Zero still going strong through Raverie, though!
    - TrevorSundberg 3y ago
      I heard the same thing and I really hope what they're doing is for the best. It would have fundamentally changed my path if I didn't get that core low level experience of building game engines.
    - DougZwick 3y ago
      I teach GAM 300/350 at DigiPen. We still require them to create custom engines in their sophomore year, but in their junior year (and beyond, in some cases), they're all using commercial engines. One of the main things we want to focus on is giving them a chance to work on a truly cross-discipline team, where every member has a chance to thrive at their work, regardless of their degree program. If you're a student of game design or art, it can be very stressful to be on a team with a custom engine, because the bar is so high for them to provide the features you need to get your work done and accomplish your goals. If the engine and its editor and other support tools are all already completed when the project begins, these stresses and barriers are removed. Meanwhile, the programming students get a chance to work in an existing engine, which is applicable for the career trajectories of so vastly many of them, who will graduate and go on to work for companies that are using an existing engine (possibly even the one they used in GAM class). If they use Unreal, they're often working in C++, interfacing directly with the engine code. These are valuable experiences as well. I have an imperfect perspective of the students' attitudes, but it seems to me that they tend to agree with my point of view: at the beginning of the year, I said, "Raise your hand if you wish you'd be working on a custom engine this year," expecting to see a few dozen hands go up. Surprisingly, only about one and a half hands were raised! Working on a custom game engine is an amazing and unique experience, but it's not the end-all-be-all of game programming.
GabeIsko 3y ago
Very cool! I can't seem to get the script editor open in the demo though.
WatchDog 3y ago
Cool project. Is there any way to scale the UI for high dpi displays? On a 2:1 display, the fonts look aliased, if I set the browser zoom to 50%, the UI looks crisp, but everything is a bit small to be useful.
- iddan 3y ago
  I fail to understand why not use the native browser rendering engine, or at least SVG for the UI. It must be cheaper in resources (memory, network, cpu), easier to make accessible and easier to render
  - jjcm 3y ago
    Anecdotally, in the very early days Figma rendered its UI entirely in canvas, but we eventually switched over to React for the UI. It ended up being far easier for development cycles and for accessibility/integration with existing browser features.
    - solardev 3y ago
      I thought you guys recently rewrote everything to be in WebGL instead?
      - rileyphone 3y ago
        Go inspect the source and see for yourself, the UI is normal HTML.
      - pests 3y ago
        I think their UI is react but the actual drawing canvas is WebGL.
    - TrevorSundberg 3y ago
      I always thought it was so cool Figma just rendered to a canvas! Oddly enough I ran into this at my previous job doing browser isolation when we got a bug report that Figma wasn’t displaying properly in our browser. Makes sense to switch the rest of the UI to react though, just for how many people know it.
kruhft 3y ago
[flagged]
hnreport 3y ago
What’s Digipen’s stature now days?
hoistbypetard 3y ago
It's been sitting on "downloading runtime" for a very long time. That makes me think this must be a challenge to host. What are the pain points to hosting it?
- TrevorSundberg 3y ago
  The runtime is currently about 37MB, and when served with gzip it’s around 11MB compressed. Once it’s downloaded it should be cached and quickly startup. I think a lot of the challenge is going to be spent getting the binary to be smaller, or potentially breaking it up into separate individually loadable parts.
damon_c 3y ago
How do I add WASD controls to the camera?
- TrevorSundberg 3y ago
  That's something you'll have to code up yourself, however to get you started this script checks for pressing the W key and moves forward: https://pastebin.com/8kMTCu3Y https://pastebin.com/8kMTCu3Y
  - damon_c 3y ago
    Hugely helpful, thanks! I really did give it a few minutes and look for docs/examples before asking. I promise!
    - TrevorSundberg 3y ago
      Also hopefully these docs can be of use. They're a bit of a mess as they were never properly ported to GitHub wiki: https://github.com/zeroengineteam/ZeroDocs/blob/master/getting_started.md https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...
TiredGuy 3y ago
The Spaces feature reminds me of how Movie Clips were used in the old days of Macromedia Flash, where I'd put many different often-independently-running clips overlayed on top of each other to encapsulate different behavior. Of course Spaces sounds even more flexible. Very neat. I'm not seeing documentation linked in the readme or within the github project. Are there how-tos and tutorials anywhere?
- TrevorSundberg 3y ago
  Not yet, the port is still a work in progress. For the old Zero docs you can go here: https://github.com/zeroengineteam/ZeroDocs https://github.com/zeroengineteam/ZeroDocs
sansseriff 3y ago
This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?
- TrevorSundberg 3y ago
  It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?
  - sansseriff 3y ago
    Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/ https://akirodic.com/p/jellyfish/ Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive
    - h4zel 3y ago
      Same experience here. I'm able to run other webgl projects fine, including the jellyfish project you linked, but this engine blows up my gpu. Strange
    - Narishma 3y ago
      That's WebGL. This engine seems to use WebGL2.
- a_JIT_pie 3y ago
  I'm getting a really nice smooth experience on my Intel HD Graphics 620 (7th gen intel integrated graphics, old and slow). Also just looking at the default ball scene, and I was really impressed how smooth it was on my system. I'm using chrome.
  - meheleventyone 3y ago
    I suspect this is possibly down to the use of readPixels and how slow that is on various devices. The engine seems to run in a worker and render to an offscreen canvas then transfer the image data in JS to the main thread before drawing it to a canvas there.
darknavi 3y ago
Trevor! I loved your CS elective at DigiPen on designing programming languages with grammars. Many of the students you taught are working on Minecraft now. I'm using so many fundamentals taught by you and my time at DigiPen when designing the Minecraft scripting API today. Glad to see you're still rocking it.
- TrevorSundberg 3y ago
  Awwww I'm so glad it's been helpful! One of these days I'll get back into teaching ;) I'd love to see the scripting interface you're working on too, I spent so much time making Minecraft mods back in the day and I always wanted some kind of dynamic scripting.
- deleted 3y ago
  [deleted]
robotnikman 3y ago
Working great so far on Firefox!
diogenes4 3y ago
Tinkercad and scratch were never tied to a browser! Why go with wasm?
- TrevorSundberg 3y ago
  I’m fairly certain the native version of Scratch is just a browser with Scratch running in a web view. I’d also mention that WASM isn’t tied to a browser either (despite being called WebAssembly, it’s now widely used outside of browsers). You can in fact make native executables now from a WASM binary.
  - diogenes4 3y ago
    That's certainly an innovation. Scratch didn't use to involve browser-play at all.
what-no-tests 3y ago
> Our end goal is to use this engine to create an online Flash-like hub for games that people can share and remix, akin to Scratch or Tinkercad. AMAZING. Hackable games are such a great in-road for new developers, and for anyone who takes an interest in software because of gaming.
- TrevorSundberg 3y ago
  Really want this to be a great learning tool!
ccvannorman 3y ago
This is awesome! What would you say are the primary differences between Raverie and PlayCanvas.com?
- TrevorSundberg 3y ago
  I haven’t tried PlayCanvas yet, but it looks great. I think the primary difference is that this engine is a learning tool primarily, and doesn’t have any intention to compete with bigger name engines.
3836293648 3y ago
Yet another reminder that WebGL is terrible in Firefox. Looking forward to webgpu being standardised and widely used instead.
- levkk 3y ago
  Same experience here, getting really low fps just moving around in an empty scene.
- hutzlibu 3y ago
  The current status seems to be, chrome is also way ahead of firefox with webGPU. They just don't have the manpower anymore, so I would not get my expectations up high and just use chrome for games and co amd be happy if webgpu comes to mobile FF at all. Or petition mozilla into rehiring some engeneers.. And with this concrete project I cannot compare, because on my mobile nothing loads, neither on ff or chrome.
  - Animats 3y ago
    The WGPU people have a new, faster version coming out and Firefox integration is in progress.[1] [1] https://github.com/gfx-rs/wgpu/pull/3626#issuecomment-1734172072 https://github.com/gfx-rs/wgpu/pull/3626#issuecomment-173417...
    - hutzlibu 3y ago
      So there is hope? Sounds good.
- TrevorSundberg 3y ago
  Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/
benkillin 3y ago
Why invent your own scripting language instead of using one of the infinity other existing languages?
- TrevorSundberg 3y ago
  This project was made in 2012 when there weren’t that many languages, especially not ones that bind to C/C++ (and we’re type safe). LUA was the primary embeddable language back then, and C# wasn’t even open source yet :)
pathartl 3y ago
The summer workshops for HS students at DigiPen helped launch me into a programming career :) No experience with Zero, but when I did the workshop in 2008 we used the .NET-based engine. I forget the name of it and the backup I have is in a pile of unlabeled burnt CDs.
- adamrezich 3y ago
  it was ProjectFUN, same name as the summer workshop program—I wish I still had a copy of it, or at least the game I made with it that same summer!
  - pathartl 3y ago
    It's sitting on some old drive somewhere. I'll probably do some digging at some point and put it on archive.org, if only for preservation.
nullifidian 3y ago
Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer? Sometimes I look at https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals and it's very confusing. There are the type imports proposal(years away), the almost complete GC proposal(which is apparently only for GCd languages, but not for anything browser<->wasm), the component model(which looks and sounds as something not for the browser use case), JS String Builtins (which will provide faster JS strings, but not DOM) and ECMAScript module integration (which will turn WASM modules into ES modules, but Web-APIs aren't ES modules so no luck). Sometimes I read contributor interactions and it looks as if providing such functionality isn't their priority or even in their plans, and for the majority the WASI + component model for the cloud, crypto and similar use cases are more important.
- TrevorSundberg 3y ago
  I really yearn for this myself. I would love to see a “pure wasm” browser where the pages are just wasm and the “browser” just provides a bunch of platform imports like WASI. I agree with you though, seems like it’s not a priority for them. One of these days…
- CryZe 3y ago
  Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls. The only real need for JS would be to initialize the wasm module in the first place.
  - nullifidian 3y ago
    >you don't really need any (almost any?) intermediate JS anymore I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.
CobrastanJorji 3y ago
How are Raverie spaces different from Unity scenes?
- TrevorSundberg 3y ago
  To be honest I haven't spent much time in Unity. Back in the day you either had to parent objects to the camera to make UI, or use a completely different UI system. It sounds like now Unity scenes can be overlaid on top of each other, is that correct?
  - Rohansi 3y ago
    Yes, multiple Unity scenes can be loaded at the same time overlaying each other. Physics can optionally be local to a single scene too. You also don't need to parent objects to the camera for UI. Not sure how it used to be in the past.
icemelt8 3y ago
It lags very slow on macbook m1 pro 14 inch chrome
- kruhft 3y ago
  Crashed my machine. I didn't know they could set web workers to realtime priority. Had to reboot. Lame.
- TrevorSundberg 3y ago
  Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/
laserDinosaur 3y ago
This looks amazing, and I really hope it gains some traction. That being said, one of the biggest annoyances I had trying to switch to Godot from Unity is that their Scene view doesn't reflect the Game view at runtime (you can see the hierarchy, but there's no visuals, no gizmos, no debug raycasting or colliders)[1]. It seems this engine has the same missing feature? [1]https://github.com/godotengine/godot-proposals/issues/7213 https://github.com/godotengine/godot-proposals/issues/7213
- TrevorSundberg 3y ago
  If you hit space bar to bring up the command selector and hit Edit In Game, you should get a view that shows you all the debug draw, gizmos, etc. Hopefully this answers what you're referring to.
  - laserDinosaur 3y ago
    oh wow that's perfect! In fact, this does something a little extra I wish Unity could do - because I can play the edit scene and game scene side by side, I can modify experimental properties at runtime, then copy+paste them into the edit scene on the fly (in Unity it's a lot of copy+paste into notepad, stopping the game and hoping you didn't forget anything and pasting back in). Thanks Trevor!
araes 3y ago
I like the concept. My GPU and browser weep with lag. Its a very impressive slideshow. I finally managed to highlight the starting sphere after several tries. At first I wasn't sure if it was loaded. Of course, I'm only using a 1.8 GHz Celeron with onboard GPU and 8GB Ram in Firefox, so... not exactly high-end stuff.
- TrevorSundberg 3y ago
  I'd be curious if it runs any better under Chrome. Seems a lot of people are hitting Firefox issues. I'll be sure to test Firefox regularly though.
  - dartos 3y ago
    AFAIK, Firefox has all around awful webgl and webgpu performance. I know personally, anything 3d in Firefox is a slideshow, even with a 4090
    - ddtaylor 3y ago
      It's running quite well here on Firefox in Fedora 38 with a AMD Radeon 6700 XT.
    - wizzledonker 3y ago
      I have an AMD 6700xt. It was laggy in Windows and under X11 on linux, but under Wayland I get 60-80fps and it's very usable. Not sure what the cause is EDIT: Under Chromium (compiled from AUR) the performance is roughly the same
    - starkparker 3y ago
      In Firefox on a 12th-gen Framework i5-1240P, Fedora 38, integrated graphics at 2256x1504, it works and looks fine for me.
    - aceazzameen 3y ago
      Works fine for me running Firefox in Windows with a 3090. Also already have Unreal open on another screen. So lots of my GPU memory is already being eaten up.
DougZwick 3y ago
Yeah I got a question, will this run on my NES? It's a refurbished front-loader, mostly original parts, but I did add some more RAM (I hot glued it to the top), and also I painted the case red and attached a few army men to it.
- TrevorSundberg 3y ago
  Why does a WASM > NES translator actually sound fun to write...
pcblues 3y ago
This is amazing. I might have missed it, but is there a plan to put the dev issues onto github, or is there another way I can get involved in dev/doc?
- TrevorSundberg 3y ago
  I'll for sure list issues there. I also need to move the docs from here: https://github.com/zeroengineteam/ZeroDocs/blob/master/getting_started.md https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...
jbaber 3y ago
This is amazing. It's working fine with firefox on my old machine with Win10.
two_handfuls 3y ago
I almost skipped this because I thought it was Unity, not a Unity-like editor.
lionkor 3y ago
> Our engine had a unique feature called Spaces: separate worlds/levels that you can instantiate This is, as far as I can tell, exactly what the Godot engine does[1]. That engine also has a browser (wasm) target. [1]: https://godotengine.org/ https://godotengine.org/
- BoorishBears 3y ago
  I don't see how it's different than scenes in Unity either
  - lewispollard 3y ago
    Worlds/Spaces in Godot at least are more to do with physics/lighting than scenes/levels. So two objects in the same scene can occupy different "spaces" (for physics), "scenarios" (for rendering), or "worlds" (which encapsulate a space and scenario, for both physics and rendering). Objects in these different contexts will appear in the same scene but will be separated in terms of those contexts and won't e.g. collide with each other or be affected by forces from one space if in a different space, or be lit by lights from a different scenario.
    - depressedpanda 3y ago
      Interesting. What are the use cases for being able to do this?
      - lewispollard 3y ago
        The main use case is for subviewports - nodes which contain a scene tree but aren't rendered with the main window, instead you grab a texture from the viewport and can display that how you like, as a mesh texture or as a sprite/texture rect, input to a shader, etc (similar to render textures in unity). You can apply a World resource to the subviewport (the default is, I believe, for them to have their own worlds), and that ensures that they are treated entirely separately from the main viewport's children and will only collide with things and be lit by objects in the subviewport. But, that may not be desired - you may want to use a subviewport to render certain objects and then apply post-processing only to those objects, but otherwise treat them like objects in the main scene - in that case you can have the subviewport share the same World as the main viewport, causing objects inside and outside of the subviewport to interact. Similarly, there are often gameplay reasons you may want to separate physics/lighting for particular objects, and maybe even have several "spaces" in which objects can interact that you want to swap out at runtime. Stealth games where shadows are important to the gameplay, or games that have an "inner" and an "outer" in terms of physics (maybe a car in the world, and then objects inside the car in their own inner world that maybe obey slightly different physics parameters, for example).
pjmlp 3y ago
While impressive, the whole UI feels much slower than using PlayCanvas.
exikyut 3y ago
Just to contribute: yet another instance of "cool slideshow" on my (most definitely low end) laptop with integrated graphics. Then tried it on my aging Mate 20 Pro (not too new, not tooo old), and it just seemed to get stuck at "Downloading runtime". Got a funny feeling my flaky 4G wasn't actually to blame, inspected the tab from my laptop (chrome://inspect) via USB, and was greeted with Uncaught (in promise) Error: Needs OES_texture_float_linear to function at M (worker-3ec07b2e.js:1:3338) at J (worker-3ec07b2e.js:1:3403) It is what it is. It's a good philosophical question about whether it's worth coding up an error screen, since it's all just to tell people they can't play with the toy. Hehe.
- murkle 3y ago
  https://github.com/evanw/OES_texture_float_linear-polyfill https://github.com/evanw/OES_texture_float_linear-polyfill
  - TrevorSundberg 3y ago
    Hmm, I think that polyfill might only be for WebGL1 (we use WebGL2). When I go to the WebGL1 report I see that my card supports both: OES_texture_float OES_texture_float_linear But on WebGL2, it only shows OES_texture_float_linear. I think OES_texture_float doesn't exist on WebGL2 I'm guessing.
- xeonmc 3y ago
  How low end is it? I'm using my 8-year-old Surface Pro 4 on Starbucks wifi and it's blazing fast.
webprofusion 3y ago
It errored on first go with a blank screen: Error: Failed to allocate type at x.allocate (worker-3ec07b2e.js:1:3516) at ImportGlGenTexture (worker-3ec07b2e.js:1:7645) at RaverieEditor-60af6467.wasm:0x1d459ee at RaverieEditor-60af6467.wasm:0xedf9e7 at RaverieEditor-60af6467.wasm:0xedf56b at RaverieEditor-60af6467.wasm:0xdffefa at RaverieEditor-60af6467.wasm:0xf213e3 Reloading fixed it, maybe a race condition between setting up the app and it being ready to run.
- TrevorSundberg 3y ago
  Hmm, it looks like our call to `gl.createTexture()` returned null. I'm actually not sure what we'd do in that case other than fail with an error dialog.
DonHopkins 3y ago
Check out what I wrote earlier about how WAForth dynamically generates and links WASM code! By just reading the WASM documentation I didn't realize it was possible to call back into JavaScript to dynamically create and link in WASM code on the fly, but WAForth opened my eyes to that, by compiling each FORTH word definition into a tiny little module and linking them all together. No (practical) limit on the number of modules that you can use in the same WASM app. It would be cool for a game editor app to have a visual programming language that compiles directly to WASM that way, so you can edit code at runtime. https://news.ycombinator.com/item?id=34374057 https://news.ycombinator.com/item?id=34374057
- TrevorSundberg 3y ago
  YES! Absolutely yes to this. Right now the built in language was made well before WASM was even a thing, but at some point in the future I'd like to make it target WASM directly or even potentially use AssemblyScript or something like it. I certainly also want to have the engine support importing WASM modules as plugins, for when you need serious near-native performance rather than a scripting language. Tiny modules also sound awesome. I'll give the article a read, thanks for this!
chaosprint 3y ago
Looks great. and it even works on mobile phone. But it is a little bit slow on my mac Chrome.
rcarmo 3y ago
Seems great, would never use a non-native app to develop games.
deleted 3y ago
[deleted]
stuaxo 3y ago
Tried on a couple of devices with Firefox, the Downloading runtime bit takes ages. On Android firefox on my poor old Nokia Android phone it's way too slow to try, on rotating the UI size hasn't caught up for a few seconds and everything stretches. Edit: I got Failed to create WebGL context: WebGL creation failed: (Feature_Failure_EGL_Create) Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXAUSTED_DRIVERS) TypeError: a is null. The Ubuntu is in qemu but should have 3D support, as others mentioned there should be some error surfacing, not just continuing to show the splash screen forever. On Firefox on Ubuntu, I'm still waiting after a couple of minutes for it to start, so might try again later.
FrustratedMonky 3y ago
Great. Pretty incredible what can be done with WASM.
dom96 3y ago
Performance is definitely an issue here, this is on an M1 MacBook with Chrome and it's quite choppy.
- TrevorSundberg 3y ago
  If you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/
lostgame 3y ago
Strange, on my M2 MacBook Pro this still absolutely crawls. I thought it was my personal (intel) MacBook Pro, but it's still extremely slow on my M2. Looks amazing, but definitely requires a massive performance improvement before it's useful. Keep at it! :) edit: chrome btw
ForOldHack 3y ago
Mess around - Find out. Rule #1 in the industry, #1 is do not anger Linux wizards on a Friday. They will spend ever single waking hour until Monday morning, nuking your business plan, and reverse engineering your product, and make no mistake: These are a large group of some of the most talented programmers on the planet. They have skills, skills which are extremely dangerous to people like you.
billconan 3y ago
The UI looks very polished! I have an old 3D modeler I want to modernize, is it possible to reuse the UI framework? is it imgui based? I don't seem to see a sign of it. is it easy to be separated out? is the rendering backend swappable? (I hope to use webgpu)
- billconan 3y ago
  I found the ui code and looked at the font handling part, it doesn't seem to support complex shaping, the font has to be monospaced I guess with a small set of glyphs

mdaniel 3y ago

heh, I got a kick out of there being a Project > Exit (bound to alt-f4!) which didn't actually exit anything but it thankfully did stop the tab from taking over my machine, so ... win-win?

TrevorSundberg 3y ago
Still a lot of hold overs from being a native app :P Good find though!

cgranier 3y ago

Having worked extensively with TDI Explore and Wavefront software on SGI machines, seeing this on my browser still blows my mind.

pineapple_sauce 3y ago

DPI is not correct on MacOS

TrevorSundberg 3y ago
Thanks for this info! I had a feeling that we weren't handling DPI scaling correctly, but don't have a Retina screen to test it on.
TrevorSundberg 3y ago
Just letting you know we put in a fix for DPI! https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/

Ashwinning 3y ago

Holy wow, opened this on my phone and it was like unity editor was running on mobile with a smooth 3D viewport! Gotta give this a shot on desktop later.

TrevorSundberg 3y ago
The mobile version needs a lot of work! But we'd love to support the full editor on phones eventually :P

kaliqt 3y ago

So I take it that this would be the highest performing + most customizable engine for web deployment due to its deep WASM nature? What about rendering, does it use WebGPU?

meheleventyone 3y ago
Poking the code it looks like it's based on an OpenGL renderer translating to WebGL2.
TrevorSundberg 3y ago
I'm sure there are higher performing engines out there, but it certainly should be easily deployed to any site. For rendering, this engine currently just uses WebGL. It was built on OpenGL originally (with a swappable renderer backend so we could target other 3d APIs). Eventually we may support WebGPU when support grows among the other browsers.
raytopia 3y ago
I'd guess Threejs or Babylonjs would be because they're web first but regardless super cool project!

meheleventyone 3y ago

This is super cool, it's great to see a pure WASM offering in this space. It does chug quite a bit on my M1 Mac Pro though!

deleted 3y ago

[deleted]

a2128 3y ago

This looks great! Some feedback - I clicked on the link and tried to find out if it's on GitHub. I looked in Help > About but it didn't seem to have much. Then I clicked on Help > Documentation and it brought me to a 404

TrevorSundberg 3y ago
Ah sorry about that, this is still a big work in progress. A lot of the old links have died so we're porting over things like documentation still. I'll add a back-link to the github!

notpushkin 3y ago

Very slow load in Firefox – stuck on “Downloading Runtime”. No error in console, and the .wasm file is stuck in the loading stage in the Network tab – a few minutes first time, 20 seconds now (with cache cleared). No such problems in Chromium. Weird! Overall though it's a cool project. Personally I would prefer if it was a desktop app as well (with better integrations and less overhead – and certainly with hi-res support!). Congrats on the launch!

GabeIsko 3y ago
Worked fine for me in Firefox.
- notpushkin 3y ago
  Probably some very flaky issue then. My current ISP isn't very reliable, although everything else seems to work fine right now.
TrevorSundberg 3y ago
I haven’t done a lot of testing with Firefox, I’ll take a look!

sakras 3y ago

Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that played a galaga clone!). This Unity fiasco had me wondering how Zero was doing. Seems like it's going to have a resurgence! Super exciting!

TrevorSundberg 3y ago
That's so cool! Zilch was my baby, that makes me so happy :D
- adamrezich 3y ago
  Zero/Zilch was great, and I wish DigiPen would've stuck with it! I heard that these days, they don't even have students make games from scratch anymore, and everyone just uses Unity or Unreal instead—any idea if that's true? it would be a bummer if it were, because striving to make a cool engine (especially once Zero was there as something to aspire to!) was like the best and most useful part of my time at DigiPen. glad to see the spirit of Zero still going strong through Raverie, though!
  - TrevorSundberg 3y ago
    I heard the same thing and I really hope what they're doing is for the best. It would have fundamentally changed my path if I didn't get that core low level experience of building game engines.
  - DougZwick 3y ago
    I teach GAM 300/350 at DigiPen. We still require them to create custom engines in their sophomore year, but in their junior year (and beyond, in some cases), they're all using commercial engines. One of the main things we want to focus on is giving them a chance to work on a truly cross-discipline team, where every member has a chance to thrive at their work, regardless of their degree program. If you're a student of game design or art, it can be very stressful to be on a team with a custom engine, because the bar is so high for them to provide the features you need to get your work done and accomplish your goals. If the engine and its editor and other support tools are all already completed when the project begins, these stresses and barriers are removed. Meanwhile, the programming students get a chance to work in an existing engine, which is applicable for the career trajectories of so vastly many of them, who will graduate and go on to work for companies that are using an existing engine (possibly even the one they used in GAM class). If they use Unreal, they're often working in C++, interfacing directly with the engine code. These are valuable experiences as well. I have an imperfect perspective of the students' attitudes, but it seems to me that they tend to agree with my point of view: at the beginning of the year, I said, "Raise your hand if you wish you'd be working on a custom engine this year," expecting to see a few dozen hands go up. Surprisingly, only about one and a half hands were raised! Working on a custom game engine is an amazing and unique experience, but it's not the end-all-be-all of game programming.

GabeIsko 3y ago

Very cool! I can't seem to get the script editor open in the demo though.

WatchDog 3y ago

Cool project. Is there any way to scale the UI for high dpi displays? On a 2:1 display, the fonts look aliased, if I set the browser zoom to 50%, the UI looks crisp, but everything is a bit small to be useful.

iddan 3y ago
I fail to understand why not use the native browser rendering engine, or at least SVG for the UI. It must be cheaper in resources (memory, network, cpu), easier to make accessible and easier to render
- jjcm 3y ago
  Anecdotally, in the very early days Figma rendered its UI entirely in canvas, but we eventually switched over to React for the UI. It ended up being far easier for development cycles and for accessibility/integration with existing browser features.
  - solardev 3y ago
    I thought you guys recently rewrote everything to be in WebGL instead?
    - rileyphone 3y ago
      Go inspect the source and see for yourself, the UI is normal HTML.
    - pests 3y ago
      I think their UI is react but the actual drawing canvas is WebGL.
  - TrevorSundberg 3y ago
    I always thought it was so cool Figma just rendered to a canvas! Oddly enough I ran into this at my previous job doing browser isolation when we got a bug report that Figma wasn’t displaying properly in our browser. Makes sense to switch the rest of the UI to react though, just for how many people know it.

kruhft 3y ago

[flagged]

hnreport 3y ago

What’s Digipen’s stature now days?

hoistbypetard 3y ago

It's been sitting on "downloading runtime" for a very long time. That makes me think this must be a challenge to host. What are the pain points to hosting it?

TrevorSundberg 3y ago
The runtime is currently about 37MB, and when served with gzip it’s around 11MB compressed. Once it’s downloaded it should be cached and quickly startup. I think a lot of the challenge is going to be spent getting the binary to be smaller, or potentially breaking it up into separate individually loadable parts.

damon_c 3y ago

How do I add WASD controls to the camera?

TrevorSundberg 3y ago
That's something you'll have to code up yourself, however to get you started this script checks for pressing the W key and moves forward: https://pastebin.com/8kMTCu3Y https://pastebin.com/8kMTCu3Y
- damon_c 3y ago
  Hugely helpful, thanks! I really did give it a few minutes and look for docs/examples before asking. I promise!
  - TrevorSundberg 3y ago
    Also hopefully these docs can be of use. They're a bit of a mess as they were never properly ported to GitHub wiki: https://github.com/zeroengineteam/ZeroDocs/blob/master/getting_started.md https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...

TiredGuy 3y ago

The Spaces feature reminds me of how Movie Clips were used in the old days of Macromedia Flash, where I'd put many different often-independently-running clips overlayed on top of each other to encapsulate different behavior. Of course Spaces sounds even more flexible. Very neat. I'm not seeing documentation linked in the readme or within the github project. Are there how-tos and tutorials anywhere?

TrevorSundberg 3y ago
Not yet, the port is still a work in progress. For the old Zero docs you can go here: https://github.com/zeroengineteam/ZeroDocs https://github.com/zeroengineteam/ZeroDocs

sansseriff 3y ago

This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?

TrevorSundberg 3y ago
It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?
- sansseriff 3y ago
  Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/ https://akirodic.com/p/jellyfish/ Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive
  - h4zel 3y ago
    Same experience here. I'm able to run other webgl projects fine, including the jellyfish project you linked, but this engine blows up my gpu. Strange
  - Narishma 3y ago
    That's WebGL. This engine seems to use WebGL2.
a_JIT_pie 3y ago
I'm getting a really nice smooth experience on my Intel HD Graphics 620 (7th gen intel integrated graphics, old and slow). Also just looking at the default ball scene, and I was really impressed how smooth it was on my system. I'm using chrome.
- meheleventyone 3y ago
  I suspect this is possibly down to the use of readPixels and how slow that is on various devices. The engine seems to run in a worker and render to an offscreen canvas then transfer the image data in JS to the main thread before drawing it to a canvas there.

darknavi 3y ago

Trevor! I loved your CS elective at DigiPen on designing programming languages with grammars. Many of the students you taught are working on Minecraft now. I'm using so many fundamentals taught by you and my time at DigiPen when designing the Minecraft scripting API today. Glad to see you're still rocking it.

TrevorSundberg 3y ago
Awwww I'm so glad it's been helpful! One of these days I'll get back into teaching ;) I'd love to see the scripting interface you're working on too, I spent so much time making Minecraft mods back in the day and I always wanted some kind of dynamic scripting.
deleted 3y ago
[deleted]

robotnikman 3y ago

Working great so far on Firefox!

diogenes4 3y ago

Tinkercad and scratch were never tied to a browser! Why go with wasm?

TrevorSundberg 3y ago
I’m fairly certain the native version of Scratch is just a browser with Scratch running in a web view. I’d also mention that WASM isn’t tied to a browser either (despite being called WebAssembly, it’s now widely used outside of browsers). You can in fact make native executables now from a WASM binary.
- diogenes4 3y ago
  That's certainly an innovation. Scratch didn't use to involve browser-play at all.

what-no-tests 3y ago

> Our end goal is to use this engine to create an online Flash-like hub for games that people can share and remix, akin to Scratch or Tinkercad. AMAZING. Hackable games are such a great in-road for new developers, and for anyone who takes an interest in software because of gaming.

TrevorSundberg 3y ago
Really want this to be a great learning tool!

ccvannorman 3y ago

This is awesome! What would you say are the primary differences between Raverie and PlayCanvas.com?

TrevorSundberg 3y ago
I haven’t tried PlayCanvas yet, but it looks great. I think the primary difference is that this engine is a learning tool primarily, and doesn’t have any intention to compete with bigger name engines.

3836293648 3y ago

Yet another reminder that WebGL is terrible in Firefox. Looking forward to webgpu being standardised and widely used instead.

levkk 3y ago
Same experience here, getting really low fps just moving around in an empty scene.
hutzlibu 3y ago
The current status seems to be, chrome is also way ahead of firefox with webGPU. They just don't have the manpower anymore, so I would not get my expectations up high and just use chrome for games and co amd be happy if webgpu comes to mobile FF at all. Or petition mozilla into rehiring some engeneers.. And with this concrete project I cannot compare, because on my mobile nothing loads, neither on ff or chrome.
- Animats 3y ago
  The WGPU people have a new, faster version coming out and Firefox integration is in progress.[1] [1] https://github.com/gfx-rs/wgpu/pull/3626#issuecomment-1734172072 https://github.com/gfx-rs/wgpu/pull/3626#issuecomment-173417...
  - hutzlibu 3y ago
    So there is hope? Sounds good.
TrevorSundberg 3y ago
Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/

benkillin 3y ago

Why invent your own scripting language instead of using one of the infinity other existing languages?

TrevorSundberg 3y ago
This project was made in 2012 when there weren’t that many languages, especially not ones that bind to C/C++ (and we’re type safe). LUA was the primary embeddable language back then, and C# wasn’t even open source yet :)

pathartl 3y ago

The summer workshops for HS students at DigiPen helped launch me into a programming career :) No experience with Zero, but when I did the workshop in 2008 we used the .NET-based engine. I forget the name of it and the backup I have is in a pile of unlabeled burnt CDs.

adamrezich 3y ago
it was ProjectFUN, same name as the summer workshop program—I wish I still had a copy of it, or at least the game I made with it that same summer!
- pathartl 3y ago
  It's sitting on some old drive somewhere. I'll probably do some digging at some point and put it on archive.org, if only for preservation.

nullifidian 3y ago

Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer? Sometimes I look at https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals and it's very confusing. There are the type imports proposal(years away), the almost complete GC proposal(which is apparently only for GCd languages, but not for anything browser<->wasm), the component model(which looks and sounds as something not for the browser use case), JS String Builtins (which will provide faster JS strings, but not DOM) and ECMAScript module integration (which will turn WASM modules into ES modules, but Web-APIs aren't ES modules so no luck). Sometimes I read contributor interactions and it looks as if providing such functionality isn't their priority or even in their plans, and for the majority the WASI + component model for the cloud, crypto and similar use cases are more important.

TrevorSundberg 3y ago
I really yearn for this myself. I would love to see a “pure wasm” browser where the pages are just wasm and the “browser” just provides a bunch of platform imports like WASI. I agree with you though, seems like it’s not a priority for them. One of these days…
CryZe 3y ago
Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls. The only real need for JS would be to initialize the wasm module in the first place.
- nullifidian 3y ago
  >you don't really need any (almost any?) intermediate JS anymore I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.

CobrastanJorji 3y ago

How are Raverie spaces different from Unity scenes?

TrevorSundberg 3y ago
To be honest I haven't spent much time in Unity. Back in the day you either had to parent objects to the camera to make UI, or use a completely different UI system. It sounds like now Unity scenes can be overlaid on top of each other, is that correct?
- Rohansi 3y ago
  Yes, multiple Unity scenes can be loaded at the same time overlaying each other. Physics can optionally be local to a single scene too. You also don't need to parent objects to the camera for UI. Not sure how it used to be in the past.

icemelt8 3y ago

It lags very slow on macbook m1 pro 14 inch chrome

kruhft 3y ago
Crashed my machine. I didn't know they could set web workers to realtime priority. Had to reboot. Lame.
TrevorSundberg 3y ago
Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/

laserDinosaur 3y ago

This looks amazing, and I really hope it gains some traction. That being said, one of the biggest annoyances I had trying to switch to Godot from Unity is that their Scene view doesn't reflect the Game view at runtime (you can see the hierarchy, but there's no visuals, no gizmos, no debug raycasting or colliders)[1]. It seems this engine has the same missing feature? [1]https://github.com/godotengine/godot-proposals/issues/7213 https://github.com/godotengine/godot-proposals/issues/7213

TrevorSundberg 3y ago
If you hit space bar to bring up the command selector and hit Edit In Game, you should get a view that shows you all the debug draw, gizmos, etc. Hopefully this answers what you're referring to.
- laserDinosaur 3y ago
  oh wow that's perfect! In fact, this does something a little extra I wish Unity could do - because I can play the edit scene and game scene side by side, I can modify experimental properties at runtime, then copy+paste them into the edit scene on the fly (in Unity it's a lot of copy+paste into notepad, stopping the game and hoping you didn't forget anything and pasting back in). Thanks Trevor!

araes 3y ago

I like the concept. My GPU and browser weep with lag. Its a very impressive slideshow. I finally managed to highlight the starting sphere after several tries. At first I wasn't sure if it was loaded. Of course, I'm only using a 1.8 GHz Celeron with onboard GPU and 8GB Ram in Firefox, so... not exactly high-end stuff.

TrevorSundberg 3y ago
I'd be curious if it runs any better under Chrome. Seems a lot of people are hitting Firefox issues. I'll be sure to test Firefox regularly though.
- dartos 3y ago
  AFAIK, Firefox has all around awful webgl and webgpu performance. I know personally, anything 3d in Firefox is a slideshow, even with a 4090
  - ddtaylor 3y ago
    It's running quite well here on Firefox in Fedora 38 with a AMD Radeon 6700 XT.
  - wizzledonker 3y ago
    I have an AMD 6700xt. It was laggy in Windows and under X11 on linux, but under Wayland I get 60-80fps and it's very usable. Not sure what the cause is EDIT: Under Chromium (compiled from AUR) the performance is roughly the same
  - starkparker 3y ago
    In Firefox on a 12th-gen Framework i5-1240P, Fedora 38, integrated graphics at 2256x1504, it works and looks fine for me.
  - aceazzameen 3y ago
    Works fine for me running Firefox in Windows with a 3090. Also already have Unreal open on another screen. So lots of my GPU memory is already being eaten up.

DougZwick 3y ago

Yeah I got a question, will this run on my NES? It's a refurbished front-loader, mostly original parts, but I did add some more RAM (I hot glued it to the top), and also I painted the case red and attached a few army men to it.

TrevorSundberg 3y ago
Why does a WASM > NES translator actually sound fun to write...

pcblues 3y ago

This is amazing. I might have missed it, but is there a plan to put the dev issues onto github, or is there another way I can get involved in dev/doc?

TrevorSundberg 3y ago
I'll for sure list issues there. I also need to move the docs from here: https://github.com/zeroengineteam/ZeroDocs/blob/master/getting_started.md https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...

jbaber 3y ago

This is amazing. It's working fine with firefox on my old machine with Win10.

two_handfuls 3y ago

I almost skipped this because I thought it was Unity, not a Unity-like editor.

lionkor 3y ago

> Our engine had a unique feature called Spaces: separate worlds/levels that you can instantiate This is, as far as I can tell, exactly what the Godot engine does[1]. That engine also has a browser (wasm) target. [1]: https://godotengine.org/ https://godotengine.org/

BoorishBears 3y ago
I don't see how it's different than scenes in Unity either
- lewispollard 3y ago
  Worlds/Spaces in Godot at least are more to do with physics/lighting than scenes/levels. So two objects in the same scene can occupy different "spaces" (for physics), "scenarios" (for rendering), or "worlds" (which encapsulate a space and scenario, for both physics and rendering). Objects in these different contexts will appear in the same scene but will be separated in terms of those contexts and won't e.g. collide with each other or be affected by forces from one space if in a different space, or be lit by lights from a different scenario.
  - depressedpanda 3y ago
    Interesting. What are the use cases for being able to do this?
    - lewispollard 3y ago
      The main use case is for subviewports - nodes which contain a scene tree but aren't rendered with the main window, instead you grab a texture from the viewport and can display that how you like, as a mesh texture or as a sprite/texture rect, input to a shader, etc (similar to render textures in unity). You can apply a World resource to the subviewport (the default is, I believe, for them to have their own worlds), and that ensures that they are treated entirely separately from the main viewport's children and will only collide with things and be lit by objects in the subviewport. But, that may not be desired - you may want to use a subviewport to render certain objects and then apply post-processing only to those objects, but otherwise treat them like objects in the main scene - in that case you can have the subviewport share the same World as the main viewport, causing objects inside and outside of the subviewport to interact. Similarly, there are often gameplay reasons you may want to separate physics/lighting for particular objects, and maybe even have several "spaces" in which objects can interact that you want to swap out at runtime. Stealth games where shadows are important to the gameplay, or games that have an "inner" and an "outer" in terms of physics (maybe a car in the world, and then objects inside the car in their own inner world that maybe obey slightly different physics parameters, for example).

pjmlp 3y ago

While impressive, the whole UI feels much slower than using PlayCanvas.

exikyut 3y ago

Just to contribute: yet another instance of "cool slideshow" on my (most definitely low end) laptop with integrated graphics. Then tried it on my aging Mate 20 Pro (not too new, not tooo old), and it just seemed to get stuck at "Downloading runtime". Got a funny feeling my flaky 4G wasn't actually to blame, inspected the tab from my laptop (chrome://inspect) via USB, and was greeted with Uncaught (in promise) Error: Needs OES_texture_float_linear to function at M (worker-3ec07b2e.js:1:3338) at J (worker-3ec07b2e.js:1:3403) It is what it is. It's a good philosophical question about whether it's worth coding up an error screen, since it's all just to tell people they can't play with the toy. Hehe.

murkle 3y ago
https://github.com/evanw/OES_texture_float_linear-polyfill https://github.com/evanw/OES_texture_float_linear-polyfill
- TrevorSundberg 3y ago
  Hmm, I think that polyfill might only be for WebGL1 (we use WebGL2). When I go to the WebGL1 report I see that my card supports both: OES_texture_float OES_texture_float_linear But on WebGL2, it only shows OES_texture_float_linear. I think OES_texture_float doesn't exist on WebGL2 I'm guessing.
xeonmc 3y ago
How low end is it? I'm using my 8-year-old Surface Pro 4 on Starbucks wifi and it's blazing fast.

webprofusion 3y ago

It errored on first go with a blank screen: Error: Failed to allocate type at x.allocate (worker-3ec07b2e.js:1:3516) at ImportGlGenTexture (worker-3ec07b2e.js:1:7645) at RaverieEditor-60af6467.wasm:0x1d459ee at RaverieEditor-60af6467.wasm:0xedf9e7 at RaverieEditor-60af6467.wasm:0xedf56b at RaverieEditor-60af6467.wasm:0xdffefa at RaverieEditor-60af6467.wasm:0xf213e3 Reloading fixed it, maybe a race condition between setting up the app and it being ready to run.

TrevorSundberg 3y ago
Hmm, it looks like our call to `gl.createTexture()` returned null. I'm actually not sure what we'd do in that case other than fail with an error dialog.

DonHopkins 3y ago

Check out what I wrote earlier about how WAForth dynamically generates and links WASM code! By just reading the WASM documentation I didn't realize it was possible to call back into JavaScript to dynamically create and link in WASM code on the fly, but WAForth opened my eyes to that, by compiling each FORTH word definition into a tiny little module and linking them all together. No (practical) limit on the number of modules that you can use in the same WASM app. It would be cool for a game editor app to have a visual programming language that compiles directly to WASM that way, so you can edit code at runtime. https://news.ycombinator.com/item?id=34374057 https://news.ycombinator.com/item?id=34374057

TrevorSundberg 3y ago
YES! Absolutely yes to this. Right now the built in language was made well before WASM was even a thing, but at some point in the future I'd like to make it target WASM directly or even potentially use AssemblyScript or something like it. I certainly also want to have the engine support importing WASM modules as plugins, for when you need serious near-native performance rather than a scripting language. Tiny modules also sound awesome. I'll give the article a read, thanks for this!

chaosprint 3y ago

Looks great. and it even works on mobile phone. But it is a little bit slow on my mac Chrome.

rcarmo 3y ago

Seems great, would never use a non-native app to develop games.

deleted 3y ago

[deleted]

stuaxo 3y ago

Tried on a couple of devices with Firefox, the Downloading runtime bit takes ages. On Android firefox on my poor old Nokia Android phone it's way too slow to try, on rotating the UI size hasn't caught up for a few seconds and everything stretches. Edit: I got Failed to create WebGL context: WebGL creation failed: (Feature_Failure_EGL_Create) Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXAUSTED_DRIVERS) TypeError: a is null. The Ubuntu is in qemu but should have 3D support, as others mentioned there should be some error surfacing, not just continuing to show the splash screen forever. On Firefox on Ubuntu, I'm still waiting after a couple of minutes for it to start, so might try again later.

FrustratedMonky 3y ago

Great. Pretty incredible what can be done with WASM.

dom96 3y ago

Performance is definitely an issue here, this is on an M1 MacBook with Chrome and it's quite choppy.

TrevorSundberg 3y ago
If you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/

lostgame 3y ago

Strange, on my M2 MacBook Pro this still absolutely crawls. I thought it was my personal (intel) MacBook Pro, but it's still extremely slow on my M2. Looks amazing, but definitely requires a massive performance improvement before it's useful. Keep at it! :) edit: chrome btw

ForOldHack 3y ago

Mess around - Find out. Rule #1 in the industry, #1 is do not anger Linux wizards on a Friday. They will spend ever single waking hour until Monday morning, nuking your business plan, and reverse engineering your product, and make no mistake: These are a large group of some of the most talented programmers on the planet. They have skills, skills which are extremely dangerous to people like you.

billconan 3y ago

The UI looks very polished! I have an old 3D modeler I want to modernize, is it possible to reuse the UI framework? is it imgui based? I don't seem to see a sign of it. is it easy to be separated out? is the rendering backend swappable? (I hope to use webgpu)

billconan 3y ago
I found the ui code and looked at the font handling part, it doesn't seem to support complex shaping, the font has to be monospaced I guess with a small set of glyphs