mo3d: 3D library for Mojo
Hello wonderful Mojicians, I thought I would share my (very immature) side project!
Introducing https://github.com/thomas-gale/mo3d
"mo3d is aiming to be a 3d graphics library built from the ground up in Mojo, with minimal external dependencies. It utilizes only a basic subset of SDL2 for rendering, employing parallelized copying of Mojo-rendered scenes directly to texture data. Unlike traditional shader pipelines, mo3d aims to rethink rendering by consolidating shaders into Mojo code, while planning for future support of Mojo’s hardware accelerators."
I'm a full stack developer in my day job at a computer aided design company. However, I'm new to Mojo and not an expert in any of these fields. Just driven by natural curiosity!
I'm building this on the foundation of various good starting points (which I've tried to correctly attribute throughout the codebase) such as https://github.com/msteele/mojo-sdl for the sdl2 window.
Any feedback and ideas are welcome!
17 Replies
Very cool
We started a group for game dev related things in mojo if you're interested
Nice! You may also want to check out these sdl bindings as they're a little bit more up to date than msteele's (I also found theirs very helpful for getting started)
https://github.com/Ryul0rd/sdl-bindings
GitHub
GitHub - Ryul0rd/sdl-bindings
Contribute to Ryul0rd/sdl-bindings development by creating an account on GitHub.
Oh sure, that would be great!
Awesome! I am working on a geometry kernel for creating 3D geometry and all kinda of geo operations. Will definitly try your project to display the geometry. 🙂
Oh nice, right now it's in a very basic/exploratory stage while I slowly learn things. It's just rendering basic signed distance fields, and that's limited to just spheres! I'm assuming you'd want a height map / mesh renderer for your geo data? I've played a bit with this sort of thing in the past, you can do nice things like accelerating hit calculations on those triangles by placing them in a bvh/octree structure.
Thanks for the interest!
Congrats @Tom Gale, you just advanced to level 1!
@Tom Gale Ohh, spheres only, you say. Rendering meshes would be probably a preffered method.
My geo library will be for modelling BREPs and I will add Mesher at some point.
@Tom Gale bvh and octree sounds like https://github.com/AcademySoftwareFoundation/openvdb to me.
Great shout, the sparse stuff in openvdb is very interesting. I definitely need to add it to my reading list. Thanks.
I also like the way sparse concepts are handled in taichi https://docs.taichi-lang.org/docs/sparse
Spatially Sparse Data Structures | Taichi Docs
Prerequisite: please read the Fields, Fields (advanced), and SNodes first.
@Tom Gale heard about taichi, but never learned or used it. Didn't want to be locked in a framework.
The article itself is quite nice. Thanks 🙂
Had some time this evening to work a bit more on the ray tracing basics! I enjoyed and finished off the Ray Tracing in a Weekend tutorial and I'm moving on to the Ray Tracing the Next Week tutorial (I'm looking forward to experimenting with how to get a rudimentary ECS working with AABB/BVH acceleration structure). I'm also keen to starting to think about performance profiling - the naïve/brute force monte-carlo sampling is now sub 1fps (CPU) on this more complex scene with motion blur.
Amazing work man
I honestly thought this was OpenGL/Vulkan in mojo though😅
@Tom Gale May I create a feature request on your GitHub repo about displaying polygons? I could then "subscribe" to the issue, which will help me monitor the functionality and eventually start using your repo.
Congrats @btokarzewski, you just advanced to level 2!
Sure, go for it! It might take a while as I'm a bit slow! However, thank you for your interest! Can you roughly outline what you're trying to achieve? I'm assuming you might want something like direct lighting to ensure you get interactive/real-time performance? The indirect lighting solution is still naïve and slow, I'm planning on attempting to speed it up with MIS/Metropolis in the future. Long term (multi-year goals), we have powerful enough hardware and a good enough renderer implementation that we can always use indirect lighting.
Ah right, yeah I'm afraid this project is a bit more primitive at the moment. I'm just learning and building a scene representation (ECS) and renderer (Path Tracer) from the ground up in mojo. I think folks are working on bindings to libraries like
wgpu if you look around in #community-showcase . I guess in that case you could write a more conventional shader pipeline.@Tom Gale Sure I can describe my project a bit more.
By geometry kernel, I mean a fundamental library with the following parts:
primitives (point, line, polyline, curve, surface, brep, mesh, vector, plane, transform, matrix, quaternion, nurbs)
and operations (move, rotate, scale, boolean operations, push/ pull, offset, cut, cap, sweep, fillet etc.)
@Tom Gale So for me personally, I would prefer the ability to
display point, line and polygon and select something in scene more than render light. But that is just my narrow point of view. 😛
Ok, this all makes sense (but is scary in terms of amount of work!). In some cases we might want to try and integrate with 3rd party tools e.g. for the BREP stuff we would need to polygonise them from an open format such as STEP to trianges before rendererd (e.g. use a library like OCCT: https://dev.opencascade.org/doc/overview/html/). However, if we want to maintain selection functionally, then we will have the slightly tricky job of keeping the render triangles in sync with the underlying representation (I think this can be quite a lot of work).
As a side note, if I could re-summarise where my current interest is drawing me:
- Basic (somewhat efficient) direct/indirect light renderer.
- Reasonably sane scene representation (basic ECS but not as opinionated/integral as say Bevy) - with support for BVH/Octree and SDF for primitives (including triangles)
- Integrate a basic rigid/soft-body simulator (physics)
- Hook in agentic systems to drive systems in the ECS.
- Experiment with differentiable rendering from various viewports.
However, given what you're interested in, selecting things like polygons should be possible (e.g. by shooting out rays at the control points attached to more geometric entities). I'll have a think about this and see if this can be integrated into my fuzzy mental roadmap!
re "scary in terms of amount of work!"
I will quote Marie Curie "Nothing in life is to be feared, just understood" 👌