Collision Mesh Generator

It'd be really cool to have a feature in Construct where we could take a sprite and let Construct generate its own collision mesh - just like refining selections in Photoshop (CS3 and newer). It'd take the sprite, analyze it and simplify it and then Construct should be able to store each collision mesh as a subobject directly in the sprite.

It's quite a nuisance and create collision sprites for the more complicated spriteshapes. An internal, procedrual solution would save ram and time.

Just a thought

Do you mean you simply want a quicker way to have a different collision mask for a sprite, or do you want a new collision engine (ie. current is pixel-perfect, it sounds like you want a vertex-based polygon collision detector), or both?

I don't know, whatever works best and smoothly with Constructs behaviors. The current problem is that for high res art that isn't blocky, you'll need to come up with lots and lots of collision tiles that you'll have to paint manually, cause the sprites can be a bit more complicated - which takes up a LOT of time.

So the idea is that Construct would analyze the sprite shape and generate a simplified version by itself.

The current per pixel implementation is a bit 'too perfect' - which means that it detects every little variation in the sprite - it there's a 1 pixel dot standing out, the playerSprite with platform behavior will often come to a complete halt when it collides with the pixel. So you have to do it manually and make sure that everything is perfect.

So the optimal implementation would be like a channel that you could turn on in the sprite editor and then change the collision mesh of a sprite with a couple of sliders - like changing how much it simplifies the shape, offset it so that it looks like the player sprite would slightly stand inside of the sprite, etc. - just a procedural way to create a collision mesh / sprite for our tiles.

Are you talking about the platform behavior getting stuck on parts of ground tiles? I get around that by using a few invisible simplified sprites for the actual platforms/ground that can be made into more complex shapes quickly by dragging around and pressing enter. It works for the games I'm making, but I don't need the player's platform object to follow the ground sprites exactly, so I don't know if it would work for you.

I think what he means is some sort of interpolation of the sprite.

Like this:

<img src="http://dl.getdropbox.com/u/666516/interpolation.png">

Its fairly easy to do via levels in Photoshop, or Gimp. In fact I already have a script that does it for me.

I think what he means is some sort of interpolation of the sprite.

Like this:

<img src="http://dl.getdropbox.com/u/666516/interpolation.png">

Its fairly easy to do via levels in Photoshop, or Gimp. In fact I already have a script that does it for me.

What he said.

I don't think stuff like that is too simple

but while we're at it

a less rounded, more polygonal version for custom physics masks would be cool too

So it would be actually just a separate collision mask which you'd import from an image?

The whole idea would be that Construct would create this procedurally the moment you import the sprite - so that we don't have to paint collision masks for every single tile manually.

Currently I use a solid block and a sphere for standard collisions, but for custom stuff like hills, slopes, etc. - it can be a pain to do everything twice if an algorithm could take over that job.

The actual creation of the mask isn't even that bad, but importing everything twice and lining things up, stacking them, hiding them, setting attributes... that can be a lot of work.

If you mean having a separate image for a collision mask as for the visual display, these 2 videos show a way of having a separate collision mask for an image. I've been too busy to impliment it properly in and easy and logical way for the picture editor...but at least it can be done

Oh, I completely forgot about that feature. It'd be cool if that stuff can be done procedurally in the future (like just selecting the image, subtracting the selection and deleting the pixels), but this will do for now

Do you mean you simply want a quicker way to have a different collision mask for a sprite, or do you want a new collision engine (ie. current is pixel-perfect, it sounds like you want a vertex-based polygon collision detector), or both?

"Vertex-based" sounds very optimizing(less cpu intensive), it would really ease my work! :~D