Ok, so I was encouraged by @pkeod to create a fluid simulation using metaballs. I read a lot about it and except mathematical shaders there are solutions where I need to:
Create a ‘particle’ go with a ‘falloff’ sprite, so that it’s alpha channel represents density falling off from the center.
Draw a lot of instances of above to a render target with additive blending.
Create a shader that will draw fluid if the alpha of each pixel is above a threshold value. It will create an effect of viscosity of those metaballs.
I’m creating game objects with the sprite and dynamic collision object for this. I created a material for those called metaball. I’m trying to create a working render script now. I think I created kind of the effect I wanted, because it’s behaving like metaballs, as you can see here:
BUT it’s my first time creating such render pipeline, understanding render targets etc, so the whole screen isn’t looking like I want it I was basing on @ross.grams’ rendercam lighting render script, because there were two targets and at the end they were merged on the third one - a plane. I understand thoroughly the pipeline and read a lot about it on our pages and about OpenGL and metaballs, though still can’t figure out what am I doing wrong I’m stuck at this point:
Physics debug allows me to see what’s going on really, but the render is far away from that A first I don’t understand why the render is like a negative - only on the background sprite.
Here’s my project, maybe someone could help me, please?
You forgot to add a rendercam camera to your collection?
It does look like the debug physics is not drawing in the correct way. I think it does work with vanilla rendercam so you might want to compare the render scripts to figure out what’s wrong.
If I disable the render target and draw the particles with the debug then the position is correct. So most likely easiest solution to make this work would be to look at current vanilla rendercam and transplant the render target stuff over to it.
For your physics, I would lower the scale of the physics in game.project, then play with increasing the mass of the particles and increasing the gravity of the world.
It looks like you have most of the pieces figured out you just need to put them together piece by piece so each works and then the whole works.
I mostly repaired the render target material, where I was multiplaying layers instead of adding them. I added an object that I want to apply buoyancy, but without it, the object floats even fine Still, the physics debug draw is not matching the render
You can see your render script (made based off an old example maybe?) is much different than the version currently live. You should probably use the current live up to date version as a bases and merge the render target stuff into it no matter what.
@britzl didn’t you make something to make using render targets easier?
I haven’t made a really official announcement of this yet. I’m not sure it’s useful enough yet or user friendly enough. I think it has potential, but I don’t want to announce anything until I know for sure. I need to spend some time coding an actual game using it. Need to game jam!
The idea looks great! Also the usage is very simplified, I’d rather start with examples like this, instead of diving into render pipeline and learning everything from scratch. When I was thinking about post-process effects I would imagine something like this - applying a commonly used post-process without really diving into how it is made.
For me, still this is the difficult topic, though I was learning it a lot. I managed to understand thoroughly shaders, but drawing in Defold is still complex at the start
It was what I was lacking in Defold from the begining - ready lights components, easy normal maps for sprites, fluid simulations, post-process examples like Unity or Godot have. Of course, I’m not taking into consideration 3D features, because I was looking for a 2D engine. Naturally, those brainless modules do not force you to learn and I think I must be grateful for that in Defold, though still, for the beginners it’s something that allows to judge the engine, unfortunately.
Your render script is based on an older version of Rendercam, and Defold changed the draw debug function last month. If you copy the debug rendering chunk from the current Rendercam render script and paste it in your render script in the “base render” chunk, after drawing particles, and remove the last two lines of the update function, then it will work correctly.
DEBUG:SCRIPT: url: [main:/instance298#collsionobject] vmath.vector3(19.734327316284, -71.744812011719, 0)
ERROR:GAMEOBJECT: Component '/instance298#collsionobject' could not be found when dispatching message 'apply_force' sent from main:/emitter#script
I’m saving the id and url of the created game objects to the table and then I’m using the same url to print it and to send data:
print(ball.url, go.get_world_position(ball.id))
msg.post(ball.url, "apply_force", {force = vmath.vector3(1,0,0), position = go.get_world_position(ball.id)})
I was basing on @ross.grams’ rendercam lighting render script, because there were two targets and at the end they were merged on the third one - a plane. I understand thoroughly the pipeline and read a lot about it on our pages and about OpenGL and metaballs, though still can’t figure out what am I doing wrong 
A first I don’t understand why the render is like a negative - only on the background sprite.
Still, the physics debug draw is not matching the render 
Maybe you should update examples page a bit?
Also the usage is very simplified, I’d rather start with examples like this, instead of diving into render pipeline and learning everything from scratch. When I was thinking about post-process effects I would imagine something like this - applying a commonly used post-process without really diving into how it is made.
!! Awesome!! I’m in.
