So I made a thing to rasterize the N dimensional features of N dimensional euclidean simplices (I need to, uh, check which chunks are within the rectangular region seen by camera... )

Such as this rasterization of the 2-simplices that make up a 4-simplex (hehe fancy words) without the issue (bit blocky tho):

Given that its something I wrote late at evening, doing the extension to N dimensions myself (I try to templatize my code), without examples I could find, Im surprised it works reasonably well in most cases.

The above image is a triangle rasterized into a voxel grid. Points A, B are at same height, point C is much lower.

However, as you can see, theres an issue with filling triangles (sometimes). Usually theres no holes like above, but in those cases the triangle face - although filled - is a bit blocky too.

The above triangle is filled by, for each horizontal slice, finding intersection points with the lines AB and AC, and using bresenham to draw a line between them. The red lines represent this. (note : since the triangle is tall, each red line is more like 3 rasterized lines with same endpoint on X,Z plane where Y is height like (0,0,0) (0,1,0) (0,2,0))

It is clear that this method wouldnt work even in 2D.

In 2D, you would want the red lines to be axis aligned.

I COULD change the axis on which I iterate through the triangle, but the issue would then just happen in another dimension.

So - since it is impossible for the lines to be axis-aligned, how is one supposed to rasterize a triangle in 3D, avoiding holes?

Obviously I can completely change approach and do something like for each voxel check if its contained in the shape, but Im interested whether something similar to this particular approach exists - without the flaw.

EDIT:

I guess this might fit math/physics or maybe graphics section better...?

EDIT2:

Hmm maybe I can replace Bresenham's with a line drawin algorithm that generates ALL pixels that are intersected by the line (instead of being restricted to one pixel for each unit interval on the main axis)

Hmm maybe I can replace Bresenham's with a line drawing algorithm that generates ALL pixels that are intersected by the line (instead of being restricted to one pixel for each unit interval on the main axis)

That's probably your simplest route out of this issue.

I'm curious what rasterisation of N-simplices is useful for?

I'm curious what rasterisation of N-simplices is useful for?

I guess you could write a buggy N-dimensional software rasterizer

I was just writing some rasterizing functionalities (to rasterize triangles), and figured it should be possible to templatize the thing in case I need only the outline or perhaps a filled tetrahedron or whatever.

I managed to make my line rasterizer to cover all points it intersects, which made the issue go away as expected. Though it was a quick hack so it only affected some methods of getting points out of the line rasterizer... I need to make a whole new class for it instead of breaking my working bresenhaim algorithm >.>

Currently I used it to rasterize the rectangle of chunks covered by camera so I know which ones to load, and it works fine given some buffer around the edges (cam corners rounded to integers and using the bresenheim algo for the triangle edges :/)