Mikko Rasa [Tue, 28 Aug 2012 10:18:41 +0000 (13:18 +0300)]
Route rendering calls through Renderer and add an exclusion system
This is necessary for generating environment maps for an object, since
the object itself should not be included in the map. The alternative is
to create a separate Scene, but that's rather clumsy.
Mikko Rasa [Tue, 28 Aug 2012 09:10:38 +0000 (12:10 +0300)]
More efficient stack management
Vectors are better than lists, since they don't need to allocate new
memory for every element. A suitably sized reserve() does away with any
initial reallocations in most cases.
ProgramData in Renderer can be stored in a semi-independent stack as
well, since it can only be removed with a pop. State is now devoid of
dynamically allocated memory, making the stack operations even faster.
Mikko Rasa [Tue, 28 Aug 2012 08:30:30 +0000 (11:30 +0300)]
Fix color equations in the standard shaders
The generated shader code assigned a scalar to a vec3 if lighting was
enabled without texture or material. An unnecessary multiplication in
the alpha equation with texture but no material was removed.
Also fix texturing in the shader demo (Mesa does funny things with
uniforms).
Mikko Rasa [Tue, 28 Aug 2012 07:50:17 +0000 (10:50 +0300)]
Provide the necessary uniforms from ShadowMap
With the recent changes to the Effect and Renderer, it's finally possible
to avoid the need to specify the shadow map texture unit everywhere, and
get rid of the hardcoded gl_EyePlane* indices.
Mikko Rasa [Tue, 28 Aug 2012 07:39:19 +0000 (10:39 +0300)]
Tweak the shader functions in Renderer
Since ProgramData is no longer tied to a single Program, we can retain it
over program changes. This opens up some new possibilities, in
particular for Effects.
Mikko Rasa [Sun, 26 Aug 2012 21:38:08 +0000 (00:38 +0300)]
Pass the Renderer to ObjectInstance::get_level_of_detail
As I recall, the camera was put in renderer to allow view-dependent
rendering without the need to pass data outside the rendering pipeline.
This is one of the cases where it is needed.
Mikko Rasa [Sun, 26 Aug 2012 12:03:21 +0000 (15:03 +0300)]
Improve performance of Bufferable::update_buffer_data
... by avoiding the walk through the entire chain every time it is
called. It's not necessary to add up all the sizes either, since we can
just get the end of the last Bufferable.
Mikko Rasa [Sun, 26 Aug 2012 10:09:44 +0000 (13:09 +0300)]
Get all blocks for the program before applying them
This way, the correct size for the buffer can be determined right away,
rather than each block resizing it in turn. Binding the buffer before
applying the blocks also avoids some thrashing.
Mikko Rasa [Sun, 26 Aug 2012 07:53:56 +0000 (10:53 +0300)]
Alter the working logic of Bufferable to avoid some problems
It was possible for the buffer data to be updated without going through
the dirty check in UniformBlock::apply, leaving the UniformBlock with a
null buf_range and resulting in a segfault.
Mikko Rasa [Wed, 22 Aug 2012 13:17:34 +0000 (16:17 +0300)]
Remove the specialized setters from UniformBlock
They were not very useful and were also getting in the way of uniform
buffer support. UniformBlock also no longer clones the uniforms for
itself, reducing overhead.
Mikko Rasa [Wed, 22 Aug 2012 12:28:40 +0000 (15:28 +0300)]
Make RenderPass shprog and shdata settable from code
For consistency with other similar interfaces, the pointers are now
const. As a consequence, a uniforms statement in a datafile overrides
any previous uniforms.
Mikko Rasa [Mon, 20 Aug 2012 13:13:46 +0000 (16:13 +0300)]
Simplify Pipeline pass management
Originally I planned to use Pipelines to bundle objects with effects like
environmentally mapped reflection. However, that task was delegated to
effects themselves recently, so there's no longer need for passthrough
rendering in Pipeline. The render_all function was also a nuisance, as
it required Pipelines to be treated differently from other Renderables.
Passes are now stored in a list instead of a map. This allows multiple
passes with the same tag (think multipass lighting), and avoids the need
to store the pass order separately.
Mikko Rasa [Mon, 20 Aug 2012 12:39:26 +0000 (15:39 +0300)]
Move PipelinePass inside Pipeline and make the data members private
It's really simple and specific to Pipeline, so it doesn't make much
sense to have it as a separate class. Encapsulation is necessary for
some future plans, and also more consistent with other public interfaces.
Mikko Rasa [Sun, 19 Aug 2012 23:46:45 +0000 (02:46 +0300)]
Use the hash function from mspcore
Constructing tags mostly happens when loading datafiles or otherwise
outside the rendering loop, so the small extra overhead from a
cross-library function call is not significant. Renderables that wish to
compare the Tag against a fixed value should avoid constructing the
reference Tag on every render call anyway.
Mikko Rasa [Thu, 16 Aug 2012 16:46:12 +0000 (19:46 +0300)]
Turn Effect into a Renderable
They were really intended to be used this way. This also makes it much
easier to apply an Effect to only a part of a scene. Previously it would
have been necessary to wrap the Effect in a Pipeline, which doesn't
really support passthrough.
Mikko Rasa [Wed, 15 Aug 2012 19:36:33 +0000 (22:36 +0300)]
Restructure ProgramData to support sharing between Programs
This removes a major annoyance when dealing with ObjectInstances and
shaders. It also paves way for Effects being able to provide uniforms,
and support for GL_ARB_uniform_buffer_object.
Mikko Rasa [Wed, 15 Aug 2012 19:18:09 +0000 (22:18 +0300)]
For a few lingering whitespace issues
The scripts had been ignored entirely in the previous conversion. As a
result, a few newly generated extensions didn't have proper whitespace.
Pure virtual functions in headers had also slipped through.
Mikko Rasa [Mon, 13 Aug 2012 17:47:53 +0000 (20:47 +0300)]
Lookup functions to determine the orientation of cube map faces
The orientations are somewhat arbitary and not deducible with a simple
algorithm. Writing the necessary conditional ladders everywhere would
be annoying.
Mikko Rasa [Sat, 11 Aug 2012 13:38:35 +0000 (16:38 +0300)]
Don't link program with the transform feature in constructor
The transform feature produces calls to external functions, which need to
be added in a separate shader. Trying to link in the constructor only
produces link errors.
Mikko Rasa [Sat, 11 Aug 2012 13:36:30 +0000 (16:36 +0300)]
Better way to deal with program-owned shaders
Track which shaders exactly are owned by the program rather than having
just a single flag. This prevents double-free problems if a program
contains both owned and non-owned shaders, as might be the case with the
transform feature.