# CDProp

Members

666

1451 Excellent

• Rank
1. ## OpenGL ZBuffer to Worldspace Z Coordinate in the Shader GLSL

Lookin good. Just one minor question: this will return the z in view space, no?

3. ## Shadow matrix calculation

I only checked a couple values, but the ortho matrix in your original post looks correct. The top left element is going to be 2/width, and so if your width is 950, then small numbers like 0.002105 are expected. Now that you're taking scale into account, these numbers might have changed a bit, but I doubt your ortho matrix is a problem. Concerning the up vector, it depends on the LightDir. You'll just want to make sure that your up vector and LightDir are not in the same or opposite directions, as this will result in a singular matrix. Given your choice of coordinate system (where x and z are horizontal axes and y is vertical, and z seems to be north/south), I think that <0,0,1> is a wise choice. Do you have a world matrix for these verts, or are they already in world space? How big is shadowRes? And how large are your objects in these units, typically?
4. ## collision

Does it work well? Can you see how you might be able to utilize that function in your game? Try this: Loop over all of your bullets. For each bullet: Loop over all bricks. For each brick: Use that function you wrote to determine if the bullet is intersecting the brick. If so, make the brick disappear. If you have N bullets on the screen and M bricks, then you'll end up calling your function N×M times. On modern computers, this is probably not a problem unless you literally have hundreds of bullets and bricks. However, if needed you can speed up this algorithm by (for example) only testing your bullet against bricks that are in the same column as the bullet (assuming the bullet moves straight up). One common pitfall with this type of collision detection is that the bullet might be moving so fast that it passes right through the brick without intersecting it. For example, on frame 1 the bullet might be fully below the brick, and on frame 2 the bullet might be fully above the brick. The easiest way to fix that is probably to divide your frame up into 5 or so increments, and move the bullet one increment at a time while testing for an intersection at each point. This requires 5 intersection tests per bullet per brick per frame, but it's often worth it. You can also use a different number of increments, e.g. 2 or 3 or 7, depending on your needs. Another option is to use a sweeping intersection test, which will tell you exactly when the bullet hit the brick and doesn't require multiple increments. However, that is an advanced topic. That article doesn't have a sweeping test specifically for circles vs. boxes, and so you'll have to come up with one yourself or find one somewhere else, or maybe use sphere vs. plane against each side of the box.

7. ## My plan for realizing my game.

This isn't the answer you're looking for, but I think you are getting ahead of yourself. You are attempting to discuss resource constraints and how to deal with them, but you don't have good data on what your game will require. For instance, how did you come up with 3 as your required number of servers (targeting 4 core CPUs?)? Do you really know how much memory this is going to take? Let alone CPU utilization? Most people don't know these things without programming and profiling. I would also disagree that distributing your game will be a simple matter of handing js files to the end user. Does the end user know how to set up and configure Node? Are you going to have them install npm and then install and run all three web apps? Are you going to give them a script that will do this for them? If so, how does this differ appreciably (from the end-user's perspective) from just giving them an installer? How is multiplayer going to work? Will one user host, and will that user's servers do all the work for all players? If so, have you worked out all of the complications involved with other users hitting resources on the host user's machine? Will this be done across the internet? Are there security issues involved? This does not sound like the path of least resistance to me, but to each his/her own. My main concern with your plan is that you don't seem to have the programming chops yet. You will soon. I would definitely recommend that you start with a dead-simple game project that includes a subset of this functionality. Then, work on another game that is slightly more complicated and incorporates a wider subset of this functionality. Gain the experience slowly but surely, and you'll be successful (and you'll have a list of intermediary accomplishments as well).

10. ## Whats the added benefit of using hexadecimal?

No one has mentioned the main reason, which is so that you can make your numbers say things like DEADBEEF
11. ## Shadow mapping problems

It looks like you're multiplying the matrices in the opposite order for the lightViewPosition and worldPosition.
12. ## Shadow mapping problems

Did You post your shader code somewhere? It looks like you're rendering the shadow map correctly, so I suspect you've made a mistake when you sample the shadow map and do the depth comparison.
13. ## Banding using GGX specular

Oh! You're right. Even in the Fresnel screenshot, the bands are only 1/255 different. That's great to know, thanks! Thought I was going crazy for a sec.
14. ## Banding using GGX specular

Greetings,   I'm implementing specular using a GGX distribution and I'm noticing some unpleasant banding in the dark colors. Here is my HLSL code for the GGX distribution function: float GGX(float NdotH, float a) { float asq = a*a; float denom = NdotH * NdotH * (asq - 1.0) + 1.0; return asq / (PI * denom * denom); } Here is what it looks like if I shade a cube using only the GGX distribution function, with roughness = 0.25:     From what I can tell, the GGX function is totally continuous with respect to NdotH, with no stepping:     Granted, it's pretty sharp and so everything below NdotH = 0.8 is basically black. Not a lot of shades in 8-bit color down there, but so what? The only way I can imagine that it matters is if I'm doing gamma correction wrong. Here's my MSAA resolve shader to show that I'm doing the gamma correction: float3 pixelShader(PSInput input) : SV_TARGET { int3 texCoord = int3((int2) input.texCoord, 0); float3 color = 0.0; [unroll] for (int i = 0 ; i < 4; ++i) { float3 c = shaderTexture.Load(texCoord, i).rgb; color += c; } color *= 0.25; return pow(color, 1.0 / 2.2); } What could be the problem? Am I using the wrong gamma function for my monitor, perhaps? Is there a better way to do gamma?   Edit: By the way, I'm seeing plenty of banding in my Fresnel, too, and it's not even that dark:   HLSL for the Fresnel: float R0 = 0.05; float RF = R0 + (1.0 - R0)*pow(1.0 - NdotV, 5.0); Starting to think I'm just doing something really wrong with my gamma...