Jump to content

  • Log In with Google      Sign In   
  • Create Account

Frenetic Pony

Member Since 30 Oct 2011
Online Last Active Today, 01:43 AM

Posts I've Made

In Topic: Irrandiance Volume v.s. 4-Basis PRT in Farcry

30 April 2016 - 09:55 PM

If you're disappointed with 2-band spherical harmonics (perfectly understandable) you can take a look at spherical guassians, or just play around with SH/SG stuff here: https://github.com/kayru/Probulator


In Topic: Looking for good fast geometry compression for streaming!

22 April 2016 - 04:35 PM

Great video, and if that's 20k polys per frame, it just shows how terrible our current realtime lighting and animation is, if five to ten plus times the polys per character can still look markedly worse.

 

But otherwise I suspect as you do fredrum, in that VR/AR stuff is still entirely too new for there to be much literature on it. At least there isn't much so far as I'm aware.


In Topic: What is the relationship between area lights and reflections (SSR/local/global)

21 April 2016 - 04:13 PM

 

 

Ah, right I got confused with that "blurry reflection look" and forgot that this video is only about lights.  What a bozo I am!

 

I've never written SSR/cube reflection before -- it seems like you would have to turn off the lights before your SSR/cube reflection pass so you don't "double up" the reflections of the light, right?  It Otherwise you would have one reflection from the analytic/punctual light model and another reflection from your SSR/cube reflection pass.  Or is that not that big of a deal?

 

For cubemaps you turn off any direct contribution, correct.

 

Do you really ? I always thought you capture it n number of times to simulate light bounces ?

 

 

I'm assuming he means the emissive texture/sprite that's supposed to represent the actual "light emitting" part of the light. EG your sun disc representing the sun. In which case you'd want to turn it off for cubemaps or else you'd get a double contribution, one from the cubemap capturing the sun disc, and one from your analytic directional light. This doesn't, or shouldn't matter for SSR as SSR is hopefully just going to overwrite your analytic specular with more accurate SSR reflections of your emissive material (assuming it hits).

 

There are plenty of circumstances where you may even want to leave them on for cubemaps too. If the light is distant enough that its analytic solution doesn't contribute, you can certainly capture it in a cubemap (distant city lights or something). 

 

And for actual light contribution otherwise, eg drawing point lights and etc. then you just leave them on for both cubemaps and SSR.

 

OH! And edit, duh. Here's the exact same thing as the area lights OP posted, but with source code and a permissive license and etc. etc. Also diffuse lighting at the same time, still no shadows though (raytrace analytic shapes/signed distance fields?) https://eheitzresearch.wordpress.com/415-2/

 


In Topic: What is the relationship between area lights and reflections (SSR/local/global)

19 April 2016 - 11:52 PM

Ah, right I got confused with that "blurry reflection look" and forgot that this video is only about lights.  What a bozo I am!

 

I've never written SSR/cube reflection before -- it seems like you would have to turn off the lights before your SSR/cube reflection pass so you don't "double up" the reflections of the light, right?  It Otherwise you would have one reflection from the analytic/punctual light model and another reflection from your SSR/cube reflection pass.  Or is that not that big of a deal?

 

For cubemaps you turn off any direct contribution, correct. But it's not necessary for SSR as you are essentially overwriting any other specular contribution if the SSR contribution actually hits valid info, so it shouldn't double the contribution. But this assumes your specular from the lightsource is actually at least somewhat of a match with whatever emissive material the light source is supposed to come from. If they're too mismatched it could certainly look odd.


In Topic: When would you want to use Forward+ or Differed Rendering?

16 April 2016 - 05:10 PM

Why is it called a Z-Pre-Pass if the Z-buffer is typically generated first before anything else in the first place?

 

It's a z only pass, just depth. You don't render anything else, such as textures and etc. As hodgeman said, there's a fast path for it, but you can't have a render target bound at the same time; it was mostly used on previous consoles as you were highly bandwidth bound so getting rid of overdraw could be a win, even if you did rasterize twice. But it's mostly outdated for deferred rendering today, at least so far as using the rasterizer. DICE recently (GDC) showed off what is essentially a compute based z-prepass, using async compute (in their case using it while the rasterizer is busy with doing shadow maps) to draw all the polys you have onscreen. Doing a compute based pass can be a win on today's consoles, which can choke a bit on the rasterization step, because you can discard triangles that would be onscreen but don't actually hit any centroid sampling and the like, and during the shadow pass your mostly using the rasterizer so your compute resources are free anyway.

 

For tiled/clustered forward it can be a bigger win though and z-pre pass is still relevant. It can reduce overdraw dramatically since you'll, again, discard triangles which miss the centroid sampling and thus don't contribute. While pre-pass can be useful for deferred cause you'll skip the big geometry step where you're still reading out textures which won't contribute and etc. it's much better for forward as you're still lighting as you draw each triangle, so you'll be saving there too. I wonder now, DICE's compute based z-prepass like thing could do the same thing for forward plus, might be a win.


PARTNERS