Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Misc: Applications of small floating point formats.
Date: Fri, 2 Aug 2024 20:54:47 -0500
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <v8k2ld$37juv$1@dont-email.me>
References: <v8ehgr$1q8sr$1@dont-email.me> <v8eloq$1qs1a$1@dont-email.me>
 <v8flo3$23t8l$1@dont-email.me> <v8h4iv$2e5g0$4@dont-email.me>
 <v8h8hv$2epjk$1@dont-email.me> <v8hg7p$2k3mm$1@dont-email.me>
 <v8hok5$2lec3$1@dont-email.me> <v8hruh$2m1tt$1@dont-email.me>
 <v8hv6d$2mklf$1@dont-email.me> <v8i709$2o7ho$1@dont-email.me>
 <v8jsbj$32llf$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 03 Aug 2024 03:54:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9f70a5d3aff46a986f34274d40582209";
	logging-data="3395551"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+JPos6h1jSTomZ1ivvo5DeKQFib/B6TVg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ijaPKsmG+nsVMh4JfTj82COKHKA=
In-Reply-To: <v8jsbj$32llf$3@dont-email.me>
Content-Language: en-US
Bytes: 5707

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.