Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Aug 2008
Offline Last Active May 08 2013 10:46 AM

Topics I've Started

Sending thousands of uniforms to a shader. (3.2 -4.0)

13 March 2012 - 06:17 PM


I'm trying to get a lot of light data into a shader to perform deferred lighting.

The lighting system populates the screen with 32*32 tiles, which are drawn instanced onto the screen. Each tile needs to be fed the data for 8 point lights.

I'm struggling to get my head around how to get the data to the shader in GLSL. Currently I have a large UBO with all the tile light arrays in, and can rebind the UBO at the correct data struct for each tile. However, when doing this, I can't use a single instanced call. So thats not fast enough.

Is there any way I can just bind the whole UBO? Trying to define a large array in GLSL (understandably) causes the shader not to link.

I know I can do this relatively easily by packing the data into a texture, but I'd like to know if there is a more intuative way that fits the uniform paradigm.

Next generation renderer design.

24 November 2011 - 11:22 AM

So if you read my last thread I'm looking into renderer design for an upcoming project. Having decided to roll my own I'm now looking for good resources for designing a such system. This thread is going to be something of a ramble!

Since I am doing this for a AAA quality game it has to work, but I am also doing it for my doctorate so I have to defend and reference any of my choices, even ones made in my gut. :D Any book suggestions would be great. I already use the GPU Gems series and Games programming Gems series with Game Engine Architecture, and Game engine Gems 2 in the post. So far, while there are tons of great titbits of knowledge to be found, a nice rounded next gen architecture hasn't been documented anywhere to my knowledge.

I'm no stranger to building renderers, but often I find my designs fall short at implementation. Heres areas I need to consider:


The core render would sit on a separate thread and run continuously. Render calls would be sent via an interface on the game thread and communicated via a buffer. Perhaps a lock-less ring buffer of some sort, or a set of buffers set to ping-pong.

Calls would be made by providing a function (pointers or handles to) a mesh object, a material (shader + textures), a culling volume, a transform and an ID of the targeted rendering stage. How would you organise your shader uniforms? In terms of organisation it makes sense to have them inside the material bundle, however that means different objects will need different materials increasing the amount of binds I will need to do. If I keep them separate then models using the same material can skip its shader and texture bind stage, but that leaves the question of how to neatly deal with uniform variables.

We also want shaders and textures to be able to be swapped in at realtime. No company I've ever worked at has managed to make that happen as fluidly as the artists would like, what design considerations would you make to make it easier? My first thought is a material manager which would centralise the change over by tracking relationships between assets etc at for a small overhead in artist's builds.

Render passes:

The implementation of the renderer in the game will be deferred, with a latter forward stage for transparent objects. We will have perhaps more than 20 passes in some frames so I need to build a compositor that artists can access and fully control.

I'm thinking I will make the render passes system reasonably generic, with no "fullscreen effect manager" or other classes to differentiate between pass types. The passes will probably be broken down into 3d and 2d/compositing. I will probably create a node based system that is scripted via XML with a series of inputs and outputs.


Since I'm not sure if I'm going to get pre-culled data from the game engine yet I'm not sure if I'd implement it. Most likely it will just be a Frustum-sphere/AABB test.

I'll add to this as I think of more issues for the design.


Edit: Clarified my tired ramblings a bit.

Graphics engines and middleware.

08 November 2011 - 01:04 PM


I'm currently studying the state of graphics engines and middleware to decide on the direction for a major indie title I will be working on. The current engine of the studio is a well known, stable, commercial engine, but has been left behind in the DirectX 8-9 era and would need to be significantly rewritten to hit the requirements of our new project. We are looking at things like many dynamic moving light sources (so probably differed lighting), soft shadowed point lights, large amounts of reflections and a heavy emphasis on costly post effects such as motion vector driven blur.

Currently I am thinking of just writing my own renderer from scratch. This doesn't phase me, and due to the very specific brief of the project, I can literally build what I need.

That said, it would be foolish not to consider every other option. What rendering engines do people recommend?

I've looked at Ogre and it seems promising, however I havnt seen it proven commercially. I'd worry that integration would also be a pain in the ass, since we'd need to mash it in with the current engine.

Any pointers would be great. I'm considering anything from small open source solutions (preferably MIT license or similar since releasing source can raise problems) to larger commercial systems, such as Englighten(standalone). Platforms are PC, Ipad and perhaps consoles depending on platform holder whims.



GCC/MinGW vs Visual studio: Code behaves differently.

27 June 2011 - 07:31 PM

I have a large game that I'm porting from a different language to C++ and SDL.

I got it built and running great in VS. Ported to Linux and got strange behaviour. I don't really want to step through it all as the system is very complex and its not my code.

I put the code into MinGW in Windows and got the same bug. I've cleaned up all the important warnings in the project and the remaining cast related ones are unlikely to be causing this.

Is there anyway to get MinGW to behave more like the VC compiler? Or indeed visa-versa, so I can debug in Visual studio?

Thanks in advance


Proper profiling of opengl + GLSL

14 December 2010 - 11:56 PM


Last night I decided to push for a better frame rate from one of my projects. I stripped all my game code... got 33 fps. I then stopped all the rendering and pre-processing of models. ...and got 40 fps. Killed my differed lighting passes... 45fps. Killed everything apart from bloom, crepuscular rays and fog 50fps. killed the rays, fog and bloom 55fps.

After this "fun" adventure, I realised that I really need some proper profiling tools. I'm looking for something like Pix or Gpad. Where I can perform a capture and then poke through a breakdown of my rendering.

I saw gDEBugger now has a free license, and tried it out. Its useful, but nowhere near as much as a frame capture in a professional tool.

What is everyone else using?