LiquidFun (Box2D related)

If you guys haven’t seen this, it’s very cool: http://google.github.io/liquidfun/.

It’s built on Box2D (the physics engine used by Codea), which makes me think there’s a possibility that one day it could be integrated into Codea without too much effort. Maybe just wishful thinking but hey :slight_smile:

Sounds really good, I can see it having an issue being as fast as 600 particles at 60 on an ipad but I do really like the viscous effect it gives.

Box2D is extreamly slow in Codea, sadly. You can see my water example and see what I’m talking about. Anyways, this is cool.

why do you think box2d is slow with codea…lack of cpu power or poor implementation?

@Zoyt: I guess it depends. On my iPad 4 Box2d is pretty great, until I start manually processing a lot of contacts. I imagine that with the fluid dynamics taking place in the optimized C++ code, I would think it would be much more efficient than implementing fluid dynamics in Lua. I’m working on getting it building so I can play with it some. At any rate, this is a very cool thing for Google to have done. It might come in handy for a game I’m using Codea to prototype :smiley:

I’m not doing fluid dynamics, but I did make a prototype with hydrogen bonding effects, but it was too slow. @Simeon - Any idea why Box2D is so slow?

What about rewriting box2d with shaders?

o_O

I’m curious…

@Zoyt could it be due to it being implemented through Lua instead of objective C? Or is it already in obj-C I haven’t checked myself.

I put Box2D in Codea and to be honest I’m not entirely certain about what causes the slowness. It’s most likely object creation for contacts within Lua. You can test this by removing the contact function which will stop it from creating the contact objects. I could try to optimise this by reusing the objects and preventing a ton of garbage collection.

@John I’m almost entirely sure its contacts. I’n a project I’m working on, it only slows down when two bodies are touching each other. I’m guessing one way to fix this would be to set a target for the collisions and ignore others? For example if I put this:

function setup()
character(CIRCLE, 20)
test = physics.body(CIRCLE, 50)
test.x = WIDTH/2
test.y = HEIGHT/2
test.target = character
end

So, it would only do collisions of those assigned to target.

I’ll do some performance tests and see if I can’t eliminate the overhead from this. The main issue is that due to persistent contacts you’ll get new ones being created continuously. If I use a single static contacts object then it will fix the problem. Only issue is if someone decides to mess with the returned contact data structure. I may make it a special userdata object to prevent this.

I thought we had figured out a while ago that collision detection, calculating the motion from collisions, and calling the collide function was what caused physics lag?

@Luatee
I’ve looked at the api and LiquidFun is essentially an extended version of Box2D. A group of particles is simply a new type of object. It has buffers that return an array of properties for each type of thing (position, velocity, etc…). Getting this to work in a performant way in Codea is going to be a challenge though and I think there will be certain restrictions. So the liquids are just particles but they have lots of different settings including the ability for them to maintain a specific shape (but still be squishy).

interesting article about the sprinkle app water physics engine here:

http://tuxedolabs.blogspot.fr/2011/11/sprinkle-behind-scenes.html

seems it used maximum 600 particles and lots of tricks.

@SkyTheCoder - Looking at how the code works it’s a bit worse than I realised initially. I’m working on a fix and the next release should be quite a bit faster. We’re also looking at adding LiquidFun too.

Great news @John Thanks!

Yay! :slight_smile:

@John I never really used physics in big projects, partially because of lag. After the update, I might try it! Thanks! :slight_smile:

LiquidFun should be great too.