• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

4808 Excellent

About Radikalizm

  • Rank
    Advanced Member

Personal Information

  1. Lighting model for flower petals

    I guess if you want realistic shading on any type of foliage you'll want to have a look at subsurface scattering solutions. Standard BRDFs give you surface shading, which only gets you so far for organic materials where light can usually permeate quite a bit underneath the surface. Performance-wise I don't know if you'll want to go for a full-blown SSS solution for foliage though, you might want to find a cheap approximation to get a similar effect. For pure surface shading I guess you should use whatever fits the rest of your scene. If everything in your rendering pipeline uses standard Blinn-Phong, then shade your foliage in the same way unless you can find a valid reason not to. Switching to a physically based model like Cook-Torrance is not going to give you more visually pleasing results out of the box.
  2. DX12 to Vulkan

      This is still very true sadly enough. The first year of D3D12 was extremely rough in terms of driver and tool availability/stability. Vulkan seems to be going through this right now. That said, the only way for an API like this to reach maturity is for more devs to use it, back it and give feedback!     I had a chance to have a chat with some of the people in charge of Khronos' SPIR-V compiler efforts not too long ago. It seems like native HLSL support in glslang is a pretty high priority to them, so I hope that this will become a viable workflow very soon. They also seemed pretty excited about Microsoft's efforts to push out their new HLSL compiler infrastructure out into the open. This only means good things for them as well :)
  3.     Don't worry, I was completely aware that they were working on this, just not aware of when it would actually make it out to the public ;) The fact that the future development of HLSL is out in the open will help slim down a lot of shader codebases, as I'm sure a robust compiler from HLSL to SPIR-V will follow soon (aside from the work that's already being done in glslang). Also as you mentioned the language now has the freedom to evolve towards more modern concepts.
  4. There's been so many exciting things happening lately. First the release of PIX for PC, and now an open LLVM-based HLSL compiler! This is great news for the graphics development community :)
  5. DX12 PIX for Windows released yesterday

      AFAIK the current build isn't robust against invalid usage of the D3D12 API, so make sure you're not getting any debug layer issues.   Also congrats to the PIX team for getting this thing shipped!
  6.   me? which ?? !! i didn't notice      I was talking about the original post :) It's been edited
  7. You might want to be careful with adopting a logo used in a popular live AAA game as your studio/company logo. The one you're using is from the Forge editor in Halo 5 :)
  8. [C++] ArrayView-class

    As mentioned above, this is pretty much exactly what gsl::span does. In addition to this gsl also provides string_span and multi_span. If you haven't played around yet with gsl, I definitely suggest you give it a try. It's been incredibly useful for us so far.   EDIT:   I also remember seeing a Microsoft implementation of array_view, and am quite sure that an implementation of array_view was suggested for an upcoming C++ standard. I also believe that boost provides a similar implementation.
  9. Take a screenshot in D3D12

    There's no such thing as a staging or readback texture anymore in D3D12, so you'll have to copy your texture over to a readback buffer first using ID3D12GraphicsCommandList::CopyTextureRegion. Have a look at D3D12_TEXTURE_COPY_LOCATION to see how you can set up your buffer as a texture copy destination.
  10. DX11 Auto Generate MipMap Not Working

    You need to explicitly call ID3D11DeviceContext::GenerateMips to generate mipmaps for your texture   https://msdn.microsoft.com/en-us/library/windows/desktop/ff476426(v=vs.85).aspx
  11. Renderer bells & whistles ~ pt. 2

    I'm always impressed when I read any of your journal entries. Awesome job!
  12.   No, they don't. pbrt is the name of the framework they walk you through in the book. You can find the accompanying source code here: https://github.com/mmp/pbrt-v3   The book walks you through the implementation of a ray tracing framework which uses physically based shading models. This doesn't mean that physically based shading is exclusive to ray tracing.    As mentioned before, physically based rendering is just an approach to shading and lighting with a foundation in the actual physics behind lighting and reflections, rather than working backwards from "what looks right" like we used to do in previous generations.
  13. DX12 [D3D12] Root Signature Reflection

      As far as I'm aware you won't be able to retrieve a root signature from your bytecode if you don't explicitly define it in your shader code. One type of validation you could do is to get information of SRV/CBV/UAV/Sampler bindings using shader reflection. You can cross-reference this data against your root signature to see whether the root signature has the appropriate descriptors, descriptor tables, constants or static samplers to support your shader.   Other than doing that I don't think you can actually extract explicit root signature information out of a shader without defining it in your HLSL code.
  14. Ecs Architecture Efficiency

      Honestly, you're going to run into a ton of actual rendering-related bottlenecks before a decently architected game object/entity/"whatever buzzword you want to use" system gets in your way. Don't start theoretically optimizing things. Solve the problems you have at hand to get to the desired frame time for your specific game.         You've obviously never worked on any type of shooter before. Try telling that to people designing any type of competitive game which supports split-second inputs. 16ms in a game update tick can definitely make a difference.           What are you talking about? There's a ton of games doing async rendering? The era of single-threaded update and render is over!         This is still a very useless comparison to make. You're acting like every engine is comparable in some shape or form when it comes to performance. They're not. Focus on what your requirements and goals are. Do some profiling, find your bottlenecks, fix them. Rinse and repeat. 
  15. Need one more book on graphics programming ;)

    +1 for all three of those. Especially Real Time Rendering is a must-have!   The GPU Pro series is neat as well, but it's all very specialized and focused towards a specific set of techniques and their implementations.
  • Advertisement