35 Replies
this is awesome! what do you use to render this onto a window?
I'm using sdl bindings for rendering, here's a link to that project https://github.com/Ryul0rd/sdl-bindings
Congrats @Ghostfire The Insatiable, you just advanced to level 18!
Current features of the collision solver:
- Multiple collision features per body
- Multiple contacts per collision
- Position normal constraints
- Velocity normal constraints with elasticity
- Velocity tangent constraints with friction
- Circle, lines, points, (some ray and aabb)
- Contact force caching for faster convergence
- Only discrete right now
i havent pushed the repo yet, I'm waiting on a few things like getting the sdl-bindings to work from a .mojopkg, making sure bodies can get deleted without leaking, etc..
It's meant for games rather than scientific purposes.
The technical name might end up being thermojo, to avoid conflicts with any existing projects name thermo.
That is sick
On my todo list today:
- being able to change the camera pivot
- being able to remove bodies
(and some unrelated things, so hopefully i get to everything)
oh yeah, checking sdl-binding from .mojopkg aswell, to see if anythings change. i heard we might be able to get it working with a different method
Wow, does it support custom gravitation fields yet?
it supports global gravity, but i left off any restrictions, so you can have rotational gravity, and scaling gravity lol.
no skewing
We dont do that around here.
local gravity would be a good thing to get to though
I'm working on my geometric algebra generator right now, but i should probably move on pretty soon so i can get to the other things, removing bodies might take a little refactoring to avoid leaks.
also, it's kinda tied to my game framework right now but it'll get better
I'm onto my last thing for the day which is removing bodies
ok.. i found a bug with my elasticity
but at least bodies can get removed. It's still tied to my game framework, so in this case i just put some logic in their update loop which gives them a life span.
ok one of my goals today was to fix the issues i noticed with elasticity acting a little wierd
im pretty sure i fixed it
but now for elasticity = 1
since that was giving me wierd behaviour before
one of the lines got stuck hehe The boxes are just 4 lines right now
Also, setting mass and inertia to infinity works to make things static bodies, so thats a good sign. But i should still add some flags for doing it proper
one of the primitives i like to support is variable width lines
so I'll probably add that at some point
This is awesome @Ghostfire The Insatiable is the repo where you're building this private at the moment?
yeah.. i told @Ryulord i wouldnt push it until i can use his sdl-bindings from a pkg instead of copying the entire thing into the project
Which is currently blocked by https://github.com/modularml/mojo/issues/3316
GitHub
[BUG] Top level
var segfaults when used from package · Issue #331...Bug description There is a bug when using top-level var: DLHandle to link to a library from a packaged binary. I've also reproduced a similar bug with just an UnsafePointer (see discussion) Eve...
Top level
var is being removed unfortunately until we have proper globals, as it results in undefined behaviorThat is consistent with the issues we were running into. Does this means that all bindings will have to live inside of a struct instance? The ergonomics there aren't great. Static linking or proper global dynamic linking would be nice to have
At the moment yes, I agree it's a pain. This is raising in priority:
https://docs.modular.com/mojo/roadmap#cc-interop
+1 for undefined behaviours of globals, chased a bug:
.value() on empty optionalMade the first commit, It's not very pretty and lot's of things need to change, but it's ok i guess :]
https://github.com/helehex/thermo
GitHub
GitHub - helehex/thermo
Contribute to helehex/thermo development by creating an account on GitHub.
oups the readme should say clock wise, eh that's ok i need to write an actually good readme sometime anyways
@Ghostfire The Insatiable this looks amazing! Since I’m working on something similar, this is a great resource to learn from!
Are you interested in game dev or for scientific?
I might need to factor in some scale mass
I am mostly working on scientific right now. but I am interested in trying out game dev sometime too.
can i send you an invite to a group chat about mojo gave dev?
Sure, thanks!
Knew I should've called it Geist, it's definitely being haunted by some spirits.
I can't figure this bug out that's causing only body2 to be effected by the contact solver.. it can clearly read from body1 correctly, but no matter what I do to change body1, it has no effect. I checked to make sure bodies are never being copied and got nothing 😮💨I even refactored everything to no avail
It means I have to double up the contacts, and causes weird things with the impulse caching
I fixed a warning about exclusivity in collision, and just due to the way i fixed it, things are behaving much better now. Always fix warnings :]
I've been experimenting with breaking out the game framework into a package called Geist, and potentially using an AOSOAOSOAOSOA approach to confuse potential threats, giving me enough time to escape.
Pure ECS sucks to work with, and i'm not really a fan, so I'm designing the entity system to get the performance of ECS where you need it (data oriented design), but feels more like traditional composition.
Not sure we can really do pure ECS for the general case in mojo yet anyways, since there's a few features missing
automatic AOS->SOA transformation can be nice for data oriented designs, but not really necessary, so hopefully i can come up with something decent for now
Not much to show right now other than a bunch of boxes, but I've made a separate directory for Geist: a mixed ECS design game framework.
I'm hoping to design it so i can plug in thermo as the physics engine, but also reuse thermo for another project i have planned.
I'm using infrared as the math library, so eventually much of the code will be dimension agnostic, but we'll see how far i can take that.
This is how using geist looks right now.
May eventually need an intermediate layer for communicating with geist instead of passing game as inout
This is pretty amazing!
Hopefully you will find this talk interesting: https://www.youtube.com/watch?v=PND2Wpy6U-E
Developer Voices
YouTube
Architecting a Rust Game Engine (with Alice Cecile)
This week we take a look at Bevy, a new game engine written in Rust. And in particular, we look at a core component of Bevy that has something to teach you even if you never write a game: its Entity Component System, or ECS. An ECS is an approach to managing complex systems with large numbers of moving parts, that takes some inspiration from the...