How to access vertex array of a shape? (Objective Chipmunk)

[DrummerB]

Hi,

I'm experimenting with chipmunk and the Objective-C wrapper in Chipmunk Pro. I'm currently still using the Trial version. How can I access the vertex array of a ChipmunkPolyShape instance? I don't want to use the getVertex: method for speed reasons. I'd like to access the underlying cpPolyShape's cpVect array. Unfortunately the cpPolyShape shape variable of ChipmunkPolyShape is private and provides no accessors. Thanks!

[DrummerB]

Defining a category on ChipmunkPolyShape, declaring a property cpPolyShape *polyShape and returning &_shape in the getter fixed the problem. But this is really more a hack then an elegant solution.

[DrummerB]

Actually it turned out I needed the tVerts of the shape. I think the best solution would be to have a public property polyShape to access the cpPolyShape variable (same for circles or segments).

[slembcke]

Shapes already have a shape property that returns the pointer to the underlying cpShape C struct. You simply need to cast that to a cpPolyShape (or cpCircleShape, etc) pointer. Keep in mind that by accessing the vertex array directly you are using the private API which may change without notice, otherwise feel free to experiment as you please.

For my own projects, I just keep a separate copy outside of Chipmunk of the vertex array. It's usually easier that way anyway. Unless you have tens of thousands of shapes, it wastes a pretty trivial amount of RAM. The storage for 10k boxes worth of vertexes use about as much RAM as a 256x256 RGBA8 texture, and you'd be hard pressed to have 10k objects simulating at once on a mobile device CPU anyway.

[DrummerB]

Thanks for the fast reply! I didn't know you could cast c structs like that, but now it makes sense. I'll store the vertices separately too, since I need them for other purposes as well (light rendering), I just wanted to quickly hack together a test.

[slembcke]

Light rendering you say? Like this: http://howlingmoonsoftware.com/twilightGolf.php The world seems to be telling me that I should write another game with dynamic 2D lighting. It's really a wonderful looking effect.

I've been making little demos every couple years. Twilight Golf is the only game I've ever released that used it, and it was a total flop. Then again we only spent maybe 2 man months of time on the entire game because we felt it was a risky project (part of the reason it was given such a ridiculous name). Also it's short, wasn't super polished and we aren't so great at making puzzles I think. :-\

Fun fact, Twilight Golf is actually where Objective-Chipmunk came from. I made a really rough version of it specifically for the game which I later polished and added to Chipmunk Pro.

I didn't actually have anything important to say I guess... I just get excited about 2D lighting. >_>

[DrummerB]

Yes, 2D lighting is really interesting. I implemented the light rendering roughly following this tutorial. Did you use any references or did you come up with a custom solution? The end result looks similar to Twilight Golf. But don't worry, my gameplay will be very different.

I wonder how you managed to render more then one light source with overlapping dynamic shadows on an iOS device with reasonable frame rates. As far as I can tell, that requires you to have at least 2 off-screen framebuffers. One of the size of the biggest light source radius and an other full screen sized. Then you render each light with it's shadows in the first buffer, additive blend it into the fullscreen buffer and multiply that to the scene. Doing this didn't want to run smoothly on my 3GS however.

[slembcke]

Oh don't worry it's not like Twilight Golf was terribly original or ground breaking. Take away the shadows and it's just a mediocre physics puzzle game with a ball in it. :p

Ah yes, I've seen that article. My method is more or less like that but without the soft shadowing. The main difference is that I do the shadow projection on the GPU using an infinite projection matrix. That way I didn't need to calculate any of the geometry on the CPU and you don't end up with shadows that don't project far enough (they always make it all the way to infinity). I found this old simple test program: https://gist.github.com/3224017

I only used one render texture, a lightmap of all the lights that I would build up. For each light I'd render the shadow mask into the destination alpha, the set up the blending function to multiply the src pixels by the destination alpha and add to the destination color. The "screen" blending mode would be preferred over additive to avoid over-saturation, but you can't set that up to work to also use a mask with regular OpenGL blending. Fillrate is your biggest performance enemy. When clearing the destination alpha to get ready to draw the next shadow mask, only clear the pixels the light will touch. I drew the light's quad with texturing disabled and a color mask to do that instead of using glClear(). To make it run at 60fps on the original iPhone the lightmap texture was only 128x128 and then stretched fullscreen to further save on fillrate. Despite the low resolution, it actually was pretty hard to notice. On the 3GS and up I used 512x512 which was overkill, but performed fine.

[DrummerB]

Good idea, I'll definitely try that. Thanks a lot for your code example. I'm not sure what your projection matrix does.

Code: Select all

GLfloat mat[16] = {
			1.0f, 0.0f, 0.0f, 0.0f,
			0.0f, 1.0f, 0.0f, 0.0f,
			   x,    y, 0.0f, 1.0f,
			  -x,   -y, 0.0f, 0.0f,
		};

Wouldn't that transformation leave the x and y coordinates of any vector unchanged? Only the z and w coordinates change depending on the light's position.

[slembcke]

So you specify each vertex point twice (v.x, v.y, 1) and (v.x, v.y, 0). The z-coordinate isn't really a z at all, it just flags if the point should be a regular point (1.0) or point projected infinitely away from the light (0.0).

The (x, y) coord in the matrix is the position of the light. So say the light is at (l.x, l.y) and you pass the point (v.x, v.y, 1.0). The homogenous coord you'd get back would be (v.x, v.y, 0.0, 1.0) or basically the "regular" coord that you put in (ignoring the weird, not-really-a-z-value). If you put in (v.x, v.y, 0.0) you'd get (v.x - l.x, v.y - l.y, 0.0, 0.0) In other words, a point at infinity in the direction from the light to the vertex. The w = 0.0 trick is actually in the OpenGL spec and is required to be supported by the hardware, which is good to know it's not just a hack that happens to work.

Anyways, nowadays I'd probably try batching all of the shadow geometry stuff on the CPU. It was a neat trick on OpenGL ES 1.x, but it effectively requires a draw call per shadow casting object (I did the entire static environment as 1 though). It saved on a bit of code, but I think having so many draw calls was more expensive than it needed to be. /me shrugs It worked on an iPhone 1 though.