I don't immediately see how you can compute the yellow rectangle. In the drawing, you are using information gleaned from looking at the contents of the image (this part is just a tall part of the building, it's not at ground level. Thus, I will ignore this part of the image when creating the yellow rectangle).

Unless you have a separate image/channel with additional data ("height" or similar?), I don't see how this can be done?

The issue with trying to extract that information from an image is that you have to somehow inform the algorithm of which parts of the image actually affect the footprint. The algorithm can't look at your example image and know that the tall part is a chimney; for all it knows, the tall part lays on the ground and thus affects the footprint, making the object occupy much more area on the back-side of the object where the chimney occludes, even though that area should be open and not affected by the footprint.

When I was still working on isometric games, I always just did the bounds/occlusion/footprint calculation step directly from the geometry in the 3D file from which I rendered the object sprite. The 3D file contains all the information to determine exactly what the footprint of the object is. In the absence of the original 3D file, then you'll probably have to go with a more brute-force approach.

You could probably ease this a bit by building some sort of tool that will allow you to associate a particular object with a rough shape. ie, you could say "this image is LIKE a cube of size XYZ", and build the footprint data from that rough shape. Provide some sort of "grammar" or tool to aggregate simple primitives for more complex shapes. ie, "this image is like a cube of size XYZ plus a box of size WUV located at MNO offset from original shape", etc... How you build this tool or grammar is entirely up to you, but ideally it would:

1) Not take as long to develop as manually determining the footprint of each image would take

2) Allow enough conciseness as to actually reduce the workload of creating each footprint, enough that the overall time savings offsets the time spent developing the tool.

Give that you could iterate on such a tool for quite some time, there would need to be a LOT of images needing done to make it worthwhile.

4 hours ago, dud3 said:

I see, I guess I would have to develop an adaptive algorithm and train it with lots and lots of data...

I don't know that you'd need to go that far. I mean, yeah, if your main focus were on the tool to do this, rather than on getting a specific task done, then sure.... Spend a bunch of time on it. But writing some kind of advanced algorithm and training it with data sets... no, I don't think that would be a good use of your time if all you need to do is a few hundred sprites for a single game. That would almost certainly take longer than doing them all manually.

My first thought would be to write a simple tool that, when executed in a given directory, would automatically iterate through each isometric sprite in the folder. It would open each sprite in turn, display it on screen overlaid on top of an annotated grid perhaps, then it would wait for my input. It seems like all you are doing is trying to determine a bounding box (rather than a more complex footprint that adheres to the shape of the sprite) so I would have it accept an input string where you key in the dimensions of the box as you perceive it from looking at the grid. Your brain could do the processing, and all you'd have to do is key in a sequence of numbers. It would use your input to write a bounding volume in a file corresponding to the sprite file, and move on to the next.

It would be an extremely simple, brain-dead tool, but even with such a simple tool it's amazing how fast you could churn through several hundred sprites. A couple hours to write the tool, a couple hours to work your way through the sprites, and done. You don't have to spend very much time polishing the tool (odds are you won't use it again down the road, unless you do a sequel or something, and even then you can just try to prepare better by obtaining this information from the artist, or stipulating that the 3D files be provided so you can calculate it).