heyx3
commented
5 months ago Hi! Sorry for not responding to this sooner, I've been busy with other projects and didn't even see the notification.
Would you say it's the only or best pure-Julia 3D [game] engine in Julia? Do you know of any non-pure Julia engine, that may be better, but already usable from Julia?
I wouldn't call it an "engine" at all, though I do have a long-term goal of providing many of the building blocks towards an engine -- asset management macros #91, automatic editors using reflection, etc. I already have a simple ECS (still adding a few features related to type parameters, that's why it's not a public package yet) and 90% of a Scene Tree implementation.
I think I've seen a few other Julia 3D frameworks, but don't remember seeing any of them having any serious 3D projects or demos like mine (though BpWorld is currently slightly broken because it hasn't been updated for my restructuring of Bplus into 3 sub-projects).
Does you already support all supported platforms, and do you think it could support Android (eventually)?
Most constraints are imposed by the dependencies -- ModernGL, GLFW, and Julia itself (I didn't think Julia supported mobile at all). I also require OpenGL 4.6, simply because when this started it was just me playing around with graphics algorithms on my desktop, and I definitely want all the niceties of 4.5+ like DSA. Mobile support would probably require Vulkan, and see below for my comments on that. I do plan to ease up on some of the OpenGL extensions required. In particular, arb_gpu_shader_int64 isn't supported on Intel graphics chips.
I realize you started in 2019, and I'm just curious is that the reason OpenGL was chosen? I think Vulkan is its successor (and also better for macOS and Windows), so would that have been ideal, or doesn't matter as a first step? Do you have any idea if it would be good/easy to support Vulkan additionally or migrate to it?
In short, I wasn't considering Mac, and did not want to deal with the extra complications of Vulkan. Despite being a "legacy" API, OpenGL (especially the most modern versions) works great for non-AAA engines, and requires a lot less mental effort to do basic things.
Fortunately for you, B+ is very modular! If you want to use a Julia Vulkan library, you can still bring in BplusCore and most of BplusTools to work with it. BplusApp is the part which integrates closely with OpenGL (and GLFW, and Dear ImGUI). While BplusTools technically depends on BplusApp, this dependency is not currently utilized. Additionally, if you wanted to, you could fork BplusApp and rip out all the OpenGL stuff without too much trouble.
I suppose the GL module could be refactored to abstract away the specific graphics API associated with a Context. If this framework gets more traction, and Vulkan becomes a highly-requested feature, then maybe I'll revisit the idea of a refactoring...
Julia has a very fast RNG
It's been a while since I made that PRNG, but I probably wasn't aware at the time that Julia was already using a very lightweight one. However, there are some things I like about my implementation:
- Arbitrary seeding of any bits-type data with thoughtful spreading of the bits
- The addition of an immutable version
- The ability to promise that the implementation won't change
Plus, I'm not so sure that Xoshiro256++ is the best for our use-case. The most intensive PRNG use for a game tends to be in massively-parallel procedural generation, more akin to hashing than generating numbers, so the performance characteristics are very different from most other programs. See this paper or this ShaderToy reference, for some popular choices in this use-case.
I agree the PRNG I chose is a bit weird, and it also has a slow warmup time, so I've raised a ticket about picking a better one: #125
Julia is always strongly typed, as opposed to weakly typed, a technical term not the same as dynamic.
Thank you for the clarification, I thought "weakly-typed" and "strongly-typed" were vaguer terms. I raised an issue to update this: #124
Julia already has Nerf.jl ... also the trend is to ray-tracing, any idea what you want to support in the future?
AI is cool but my framework is not really focused on that. Ray-tracing I haven't directly looked into, but from my understanding you can't get it in OpenGL and probably never will.
Let's remove Quaternions from every 3D Engine (An Interactive Introduction to Rotors from Geometric Algebra)
Looks interesting and I'll definitely add it to my reading list!
At least GC not an issue, you easily avoid it? You know of Bumper.jl and the recent package to confirm no allocations? Do you need help with anything specific?
I haven't thought about tracking heap usage in a long time, as my messy test macro seems to work well-enough. But I certainly am interested in revisiting the topic at some point.
Hi,
I have some questions and comments.
It's great that you are doing this, very intriguing. I know there's a 2D Julia game engine, with 3D as TODO. I think this may be the first Julia 3D game engine (though not the first game, people have made something; Minecraft clone with Makie.jl?). Would you say it's the only or best pure-Julia 3D [game] engine in Julia? Do you know of any non-pure Julia engine, that may be better, but already usable from Julia? Does you already support all supported platforms, and do you think it could support Android (eventually)?
I realize you started in 2019, and I'm just curious is that the reason OpenGL was chosen? I think Vulkan is its successor (and also better for macOS and Windows), so would that have been ideal, or doesn't matter as a first step? Do you have any idea if it would be good/easy to support Vulkan additionally or migrate to it?
Julia has a very fast RNG. I proposed migrating to it, since I believe the fastest. I looked at your code, but you seem to do more, but also implement an alternative. I looked up:
https://burtleburtle.net/bob/rand/smallprng.html
[I found a link in your doc-string. Actually they are not triple-quoted, and I thought it a requirement... Apparently single-quoted works too; except for some tool?]
I didn't time it but you're sure your chosen RNG is better for some reason? I doubt that WOB is either.
FYI: Let's remove Quaternions from every 3D Engine (An Interactive Introduction to Rotors from Geometric Algebra) https://marctenbosch.com/quaternions/
The code isn't much different, but easier to understand: https://marctenbosch.com/quaternions/code.htm
I see you did your own C++ engine. And you at least believe enough in Julia. It's very hard work to start from scratch. I commend you for trying. What's you subjective feeling about using Julia rather than C++? [EDIT: I saw your why do; it mentions weak-typing, should be renamed to dynamic-typing? Julia is always strongly typed, as opposed to weakly typed, a technical term not the same as dynamic.] At least GC not an issue, you easily avoid it? You know of Bumper.jl and the recent package to confirm no allocations? Do you need help with anything specific?
Julia already has Nerf.jl and NeRFs are awesome, though not yet mainstream in games I think. I think they depend on everything static. There's a recent paper on making them very fast, i.e. skipping the neural part actually... more like scanline-rendering if I recall, why fast. Also the trend is to ray-tracing, any idea what you want to support in the future?