Jump to content
  • Advertisement

d07RiV

Member
  • Content Count

    127
  • Joined

  • Last visited

Community Reputation

258 Neutral

About d07RiV

  • Rank
    Member

Personal Information

  • Role
    3D Animator
  • Interests
    Art

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I use hardware sRGB for material textures, then all the colors are stored and accumulated in RGBA16F buffers until the final step where I simply do `pow(color, 1.0/2.2)` to get the final result. My light pass shader outputs like this: o_Color = vec4(pbr * light.color * shadow, 1.0); Where pbr is the multiplier from PBR formulas, and shadow is shadowmap sample. Then the final pass does vec3 color = tColor * tEmissive.a + tEmissive.rgb; o_Color = vec4(pow(color, vec3(1.0 / 2.2)), 1.0);
  2. It's opengl and this was PCF with kernel size 2, but I don't think any of that matters. My concern is that if your shadow forms a linear gradient in RGB space, once you apply gamma correction the shadow edge becomes really sharp. With VSM shadowmapping the pixels aren't visible, but the shadow is still very sharp, when it looked really well in uncorrected space.
  3. When I try to use any kind of shadowmaps (let's say PCF for simplicity) with gamma correction, I'm getting very blocky shadows. Without gamma correction, PCF generates a smooth gradient, but after applying the power function, the pixels are clearly visible. Am I doing something in the wrong order here, or that's how it should be? Shadows with gamma correction Without:
  4. Keeping track of angular momentum instead of velocity is technically more correct, but since you're doing numeric integration, both are going to give "wrong" results, and updating angular velocity instead is much easier and more stable. You won't be able to reproduce some peculiar motions like these without a more robust integration method anyway.
  5. d07RiV

    Raycast From Camera To Mouse Pointer

    You multiply your vector by inverse projection matrix, but then discard Z/W values and put -1,0 in there. Z=-1 is only correct if your zNear is 1. Setting W=0 makes it ignore the translation component of inverse view matrix, which is what you need if you just want the ray direction. The origin of the ray is, indeed, your camera position. It is the same as the translation column (12,13,14) in inverse view matrix. You should keep the Z so it works for every zNear. The rest seems fine, and you seem to have figured out the problem by now.
  6. If it's a fullscreen quad, then don't worry about it. The cost of processing a screen-full of pixels is much higher. But you should still try to squeeze multiple postprocessing steps into one where possible.
  7. Hm thanks, I'll try to play around with sorting, because quicksort in JS isn't all that fast anyway (since it runs a callback for every comparison). Got a couple more questions if you don't mind. 1. How do you deal with non-discrete data like model matrices? You can't encode them in a 128-bit draw call, unless you put them in a big list or something. 2. Are draw calls supposed to be "compiled" on every frame, or are they cached inside objects?
  8. However, I'm not sure if individual samples generated for MSAA count as separate fragments, since FS is only ran once.
  9. I've also been thinking if there are better alternatives to picking the rendering order than simple radix sort, which can have abysmal results in some cases (i.e. 0111111 -> 1000000 -> 1111111 -> 2000000 etc). It is essentially a traveling salesman problem, which has plenty of decent approximate solutions, the question is, how much time are we prepared to dedicate to sorting. I'm guessing the most reasonable way would be to always pick the draw item closest to the current state, using some LSH or tree-based structure to preprocess the draw list. It also raises a question of whether we need "don't care" values, because they can significantly reduce the cost of switching states.
  10. d07RiV

    Contour of the shadow region

    That's what cascaded shadow maps are for - you get high shadowmap density close to the camera, and lower as you get further away from it. The sun is the most important light source, you can't just get rid of it.
  11. d07RiV

    Contour of the shadow region

    Is the light not supposed to shine outside the box at all? Then near Z border might solve it, I suppose (if you need blurry light edges).
  12. d07RiV

    Contour of the shadow region

    Didn't you say you use PCF, which samples a block of pixels around the target, leading to incorrect results. You should always make shadowmaps slightly larger than the area they affect, so you never have to sample outside.
  13. Thanks, I'm still not sure how much abstraction I need since API is always going to be the same. Another thing - when you put all passes in the same shader file, do you run a lexer on them, or do you just feed everything to shader compiler and let it figure out what to optimize away? The former option would us to know which options affect which passes, so we don't have to make redundant copies (instead of having to manually specify them for every pass). edit: I guess this is partially answered by bonus slides.
  14. Do you have any suggestions on how to handle texture bindings? Should I even bother to minimize the number of swaps? I.e. in deferred rendering, I could keep the gbuffer textures bound to targets 0-3 throughout the rest of the rendering phase, but that requires making sure all shaders are bound to them correctly, and shaders that don't need them use the remaining targets. Or I could assume that every time I switch shaders all textures have to be re-bound, which simplifies things greatly. I'm targeting WebGL by the way, so no resource lists, and many of these bitwise optimizations are hard to apply there.
  15. Umm apparently it does work, but takes ages to process? And the one in wisiwyg editor doesn't work, either.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!