Cool! I saw this link and your books came to mind as another example of how material like this is vital for seeing (amongst other things) how creative endeavours cope with ‘the other 90 percent’ of projects.
Quite a few games (eg: Starfox) in the 90's would use BSP in a slightly different way - purely within each object. The tree would be generated offline (mechanically or by hand), and would often be some sort of branching bytecode (test this, draw that etc.)
It was very useful to be able to use one plane test to discard a whole bunch of geometry, eg: a surface plus its detail, or everything visible through a window.
This still left the problem of sorting between objects - mostly a depth sort was just fine. Special cases like weapons on hardpoints, or vehicles in hangars could be handled by having some sort of 'call submodel' for spaces within the parent model. Beyond that, just dial up the hostile firepower until players stop complaining about rendering artefacts.
It might be interesting to explore with the students why this would not be quite right for a general 3D view, and how it could be fixed. Conic sections, etc.
The best GPU vector rendering library I have seen is https://sluglibrary.com/. The principal use case is fonts, but it appears that the underlying mechanism can be used for any vector graphics.
Random fact - the artwork was by Tom Ashton - previously the guitarist for The March Violets, also performed with The Sisters of Mercy, and went on to Clan of Xymox.
Also, this was the project I worked on before BRender - covered in another thread here.
There were three similarish software renderers around at that time, BRender, Canon Renderware (Adam Billyard), and Rendermorphics RealityLab (Servan Keondjian). There were also some renderers out of the demo scene that were definitely faster (but often with perf. related limitations).
The code was mostly C, with some protected mode x86 for inner loops. Prior to that point, all our PC games had been real mode x86- and BRender was a result of moving away from that.
It is! Although what I missed out from above is that whilst the API and it's documentation is the deliverable - we would, to the best of ability, try and minimise risk whist developing it. Eg: by doing small performance experiments, drawing on prior experience, thinking about the evolution of resources within the API whilst writing samples, and looking at how other APIs handle similar things (but be careful - they may have had to perform heroics to achieve their behaviour).
Whilst the official progress is top down, the duck's feet are working hard feeling along the bottom to check for obstacles.
Something I missed above is that either prior, or concurrently, there will be performance experiments to check that things are staying sane, but these do not contribute to the later software development (except as a reference) and are likely not consistent with each other. The deliverable at this point is only documentation - getting it good as possible without any concern for impact on existing implementation. The goal is to get as far up the slippery pole as possible - inevitably things will slide back over future version iterations.
The starting point for BRender was a sequence of software rendering experiments that grew from 'never doing it like our hand coded asm real mode x86 renderers ever again'. There were various diversions, eg: an achingly beautiful plane sweep that only rendered the visible parts of each output scanline, whilst murdering the cache so comprehensively that there are likely still lines waiting to be filled even now. Fortunately, to get the FX Fighter team going with something stable whilst debugging continued, I knocked up a Z buffer implementation, and was given a sharp lesson on caching when it blew all the previous attempts away (notably with consistency of performance).
Arriving at this point we figured there might be a product in it and looking at our own interaction with other libraries, it was clear that a manual was key to this. If I remember correctly, the API was a negotiation between myself proposing designs, and Crosbie Fitch documenting it - pushing back with ways to make things easier to explain.
It worked out very well, and we took it into later Argonaut hardware projects. The hardware guys had enough tools to do frame capture and replay from various games/apps at a low level, so were not desperate for a full software stack. The clients had very particular views about how APIs should look, depending on planned uses, in house style, compatibility etc. We would negotiate the API documentation back and forth - including lots of sample code.
This sample code was important, (and BRender would have benefited from more of this). I took lots of real use cases, then wrote proper code to implement them against the proposed APIs and included them in the docs as tutorial and example code. Importantly - they were a representative sampling of the anticipated uses (not just the easy ones), they were not 'handwavy' and included all appropriate resource management and error handling, and they had to read well on the page. As the API negotiation continued, so the examples and tutorials got updated.
This process also had the benefit that we only started investing in client specific software development once the project had got enough momentum (typically committing hardware NRE).