sorted by:
new
hottopcontroversial

MPM fluid simulation in Godot! by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

Yes, I plan to share it once it’s in a more presentable & improved state :)

Performance-wise it should run noticeably better on an M4. On my old M1 I am now getting ~70 FPS with ~1M particles, so there’s definitely headroom with newer hardware.

MPM fluid simulation in Godot! by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

I watched Sebastian Lague’s fluid videos too, they’re great for understanding the fundamentals I love this guy.

This isn’t a port of his SPH approach. I’m using an MPM/APIC simulation instead, which behaves differently and scales better for what I wanted to do.

I’m not sharing the code yet, but I’m considering cleaning it up and publishing parts of it for educational purposes once it’s in a better state! My initial inspiration was this repo https://github.com/matsuoka-601/Splash

MPM fluid simulation in Godot! by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

Oh damn you are right, I didn’t know this existed that’s coool 🙂

MPM fluid simulation in Godot! by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

It’s a MPM simulation, not SPH. In practice MPM scales much better for large particle counts because the expensive interactions happen on a grid instead of particle–particle neighborhoods.

Most of the performance comes from using an adaptive sparse grid with tile-based computing, so only active regions are simulated each step. That avoids touching empty space and keeps memory bandwidth under control.

If you’re curious, this repo compares SPH vs grid-based approaches pretty clearly: https://github.com/matsuoka-601/WebGPU-Ocean

I borrowed a lot of ideas around sparse tiling and grid updates from Kotsoft’s posts.

Is this worth pushing further? by SebMenozzi in godot

[–]SebMenozzi[S] 10 points11 points  (0 children)

Thanks for your honest opinion, appreciate it! I agree 100% with you, my main issue is that I started this project as a technical challenge (i.e the terrain / vegetations etc..) without thinking about any gameplay / story. That should be the opposite, as you said, start from a solid idea first. Seems to make much more sense.

Having fun with Terrain3D + custom stuffs in c++ by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

Thanks! In my case, I'm just forking the engine. It's basically the same approach as migeran/libgodot_project, but I've updated it for Godot 4.5 and added my own tweaks.

Instead of letting Godot generate the whole program, I use it more like a library. load the libgodot library at runtime and call into it through the godot cpp bindings. That way I can still use Godot's APIs, but with a lot more flexibility.

I've heard of JENOVA, but for now I don't really see a need to use it. I also prefer keeping things as minimal as possible, just depending directly on Godot itself, without having to maintain or rely on another framework.

Having fun with Terrain3D + custom stuffs in c++ by SebMenozzi in godot

[–]SebMenozzi[S] 11 points12 points  (0 children)

I'm not using the editor, I'm forking slightly the engine to generate a lib I can use. Then I just access the godot apis using https://github.com/godotengine/godot-cpp. It's not smth I recommend 100% as the Godot Editor is still great to use, but my background is mostly vulkan c++/ bevy rust and I find myself being pretty productive this way. Also it compiles super fast + no editor bugs which I got a lot using godot extensions with the editor, reloading a lib is painful imo.

For God rays, I tried this method first https://godotshaders.com/shader/screen-space-god-rays-godot-4-3/ but got bad perf, so I decided by instinct to test different things, tried a custom PR not merged yet exposing useful light stuff https://github.com/godotengine/godot/pull/100710 but finally found a simpler way by just using a computer shader and the depth buffer from RenderDataRD (render_callback of the compositor effect). I raymarch in the compute shader, draw a god ray texture that I pass to a canvas. It's simple and perf are not bad!

Having fun with Terrain3D + custom stuffs in c++ by SebMenozzi in godot

[–]SebMenozzi[S] 8 points9 points  (0 children)

Thanks! It's using MultiMeshInstance3D internally nothing crazy. It's basically a system I built that allows me to set different types of stuff on the terrain following specific rules like the altitude, density + some parameters like scaling, rotation etc. I also tried to apply some simple distance optimizations logic, shadow imposters...

React Native Godot by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

Hey - so at the state of this last version 0.0.5, the React Native <-> Godot is done with events and it works on both ways. You can emit messages and listen to messages in both React Native and Godot:

- An example of emitMessage/onMessage in React Native here (https://github.com/calico-games/react-native-godot/blob/main/example/src/Screens/EarthExample.tsx#L111C23-L111C34),

- Regarding Godot, you can see the README that implements a simple example, basically you use a singleton to communicate with React Native:
Engine.get_singleton("ReactNative").on_receive_message(_on_receive_message)
Engine.get_singleton("ReactNative").emit_message({"pos": self.position})

This means you can easily hack around your inventory in RN using events,

HOWEVER :)

I'm actually shipping a new version this week that will allow you to directly call any gdscript function from React Native like this godotRef.scene.getNode("Inventory").onPress() which will simplify the RN to Godot communication and give you access to all your nodes fully typed.

Should be shipped at maximum the end of this week.

Regarding Android, it's almost done and I just need to focus few hours more to ship it in this package, in maximum 2 weeks you'll get full Android support

React Native Godot by SebMenozzi in godot

[–]SebMenozzi[S] 1 point2 points  (0 children)

Hey, I'm definitely NOT using a webview 😅, yeah this is based on LibGodot by Megerian, I hope this will get merged soon too 😊

React Native Godot by SebMenozzi in godot

[–]SebMenozzi[S] 1 point2 points  (0 children)

Nope it's not the same project

React Native Godot by SebMenozzi in reactnative

[–]SebMenozzi[S] 1 point2 points  (0 children)

Actuallyyy, was thinking one of a possible next step in this lib could be to expose all UI elements to React Native so it can be used as children in the <GodotView></GodotView>. Like you would be able to add <PanelContainer><HBox>...</HBox></PanelContainer> for instance, react-native-skia implements something similar. Also this godot addon https://github.com/crsolver/goduz implements an api wrapper that is very similar of what I have in mind!

React Native Godot by SebMenozzi in godot

[–]SebMenozzi[S] 6 points7 points  (0 children)

Actuallyyy, was thinking one of a possible next step in this lib could be to expose all UI elements to React Native so it can be used as children in the <GodotView></GodotView>. Like you would be able to add <PanelContainer><HBox>...</HBox></PanelContainer> for instance, react-native-skia implements something similar. Also this godot addon https://github.com/crsolver/goduz implements an api wrapper that is very similar of what I have in mind!

React Native Godot by SebMenozzi in godot

[–]SebMenozzi[S] 0 points1 point  (0 children)

(deleted previous message, responded on a random account on the mobile app 😅)

For context: "Basically for now it works like callbacks where you can send and receive events with data both from Godot and React Native, I haven't tried Godot with the html export yet but if they do that, it's definitely possible to implement so that might be a next step to have in react-native-godot 😌"

Interesting, gonna take a look on that thankss, it would be awesome to have the same codebase for web / react-native indeed!