fwilliams / fgfx

A typesafe OpenGL abstraction

FGFX

A lightweight typesafe 3D graphics abstraction based on OpenGL. The goal of this project is to automate a lot of the tedium that comes with writing OpenGL code. This library depends on glm for vector and matrix types and operations.

Type safety

By using type information, the interface between GPU and CPU code is vastly simplified. In addition the abstractions provided by this framework are typesafe, preventing many errors which would normally only be caught at runtime. In addition an OpenGL traits library is provided, allowing static conversion from types to OpenGL constants.

Shader compiler

FGFX automates many OpenGL tasks such as shader compilation and linking. In addition, the FGFX shader compiler supports external defines, as well as includes for modular shader development.

Context and window creation

FGFX provides a simple API for OpenGL context and Window creation based on GLEW and SDL 2. The API allows fast prototyping of interactive 3D applications.

fgfx's Issues

ShaderProgram introspection

• Get names, values, and locations of uniforms
• Get names, and locations of vertex attributes

Implement curreng gl_traits with all supported OpenGL 3.3 types

Implement

• is_glsl_type<T>
• dim<T>
• value_type_id<T>
• gl_type_id<T>
• container_type<T>

such that T can be any glm or fgfx type with a corresponding GLSL type supported by OpenGL 3.3

Look into BOOST MPL to do this easily

Investigate BOOST MPL for gl_traits

See if gl_traits code can be reduced with boost MPL

Create move constructors/assignments for Tuple

Ensure move semantics exist for gfx::Tuple objects and are recursively applied to all members.

Add padding types to tuple

• Create Padding<size_t N> type such that sizeof(Padding<N>) is N bytes
• Have tuple ConsCell "ignore" Padding structs. That is, for a tuple of type Tuple<int, Padding<2>, float>, the 2nd item (get<1>()) is of type float.

Generate VAO offset value will always be 0

The offset of the tuple element is computed as 0 which is not correct. ListElement<0, C> treats C as the first element of a list whose offset in that list will always be zero. A naive solution is to pass the recursively through the EnableAttribArrayAOS metafunction, but its worth investigating a better way.

Tasks:

• See if there is a clean way of fixing this without passing offset through metafunction
• Implement fix
• Add offset tests for this metafunction

template <size_t I, class ConsCell>
struct EnableAttribArrayAOS {
  inline static void enable(size_t stride) {
    typedef typename ConsCell::HeadType HT;
    typedef typename ConsCell::TailType TT;
    typedef ListElement<0, ConsCell> LE; // <=== The offset of this list element will always be 0 because of the 0 parameter cause ListElement to trea ConsCell as the head of the list

    glEnableVertexAttribArray(I);
    glVertexAttribPointer(I, utils::dim<HT>(), utils::gl_value_type_id<HT>(), GL_FALSE, stride, (void*)LE::offset());

    EnableAttribArrayAOS<LE::offset() + OFF + sizeof(HT), I+1, TT>::enable(stride);
  }
};

Design framework to guarantee vertex attributes are bound correctly with shaders

This is to be a static solution based on types. The strength of this approach is correctness can be achieved mostly at compile time. Run-time checks can also be implemented with minimal overhead.

The workflow this works well for is as follows:

• Import some kind of geometric data where the vertex data types are known ahead of time.
• Edit shaders with this vertex data, possibly removing attributes which are no longer needed.

If new vertex attributes are added to the shader, a recompile could be necessary if the type of vertex isn't available.

Currently, we take the types in a tuple and assume each entry will be used in order in a shader. That is, for a Tuple<T1, T2, ... TN> the ith value of type Ti is bound to location i in the shader program. This may not be the case because:

• Some vertex attributes may not be used causing the order to be incorrect.
• Vertex attributes may be declared in a different order than in the Tuple without layout parameters to specify location

Some possible solutions (Note this is an Idea dump):

• Include attribute names in the vertex type
  • Pros
    • Vertex attributes will be matched correctly by name in the shader
    • Allows for matching vertex type with shaders (error checking)
  • Cons
    • Vertex declarations become more verbose
    • Shader names must match vertex names
  • Misc
    • Can reduce declaration overhead by accepting vertices of type Tuple<T1, ...., TN> for shader type Tuple<T1,N1,...,TN, NN> where Ni is the name of Ti.
• Match the vertex types in order against the attribute types using shader introspection
  • Pros
    • Vertex declarations are simpler
    • No knowledge is required on the client or server sided about naming of vertex attributes
  • Cons
    • Can't do proper error checking in all cases. Types could match but semantics could make no sense
• Decouple vertex attribute names from vertex types. That is, a GLSL Vertex consists of a list of types, a list of attribute names, and a layout (struct of arrays v.s. array of structs)
  • Pros
    • Vertex information is broken into distinct parameters
    • Can implement many ways of specifying the information on top of this
  • Cons
    • More work to implement abstractions over this
  • Misc
    • BOOST MPL might make implementing abstractions easier

Design texture classes

Design classes to wrap textures of type:

• GL_TEXTURE_2D
• GL_TEXTURE_CUBE

Texture class

• Create classes and functions to create them in the context
• Add traits to gl_traits to handle these texture types
• Set data / subset of data for a given mip-map level
• Create methods to set sampling parameters for a texture

Augment context to bind textures to texture units

• setCurrentTexture() method
• getCurrentTexture() method
• store textures in texunits
• Have a superclass for textures to allow texture aggregation

Have GLProgramBuilder handle multi-level includes

\#pragma include should work for multiple files.
Call preprocess every time a new file is included up to some maximum recursion depth