(November 2018) Monthly WIP & Screenshot thread

working on the water, very milky, hard to find a balance between invisible and milky, what colour is water ? what colour is glass? what colour is the wind?
dialing in the refraction to be more physically accurate, less impressive in static screenshot, waaaaaaay better when moving.
currently has double reflections, I know why… it’s complicated.
slapped in a table top

15 Likes

Water is mostly clear but refracts to a very light blue. In a bowl like this, it would be basically clear. The difference visually would be that it would refract as a solid instead of two thin sheets of glass.

2 Likes

This line tells me you are not a dad. If you were you’d have watched pocahontas.

1 Like

It’s from Terrance and Phillip.

I’ve seen Pocahontas and I’m not a dad… but I was a child xD

I have seen Pocahontas… my kids have not. It’s an era/generational thing.

They do look at me really strange when I started belting out “Did you ever hear the wolf cry at the blue corn moon…”

1 Like

some video this time. I listened mr speed’s advice and pushing the water to clearer and a bit blue is helping.
I dumped a hell of alot of time into exporting the fish animation, such a waste of time, ended reverting to blender 2.6 and ogre exports. I need to find a more robust pipeline.
The fish has ugly alpha blending artifacts and animation jumping, eh, these can be sorted.
The glass is getting harder and harder to dial in.
Trying different methods to “ground” the bowl on the table.
I’m very happy with the refraction through the top of the water, an unintentional side effect of making the shader more physically accurate.

15 Likes

Some little slabs of instanced bacon entities having a swim and a walk about. They have a SimpleMovement component in them that gives them a velocity and basic collision detection. I was going to use bullet but why stop learning now I guess. Physics is not the easiest of subjects. Gives me actual headaches. Or maybe its the 9 cups of tea. Who knows.

10 Likes

I always joke that physics is easy… it’s collision detection/resolution that’s hard.

50% of a physics engine is proper collision detection, the other 50% is contact resolution.

The physics:
v += a * t
p += v * t
…is pretty easy. :slight_smile:

4 Likes

Its easy when you put it like that. I had to work that out. And yeah, Collision detection is/was a small pain. But if you say it like

pos.addLocal(normal.mult(penetration));

it sounds simple too. I am not an educated game developer. I have holes like swiss cheese in my fabric of knowledge :stuck_out_tongue: And I like to learn, not just a copy-paste specialist…

When you are done, you will find that ~50% of your code is collision detection and ~%50 is collision restitution.

While the code I posted is literally the physics part:
vel.multLocal(accel.mult(tpf));
pos.multLocal(vel.mult(tpf));

You will find that there is a LOOOOT more to collision restitution than:
pos.addLocal(normal.mult(penetration));

And that doesn’t speak at all to how you found the normal and the penetration to begin with. For spheres, it’s not much more complicated than that. For everything else, the complexity goes up exponentially.

Since you are using little cube shapes, for example, you have to deal with face-to-face collisions, edge-to-edge collisions, edge-to-face, corner to face, etc…

You will learn tons of cools stuff in the process, though.

I still contend that the physics is the easy part. :slight_smile: Every game since pong has had a variation on at least: p += v * tpf

2 Likes

I have literally spent the entire day figuring out how to throw 50 of them in a small enclosure without them either sky-rocketing sideways or being pushed through the wall due to lack of space. You are not wrong, and I am still not sure. From letting them overlap and push away less to standing on top of each other and vibrating like an angry child eating sugar… Everything seems to have a corner case.

Yep. That’s what makes restitution so hard. I’ve read a couple of game physics books at this point and most of them spend the majority of text on this very issue. Collision detection is largely considered a ‘separate issue’ and indeed I have a book entirely on that subject.

The thing is collision detection is basically a solved problem… it’s just really hard in the general case. So you may have an entire book on doing it efficiently.

Contact restitution is not a solved problem. There are several distinct approaches and each have their tradeoffs. For example, do you just push things out as you’ve done? (and basically never be able to stack anything) or do you rewind time to the first estimated collision, resolve it at the collision time, then continue forward until the next collision, then repeat? (and deal with the performance issues, potential to never resolve, etc.)

…or some hybrid of the two approaches.

Or do you treat all of the contacts as constraints in some giant combinatorial matrix and use magic to solve them simultaneously. (Jacobian matrices?)

My mphys library (soon to be released I hope) is using the first approach (push everything out based on penetration) but it sums those “pushes” per object per frame. So if a ball is flying directly into a corner (simultaneous contacts) it doesn’t shoot out at a weird angle as the two constraints will average out to a single push. It has its own down sides but it made things a LOT more stable. Prior to that change, it was impossible for a table to land on all four legs. One leg would win the constraint and flip the table at an odd angle.

I still can’t stack things more than two objects high without ugly jitter… but I have ideas for solving that, too.

You will spend your life on contact solvers… and it will be especially frustrating because invariably you will find that your contact solver fails sometimes because of bad inputs from your collision detection. (Hint: when a sphere hits the edge of a box, what normal should be used? It turns out to be very important…)

Edit: on this last point, I ended up setting up a special test program where I can load wireframe shapes and maneuver them into each other… contact information is then displayed as arrows and lines of penetration. Being able to microtest each and every edge case (sometimes literally ‘edge’ case) has been sooooo useful.)

2 Likes

A amazingly powerful but simple physics engine trickI learned a while back that solves virtually all restitution issues is to simple let someone else (aka pspeed in most case) worry about it =)

3 Likes

That sounds like an amazing trick.

This. Those thought experiments are very revealing. You are describing exactly what is happening. Thank you :slight_smile:

Can confirm, have used this neat trick a lot and it always works out in the end. :smiley:

2 Likes

This is not designed to run in realtime, its a generation algorithm, but looks pretty snazzy while generating :

It’s similar to an LSystem, used to proceduraly generate trees among other things, accept sort of works in reverse, it takes a 3d point cloud of end points, and generates paths to complete at all of these endpoints. This demo the 3d points are scattered across a sphere.

12 Likes

This is not a screenshot nor a gameplay video, and I didn’t event did it myself but… how cool is that? My game isn’t event out and there’s already fan art for it! :slight_smile:

3 Likes

Proof of concept:

  • step 1, draw on a texture where you want Ivy to grow
  • step 2, generate vines, add leaves

so it kinda works, but this is not the intended purpose for this.

5 Likes