Jump to content
  • Advertisement

mafiesto4

Member
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

641 Good

About mafiesto4

  • Rank
    Newbie

Personal Information

Social

  • Twitter
    wfigat
  • Github
    mafiesto4
  1. mafiesto4

    Light Shafts

    Recently I've implemented Volumetric Fog effect based on Volumetric fog: Unified, compute shader based solution to atmospheric scattering – Bart Wronski at Siggraph 2014 (link) Physically Based and Unified Volumetric Rendering in Frostbite – Sebastien Hillaire at Siggraph 2015 (link) Here you can find a blog post with some implementation notes and tips: https://flaxengine.com/blog/flax-facts-14-volumetric-fog/
  2. mafiesto4

    DirectX12 adds a Ray Tracing API

    I think it's a very promising step in a good direction. There's so many rendering techniques that relay on ray-tracing idea (SSR, GI, SSAO SSVGI, Screen-Space Everything) and a low-level API will help to achieve performance. I wonder if it could be used to shoot some rays before scene rendering to replace Hi-Z PrePass for the geometry culling. Do you think it could quickly calculate the scene objects visibility? Finally, of course NV always had been one step forward in terms on new rendering features They like to put some pressure on others.
  3. mafiesto4

    What engines do you use, and why

    My first choice was UDK, ages ago Later I has been working for 2 years for company creating games in Unity. Shipping mobile games with Unity is super efficient and easy but creating third-person shooter was a nightmare. I see many people saying: 'Oh I like this engine because I can do everything with it'. But remember that it also sometimes means: 'you have to do everything to actually achieve anything with it'. So using UE4 makes live easier if you can just grab all the ready stuff and after a day, finish your level with all logic, terrain and a proper lighting. I think that's very important. Anyway checkout my: Flax Engine Oh, and here is open source C# API and Editor: GitHub
  4. Moving from DX9 to DX12 is like moving from JavaScript to C++.
  5. mafiesto4

    Lighting Series

    So we are refreshing physics theory from the high school Anyway I think it's nice introduction but.. ..it would be just easier to describe L, V, N vectors, dot(N, L), etc. I assume this would go in the next post.
  6. Hey, I wonder what is the best way to handle multiple shader permutations? I wrote a blog post http://flaxengine.com/blog/flax-facts-4-shaders-parser/ where I described how we do it in Flax Engine. The thing is we want to avoid having too many shader versions and to try compile shaders offline (reduce amount of compilations at runtime). It's a little bit manual kind of job because you have to write all possible sets of permutating macros but it has some advantages, eg. it's quite deterministic and you can provide different amount of macros per permutation: META_PS(false) META_PERMUTATION_2(NO_SPECULAR=1, USE_IES_PROFILE=0) META_PERMUTATION_4(NO_SPECULAR=0, USE_IES_PROFILE=1, SKIP_STH=1, BUMP_COLORS=4) META_PERMUTATION_3(NO_SPECULAR=1, USE_IES_PROFILE=1, BUMP_COLOR=2) void PS_Spot(Model_VS2PS input, out float4 output : SV_Target0) { ... GBuffer gBuffer = SampleGBuffer(uv); output = GetLighting(Light, gBuffer, shadow, true, true); #ifdef BUMP_COLORS     output *= BUMP_COLORS; #endif #if USE_IES_PROFILE output *= ComputeLightProfileMultiplier(IESTexture, gBuffer.WorldPos, Light.LightPos, -Light.LightDir); #endif }  Plus we don't have to store used macros after shader compilation but just access permutations by index so it's faster to pick a proper shader version during rendering.
  7. mafiesto4

    directional shadow map problem

    You can use bias value that depends on angle between surface normal and direction to light: float bias = clamp(0.005 * tan(acos(NoL)), 0, 0.01); where: NoL = dot(surfaceNormal, lightDirection);
  8. Good step is to separate low-level rendering layer (DirectX, OpenGL) from the higher one (deferred renderer, forward, light pre pass, etc.).   To achive this use of course objects inheritance. Create some interfaces like IGraphicsDevice, IPostProcess, IRenderer or IRenderTarget. It depends on Your plans about the engine itself. But it's always easier to use: context->Clear(task->Buffers->GBuffer0, Color::Black); than: _commandList->ClearRenderTargetView(cpuHandle, color.Raw, 0, nullptr);   So I would defenetly define some base clases and basic rendering flow like: prepare(collect scene data, culling, etc.) -> main scene rendering -> post proceses -> present -> do additional jobs (textures streaming etc.)
  9. Keep in mind that Virtual Reality is also growing up. When I was developing app for Samsung Gear VR it was absolutely necessary to apply AA for each eye (even if it costs). Without it pixels were flickering all around because head is all the time moving (not like in a games) so this introduced unstable view.   I'm pretty sure that AA will be with us for a long time.
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!