Oasis Game Engine - Vulkan and Java

User Code & Projects
1

Hello JMonkeys.

I finished reading some computer science research that were in my todo list so now I have time to tackle a huge project. So creating a Vulkan and Java game engine is on the radar.

Below is an image of the oreon engine I downloaded to my netbeans. A first step.

Below are two of the latest sources on the topic of Vulkan and Java.

Oroeon Engine @fynnfluegge

Vulkan Java API Research @lwjglgamedev

It’s very likely the name of the engine is changed from oreon to oasis. It’s a bit more marketable.

Please note I understand this would be a new engine that is not JMonkey. But I do need a community where I can post. So please keep my post and move them to an appropriate section if necessary. :slight_smile:

Purpose of this project:

  1. The purpose of this project is so that Java developers have moderns tools to make games.
  2. Making things is the only way I (Pixelapp) improve my skills.

This project will have a bit of an open timeline. But there will be progress little by little.

Finally here’s my latest game so future readers have trust I can significantly contribute to this project.

3 Likes
2

For another example of Java with Vulcan, see my V-Sport engine.

8 Likes
3

Hm, Oreon Engine hasn’t been updated in several years. That’s kind of a shame.

1 Like
4

Hmm. What does Oreon/Oasis use for physics?

5

Thank you for suggesting V-Sport.

The most important features for the engine are:
Deferred rendering pipeline
Physically base rendering
Mesh Skinning (animations)

These features must be included to have a modern game engine.

Eventually I’ll try to create a library that deals specifically with water physics in an arcade sort of way.

Oreon has a lot of graphical features that are not priority right now. But if V-Sport supports deferred rendering out of the box and it’s easy to add physically based rendering, then I would pick it over Oreon right away. Because I prefer great physics than great visual effects.

To answer your question: I quickly checked and I don’t think Oreon supports physics engine. I think it’s just Vulkan visuals so far.

1 Like
6

I imagine one could use either Jolt JNI or Libbulletjme with Oreon.

7

Trends come and go, but isn’t it something like Forward+ the latest hit in rendering?

1 Like
8

I don’t understand, do you want to write your own game engine from scratch for learning purposes, or do you want to use another engine that has all the features you need?

Anyways: unless you target very special devices you most likely do not want a deferred renderer. It was the cool kid on the block 15 years ago. Here is why:

  1. Monitors have evolved:
    On the old tvs/monitors 800/600 was the resolution of choice. A full rgba texture consumes 14.7mb of vram
    On a 4k display this amounts to 270mb.
    Now, you also have to rewrite this textures each frame.
    If you take into account that you need albedo.rgb/metal/rough/normal.xyz at the very least you need two of then. Summing it up it is 540mb of memory and ~32GB/sec of data written. Considering even current gen rtx 5000 cards have ~440gb/s of memory transfer you are using 10% of your total memory bandwith only for writing the the gbuffer.

  2. You still suffer from overdraw, not computationally but memory transfer wise

  3. you still need a fast forward renderer if you want to support translucency

  4. you are limiting yourself to one lighting shader in the best case.

If you want to stick with rasertization, forward+ with a depth prepass is the way to go.

1 Like
9

“I imagine one could use either Jolt JNI or Libbulletjme with Oreon.”

Thank you for the suggestion. That’s what a thought as well. V-Sport and Oreon are good picks. We’ll see how it goes.

“Trends come and go, but isn’t it something like Forward+ the latest hit in rendering?”

Thank you for the information.

I’m choosing deferred rendering because I like you can add more lights to a scene. Maybe Forward+ can be something that can be added in the future.

But I’m sticking to slightly older tech that way I’m able get the project to the finish line. Remember the point is to modernize tools for Java devs, not necessarily to be cutting edge.

“I don’t understand, do you want to write your own game engine from scratch for learning purposes, or do you want to use another engine that has all the features you need?”

The point is to make an engine that supports Vulkan and Java. It doesn’t have to be written from scratch. If I learn in the process, that’s a good thing as well.

“If you want to stick with rasertization, forward+ with a depth prepass is the way to go.”

Thank you for the information.

So far these items are on the short list of features:

Deferred rendering or Forward+
Oreon or V-Sport.

All of your comments being posted here are very valuable. Even if they are one sentence. Haha

2 Likes
10

May i ask why do you need vulcan? I am just curious because from my point of view “getting the project to the finish line” and “developing a vulcan java engine” are xor tasks.

If you only need a deferred renderer, there are quite a few examples on how that is done in jme too.

Lastly, a gameengine is not only graphics, its graphics, audio, input, physics, networking?, and game logic, and wireing everything.

I was quite surprised that the openal reference doc is ±60 pages long.

3 Likes
11

“May i ask why do you need vulcan?” I need a Vulkan engine because eventually OpenGL will not be supported.

12

I was interested in deferred rendering for a period of time for the same reason.

I noticed that jme’s current forward rendering pipeline would have drastic framerate drops when adding even just 1-2 point lights to a large scene, since it has to do a whole extra pass for each light (or so I thought)

But then I was thankfully informed by @RiccardoBlb that you can just change the number of lights per pass in jme with this code: (still very thankful to him for informing me of this just in time before I started work that I ultimately didn’t need to do)

app.getRenderManager().setSinglePassLightBatchSize(9);

And now I can render a decent number of lights with jme and it doesn’t lower the framerate at all.

I’m sure there are still benefits to a deferred pipeline, and maybe it would be beneficial in cases where I need 100s or 1000s of lights in close proximity to each other.

But in hindsight, I’m very glad I did not divert my efforts into working on a full deferred rendering pipeline since it ultimately was not necessary for my game. I think that you’d have to be making a pretty huge scale game for the differences in rendering pipelines to be a make-or-break factor, and most indie games don’t fail due to a bad rendering pipeline, they typically fail due to not being finished.

So (as others mentioned) I’d be careful about taking on such a huge task if your end goal is primarily to make games. Engine development is a great learning experience, but it also requires learning many things that are not necessary to develop a game, and the mindset is very different when you are developing a game for consumers vs developing an engine for developers.

Finding the time to do both effectively is very difficult in my opinion. I haven’t even delved into the deep side of rendering pipelines much myself, but I do know that just the work I’ve done developing shaders over the past few years has been enough to pull me away from my game more than I expected. So my advice would be to make sure that you are okay with putting game development on hold to exclusively be an engine developer for the next year or two (possibly more) if you do decide to take on such a huge task.

I also wouldn’t worry too much about this, especially not now. It will be a long time until new devices stop supporting OpenGL altogether. At most you may be missing out on 5% of the market who have new devices that don’t support opengl in the next few years, probably even less than that. And I suspect that when this time nears, there will likely already be community efforts to port as much of jme3 as possible over to a new vulkan based version of jme. There’s certainly many aspects of the engine that would need replaced and entirely rewritten, but also many parts of the engine that could be reusable. Starting over entirely from scratch would be a ton of work if the goal is to create a full fledged engine that can make shippable games. It would be a great learning process, but not a good business plan if your goal is to make a profit as a game dev.

5 Likes
13

MacOS does not natively support vulcan at all. The only option is moltenvk developed by khronos? which is a vulcan to metal layer. Nothing bad up to here but it already was behind for months/years? on the second ever vulcan release

I am not sold on vulcan yet if you can live without hardware raytracing. But @sgold implemented sport both in vulcan and opengl so he can say more about the complexity of both

2 Likes
14

Thank you everyone for you input.

I will pick an open source engine, jmonkey or godot and heavily contribute to:

Graphics Pipeline (OpenGL or Vulkan)
Physics (Bullet)
and a 3rd random thing like the game editor or such.

That way I know how to build a modern game engine without undertaking such huge task with no reward. So I get all benefits and no drawbacks. And also I get to go on vacations and have a social life while still having a decent game engine to work with. Haha

I’ll stay away from shader development or things that not add much value to my coding skills.

I’ll go ahead and create a back up version of my game in Godot. And as soon as OpenGL support starts to dwindle I migrate to that.

Thanks everyone for showing up to this thread. Your input is greatly appreciated. Keep being awesome.

1 Like
15

As I recall, Vulkan is more complex than OpenGL, but not hopelessly complex.

Vulkan is specified very thoroughly, with good tools for verifying compliance, so I expected good compatibility between vendors. Imagine my disappointment when I discovered that macOS supported only a subset of the Vulkan 1.0 spec. Apparently “portability subset” is a euphemism for “making it difficult to port your app to macOS”.

3 Likes
16

It should be a nearly complete subset of vk1.2 according to molten docs. You probably already know since you mentioned validation layers, but you can force lwjgl to use the molten library shipped with the vulcan sdk instead of the bundled one.

Of if you want to rewrite sport and give up on low level api’s you can switch to the sdl3 bindings :wink: The context toolkit is quite nice and has less issues then glfw.

1 Like
17

The issue I had was lack of support for the TriangleFan mesh topology. This was almost 2 years ago, using MoltenVK.

I didn’t know about sdl3 bindings.

Regarding complexity, I have some actual measurements:

  • the core package of Sport (interfacing to OpenGL and GLFW via LWJGL) is 3738 lines of code
  • the core package of V-Sport (interfacing to Vulkan and GLFW via LWJGL) is 6670 lines of code

The coding styles are very similar. I’d estimate V-Sport is providing about 90% of the functionality provided by Sport. So for equal functionality, V-Sport might require about 2x as many LoCs.

2 Likes
18

No, it’s frame generation now. Why render at 120 fps when you can render at 30 and then generate 3 fake frames? :roll_eyes:

2 Likes
19

Do not forget upsampling. You can render 1 frame at fullhd to get 4 at 4k.

But i habe not tried it yet since i dont own any modern games

2 Likes
20

Yes, AI upscaling too. All I’ve seen are youtube videos of it, but it’s reportedly pretty blurry at times.