You are on.

EDIT: I am going to bed now. You can test this. I probably won't be on for a few days.

Zimbobway.lua is how you asked for it. (Does not work at all the way I did it actually)

Zimbobway - Copy.lua is how is should be done, methinks. At least it will be about a 100x faster.

This is the best thread in the history of CC Lua.
I'm glad someone else thinks this is possible, im loading Tim's scene now.
The one using quadtree doesnt load. What the hell. I'll try and get it to work, here goes..
after some blunders (i took out the subdivision, at one point by mistake..), it should load now.
DAMNIT TIM YOUR FILE INCLUSION SUCKS
and now it says i cant index quadtree because it is a nil value. I give up for now oo"

Yeah, I know it doesn't work yet. I still have to make some changes to the source quadtree I think.

I'm in, since I plan to have water in my own game why not try it out in CC first then if it works I can implement it in my game, simplez.

Also I've always wanted to develop the "impossible" in CC and made a previous water mod which failed (last minute lag reductions made the particles pop peoples heads, other than that it wasn't that bad)... I NEED REDEMPTION.

Tim, remember, when you press Ctrl+R it refreshes Lua scripts, so you can do rapid testing.

Double reminder, the longer you procrastinate on this, the more of a window you give other
people to steal the title of "Creator of Dynamic Water in CC" away from you. And of course, the prize.

Search around for other water threads, someone said something about dynamic water and MOSParticles avoiding actors.

I have a question. I don't actually code, so i'm going to say this in a way i hope you can understand.

Why don't we just make everything, the map, the MOSRs air, and water, deformable volumetric bodys?

I'd like to explain what I mean.

Define an area say a rectangle, 0,0 to 50,0 to 50,75, to 0,75. Now lets say that has a Density of 100 atoms per 'volume' (square, 0,0 1,0 1,1, 0,1) and that any 1 atoms have Structural integrity (A) Elasticity (B) Density (C, or 100 in this case) mass per atom (d) etc.

When any stress is applied, it would calculate, (By volume) the structural integrity, elasticity, and density, to figure out if the volume cracks, expands, compresses, or changes shape, finding the old and new volume and calculate the difference in density (X atoms in volume A becomes X atoms in volume B, X = X no mater what)

If thats the case, we could still compress materials (terrain, objects, water) to a maximum density, into any shape, And, a material could be weak enough to not hold its shape IE liquid.

This could also be a way to get true volumetric explosions and expansion, by making a material maintain its number of atoms, but decrease its density/volume, over time, and the force it would apply to surrounding objects.




This isn't exactly doable in Cortex Command as it is, but in theory, could these methods work, in another program, by combining the existing physics of CC, with a new engine, with more variables (IE Rate of expansion for solid/liquid/gas as over time and density changes, or possibly temperatures for reactions, magnetism, or any other variable we want really) also, to clarify, if an object has no elasticity, and it's Structural integrity breaks, it becomes 2 independent non-connected volumes, and if its still dense it could simply crack.







This is all purely hypothetical, and my question is, given this information, How much harder would it be, to code this, compared to how long it has taken to get CC to its current state, and how doable is this, in 2d or 3d, on a PC, or on a console. It's like I said, I can't code, i'm just curious and i got that idea. If it does work I'd love to know if A) if its already been done and B) where it is/might be

They already do that in Blast Miner, and for the "rigid objects" in Gish.
It makes for very stable physics. You can see it very clearly in this video.

And I've already thought about volume-conserving soft bodies
for liquids, but Cortex Command is just so particle based already
that you just can't change its fundamental nature.

I wonder if a Volume Conserving Softbody would be less computationally expensive than Particles.

So that's where your avatar came from... And are you going to say what the prize is?

Probably having the satisfaction of being the first person to ever code dynamic water into CC. (Even if it's using a different scripting language to create the water.)

Ah, so it does work. Now the fun part.

Everything in the video you posted was in blocks. How would you go about making non-squared objects.... Fractions and either vector graphics, or polygons. (or whatever words you'd use for it)

And for high detail, scaling, such as between 0,0, and 1,0 is defined as an area of 0=0/100 and 1=100/100. you could have infinitely deformable objects. They wouldn't have to keep there shape, and they could all be sculpted like clay, AND it would probably work in 3D, and given that in 3D it could use graphics cards, it might work in 3d, and still run as fast as CC does now, as is.






Now, on another note, Couldn't you add this method to CC using lua, Or best yet, Use lua to include new languiges. you could use lua, to then define your own instance types (MosDeform?) and tell it how to react to all the existing instance types... it would treat its entire body as 1 object, and as one area gets compressed, decompressed, or whatever, it would define the changed area as a separate object, like an attachable, it's its own object, that's part of the parent. The hardest part I suppose would be making this volume apply forces to itself (Ie the mass of the top is compressing the mass on the bottom, making it A) spread and B) become more dense, and much more)

I just thought it was an interesting Idea, that should be spoken.

Ah, but if you wanted to implement a deformable system like the one in Blast Miner into CC,
then you should implement it like it was implemented in Blast Miner.

For the deforming Simulation Part, you should still have that square grid, but have CC terrain inside the grid.
For the surface of the ground, the terrain would only fill up part of a square on the deforming grid.
For the mass of each square on the grid, it would measure the number of pixels in that square.

It would be a lot less computationally expensive than having infinitely detailed deforming objects.

Also, Vector Graphics are based on points. Control Points. They don't have any simulation advantages except
for they mess up really a lot when you bend the control points the wrong way. They are terrible for deforming
objects because either they mess up and fill the screen and glitch, or they look really cheesy.

Anyway, straight lines look pretty good: http://kotsoft.googlepages.com/blob.html

'k, I mailed kotsoft, the fluid physics genius, and asked him how he did it.

He gave me this:

Basically, it's circle collision that's soft and doesn't have any friction.

He also said that the code for finding neighbors within a radius was the more expensive part.
And for that, he said he used a (temporally coherent uniform) grid, though he says octrees are
probably better for adaptive simulations.

He also says that he is working on a method that doesn't require neighbor searching.
I don't see how you can do this with particles, but apparently he's found a way (unless it's navier-stokes).

so basically we could get that working in a quadtree and have 4-directional water, yes?