Hidden vector graphics (3D)

@BadWolf359
if it can be of help, here you can find resources that were very useful to me when developing E3D.
I never succeded in opening chapters 1 and 7 but you can compensate searching on the net for similar arguments.

@turbor
it is a pleasure to find that you are always on the (3D) point ;)

@MicroTech: Document 1 and 7 seem to be corrupt. The other docs in the zip seem to work. It looks to be a great resource indeed, so I would like it if you could re-upload it (or only parts 1 and 7)

Reuploaded the pdf conversion of all documents except 1 and 7.
Please let me know if anybody should succed in opening these 2 chapters and converting to .pdf.
The original book was worth all the money I spent to buy it... I recommend purchasing it.

I'm very late to the discussion, but also the author of Sam Coupé 3d, albeit that I'm more than a decade older now. I'm happy to expound on anything in there if it's helpful. I think that reverse-face-detection has already been well covered here on a face-by-face basis.

That said, I just wanted quickly to note that there is a BSP solution that does a potentially-better* job for convex objects that I didn't really explore back then and which I will attempt to return and explain more clearly if there's any interest but in essence:

1. use the planes that polygons sit upon to divide space relative to the object;
2. categorise the current player position using those planes;
3. draw only the faces or edges that are known to be visible from the subset of space the player is in.

The win comes during the categorisation stage — you don't need to test the player against planes that definitely don't overlap the subregion that you've already established. It's a generalisation of the special case you can intuitively get to with a cube: if the viewer is in front of +x then obviously they're not also in front of -x.

If you want to precompute the decision tree that leads to eventual categorisation then in principle it's a lot of "does this infinite plane overlap the region defined by this collection of infinite planes?" — except that infinite planes are difficult to reason about in non-implicit terms (or, maybe, I'm just thick), and anyway not exactly right because you're using a computer with finite numbers producing a finite space. So just extend the original polygon you're interested in to be some massive thing, clip that against the bounds of your coordinate space to make a finite polygon, and proceed with a thoroughly-standard "does this polygon overlap the region defined by this collection of infinite planes?"

For the sort of objects you might expect an 8-bit computer to handle, you can probably brute-force your way to finding the optimal decision tree per object, which will be a function of the order in which you add planes to the tree.

* in that for small data sets, more complicated algorithms are often slower than brute-force. Though you could precompile the decision tree here for a definite speed improvement, at the cost of memory. But you still might end up not saving anything, or saving very little.

----

Minor addendum: there's actually lots of things in Sam Coupé 3d that I'd do better now, but actually the most striking is the manner of line clipping. That version does a full-on linear interpolation to find where each line hits each frustum edge. I should have used a binary search. What a dunce.

I saw that! I definitely want to find an opportunity to read it; I never really figured out how object sorting worked in the original — if it were me writing the original I'd have gone with separating axis-aligned planes, but I couldn't get anything based on that to match the empirical behaviour of the original. Hmmmm.

(So in OpenGL I just used a combination z-buffer, polygon offset and stencil, in an attempt to get what amounts to "plot if z <=, allowing a little for numeric instability")