Jump to content

  • Log In with Google      Sign In   
  • Create Account

lipsryme

Member Since 02 Mar 2010
Offline Last Active Dec 23 2014 08:06 AM

Posts I've Made

In Topic: Rendering blurred progress lines

23 December 2014 - 02:18 AM

Looks like a 2D animation to me.

You just blur it manually in photoshop.

Or maybe do something more fancy with UI stuff like flash (I think UE3 does UI animations with scaleform).


In Topic: Tube AreaLight - Falloff problem

04 November 2014 - 09:14 AM

Hi Vilem Otte,

First of all thanks for taking the time to answer in full length.

What you are describing for calculting the specular light is as I understand basically what I'm doing in my code.

Howhever for diffuse I'm not sure how the original author of the technique had this in mind. I'm trying not to do any kind of raymarching or monte carlo approaches since this is supposed to be a "quick n'dirty" approximation for realtime use. Have you had the time to look at the epic siggraph notes that describe this technique ?

There's also an implementation on shader toy that however does not seem to include a falloff here: https://www.shadertoy.com/view/ldfGWs


In Topic: Forward+ Rendering - best way to updating light buffer ?

06 October 2014 - 12:44 PM

Ah so I can just basically do the same as with constant buffers ! smile.png

Having some issues copying the data due to heap corruption but that might be related to something else.

Is this the correct way of doing it ?

 

Update: yep that heap corruption was something else. Seems to be working now smile.png

if (!pointLights_center_and_radius.empty())
{
	this->numActiveLights = static_cast<unsigned int>(pointLights_center_and_radius.size());
	D3D11_MAPPED_SUBRESOURCE pointLightResource = {};
	if (SUCCEEDED(this->context->Map(this->pointLightBuffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &pointLightResource)))
	{
		DirectX::XMFLOAT4 *pData = (DirectX::XMFLOAT4*)pointLightResource.pData;
		memcpy(pData, &pointLights_center_and_radius[0], sizeof(DirectX::XMFLOAT4) * numActiveLights);
		this->context->Unmap(this->pointLightBuffer, 0);
	}
}

In Topic: Alpha-Test and Forward+ Rendering (Z-prepass questions)

10 August 2014 - 07:17 AM

 

Alpha-tested geometry tends to mess up z-buffer compression and hierarchical z representations. So usually you want to render it after your "normal" opaques, so that the normal geometry can get the benefit of full-speed depth testing.

 

As for why they return a color from their pixel shader...I have no idea. In our engine we use a void return type for our alpha-tested depth-only pixel shader.

 

Could it be beneficial to skip z prepass for alpha tested geometry compleatly to avoid that z-buffer compression mess ups?

 

The issue here is you can't since you need the depth information for light culling in the compute shader.

By the way it seems they have alpha-to-coverage enabled in the AMD sample so maybe the color return type has something to do with that ?


In Topic: UE4 IBL glsl

09 August 2014 - 01:13 PM

Hi REF_Cracker. Sorry for the late answer I just happened to stumble upon the thread again (hadn't been following it).

The format I'm using is R16G16B16A16_FLOAT for each cube map face.

I calculate the roughness in the shader like this:

float Roughness = (CubeLOD) / (CubeLODCount);

Which would give you values like these:

0 (256x256)

0.166667 (128x128)

0.333333 (64x64)

0.5 (32x32)

0.666667 (16x16)

0.833333 (8x8)

1 (4x4)

CubeLOD is starting at 256x256 and going down 6 levels (so 7 in total / original + 6 mip levels) to 4x4 for the roughest one.

Maybe you should use less mips and make it end at 16x16 or so haven't done much testing here.


PARTNERS