Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 03 Oct 2000
Offline Last Active Today, 10:10 AM

Posts I've Made

In Topic: An alternative to the Sponza mesh for demos?

02 March 2015 - 11:43 AM

I went looking for a similar thing when the sponza got a bit boring and I quite like the Natural History Museum model from here: http://www.3drender.com/challenges/

IIRC it might require a bit of tidy up with the materials (but it's been a long time since I grabbed it).

In Topic: Simple Alternative to Clustered Shading for Thousands of Lights

22 February 2015 - 05:29 AM

This is really great, thanks for taking time to share this.

In Topic: Propagating data through an engine to constant buffers

02 February 2015 - 05:00 AM

Just throwing in another idea that's a slight change on the render key approach that I'm trying recently:


In my hobby engine I maintain a list of sorted material instances - they're sorted by state, shader, texture and hashed constant data. They don't need much sorting after being loaded (changing material params or streaming in new materials requires another small re-sort). I sort these much like you would with a render key and maintain a list of indices into the material instances. Additionally, each material instance also knows its sorted index.


When I render, rather than trying to pack lots of info into the render key, I make use of the fact that the material instances are already sorted and simply use the material instance's sorted index + mesh data (vb/ib handles munged together) to then sort the data. I can also pack depth in at this stage since I don't need much space for material index (14 bits currently and that's overkill for my needs).

In Topic: Preserve rendering order with queues

20 December 2014 - 10:07 AM

I do mine a little differently as I hit upon the same issue. Each time I change high-level state*, the state information gets saved off into a separate buffer. The index to that state information is what goes into the command bitfield, along with any draw calls that follow. It lives higher up in the bitfield so during sorting, those states are preserved for the appropriate draw calls. 


I currently use different command buffers for different bits of the pipeline e.g. per shadow frustum, main render and post process. This keeps the number of state changes per single buffer down.


* By high level state, I mean things like blendmode, viewport etc - changing shader, texture and vertex formats get rolled into the regular bitfield. I could also have custom commands for things like perform-clear or generate-all-mips etc since the separate state buffer can encode anything I want (and isn't restricted to 64 bits).

In Topic: UE4 IBL / shading confusion

27 June 2014 - 01:23 PM

3) Not sure about the precomputed textures - are your inputs mapped differently to his? I've used an empircal EnvironmentBRDF for playing around at home (similar to the one in http://blog.selfshadow.com/publications/s2013-shading-course/lazarov/s2013_pbs_black_ops_2_notes.pdf) and haven't tried that approach yet (it's on my list though). The 1024 samples he takes in the sample code is (I assume) for generating the reference version so he can see how close the split-sum approximation gets.