5 ms·

Nebula is an open-source and free-to-use modern C++ game engine

171 points by ibobev 3y ago

shortrounddev2 3y ago
This looks cool, but I always wonder why we see so many game engines and not a ton of open source rendering engines. People could do so much more with 3D indie game dev with just a rendering engine and maybe PhysX, then they could define the game logic any way they want without having to use the specific entity component system or whatever paradigm of an entire engine
- TillE 3y ago
  You can do this with nearly any game engine. Ignore whichever pieces you want and use the lower-level APIs. I used to use Unity with a third-party 2D framework that bypassed all its game object stuff.
  - JKCalhoun 3y ago
    When I was looking about last year I eventually settled on SDL2. It had everything I needed (for a sprite-based game) and was low-level enough that I didn't feel like the game mechanics were baked in. Still happy with it.
    - novagameco 3y ago
      Yeah I think there are tons of graphics frameworks for 2D with no built-in entity management system (SDL2, Monogame, SFML), but it seems like when people work in 3D, they tend to make an entire engine. I think people would be less mystified by 3D if they could just plug in a 3D PBR rendering engine and then implement game logic any way they want, in any language they want (e.g: have bindings to a rendering engine coded in C++ but the game logic is all python, lua, C#, whatever). I think Three.js actually is kind of like this, but idk how useful it is for updating real time games. There's also always Ogre, but I just wonder why there aren't more rendering engines out there
AHTERIX5000 3y ago
Neat list of features but what about asset pipeline? How can I take stuff from material editor or Maya into Nebula? There are lots of engines with interesting features but with very thin content pipeline. Having worked on engines and games it's often the pipeline and tooling in general which makes engines great even when there are others more capable in terms of renderer features.
- Gustaph 3y ago
  Hello! The asset pipeline handles FBX and GLTF with regards to models. We read GLTF materials and support the baseline metallic-roughness natively. For FBX:s though, you need to edit the materials manually. The biggest hole in Nebula is that there are almost no tools, so editing materials is painstakingly done in XML. We basically haven't had time to implement the plethora of UI required to interface with the engine in any meaningful way. Long term, we plan to do all of this obviously. We used to have a pretty good toolset back before we did a total rewrite of the engine internals to get rid of all the smart pointers and move towards cache coherency and a data driven design. We support a wide range of image formats as well. They end up getting compressed (or not) to DDS in the end. The import settings is also something we need to implement a bunch of UI for, but currently we look at the file name to reason about compression schemes and whatnot.
  - gooob 3y ago
    what are some games that were made using the nebula engine?
flohofwoe 3y ago
Wow, Nebula on HN. As the original author of the Nebula engines it's absolutely astonishing and heartwarming to me that the University of Luleå has picked up the (open source) pieces and developed it into something so much better and more feature complete than the "inhouse Nebula" ever was :) I still remember when I was visiting Skellefteå around March (? it was still deep winter up there though) 2010 to meet the students doing some pretty damn impressive game projects with Nebula even back then and on that same day I got the call from Berlin that our company (Radonlabs) had finally to file for bankruptcy. Massive props to Johannes (who moved on AFAIK) and Gustav (who just added D3D12^H^H^H (oops looking at the source it's Vulkan!) raytracing and meshlet support - how crazy is that!).
- kaffeewolf 3y ago
  [dead]
- Gustaph 3y ago
  Thanks Andre! Should also give some cred to Fredrik who's been working on the entity-component setup on the game side.
- darek 3y ago
  Nebula was the tech that I watched very closely and it inspired me a lot. It was back in the ancient year of 2000, if I remember correctly, when our game was being published by CDV and I just learned about Project Nomads, based on Nebula. Beautiful engine and I loved the clean, simple and extensible architecture. I would love to have such tech nowadays, but focused on 2D/light-3D mobile games :)
  - flohofwoe 3y ago
    The most interesting design detail in Nebula1 (the close connection between C++ classes and Tcl) was also its biggest problem in Project Nomads. A lot of Project Nomads consisted of Tcl scripts which directly called into C++ class interfaces exposed to Tcl. This was extremely flexible, but also put too much power into the hands of gameplay scripters which came up with hair-raising workarounds for missing features in the C++ code heh. Another design wart was that we also closely integrated Tcl into the asset pipeline (e.g. you could attach small Tcl 'scriptlets' directly to Maya 3D objects which then would be evaluated during the asset export). This means we had to carry a small Tcl interpreter in the Maya plugin all the way to the end even though the actual engine long had dropped any support for Tcl scripting. Project Nomads scripting left such a deep scar that I removed all scripting features in Nebula3 (which the gscept/nebula version is based off, although I see there is some Python support under addons/scripting), and I remain a big sceptic when it comes to integrating 'scripting languages' into game engines. A probably too extremist pov. TL;DR: don't expose your low level engine APIs to scripting, and don't use the same scripting API for persistency and/or asset pipeline file formats, it will inevitably end in tears ;)
deleted 3y ago
[deleted]
dualogy 3y ago
Nice, another candidate for my current still-ongoing engine checking-out journey! Looked around the space recently with a focus on "Linux-usable, C++-able, Vulkan-able non-abandoned/non-rather-too-outdated engines today" (license unimportant in my search) and came away with: Unreal 5, Flax Engine, Godot (C++ story shaky / WIP, C++ is not a first-class game-dev scenario here AFAICT), Wicked Engine. (There's more out there that I ruled out for this or that reason and thus forgot about by now.) Top candidates for me ended up being UE and Wicked, the latter currently preferred due to my actual (somewhat foggy/fuzzy =) code-first & code-mostly use-case idea. UE5 has way more batteries-included but it feels heavy and presses your C++ coding into a cage of its various de-facto-required macros, the whole setup seems to throw off both major VSCode extensions for C++, and its hit-or-miss hot reload thingie. Everything very geared to its authoring environment, understandably. But I really just want "engine as a linked .so library" here for my stuff.. (By Linuxable I don't mean Proton/Wine, but actual compiled-for/compileable-under-and-for Linux.)
- Gustaph 3y ago
  You might find that Nebula lacks a bunch of tools. We have ImGUI integrated so it's easy to use, but considering there are plenty of systems to interface with, it might be hard to deal with content without some content tools. We mostly work on the core engine side of things. I am still not happy with a bunch of things rendering wise and want to make the engine capable of current gen rendering with GI, raytracing and whatnot. But it's an open source project, so anyone could build tooling around the engine if they want ;)
- _shantaram 3y ago
  Holy crap the example footage on Wicked's site looks so good! I'm blown away.
  - Capricorn2481 3y ago
    It does? I'm not sure what it is about that footage that seems mind blowing https://wickedengine.net/ https://wickedengine.net/
capl 3y ago
It has a 90's Pixar look to it, which is cool
bastard_op 3y ago
That's not at all confusing with Slack's Nebula. https://github.com/slackhq/nebula https://github.com/slackhq/nebula
- flohofwoe 3y ago
  Development of the first Nebula engine started around 1999 (as 'Nebula Device', later shortened to Nebula2 and Nebula3). I doubt that Slack was around at the time ;) (IIRC the only name collision we were aware of was some American rock band)
yazaddaruvala 3y ago
Clearly great work by the Nebula team, thanks! That aside, looking at the whole game engine "market", I'm surprised that more game engines in 2024 don't talk about or differentiate on their net-code. Syncing the physics sim between multiple clients and the server is one of the hardest problems in gaming today. Are there any game engines or state management frameworks for game engines that really stand out?
spintin 3y ago
100 FPS with 1500 characters? OpenGL (ES) 3 beats Vulkan at anything interesting on a single thread. How are these new protocols not divulged as bloated waste of time? Is every programmer a brainwashed eternal growth buffon? Probably job security: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”.
- Gustaph 3y ago
  Should probably update the screenshot, it's ancient and doesn't really show the current state when it comes to the performance. The job system used to push work to threads, but has been completely rewritten to better utilize many-core CPUs. Also, if you look closely at the profiler, you'll see that we spend 2.2ms in the frame just waiting for the previous frame to finish. That was a major performance hog at the time. This frame also basically shows no game logic whatever. So we just spend time waiting on other threads to finish while doing nothing else, which is also not indicative of a real-game scenario.

171 points by ibobev 3y ago

This looks cool, but I always wonder why we see so many game engines and not a ton of open source rendering engines. People could do so much more with 3D indie game dev with just a rendering engine and maybe PhysX, then they could define the game logic any way they want without having to use the specific entity component system or whatever paradigm of an entire engine

TillE 3y ago
You can do this with nearly any game engine. Ignore whichever pieces you want and use the lower-level APIs. I used to use Unity with a third-party 2D framework that bypassed all its game object stuff.
- JKCalhoun 3y ago
  When I was looking about last year I eventually settled on SDL2. It had everything I needed (for a sprite-based game) and was low-level enough that I didn't feel like the game mechanics were baked in. Still happy with it.
  - novagameco 3y ago
    Yeah I think there are tons of graphics frameworks for 2D with no built-in entity management system (SDL2, Monogame, SFML), but it seems like when people work in 3D, they tend to make an entire engine. I think people would be less mystified by 3D if they could just plug in a 3D PBR rendering engine and then implement game logic any way they want, in any language they want (e.g: have bindings to a rendering engine coded in C++ but the game logic is all python, lua, C#, whatever). I think Three.js actually is kind of like this, but idk how useful it is for updating real time games. There's also always Ogre, but I just wonder why there aren't more rendering engines out there

AHTERIX5000 3y ago

Neat list of features but what about asset pipeline? How can I take stuff from material editor or Maya into Nebula? There are lots of engines with interesting features but with very thin content pipeline. Having worked on engines and games it's often the pipeline and tooling in general which makes engines great even when there are others more capable in terms of renderer features.

Gustaph 3y ago
Hello! The asset pipeline handles FBX and GLTF with regards to models. We read GLTF materials and support the baseline metallic-roughness natively. For FBX:s though, you need to edit the materials manually. The biggest hole in Nebula is that there are almost no tools, so editing materials is painstakingly done in XML. We basically haven't had time to implement the plethora of UI required to interface with the engine in any meaningful way. Long term, we plan to do all of this obviously. We used to have a pretty good toolset back before we did a total rewrite of the engine internals to get rid of all the smart pointers and move towards cache coherency and a data driven design. We support a wide range of image formats as well. They end up getting compressed (or not) to DDS in the end. The import settings is also something we need to implement a bunch of UI for, but currently we look at the file name to reason about compression schemes and whatnot.
- gooob 3y ago
  what are some games that were made using the nebula engine?

flohofwoe 3y ago

Wow, Nebula on HN. As the original author of the Nebula engines it's absolutely astonishing and heartwarming to me that the University of Luleå has picked up the (open source) pieces and developed it into something so much better and more feature complete than the "inhouse Nebula" ever was :) I still remember when I was visiting Skellefteå around March (? it was still deep winter up there though) 2010 to meet the students doing some pretty damn impressive game projects with Nebula even back then and on that same day I got the call from Berlin that our company (Radonlabs) had finally to file for bankruptcy. Massive props to Johannes (who moved on AFAIK) and Gustav (who just added D3D12^H^H^H (oops looking at the source it's Vulkan!) raytracing and meshlet support - how crazy is that!).

kaffeewolf 3y ago
[dead]
Gustaph 3y ago
Thanks Andre! Should also give some cred to Fredrik who's been working on the entity-component setup on the game side.
darek 3y ago
Nebula was the tech that I watched very closely and it inspired me a lot. It was back in the ancient year of 2000, if I remember correctly, when our game was being published by CDV and I just learned about Project Nomads, based on Nebula. Beautiful engine and I loved the clean, simple and extensible architecture. I would love to have such tech nowadays, but focused on 2D/light-3D mobile games :)
- flohofwoe 3y ago
  The most interesting design detail in Nebula1 (the close connection between C++ classes and Tcl) was also its biggest problem in Project Nomads. A lot of Project Nomads consisted of Tcl scripts which directly called into C++ class interfaces exposed to Tcl. This was extremely flexible, but also put too much power into the hands of gameplay scripters which came up with hair-raising workarounds for missing features in the C++ code heh. Another design wart was that we also closely integrated Tcl into the asset pipeline (e.g. you could attach small Tcl 'scriptlets' directly to Maya 3D objects which then would be evaluated during the asset export). This means we had to carry a small Tcl interpreter in the Maya plugin all the way to the end even though the actual engine long had dropped any support for Tcl scripting. Project Nomads scripting left such a deep scar that I removed all scripting features in Nebula3 (which the gscept/nebula version is based off, although I see there is some Python support under addons/scripting), and I remain a big sceptic when it comes to integrating 'scripting languages' into game engines. A probably too extremist pov. TL;DR: don't expose your low level engine APIs to scripting, and don't use the same scripting API for persistency and/or asset pipeline file formats, it will inevitably end in tears ;)

deleted 3y ago

[deleted]

dualogy 3y ago

Nice, another candidate for my current still-ongoing engine checking-out journey! Looked around the space recently with a focus on "Linux-usable, C++-able, Vulkan-able non-abandoned/non-rather-too-outdated engines today" (license unimportant in my search) and came away with: Unreal 5, Flax Engine, Godot (C++ story shaky / WIP, C++ is not a first-class game-dev scenario here AFAICT), Wicked Engine. (There's more out there that I ruled out for this or that reason and thus forgot about by now.) Top candidates for me ended up being UE and Wicked, the latter currently preferred due to my actual (somewhat foggy/fuzzy =) code-first & code-mostly use-case idea. UE5 has way more batteries-included but it feels heavy and presses your C++ coding into a cage of its various de-facto-required macros, the whole setup seems to throw off both major VSCode extensions for C++, and its hit-or-miss hot reload thingie. Everything very geared to its authoring environment, understandably. But I really just want "engine as a linked .so library" here for my stuff.. (By Linuxable I don't mean Proton/Wine, but actual compiled-for/compileable-under-and-for Linux.)

Gustaph 3y ago
You might find that Nebula lacks a bunch of tools. We have ImGUI integrated so it's easy to use, but considering there are plenty of systems to interface with, it might be hard to deal with content without some content tools. We mostly work on the core engine side of things. I am still not happy with a bunch of things rendering wise and want to make the engine capable of current gen rendering with GI, raytracing and whatnot. But it's an open source project, so anyone could build tooling around the engine if they want ;)
_shantaram 3y ago
Holy crap the example footage on Wicked's site looks so good! I'm blown away.
- Capricorn2481 3y ago
  It does? I'm not sure what it is about that footage that seems mind blowing https://wickedengine.net/ https://wickedengine.net/

capl 3y ago

It has a 90's Pixar look to it, which is cool

bastard_op 3y ago

That's not at all confusing with Slack's Nebula. https://github.com/slackhq/nebula https://github.com/slackhq/nebula

flohofwoe 3y ago
Development of the first Nebula engine started around 1999 (as 'Nebula Device', later shortened to Nebula2 and Nebula3). I doubt that Slack was around at the time ;) (IIRC the only name collision we were aware of was some American rock band)

yazaddaruvala 3y ago

Clearly great work by the Nebula team, thanks! That aside, looking at the whole game engine "market", I'm surprised that more game engines in 2024 don't talk about or differentiate on their net-code. Syncing the physics sim between multiple clients and the server is one of the hardest problems in gaming today. Are there any game engines or state management frameworks for game engines that really stand out?

spintin 3y ago

100 FPS with 1500 characters? OpenGL (ES) 3 beats Vulkan at anything interesting on a single thread. How are these new protocols not divulged as bloated waste of time? Is every programmer a brainwashed eternal growth buffon? Probably job security: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”.

Gustaph 3y ago
Should probably update the screenshot, it's ancient and doesn't really show the current state when it comes to the performance. The job system used to push work to threads, but has been completely rewritten to better utilize many-core CPUs. Also, if you look closely at the profiler, you'll see that we spend 2.2ms in the frame just waiting for the previous frame to finish. That was a major performance hog at the time. This frame also basically shows no game logic whatever. So we just spend time waiting on other threads to finish while doing nothing else, which is also not indicative of a real-game scenario.