beta 1.3

I guess I don’t understand how you’d distort the image without the triangles in 3d space…

Oh. By the texture mapping. I get it. So you could get, say, a lens warping by mapping a texture then changing the vertex coordinates, making the triangles smaller on the edges… Different.

Is the idea behind tile maps simply that you could pre build them, as opposed to nested for loops like we have to do now? (I’ve just been planning on larger tiles for performance, and compositing to an image that’s cached until I scroll… But I have yet to implement that to know if it’s performant. Interesting. In my case it’s a starmap, so large tiles are necessary anyway, but I can see the utility there…)

In some other threads, they’re talking about the keyboard coming in 1.3 - did I miss something, or should we manage expectations? (I’d like a keyboard too, but you know that)

Physics:

The gravity as expressed by Gravity.x and Gravity.y versus setGravity are orders of magnitude different - I am multiplying by 300 before they’re high enough. Not a complaint - an observation. I suspect wanting gravity to match real-world gravity will be common - it might be nice to have some sort of convenience function where physics could just eat the Gravity vec3 and “do the right thing” (which would be ignore the z, and multiply x and y by some adjustable constant - 500 as a default?)

It would be nice if the docs for properties of bodies had default values shown. Side note: nothing in this world has a restitution of 0 except maybe a lump of clay. I’d default it higher, it feels more “alive” to me. Or maybe another demo…

Here’s the thing. There is a conversion between screen coordinates and physics coordinates is because box2d is tuned to use units on the scale of kilograms / meters / seconds, which means if you map things 1:1 on the screen you get low stability from the solver. There are about 32 pixels per meter in the current setup (this will be settable).

When the ipad is standing up i noticed Gravity.y is around -1. The units used for physics.setGravity are in p/s^2 (pixels per second per second). This means that if you want the equivalent of -9.8m/s^2 you need to set it to Gravity.y * 316.8 (pretty close to your estimate). The only thing i can really do is take out the conversion for gravity, or perhaps have a convenience function like: physics.setUseAccelerometerForGravity(true/false).

I don’t think it’s worth having a convenience function when you can just multiply by a constant. It adds API complexity that solves something the user can easily solve themselves.

I never mentioned that a keyboard would be in 1.3. Though that’s not to say it won’t make it in there. It’s just not definite.

I’d just have setGravity recognize that if you pass it a vec3 (ie. Gravity from the accelerometer), it should discard z, and set x and y to 318.6 times what’s passed - that would make the idiom to set physics gravity to the real world be “setGravity(Gravity)” which seems pretty clean. You leave the vec2 and x,y behaviors as they are. Does that make sense?

I’m just suggesting it’s going to be a FAQ; if we’re willing to discuss things like convenience functions for n-gons when they can do simple lines, then an easy way to say “please use real gravity” seems fair, since “oh, multiply x and y by 316.8 and discard z” is fairly non-obvious.

It makes sense, but the user could also just do physics.setGravity( Gravity * 318.6 ). Or we can add a constant ACCELEROMETER_GRAVITY_TO_PHYSICS you can multiply.

I don’t think it’s necessary because most times 318.6 won’t be the right value. It will depend on what feels right for your project. 200 might be better, or 500, or some arbitrary scale factor that makes things run correctly for your project.

But - setGravity takes vec2 and x,y - will it take Gravity, which is vec3? I haven’t actually tried. If so, that’s great - but it’s still going to be a FAQ. :slight_smile:

Hmm you’re right. I think it’s better if we make setGravity do an implicit conversion (discard Z) and add multiply operator support to vec3.

Edit: as well as other operators. We’ll need them anyway for when 3D is added.

I might just make mesh2d, into mesh and change it to use 3d coordinates by default and just use z=0 for vec2 input. That way when additional 3D api stuff is put in, it’ll just work.

reading my mind, John.

Reqding through some of the physics code now.

Body:testPoint could have a better name. Maybe body:inbounds?

Or Body:containsPoint

Mmm… Assuming this is the same testpoint functionality as box2d, I’d avoid changing it - the better the mapping between the two, especially in function names, the more the docs and examples will apply to codea. Principle of least surprise.

Cooments and questions on the physics api.

  • rigibody could be just “body”. If you’re thinking about adding non rigid bodies later, then make that one be the one to have a longer name

  • getlinearveloc…how about just velocity? And if it’s easy to convert from world to linear point and vice-versa, i’d just keep one of the two versions

  • applyTorque: what’s the units?

  • applyForce: what happens if i dont pass a point, does it apply to every point? So i’m guessing if i dont pass a point, it doesnt change the torque, but if i pass a point it does (just tested this, seems to be the case)

  • body:draw() and body:fill() would be cool

That’s it for now. It all seems very cool.

Bortels, ok but least surprise for me would be a more descriptive name because i dont know box2d.

Also tried the font picker today and it’s sexy. One idea would be to put common fonts up on top.

Also on the physics, on joints, do you just create one and starts doing its thing? Is there a way to get a list of joints? Could be useful (at least for debugging if nothing else)