A shader for 2D metaballs to be exact. It’s all rather simple but a cool effect notwithstanding.
My intent is to adapt it to represent zones of a faction on a map, with points representing owned star systems and the barriers extending all around. Hopefully with a bit less aliasing…
Are you doing the true isosurface calculation in 2D or are you using the additive alpha trick? (Hint: additive alpha can be just as good and waaay faster depending on the situation… even just in CPU.)
Or at least something that may be in that ballpark. It’s basically just a distance to point thing, inverted and raised to a power then clamped. No cpu work.
It does produce a lot of aliasing since I haven’t put it any smoothsteps and or anything yet though. It was half messing around and half an adaptation of a few metaball things I found on shadertoy.
One of the benefits of the alpha-add approach is that you can have a single “sphere” texture filled with the inverse exponent fall off. If you paint the quads to the frame with alpha additive then you can come back and apply a thresholding filter based on alpha. You essentially get the same effect but let the GPU do all of the work… and no pow() calls. (Though I guess pow() is plenty fast these days.)
Not 100% great if you need the data back again but really neat for painting water from drop meta-balls or clouds, dirt, etc…
Hmm right, I suppose one texture sample would be faster than doing a ton of iterations and distance checks per pixel. Still one would need to generate this texture and switch it every time a change happens…
Anyhow here it is in jme, looking like a petri dish of bacteria or something:
Just rendering with two discrete groups of random data in this case, both representing a different faction I suppose so they only connect with the same color. A cool side effect is that the colors add up into yellow at intersections. In the end with proper data there shouldn’t be any overlaps I think though.
It does seem to be a bit heavier than I anticipated, with 512 points in this case running at only about 100 fps in this otherwise nearly empty scene. Especially since I’ll need a max of about twice that.
I’m talking about something like a post-processing effect. Paint a bunch of quads into an offscreen buffer with the sphere texture on them. Just one texture on a bunch of quads, one quad per meta-ball. Copy it to the screen using a threshold.
I think even in your case you could do it all in screen space, but I’m not entirely sure.
It would also handle any number of meta-balls. (At least within normal rendering limits of the GPU.)
Can’t say I can imagine that process. What do you mean one quad per metaball?
Anyway I’m pretty sure I won’t be using any post effects in this case since that map viewport I’m planning to use this in is glued together enough as it is. Something capable of being a standalone geometry would be best.
I don’t see any major problems with my current idea though. That would be:
offscreen render each group separately which is within the const limit
add these up together either in the offscreen buffer if possible and output a texture
use that one or multiple textures as a material param on a single geom
The territory layout should only need to change every few minutes at most anyway so it’s not like frequent updates will be a problem.
I mean, there is a quad. That is rendered with alpha additive. That has a meta-ball texture on it. Then you render another quad for another meta-ball. And another quad for another meta-ball.
What you end up with is a bunch of painted ‘spheres’ where their overlap is added together. Then anything with alpha > threshold, you keep. Anything with alpha <= threshold you don’t keep.
I’m not sure how else to explain it at this point.
Edit: alpha could be replaced with any color for thresholding really. It actually might be required as I don’t remember if alpha is also added in BlendMode.AlphaAdditive.
Added basic ghost object support… kind of a bit hacked in at the moment, I’ll explain after this debug view screen shot:
On the left, a sphere ghost that publishes contact entities for everything.
In the middle, only publishes against non-kinematic bodies.
On the right. only against other ghost objects.
(Those flags are combinable in any masked combination.)
I say kind of “hacked in” because I haven’t bothered to learn anything about bullet’s built in collision groups or whatever. So maybe there is an optimization to be made later. As it stands, I get notified about the collision and then choose to publish the contact or not based on the objects in the collision and the flags set on the ghost end.
Functional enough to move on to my next assignment… collision avoidance in the steering system… which I’m hoping to use… drum roll please… ghost objects.
dyn4j is a 2D physics engine. It’s very good. I also use it for 2D physics when I need it.
This is bullet integration, ie: 3D physics. I integrated this the same way I did for dyn4j. Entities, components, systems, etc… I’ve implemented this pattern like 6 times now… so it’s almost something I can do in my sleep.
Edit: and I’m not sure what any of that has to do with a world object. I’d have to check my dyn4j code but I don’t remember having any special world object… unless it’s something internal to the physics system.
Yea, it’s the object you add physical objects to, then run ‘world.update()’ which then calls collisionslisteners etc… I was just thinking if this new project of yours would could replace it, or would it rather be something that could be put on top of a Dyn4jBaseAppState, to make it more ES-oriented, instead of EventListener oriented?
That was really up to you and how you integrated dyn4j. My dyn4j projects don’t have a Dyn4j app state. Just like my bullet project doesn’t have a bullet app state… and my mphys project doesn’t have an app state, etc…
All of those things have PhysicsSystems that wrap the physics stuff and get entities and publish positions. Other than the specific wiring for a particular physics engine, they are remarkably similar.
I was happy that I could easily repeat the pattern with bullet.
Ehm… JMonkey engine tool suite… seems like something I would like to know more about (I’m back to the forum after 5 years so I guess I missed a thing or two )