Category: Uncategorized

The effects system : Take 3?

I made a u-turn and totally scrapped the idea of having an effect expose a collection of cameras in order to have visibility sets generated for additional views. Instead, I opted for an effect interface which supports both external and internal potential visibility set generation; external generation reuses the visibility information from the effect subtree culling process vis-a-vis the main camera. Internal generation allows an effect to manage its culling strategy and come up with its own visibility set(s) given an instance of the currently active culler. In doing so, the determination of visible elements for additional drawing passes (such as shadow map generation) is fully customisable and active only within the scope of the effect. Moreover, the main culling process, which is concerned with culling objects which are not in the main camera frustum, needs not be concerned or involved with specialised culling instances. While pondering on how to actuate an all encompassing design, it struck me that some effects may actually be optimised through the provision of precomputed visibility sets. Being in control of the culling process, I could now apply local optimisations to the culling process, instead of having sets generated for me by a delegate which is potentially ignorant of any such optimisations.

This new scheme brought its fair share of woes, nevertheless. Since internal culling is now an offshoot and no longer managed externally, sorting visibility sets does not come for free anymore. Therefore, being stuck with an unsorted set, I chose to provide the effects framework with an interface by which sorting can be managed internally too. Again, although the set can be sorted straight away by a call to the currently active sorter instance, some local optimisations can be carried out which a generalised solution cannot provide, which one might as well take advantage of.

This new setup provides a flexible and extensible foundation for effects. Of course, the proof is in the pudding; I will be able to fully assess the ramifications of the current design only once I’ve actually built some complex effects and had them integrated within the scene graph (the first of which I’m off to build is effectively shadow mapping).


RIP 7900 GTX

It seems like the next update will have to wait – my laptop’s video card is busted! It was during a perfectly normal Windows session, that, all of a sudden, the desktop froze and the only way out was rebooting the machine. When the BIOS screen came up, it was evident something was not quite right – a display overlay of green vertical stripes is usually not a good sign. Well, to cut a long story short, I could boot neither Vista nor XP except in safe mode. I tried re-installing the video card driver but to no avail – the vertical stripes from hell have made a comely abode out of my display.

Since the last post, I have been working on a scene graph system and a high level pipeline for culling, sorting and rendering it. The pipeline consists of fully customisable modules, which can be extended or replaced at will, through the plug-in system. The culling module, for instance, is input a node of the scene graph and outputs a set of potentially visible entities. The culling strategy is up to the user to decide; so far, the core culling module only provides frustum culling of bounding volume hierarchies. Eventually, there will be implementations for various space partitioning schemes.

From the culling stage to the sorting stage: the entity set output from the culling stage is not optimally ordered or sorted for rendering. During this stage, the visibility set is sorted to provide a queue optimised for drawing operations. The basic implementation of the sorting module organises geometry, grouping it together using its material properties (render state changes, shader programs and textures), and comes up with a number of batches which, when rendered in the specified order, reduce the number of state changes. Although various sorting strategies will be made available, if none satisfy specific user requirements, the framework empowers the user to write his own sorting plug-ins.

The rendering module may take its input from the sorting stage or directly from the culling stage. Basically, when drawing from the sorting stage, entities are batched, grouped by specific criteria. On the other hand, drawing directly from the culling stage implies that no optimisation is performed on the input set, and accordingly entities are rendered one by one. So, fundamentally, the high-level rendering interface supports two modes of operation: batch and immediate. Being fully customisable, rendering modules allow a great deal of control over how scenes are rendered. It will eventually be trivial (I hope) to switch between, say, forward and deferred shading.

The next stage of development is the effects system, which is very much inspired from David Eberly’s Wild Magic engine ( With the effect system in place, I will have a framework within which to implement multi-node effects such as shadow mapping or planar reflections.

With my XPS out of the way, I thank the good Lord for providing me with a machine I can do some development on, until my trusty laptop is back home.

Meson : Vistas

Finally I got around posting a short video of Vistas on youtube. At this stage, there isn’t much to show bar some simple parallax-mapped primitives illuminated by a point light. As it stands, I have completed the driver abstraction layer, shader and geometry sub-systems and am currently working on the scene graph system. I should be able to post some more complex scenes pretty soon, if everything goes according to schedule.