Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

  • Days Won


matt77hias last won the day on March 15

matt77hias had the most liked content!

Community Reputation

556 Good

About matt77hias

  • Rank
    Advanced Member

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

13612 profile views
  1. How can I redirect all https://www.A.net/Page.html requests for some page Page.html to the corresponding page on another domain https://www.B.net/Page.html via the https://www.A.net/404.html? Github/Gitlab Pages redirects all Page-not-found errors to the latter. Is it possible to somehow retrieve the original requested page and use this in a Javascript (jQuery) function to modify the redirection URL? I currently use something like the following HTML code for a many-to-one redirection, but I rather need a one-to-one redirection (i.e. not always to the same https://www.B.net/404.html). <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"/> <meta http-equiv="refresh" content="0; URL=https://www.B.net/404.html"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/> <meta name="viewport" content="width=device-width; initial-scale=1.0"/> </head> <body> You are being redirected to https://www.B.net/404.html <a href="https://www.B.net/404.html">https://www.B.net/404.html</a> </body> </html>
  2. https://stackoverflow.com/a/13793660 Checkout the above Q&A (I write this with my phone, so my apologies for my less clean formatting). I think MSDN wants to say that you cannot pass the WM_OVERLAPPED flag on its own, but you may pass it if you ORed it with at least one other style flag.
  3. Thanks, that is interesting! Though, I need to recheck, but I have seen many DirectX samples from Microsoft themselves using this combination. I use the combination without having any problems, but I don't use a menu bar. Maybe adjusting fails with a menu bar? Edit: Microsoft seems to violate this. Their samples use WS_OVERLAPPEDWINDOW which includes WS_OVERLAPPED. WS_OVERLAPPEDWINDOW (WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX)
  4. Small update to my original regex: #include <iostream> #include <algorithm> #include <iterator> #include <regex> int main() { std::string text = "Quick \"\"\"\" \"brown fox\"."; std::regex re(R"((\"[^\"]*\")|[^\n\r\s\t]+)"); std::copy(std::sregex_token_iterator(text.cbegin(), text.cend(), re, 0), std::sregex_token_iterator(), std::ostream_iterator<std::string>(std::cout, "\n")); }
  5. Unfortunately, the capture group approach seems not work in C++ (at least not in combination with the std::sregex_token_iterator).
  6. I use the following regex to tokenize a string using '\s' (space), '\r' (carriage return), '\t' (tab), and '\n' (new line) as delimiters, but between quotes no delimiters are considered: R"((\".*?\")|[^\n\r\s\t]+)" The tokenization is achieved using: std::sregex_token_iterator(line.cbegin(), line.cend(), regex, 0); This results in the inclusion of the quotes in the sub matches. I can obviously modify such sub matches manually to eliminate the surrounding quotes, but I wonder if it is possible and how one can achieve to eliminate the surrounding quotes using the regex? Test sample: #include <iostream> #include <algorithm> #include <iterator> #include <regex> int main() { std::string text = "Quick \"brown fox\"."; std::regex re(R"((\".*?\")|[^\n\r\s\t]+)"); std::copy(std::sregex_token_iterator(text.cbegin(), text.cend(), re, 0), std::sregex_token_iterator(), std::ostream_iterator<std::string>(std::cout, "\n")); }
  7. FWIIW I use something like: static constexpr DWORD s_default_window_style = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX; Which imho is kind of a good default for graphical applications like games. MSDN is not really mentioning any prerequisites for WS_VISIBLE. Though, the documentation contains some flaws and ambiguous explanations.
  8. matt77hias

    Contour of the shadow region

    I know, but you still need to decide on the largest projection plane of your cascade. If the non-visible scene to total scene ratio is large, you don't want to waste most of your shadow map texels to the non-visible scene parts. My point was just let the user control the regions and thus the projection planes instead of figuring out a temporal stable solution myself taking the scene's AABB and all the camera frustums into account.
  9. matt77hias

    Contour of the shadow region

    Actually, this is not a problem. The irradiance will be zero for p_ndc.z outside the [0,1] range. The PCF filtering thus won't have to deal with such values. And handling p_ndc.xy values outside the [-1,1]×[-1,1] range can be dealt with a border value. A larger shadow map, however, will result in a somewhat smoother penumbra border.
  10. matt77hias

    Contour of the shadow region

    I actually wasn't sure for a long time how I could support shadow mapping for directional lights. Originally my directional lights were not restricted to a finite region unlike omni and spotlights. Calculating the maximum projection plane covering the complete scene, is not worth the trouble and is quite limiting the shadow quality in large scenes. So I decided to just use an AABB for directional lights with and without shadow mapping and let the user figure out the required size. As a side effect, I can now cull the lights and put them in a spatial data structure. As a side note, however, I do not see much value in directional lights. Maybe to model the sun, but this will probably be handled more efficiently by explicitly considering one light source representing the sun.
  11. matt77hias

    Contour of the shadow region

    Or use a border color 😮 Thanks that probably explains the differences! Saved my day and more importantly my night rest src >= dst --> src >= 0.0 (border color at my "reversed" far plane) --> comparison succeeds, so return 1 (for that sample) ---> so not in shadow (for that sample) src >= dst --> src >= 1.0 (border color at my "reversed" near plane) --> comparison fails, so return 0 (for that sample) ---> so in shadow (for that sample) Though, the border color does not suffice, since we can have a depth larger than 1.0 (i.e. closer than the near plane) at some sharp discontinuity. The check for the irradiance cannot counteract this. But how likely is this (e.g. tightly fitting a directional light to a shaft)? Adding some margin to the shadow map can work, but that feels like adding a magical offset. Furthermore, the shadow map will be projected on a larger plane and resolved on a smaller plane (i.e. the light projection matrix for the shadow map generation will differ from the light projection matrix for the lighting computation). I think this may impose some numerical issues while multiplying transformation matrices.
  12. Why do you use all this dpi boiler plate: SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_SYSTEM_AWARE); RECT client{ 0, 0, 100, 40 }; UINT dpi = GetDpiForSystem(); AdjustWindowRectExForDpi(&client, windowStyle, false, windowExStyle, dpi); instead of something like: AdjustWindowRect(&client, windowStyle, FALSE);
  13. While adding shadows maps for directional light sources (spatially restricted to an AABB), I noticed a weird artifact at the border of the shadow map. The region to the right is not illuminated directly by the directional light source. Though, one can clearly see the contours of the orthographic projection plane projected onto the floor of the scene. (P.S.: blame GameDev.net for the image compression artifacts ) This contour corresponds to normalized texture coordinates outside the [0,1]^2 range (i.e. just outside the orthographic projection plane projected onto the floor of the scene). Since, I use a D3D11_TEXTURE_ADDRESS_BORDER, the PCF sampler state, will use the border color. This border color is equal to my far plane, so obviously the points will never lie inside a shadow. By using a different border color, I can circumvent the problem: #ifdef DISABLE_INVERTED_Z_BUFFER desc.ComparisonFunc = D3D11_COMPARISON_LESS_EQUAL; #else // DISABLE_INVERTED_Z_BUFFER desc.ComparisonFunc = D3D11_COMPARISON_GREATER_EQUAL; desc.BorderColor[0] = 1.0f; // near instead of far plane = never in shadow desc.BorderColor[1] = 1.0f; // near instead of far plane = never in shadow desc.BorderColor[2] = 1.0f; // near instead of far plane = never in shadow desc.BorderColor[3] = 1.0f; // near instead of far plane = never in shadow #endif // DISABLE_INVERTED_Z_BUFFER Unfortunately, this does not solve but rather hides the problem. The incident orthogonal irradiance of the directional light, should be zero. And since the contribution is zero, the shadow factor should not matter (i.e. it does not matter whether outside the shadow map region, points are considered lying inside or outside the shadow). The incident orthogonal irradiance of the directional light is computed as follows: void Contribution(DirectionalLight light, float3 p, out float3 l, out float3 E, out float3 p_ndc) { const float4 p_proj = mul(float4(p, 1.0f), light.world_to_projection); p_ndc = HomogeneousDivide(p_proj); l = light.neg_d; E = (any(1.0f < abs(p_ndc)) || 0.0f > p_ndc.z) ? 0.0f : light.E; // Should be zero outside the shadow map region. } The position, p_ndc, expressed in Normalized Device Coordinates is transformed to UV coordinates ([-1,1]x[-1,1]x[0,1] maps to [0,1]x[1,0]). The latter will be used in HLSL's SampleCmpLevelZero. But am I allowed to use p_ndc as computed above directly? Do I miss a half-texel offset? Edit: Given that "(any(1.0f < abs(p_ndc)) || 0.0f > p_ndc.z)" is false, the point should be located inside the AABB and thus inside the shadow map region. But in this case, how is it possible that a different border color has any effect at all?
  14. matt77hias

    Normal encoding/decoding

    To be sure, I asked the compiler team: https://github.com/Microsoft/DirectXShaderCompiler/issues/1245 And unfortunately, there is no guarantee. A check needs to be added, making spherical encoding quite expensive . (Though, I am really happy with the Octahedron ) Note that if you store tsnms as (BC5_)_UNORM 0 won't be represented exactly. So the encoding only becomes undefined, if you explicitly pass a (0,0,1) normal.
  15. matt77hias

    AVX2 support in Visual Studio

    I just noticed that although /arch:AVX2 is set for x86/x64, msvc++ 15.6.7 does not set __AVX2__?
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!