Difference between revisions of "LibSR:Proof of concept"

From Maths
Jump to: navigation, search
(Created page with "There's an old proof-of-concept implementation written in C++, it supports depth tests, vertex and fragment shaders, and there's limited work on texture objects, oh and render...")
 
m (Fixing template change - this was the only place ckw was used.)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 +
==Overview==
 +
This was a rushed proof of concept, nothing more. The critical things that needed to be proved were:
 +
# A natural handling of shader variables, code must read {{C|1=z=x*y}} not {{C|varyings.assign("z",MAT4F::Multiply(varyings.get("y"),varyings.get("z"));}} or something, and statically typed.
 +
#* ''Both'' of these were achieved.
 +
#* However there was a problem, due to the {{C|{{ckw|virtual}}}} methods in play (among other things) it was slow, also it could not be easily made parallel, a re-write would be easier.
 +
# How a rasteriser might work (see: [[LibSR:Rasteriser]]), its performance and so forth (the [[LibSR:Proof of concept rasteriser]] was very poor indeed).
 +
 +
 +
 +
=Stuff to go on page=
 
There's an old proof-of-concept implementation written in C++, it supports depth tests, vertex and fragment shaders, and there's limited work on texture objects, oh and renderbuffers, so it is double-buffered.  
 
There's an old proof-of-concept implementation written in C++, it supports depth tests, vertex and fragment shaders, and there's limited work on texture objects, oh and renderbuffers, so it is double-buffered.  
 
I often show the following screenshots:
 
I often show the following screenshots:

Latest revision as of 08:18, 1 October 2017

Overview

This was a rushed proof of concept, nothing more. The critical things that needed to be proved were:

  1. A natural handling of shader variables, code must read z=x*y not varyings.assign("z",MAT4F::Multiply(varyings.get("y"),varyings.get("z")); or something, and statically typed.
    • Both of these were achieved.
    • However there was a problem, due to the virtual methods in play (among other things) it was slow, also it could not be easily made parallel, a re-write would be easier.
  2. How a rasteriser might work (see: LibSR:Rasteriser), its performance and so forth (the LibSR:Proof of concept rasteriser was very poor indeed).


Stuff to go on page

There's an old proof-of-concept implementation written in C++, it supports depth tests, vertex and fragment shaders, and there's limited work on texture objects, oh and renderbuffers, so it is double-buffered. I often show the following screenshots:

LibSR POC 1.png
Example showing a Fragment shader which renders a red border around quad

patches where the light is below a certain intensity.

LibSR POC 2.png
The corresponding Vertex shader showing how Uniform variables and

Varying variables are bound to shaders.