Re: Misc: Applications of small floating point formats.

On 8/2/2024 7:07 PM, Lawrence D'Oliveiro wrote:

On Fri, 2 Aug 2024 03:56:35 -0500, BGB wrote:
 

For batch rendering, it doesn't really need to be efficient though.

 Of course it does. Ray-traced renderers can compute hundreds or thousands
of rays per pixel, taking anywhere from minutes to hours per frame. This
is how you produce those cinema-quality 4K (or even 8K) frames. Anything
that can shave a little bit off the time for a single ray computation can
very quickly add up.
 

You don't do raytracing in OpenGL...
That is not the point of using it.
Similarly, not everything needs raytracing.
For many uses, rasterization is fine.
For a lot of shows, you don't even really need 3D.
Say, if one was doing a primarily 2D animated show (such as anime), there is no need for a raytracer.
One might instead go the other direction, and use a 3D renderer with a cel-shading filter to try to make it fit better with the anime characters (though, cel-shading didn't really seem to gain popularity until after the rise of hardware capable of fragment shaders).
Like, in a lot of early 2000s anime that used 3D effects, there was a bit of "jank" where the 3D rendered parts often didn't quite match up with the drawn look of the anime characters.
But, to some extent, in the 2000s, people got used to the look of anime characters imposed on top of 3D rendered backgrounds and the occasional off-looking 3D model...

General strategy would be to setup a context, render to the context, and
then fetch the rendered image using glReadPixels or similar.
>
The "glReadPixels()" function is not exactly new...

 Almost verging on useless, in my (albeit limited) tests. OpenGL, Vulkan
and the like are targeted towards on-screen rendering, and that’s what you
should stick to using them for.
 

If you don't need fast screen fetch (which you don't for batch rendering) then "glReadPixels()" works fine.

Don’t confuse this with the fact that programmable GPUs are adaptable to
run SIMD-oriented compute APIs like OpenCL/SYCL (and their proprietary
rivals), and that these are commonly used to implement high-quality
offline renderers like those I mentioned above. These have nothing to do
with OpenGL.

The examples I gave (for TV shows) were pretty much all from the era of fixed-function hardware.
Granted, the use of fixed-function and low-dynamic-range rendering was fairly obvious (one can watch these shows and have a fair idea how they implemented nearly every graphical effect in the show).
Say, for example:
   Lighting: Looks like GL_LIGHTING;
   Shadows (N/A for early seasons of ReBoot):
     Likely depth-pass stencil shadows.
   Shiny surfaces:
     Use an ambiguous texture and normal vectors to calculate coords;
     Basically, the texture warps in a way that it looks shiny.
     Looks like ReBoot was mostly using a Perlin noise / clouds texture.
     Though, some other cases also look like cubemaps.
   Reflections:
     Render scene from a different orientation;
       fetch pixels, reload this into a texture;
       Render the scene using the reflection texture.
There is a different way of rendering reflections, namely rendering the scene multiple times with a a mirror-flip applied, and some trickery with the depth-ranges and Z-buffer. Quake 3 and Doom 3 used this effect, but examples in ReBoot are more obviously being done with texture maps.
As I can note, nothing in these shows seems terribly out of place for OpenGL 1.x ...
Likely, the renderer for the shows was comparable to Doom3 but without the use of shaders, and likely allowing for bigger scenes by not being constraibed by rendering time (though, these shows do seem to be rather sparing with the use of light sources).
...
Otherwise:
In my case, the OpenGL implementation is mostly backed by either a software renderer, or a limited hardware rasterizer (edge walking with affine texturing).
Though, I had started working on adding support for RGBA32 rendering.
Ironically, my implementation doesn't have direct rendering to the screen or a window as of yet, so fetching the framebuffer image and then manually drawing it to the screen or window, is how it is done in my case.