How is something like this even possible?

0 favourites
From the Asset Store
Goodbye to sprite fonts, when you have something new on the anvil for your upcoming Games !
  • How are such physics (if they are physics), where every pixel is like an object of it's own even possible? It doesn't seem even optimization wise plausible to work

    Subscribe to Construct videos now
  • It would have to be a shader for it to work in Construct, although you could get fairly close on a higher end machine.

    I would say it would entail the a physics engine written to run just from the gpu.

    Nobody does that, that I know of.

  • Maybe they are 2d fluids, they are made to look like particles. I doubt its full physic engine or shaders

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • That looks pretty impressive. You couldn’t do that with construct. Indeed they used the gpu to handle all those particles at once, but shaders are only a subset of the gpu features needed. I mean they cold have also used cpu for a lot of it too. There are astounding amounts of performance gains to be had if you have the know how in assembly and stuff.

    What I like about games like that is they put a good amount of work in their own tech to create something cool that’s not easily repeatable by others.

  • Looks very cool, I'm expecting that they have an awful lot of shaders to deal with the simulation. It would be very heavy to simulate on the CPU and much better suited to the GPU. Compute shaders are probably the way to go. Or you could CPU if you had a lot of threads, but that would limit what hardware it would work well on.

    You could probably emulate some of this with custom effects, but I imagine they would be pretty tedious to iterate ( modify plugin, package, install, reload, load project, test, repeat... ).

    In case anyone hasn't seen it https://www.shadertoy.com/browse is a website dedicated to making cool things using only fragment shaders. It's kinda amazing. Just to warn you, some of them run very slowly even on powerful computers... So your computer might get kinda toasty.

  • Is there a way to get water/liquid physics like that for a platformer? doesn't need to be as tiny particle, even if it's a bit chunkier/blobier?

  • You could try something like this with the physics behaviour, it's not perfect but works surprisingly well.

    https://www.scirra.com/tutorials/813/how-to-make-fluids

  • Yeah that's sick, we'll have test to see how hungry the performance impact that kind of thing will have with the rest of the normal game stuff going on.

  • Web Worker using vertices like the Particles object perhaps.

    Shove a C++ physics library into Webassembly?

  • I tried out the alpha clamp technique, the flowing water looks good but when you have places that it settles it looks a bit like slushy snow instead. Also it can cause some serious CPU churn.

    This could be a good starting point to fluid simulation:

    github.com/google/liquidfun

    Can probably be compiled to WASM, doesn't help with rendering but gets you nice fluid sim!

  • Neat little game like that dan-ball.jp/en/javagame/dust in which you can make similar effects youtube.com/watch

  • As I recall lucid did some fluid dynamics stuff in CC... back in the day, but the stuff in the vid looks like it does a bit more than that. Looks like arrays of particles acting as solids.

  • It actually looks like a combination of things. The water, falling lava and sand piling up looks like the "falling sand game." When particles are going fast or being pulled by something, it's just simple particle physics. Then when there are big clumps rolling around it's a rigid body physics simulation. All that with some logic to switch between the three in a fairly seamless way. It doesn't look like it's doing a true fluid simulation.

    They could have used an existing physics engine like box2d to do the rigid bodies, but it would need to be scanning the terrain and generating the collision polygons from the pixels pretty often. Making their own per pixel physics engine isn't out of the question. It actually is probably faster and simpler for their purposes.

  • I agree with R0J0hound that it looks like a combination of things.

    It looks like it almost definitely uses some type of cellular automata for a lot of things (Google it for tons of info and vids), but if they did, they did a lot of work to make it behave and look all pretty. You can see some telltale signs by the way the magic destruction spreads, and how there is a delay in filling the empty space when liquid is flowing and the container or ground breaks beneath it.

    I think for the per-pixel physics they might be using a more sophisticated version of the same thing. If I were to try to do it, I would try to make a super simplified physics engine per cell, more like a vastly simplified platform behavior per pixel than like a true box2d style physics behavior. They said they're doing the simulation on CPU so I'd guess the simulation is a data-driven design, so there's just a bunch of dumb data sitting there, and the simulator runs over all of it, rather than each individual pixel being its own object. Each cell probably has a state that changes to different modes when it becomes airborne, or joins a larger body, etc.

    As far as how they're making the larger objects behave like they're part of that same pixel based physics, I don't have a clue. My guess would be magic. I've always been fascinated by soft body and brittle object physics, but I never delved into much of the math of it. The thing I did with CC that newt mentioned was using a library to do most of the work.

  • Nice, that Liquidfun examples page looks great google.github.io/liquidfun

    This is my attempt at seeing how similar I could make it in C3 😂

    drive.google.com/uc

    The liquidfun is a lot nicer than mine, and has nicer performance!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)