padrend / rendering Goto Github PK

Initially reported by @ClaudiusJ as #558:

E.g. to have a simple way of modifying particles using a pixel shader:

Texture t( 1000x1000, correctFormat );
initParticlePositions( t )

Mesh m( correctFormat );

loop{

  // update positions using a shader
  Texture t2 = renderFullscreenQuadToTexture( t, animationShader )


  // attach new coordinates to mesh
  swap( m._accessVBOBuffer(), t2._accessBufferObject() )

  // render particles to screen
  ...
  m.display()
  ...

  // move vertexData back into the buffer.
  swap( m._accessVBOBuffer(), t2._accessBufferObject() )
}

Initially reported by @ClaudiusJ as #531:

As lightweight alternative to the use of Meshes ('I want to draw a single line without creating a Mesh.')

Initially reported by Benjamin as #581:

At the moment, there are many calls to ​glEnableClientState/​glDisableClientState when not using a shader, or to ​glEnableVertexAttribArray/​glDisableVertexAttribArray when using a shader. This is because we do not cache the previous value, enable all states/arrays in MeshVertexData::bind and disable them again in MeshVertexData::unbind.
A low-level caching of every array might be too tedious, but maybe one could only change the enabled states/arrays when changing the VertexDescription.

The trace shows that maybe even the calls to glBindBuffer(..., 0) are superfluous.

Initially reported by @rpetring as #83:

Splitting triangles till max size of Triangle < threshold
Splitting meshes into two parts
Splitting meshes till size of mesh < threshold
Splitting meshes till #polys in mesh < threshold

Splitting GeometryNodes till ...

Initially reported by @ClaudiusJ as #612:

Example file is appended.
Forest-experiment-1-mesh.zip

Initially reported by Benjamin as #534:

If the MeshBuilder::create... functions get a MeshBuilder instance, things like combining or transforming meshes would be much easier.

When using the fixed function pipeline on a Radeon graphics card, textures bound e.g. to unit 6 result in a flickering due to missing texture coordinates (e.g. when the SSAO2 PP-Effect is enabled). On graphics cards from other vendors, those textures are ignored.

This is part of the redesign (see #10).
To have a base for discussion, I created a first draft, how the new classes might look like:

Initially reported by @ClaudiusJ as #514:

Something like this:

rc.pushAndResetLightingContext() // all lights are off
rc.pushLight( someLightParameter ) // one light is on
...
// do something with this one light
...
rc.popLightingContext() // restore the old lighting

Initially reported by @ClaudiusJ as #704:

"setTexture(...)" binds the given Texture to the texture unit.

"markTextureUnitEnabled(...)" sets the given texture-enabled-uniform to true and enables the gl texture state (glEnable(GL_TEXTURE_??) for the fixed function pipeline.

This is needed for setting (=binding) textures that should not be used for normal rendering. (Problem: reflection textures, fixed function pipeline and AMD-graphics card...).

Implement AFTER Diss-related measurements are finished!

Initially reported by Ralf as #600:

if this->bufferId was not 0 before, the memory gets never freed...

BufferObject & BufferObject::operator=(BufferObject && other) {

    Handle self-assignment.
    if(this == &other) {

        return *this;

    }
    bufferId = other.bufferId;
    Make sure the other buffer object does not free the handle.
    other.bufferId = 0;
    return *this;
}

While looking at some classes in Rendering, I got some ideas for a redesign. I collect them here. When you want to implement parts that are mentioned here, please create a new issue to track the progress and mention it here.

• The RenderingContext should be passed to all functions that call gl* functions.
• Functions that are marked as deprecated as of OpenGL 3.3 should be removed completely.
• Something like an MemoryObject should be added as a representation of an array in memory (see #11). There should be two main manifestations of it: A MainMemoryObject (something like std::vector or Util::Bitmap) and a GraphicsMemoryObject (a BufferObject or Texture). Functions like upload and download could convert between the two types (maybe using specialized template instantiations). They can be used in Texture and Mesh (see also #6).
• The previously mentioned MemoryObjects should be used inside a Mesh to allow different Mesh configurations (no or single IndexData, single or multiple VertexData).
• Keep track of Meshes and reduce the number of state changes required during rendering (see #3).