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!


Ashaman73

Member Since 10 Nov 2006
Online Last Active Today, 01:21 AM

Posts I've Made

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

Today, 12:05 AM


So I’m hoping (lots of hand waiving, I don’t really know yet...) that with the coherency of nearby pixels traversing similar paths of the BVH, the bandwidth consumption and cache misses will not be too much worse than with clustered.

I've done some testing with a quick BVH implementation to check the number of nodes read. I will not present my result, because the implementation is quick and dirty and would most likely not represent your work. Nevertheless, the question that arose was the number of how many nodes you need to touch per pixel in average. Eg the spheres in a spheretree get quite big really fast, and all the not light related spheres will increase the overhead of all pixels, even if you have unlit pixels etc. So, if you have pixel lit by 100 lights and you have an overhand of X nodes, it is quite cheap, but if you have a pixel lit by none or only one light, X nodes is really expensive. A clustered/cell based shader would fit more tighly around the variable number of lights influencing pixel areas. The question is, how high is X under different setups ?

 

Just for testing this number I would implement the same search algo from the shader on the CPU to do some rendering simulation to get some quick statistics.

 

 

 


Ashaman73: I dont know how to post an article on here, but maybe I'll do that at some point though, if theyre interested in me doing that.

Check this out to get some infos smile.png


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

Yesterday, 05:05 AM


Sorry I'm taking the thread off topic here!
Do you have a single UBO containing an array with info on all clusters, and then you index that array?

I'm still using OGL2.1, thought UBOs are available as ARB extension. Up until now I have targeted more urgent buffer usages(most recently PBO texture streaming... yeah, I know, but time is a very valueable resource). UBOs in conjunction with animation data or light data sounds interesting, especially due to concurrently filling the buffers with multiple threads/jobs ... *making mental note for next engine improvement*.

I'm still somewhat curious about nextgl and what they will show off next month, so I'm a little bit careful with my coding time and hoping to add support of a modern,slim,cross platform,open APIsmile.png


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

Yesterday, 01:26 AM


In my experience with clustered, you store all the lights in the buffer in a very similar manner, except each cluster has a linear section of the buffer.

Yes, I think that this would be the more common way of doing it. I currently use the uniform way to do it in my engine.

 

 

 


So the main additional cost is doing a bounding sphere test per light that you visit, and iterating through the light array as a linked-list rather than a simpler linear array traversal.

It is more like a tree structure, isn't it ? Traversing a tree will, even if you will narrow down to the candidates quite quickly, still need to jump around quite often. The virtual nodes in this tree (which will not represent a light) would add atleast extra costs and if you need to traverse partly through a tree with 3000 leafs, then you could have a few cache misses and this for every pixel.

 

I would be interested in the expected overhead, would it be roughly x1.5 , x2.0, x3.0. The system could perform better on more realistic game setup (few hundred visible lights) with a much flatter tree structure.

 

Nevertheless, I found this approach very sexy. I could think about using it to add some extra eye-candy to the forward rendered stuff (particles) as option for people with hi-performance hardware.

 

PS: if you do the light calculation in the vertex shader you could push out lit particles with ease and with much better performance.

 

PPS: @fries: how about posting your approach as article on gamedev ?


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

Yesterday, 12:30 AM

Very interesting and good work smile.png

 

When taking a look at your technique, you would need to sample the memory quite often, compared to a clustered/cell deferred rendering pipeline, where the lights are stored as uniforms/parameters. So, my question is, how much bandwidth is your approach using ? How does it perform on a low-bandwidth system ? How much time does it take to rebuild the bhv and upload it per frame (dynamic light sources) ? How does it scale with number of lights ? How does it scale with the size of the render buffer ?

 

That is works with deferred and forward and a mix of it makes it really interesting, especially for the notoriously hard to implement lit particles and transparent surfaces in a deferred shader.


In Topic: Need creative help to make my game fun (Gauntlet Clone)

25 February 2015 - 05:07 AM


I suspect it has something to do with the fact that my game is not balanced yet - its way too easy at this point. ... This does make the game harder but its still missing that addictive fun factor that I really need.

Fun is always hard to define, interesting might be better. There are many ways to create interest like exploration (adventure), story, progress (RPG), challenge.

Gauntlet is a challenge game, you need to beat a level and progress to the next, if you fail, insert a coin and try to be better the next time.

 

Challenge an the other hand can be subdivided in multiple parts. For one you have a knowledge and a skill challenge. Skill is to learn the moves, the reaction to certain behavior pattern, whereas knowledge is to know how to counter a creature, what to prioritize first etc.

 

To increase the challenge you need to consider yourself as player, where would other players relate to you. As developer you will most likely have mastered the  knowledge challenge (because you coded the thing) and will be at least an advanced/expert skilled player. Therefor you have casual players, which will fail at what you will find as easy and you will have expert-fan who will surpass your skill by far.

So, for whom are you creating the game ?

 

If you want to increase the challenge for yourself first, try to increase all parameters quite drastically, like increasing hp, spawnrate, spawnpoints etc. Don't try to estimate what other players would find challenging, take yourself as reference player.

 

How does the game feels if you are barely able to reach the end ?

 

From this point I would try to establish different difficulty levels, take your own level as hard, have an easy and nightmare mode in mind. You can try to change some value to define a rough version of the different modes, whereas hard is your own level. Now try to get some testers at board and let them play your game.

 

Nevertheless, before adding more features to fill in the fun gap, you need to fix your core concept first.


PARTNERS