Jump to content

  • Log In with Google      Sign In   
  • Create Account


Frenetic Pony

Member Since 30 Oct 2011
Offline Last Active Today, 06:02 PM
-----

Posts I've Made

In Topic: Simulating lighting using volumetric meshes.

28 June 2014 - 01:44 AM

Sounds a lot like Crytek's Light Propagation Volumes, which never had enough precision for anything more than secondary illumination and increases memory requirements by squared or more as you extend the range of the illumination. Alternatively it also sounds like the same hack used by Bungie in Destiny/Irrational in Bioshock Infinite/Epic currently in UE4. All of them render lighting information to a volume texture which is then used for deferred rendering of transparencies. Trouble there is it's all too low of a resolution to get very good shadow information or good specular.

 

Here are some of the examples: http://advances.realtimerendering.com/s2013/Tatarchuk-Destiny-SIGGRAPH2013.pdf   http://www.crytek.com/download/Light_Propagation_Volumes.pdf


In Topic: Screenspace Shadow Mapping Help!?

06 June 2014 - 04:13 PM

 


"Efficient virtual shadow maps for many point lights" It's

I know this paper, it is still more theocrafting than practically useful (~15-20ms frametimes on NVIDIA GTX Titan GPU + Intel Core i7-3930K CPU isn't awesome for games yet). I've hoped for a more pratically useful solution, we will see what useful changes happens once the new API approaches/consoles kicks in.

 

 

Found that with shadow map caching it can work well for many dozens of lights. But indeed while hundreds may "possible" it's not practical on most systems. And you need all the overhead of the culling scheme, which is great if you're targeting hundreds of point lights to begin with. But we're still a long way off from having a city scene with hundreds of proper point lights, and I suspect that will just have to be brute forced one way or another.


In Topic: Screenspace Shadow Mapping Help!?

06 June 2014 - 12:33 AM

"Efficient virtual shadow maps for many point lights" It's basically an extension of clustered shading to also allow culling for shadow mapping, along with a few hacks (the "virtual" part) for the maps themselves.

 

So if you've already got clustered deferred/forward going on your halfway there, which is nice.


In Topic: Screenspace Shadow Mapping Help!?

05 June 2014 - 11:19 PM

 


Right now Telanor has chosen to use cube map shadow mapping for the point lights ( creating a big issue with peformance ).

That is the way to go:

add cube map shadow mapping for point lights

-> be happy about how cool it looks 

-> add more lights

-> see how bad the performance go

-> remove pointlights smile.png

 

To be honest, point light shadows are really extremely expensive, all shadow mapping variances are just too expensive to handle more than a handful of lights. One major issue is, that you need to render the scene multiple times which kills your performance by too many batches (this might change with new API approaches AZOD, Mantle,DirectX12), but for now shadow mapping is really,really expensive and real screen-space shadow mapping does not exist in any general, acceptable way.

 

The most common workaround:

1. use only point light shadows , if it is really necessary (even paraboloid shadow mapping), e.g. one major gameplay feature use one pointlight shadow

2. use shadow mapping for the most important light sources only (sun/moon plus some major light sources).

 

 

Nah, do enough work and you can get hundreds of point light shadows in the same scene. Culling is really a key, and not doing work when not necessary. Shadow map caching can do wonders for reducing everything from bandwidth to draw calls.

 

It's all a lot of work though, well documented work, but a lot of it. CSM scrolling has a basic overview for both point lights and a directional light: http://advances.realtimerendering.com/s2012/insomniac/Acton-CSM_Scrolling(Siggraph2012).pdf the basic idea is to check whether each light has a moving object inside its influence and then only the changes necessary, which should be a handful of objects if the point light is stationary and so is most of its environment.


In Topic: Metal API .... whait what

04 June 2014 - 07:41 PM

 

Eh, there's a market for most things. Many of this simpler games you see on iPhones and such won't need Metal, strictly speaking, but on the other hand, there are probably plenty of game ideas floating around where the current state of OpenGL ES on those platforms just isn't up to snuff, performance wise. The overhead of draw calls is still a very real thing, and on an iPhone with a relatively slow (compared to PC) processor that's aggressively throttled, running GLES which limits drawing to a single thread, effectively, you can hit a wall much more easily than you'd expect from a 'modern' device. I mean, Sweeny talked about achieving ~4 thousand draw calls per frame (at. I would guess, 30fps) and how that was such a marked improvement over GLES -- I don't know exactly how bad the situation was, but it must have been bad if 4000/frame is such a revolution -- It seems their mostly floored to finally match normal PC-levels of draw calls, at a time when PCs are about to make a huge leap forward. 

 

I don't do any mobile development, but when I asked some fellow programmers about it I believe they told me that you're generally limited to around 100 draw calls per frame on mobile. I then told them how many draw calls we do on PS4, and they started to cry.

 

 

I'm not sure whether that's sad or hilarious. Both probably.

 

Regardless I don't see what a cash strapped mobile developer has to do with a high performance API to begin with. Even if you're really small, if you've got the programmer capable of doing it then they'll probably be capable of doing it if necessary. Otherwise they won't. Metal may not be OpenGl getting onboard with the whole Mantle style API thing. But I don't see how it can necessarily be a bad thing.


PARTNERS