Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Nov 2007
Offline Last Active Sep 02 2013 05:07 AM

#5069418 Depth Biasing

Posted by Nyssa on 13 June 2013 - 07:34 AM

If you only need the data in one pass then it would be a simple matter of transforming a vertex a second time in the vertex shader by the WVP matrix with a depth bias added. The result of that could then be passed on to the pixel shader where you can play with the biased value, while the pixel will be rendered in it's un-biased position by the first transform.

#5069112 distributing my program

Posted by Nyssa on 12 June 2013 - 06:32 AM

Yep. Or getting them to install the Microsoft Visual C++ Redistributable should fix it too.

#5037399 Projectile Class Format

Posted by Nyssa on 27 February 2013 - 05:55 PM

I think you've pretty much got the right idea. When you talk about vectors I assume you are talking about std::vector? One thing I'd suggest is to not copy vectors into the projectile class as this may start getting expensive depending on the size of the vector and how many times per frame you are doing it. Instead I would either have the projectile store a pointer back to the character that created it. This way you can access the effect vector you were talking about without any copying. Or use bit flags to hold a projectiles effects rather than a vector. This will reduce memory consumption and probably be faster to process. You can read a little about bit manipulation here


These options depend on what information you need to store and how it will be accessed.

#5034469 Shader (LPD3DXEFFECT) crashes when setting my Matrix

Posted by Nyssa on 20 February 2013 - 03:08 AM

You were right to change it to LINEAR (WRAP is wrong for the filters). You said in a previous post you copied the effect to different locations to try getting it to work. Are you sure you changed the right copy?

#5034440 Shader (LPD3DXEFFECT) crashes when setting my Matrix

Posted by Nyssa on 20 February 2013 - 01:49 AM

Call D3DXCreateEffectFromFile() with the debug flag and see what error message is being produced.


if (FAILED(D3DXCreateEffectFromFile( g_pd3dDevice, str1, NULL, NULL, dwShaderFlags, NULL, &g_pTestShader, &pErrors ) ))
	if (pErrors != NULL)
		char *errorString = (char*)pErrors->GetBufferPointer();

#5033352 Cascaded Shadow Map Issue

Posted by Nyssa on 17 February 2013 - 07:37 AM

One last thing. Use just 1 cascade instead of 4 and see if the problem is still there. Other then that I'm out of Ideas from what you've posted sorry.

#5033339 Cascaded Shadow Map Issue

Posted by Nyssa on 17 February 2013 - 05:27 AM

Ok cool, one potential issue down smile.png


Another thing I noticed, In your original images the shadow maps look upside down. This could be a slimDX thing? And maybe you're compensating for that? So maybe try this... In your .fx file invert the .y element of your texture coordinates when you are checking to see if a pixel is in shadow or not. So somewhere in there you will have something like:

tex2D(ShadowMapSampler, vShadowTexCoord)




vShadowTexCoord.y = 1.0 - vShadowTexCoord.y;
tex2D(ShadowMapSampler, vShadowTexCoord)

#5033327 Cascaded Shadow Map Issue

Posted by Nyssa on 17 February 2013 - 04:30 AM

It's not wrong, just specific for that scene. Give the original code a go and see if the issues go away.

#5033319 Cascaded Shadow Map Issue

Posted by Nyssa on 17 February 2013 - 04:11 AM

I haven't used SlimDX before so I can't comment on its usage. I did see a problem with how you are positioning the frustum. Specifically in the following line:


var viewMatrix = Matrix.LookAtRH(Vector3.Zero - (LightDirection*100), Vector3.Zero, new Vector3(0, 1, 0));


This code means the shadow frustum never moves with the camera. MJP's examples calculates the frustum center (instead of using Vector3.Zero) with the following code:


// Find the centroid
Vector3 frustumCentroid = new Vector3(0,0,0);
for (int i = 0; i < 8; i++)
	frustumCentroid += frustumCornersWS[i];
frustumCentroid /= 8;


There is one limitation with the example MJP gives as well that may be problematic for you. Only the viewable objects in the scene are being considered as shadow casters. So if you have an object behind the camera that's casting a shadow in front of the camera then the shadow will not be visible. Depending on your application this may not be an issue, but it's something to keep in mind. 

#5033217 Cascaded Shadow Map Issue

Posted by Nyssa on 16 February 2013 - 08:05 PM

Without seeing your code It's hard to say exactly where the issue is. The shader code you posted looks alright. From the images you have posted I've seen that issue before when the shadow frustum hasn't been built correctly and/or the frustum is missing a transform into light space. Maybe also look over the matrices you're passing into the shader to make sure they are correct.

#5032159 Cascaded Shadow Map Issue

Posted by Nyssa on 14 February 2013 - 02:31 AM

My guess would be that your not creating your orthogonal projection matrix for the shadow map wide enough to contain the whole scene. Try widening that projection matrix and see if the problem is resolved.

#5028563 iterator list corrupted (with alt-F4 only)

Posted by Nyssa on 04 February 2013 - 12:46 AM

 Ignoring doesn't make a problem go away.


I agree, I wasn't suggesting they should ignore it.


The windows messages should be checked to see if there is an issue there. Otherwise memory leaks can do some strange things too. There is an app called Application Verifier that I have found to be very handy in detecting lots of hidden issues. Perhaps it could help here as well.

#5028504 iterator list corrupted (with alt-F4 only)

Posted by Nyssa on 03 February 2013 - 07:39 PM

Should you really be closing an application down with alt-f4 anyway? :)


If it's only happening from within visual studio then maybe the debugger simply doesn't like to quit by alt-f4? I'd recommend setting up maybe the Esc key to quit so your application can close gracefully.

#5028288 Smooth Shading

Posted by Nyssa on 03 February 2013 - 03:44 AM

Yeah the Normal is perpendicular to its surface. It is needed in lighting calculations so it can be compared to a lights direction and determine that surfaces lit value. You could search for Blinn-Phong shading. This website also has a pretty good explanation under "OpenGL Directional Lights 1"

#5026700 Component based game engine book

Posted by Nyssa on 29 January 2013 - 03:04 AM

A few books specific to engine programming are "3D Game Engine Architecture" by David Eberly (he has an older version too) and "3D game engine programming" by Stefan Zerbst is ok too. You could use these books for general design then improve on their implementations later. I don't know if their is a book specific to creating a Unity type environment, but there are resources on creating scene editors. Once you have an engine running you could then create a scene editor for your engine.