MegaPixel

Hi to everyone,

I'm trying to build a generic camera class (so just one class) that with few simple operators can allow one to create any type of high level camera.
I'd like to do it this way because I think that, then, switching for example between a first person and a trackball like camera will be easier.
For now I've successfully implemented the usual 1st person camera by defining few simple operators on the camera class and creating orientation using quaternions.

Operators/Methods:

moveXCameraRelative
moveYCameraRelative

rotateXCameraRelative
rotateYCameraRelative

The thing is that I can't figure out how to switch between (say) a 1st person and a trackball without screwing everything. What I mean is flying a bit with a 1st person and then from that exact pov switch to trackball and use it and then back to 1st person transparently (like in a DCC tool).
What I thought is that I should accumulate orientations etc. but I guess that my current method is not very correct because instead of accumulating orientations deltas I accumulate the angle and calculate the orientation of accumulated angles instead of defining an offset quaternion. I saw some implementation they do something like:

Quaternion q(axis,delta) //the offset quaternion (relative rotation quaternion)

I do something like:

angle += delta;

Quaternion q(axis,angle); //the absolute rotation quaternion

should I use the first solution and accumulate quaternions instead of accumulate the absolute angle to have the possibility to implement the behaviour that I described before ?

Thanks in advance for your help

Hi guys,

I was studying through tonemapping operators and exposure control.

I've read several threads on gamedev about those topics and I've also read the MJP article on tonemapping on his blog and John Hable on filmic S curve.

Just one thing Is not clear to me: I understand that exposure control and tonemapping are two different things, but I wonder why someone is still multipling the RGB color by the adapted/tonemapped luminance L straight away.
Shouldn't be more correct to go in CIE color space Yxy, adapt Y to get Y' and then given Y'xy go back to RGB to get the new tonemapped color ?
Also, given that automatic exposure is a different thing with respect to tonemapping (which brings the Luminance values in [0,1] range in Reinhard) why in the Reinhard paper he basically calculates the geometric mean to get the average luminance in the context of a tonemapping process (I mean it's just part of the process but is still not the tonemapping step), that means that the relative luminance then can be used in the context of any tonemapping curve (not just reinhard) to have automatic exposure control ? And therefore shouldn't the relative luminance Lr calulation (the one before Lr / (1 + Lr), which is the actual tonemapped Lt ) consider the interpolated Lavg across frames in its calculation ?

Lr = (L(x,y) / Lavg)*a, where Lavg is the interpolated average scene luminance across frames and a is the key.

So it seems to me that the process of calculating the average scene luminance Lavg and from there the relative luminance Lr can be shared accross the different tonemapping curves and can happen just right before whatever curve is applied (not just Reinhard). Otherwise I can't see a general way to calculate automatic autoexposure.


See If understand then:

1) Get scene in HDR
2) Go from RGB to CIE Yxy
3) calculate average scene Yavg using Reinhard method (sum of logL div N)
4) calculate relative luminance Yr = (Y(x,y) / Yavg)*a (a is the key)
5) calculate autoexposure considering the average scene luminance of the previous frame Lavg(i-1) and the one of the current frame Lavg(i) and interpolate between them using an exponential falloff for example...
6) use the new adapted luminance in 4) to calculate the relative adapted luminance of the pixel (x,y) ?

so basically Lavg is always the interpolated average luminance across frames ?

7) use the Yr in the tonemapping curve to get Yt (i.e. tonemapped luminance):

if Reinhard:

Yt = Yr / (1+Yr)

if filmic curve (uncharted 2 variant):

Yt = ((Yr*(A*Yr+C*B)+D*E)/(Yr*(A*Yr+B)+D*F))-E/F

and more generally if whatever tonemapping function f(x):

f(Yr) = Yt

8) Transform from Yt xy CIE to RGB to get the tonemapped RGB color given its tonemapped luminance Lt which is calculated from the Yr, wihch is in turn calculated from the interpolated average scene luminance Lavg across frames (automatic exposure control).

Pfu, I made it.

Now is this the correct way of calculating autoexposure before applying any tonemapping curve to Yr at all ?

And why someone still apply tonemapping on RGB values straight away knowing that is wrong ? (John Hable said that is not correct to apply the reinhard curve to each rgb channel straight away but at the same time its examples are all doing that, maybe is half correct ?! ) Maybe CIE is more correct but because we can't alpha blend in that space we can live with a less correct solution applying tonemapping on rgb right away. But we have to still interpolate Lavg across frames to have the autoexposure control.

A quite important note: Since I send all my lights in one batch I need to have support for alpha blending, therefore I'm thinking to use CIE Yxy only during post fx and tonemap as being on PC I won't have any problem in fp blending support (as instead happens for other platforms ;) ).
I guess the variant Luv is just convenient if we don't have fp blend support (which on PC is not case anymore by long time). So the idea of accumulating lights in Luv is justified only if the underlying platform doesn't have support for fp render target blending and therefore we are constrained in relying on 8888 unsigned light accumulation buffer right ?

Thanks in advance for any reply

hi all,

very simple question coz I need to know whether I need to rescale the z range in 0,1 or not and I couldn't find any explanation on the xnamath docs.

If it's like the old dx convention z should be in 0,1 in clipping space (the openGL convention was different in fact we had -1,1 for z in clipping space).

The function that I'm using to project my scene is XMMatrixPerspectiveFovLH

thank in advance ;)

Hi all,

I'm trying to render to a cubemap using the geometry shader (GS). I want to render just depth, therefore I need to set a null render target and a depthstencilView as a texture2Darray of resources and indexing them with SV_RenderTargetArrayIndex in the GS.
The problem is that anytime that I launch PIX to verify the rendering results, the application crashes under pix (it doesn't crash if launch it without pix).
I tried disabling the shadow generation code and it still crashes, then I disabled the code that was creating the depth stencil view and the shader resource view for the cubemap and magically PIX wasn't crashing anymore.
So I think the problem might be in how I create those resources. I started digging on the internet to be sure that I was doing everything in the correct way etc. But I couldn't find any contraddiction with my code, so everything seems correct. It's also true that I couldn't find any reference or code sample that was showing the use of a depthstencilview for cubemap rendering with a rendertargetview set to null and color writes off.

btw here is my code to create DSV:

// Create a texture array to hold cube map data
FdkGfxTexture2DDesc texDesc;
ZeroMemory(&texDesc,sizeof(FdkGfxTexture2DDesc));
texDesc.width									 = 1024;
texDesc.height									= 1024;
texDesc.mipLevels							  = 1;
texDesc.arraySize							   = 6;
texDesc.format									= FDK_FORMAT_R32_TYPELESS;
texDesc.sampleDesc.count				 = 1;
texDesc.sampleDesc.quality				= 0;
texDesc.usage									 = FDK_USAGE_DEFAULT;
texDesc.bindFlags							   = FDK_BIND_DEPTH_STENCIL | FDK_BIND_SHADER_RESOURCE;
texDesc.CPUAccessFlags				   = 0;
texDesc.miscFlags							  = FDK_RESOURCE_MISC_TEXTURECUBE;
FdkGfxTexture2DId  texId					= fdkGfxCreateTexture2D(device,&texDesc,NULL);

// Create the depth stencil view desc for cube depth render
FdkGfxDepthStencilResourceViewDesc descDSV;
ZeroMemory(&descDSV,sizeof(descDSV));
descDSV.format									  = FDK_FORMAT_D32_FLOAT;
descDSV.viewDimension						 = FDK_DSV_DIMENSION_TEXTURE2DARRAY;
descDSV.texture2DArray.firstArraySlice  = 0;
descDSV.texture2DArray.arraySize				  = 6;
descDSV.texture2DArray.mipSlice				   = 0;
mDeferredData->mPointLightShadowMapBufferId	   = fdkGfxCreateDepthStencilTarget2D(device,&descDSV,texId);

//create shader resource view desc for the cube depth texture
FdkGfxShaderResourceViewDesc srvDesc;
ZeroMemory(&srvDesc,sizeof(srvDesc));
srvDesc.format								   				= FDK_FORMAT_R32_FLOAT;
srvDesc.viewDimension									  = FDK_SRV_DIMENSION_TEXTURECUBE;
srvDesc.textureCube.mipLevels						 = 1;
srvDesc.textureCube.mostDetailedMip			   = 0;
mDeferredData->mPointLightShadowMapShaderResource = fdkGfxCreateShaderResource(device,&srvDesc,texId);
fdkGfxDestroyTexture2D(texId);

fdk is just my API you can replace it with D3D11_blabla ;)

When it comes time to render, I expect to do something like:

OMSetRenderTargets(0,0,cubeMapDSV); //rtViewCount == 0, rtView == NULL

which means no render target view, just depth. I guess the rendering should be faster if we render depth with no color writes.

Could someone shed some light on this ?

Thanks in advance

Hi all,
I'm getting crazy to understand why pix does not playback at all !! I googled to find people that had a
similar problem but none of the post have been very useful.
I get that problem only during single frame capture in PIX (which is the only way to debug shaders).
If I try capture a replayable direct3d call stream on disk I don't get that error but unfortunately I can't debug the shaders either because It's possible only with single frame capture (F12).
Also, I checked the swap chain desc values and they are definitely correct.
My program starts perfectly from visual studio and perfectly if I double click on the executable as well.
I do not understand why PIX can't playback correctly if I start an experiment and I do a single frame capture of Direct3D.
One last thing: the d3d debug trace is perfect and I don't get any warning nor errors.
Thanks in advance for any reply