"Mark Weyer" <nomail@nomail> wrote:

> Let me mention shadows.
> [snip]

I didn't mention shadows in my original message, but I have thought about that.
I basically just set up the lighting so that pieces will only ever cast shadows
onto the board, and not onto other pieces.  (At least for the key light... the
fill lights would cast shadows, but their shadows would hopefully be subtle
enough to not be missed).

For the board shadows I rendered the board entirely without shadows, and then
again with shadows (from a typical-enough piece) at all locations.  As with the
piece images, I was going to take crops from this shadow image to overlay the
non-shadowed board at locations where the pieces are.



> Also, let me mention antialiasing.
> If you want some, then you should not just render your pieces with the
> board set to noimage. Instead, you should render twice, first the piece
> and the board normally, then just the piece with all textures replaced
> by white and a black background. Afterwards, you use the non-black parts
> of the second image (due to AA, they will not be full-white, mind you)
> as a mask for the first image.

Ok... I'll keep that in mind.  I'd thought about the AA, but was hoping it
wouldn't cause problems.


> > I also considered generating individual bounded images for the pieces (rendered
> > at all the various positions).  This essentially amounts to crops of the images
> > in option 1.  That options seems to only complicate everything below...  so I
> > think the first option is better, but I'm open to suggestions.
>
> What does it complicate?

I was thinking I would need to directly render the individual piece images
bounded to the size of the piece... How do I render that?  Do I change the +W,
+H and camera{ right<???> } for each one?  It seemed like it just pushed the
cropping-coordinates problem further up the chain to povray... and in such a
way that I would have to tell pov before it rendered these coordinates.

It makes sense as you say below to do full image renders, with one piece...
that's more workable.

> This is what I would suggest. Of course, it wastes
> a bit of time. But very little: It wastes the time to parse a scene more
> often and for povray to find out that some pixel is indeed transparent.
>
> So, now you have for each piece at each position an image which consists
> mainly of transparent pixels. Then use some postprocessing tool to crop
> this to the minimal rectangle. Write this tool yourself, unless somebody
> else suggests an existing one.
> The important point is, that the tool should output, separately, the
> coordinates of cropping it has used. Plug these into your game source
> code. That's all.

Good idea... I used ImageMagick:
convert -deconstruct \( all_transparent_frame.png BoardPieces_0_0_0_0.png \)
out.png
"-deconstruct" diffs the two images and gives a crop of only the parts that
changed, i.e. the non-transparent pixels in the BoardPieces image.

I modified the ImageMagick source to print the coordinates:
magick/layer.c : CompareImageLayers()
line 818:
    bounds[i]=CompareImageBounds(image_b,image_a,method,exception);
+    printf("Bounds[%d]: (%lu x %lu) @ (%ld , %ld)\n", i, bounds[i].width,
bounds[i].height, bounds[i].x, bounds[i].y);

I will probably still go with my original plan of loading the big images with
several pieces into my program... I think it's a little more memory efficient
than having thousands of images for every piece at every location.  But I will
use the individual-piece images to figure out the coordinates as I described
above.

So... That solves my problem nicely.  I'm still curious though if there is a
neat way to do it all within povray...

Given a +W, +H, camera{} and an object{}, is it possible to print out the
output-image pixel coordinates of the bounding box of the object?

Anyway, Thanks Mark and others who responded.

Malcolm

Post a reply to this message