• Content count

  • Joined

  • Last visited

Community Reputation

291 Neutral

About piluve

  • Rank

Personal Information


  • Twitter
  • Github
  1. Hi, As a programmer and a game maker enthusiast, I often read posts about one person that has been working on a game (alone) for the last "x" years and that finally published the game. I have been trying to come up with a game idea but I end up going in circles, going back to the drawing board every time. Maybe its because I got too motivated in the aspect of solo gamedev, maybe that's not for me. What I´m looking for? I would love to find another a person with art skills that also has a game idea. It would be awesome if this person could handle the artistic part of the game, that way we can keep the team small. What do I offer? I will be in charge of the technical aspects of the game. I have experience with existing engines like Unity or UE4 and also in general software development and graphics programming. You can get in contact with me through PM or email: nachocpol@gmail.com Thanks!
  2. DX12 Single root signature

    Hi! There is a nice discussion here : I think UE4 is using something like this ( a common root signature) so it may not be a bad approach.
  3. Hi! Maybe you could go for PBR, learnopgl has a really nice tutorial with theory and code. If that looks like too much there are also other techniques like cell shading or maybe you could try to implement a post processing effect like bloom
  4. @SoldierOfLight thanks for pointing out the differences between hw tiers, I forgot about that. On the other hand, I think it could be possible that compiling the shader + rs at the same time may allow for better optimisations. I'm guessing that because XBox requires the shader to be compiled with the RS (otherwise it will do it on runtime).
  5. Hi, I recently started reworking my RootSigature system, I basically want to declare a RootSignature in hlsl and then reuse it across all my shaders. Until this point, I've been generating a custom RS for each PSO (with the exact number of resources that PSO will use). This means that each RS is efficiently used but it also means that each time I draw or dispatch the RS will change. This new system will use this RS: #define GFXRS "RootFlags(ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT)," \ "DescriptorTable" \ "("\ "CBV(b0, numDescriptors = 16)," \ "SRV(t0, numDescriptors = 16)," \ "UAV(u0, numDescriptors = 16)" \ ")," \ "DescriptorTable" \ "(" \ "Sampler(s0, numDescriptors = 16)" \ ")" \ NOTE: I want to start with only one RS for everything and then maybe have one for gfx and other for compute. However, I was wondering if there is any overhead of declaring the above RS and not using all the descriptors. As far as I can tell it shouldn't cause much trouble (I'm also aware that UnrealEngine uses something like this). I would love to hear the opinion of someone with more experience on this topic. Thanks!
  6. I really think that the most important thing is a good building block (the base shape of the terrain). I would also take time on texturing (note that I'm not talking about shading), making sure you have variety of textures and that they make sense with the shape of the terrain (@noizex mentioned a lot of really useful techniques). Just take a look at this shader from IQ: https://www.shadertoy.com/view/MdX3Rr. The shape of the terrain is awesome, you have tall mountains with a lot of rough details but you also get some smooth surfaces. And the texturing is just superb! He is not even using textures just mixing between colors.
  7. Hi, The answer will depend on how do you render that terrain. The naive approach will be to generate a grid and apply height and also store normals as attributes, this will work OK but once you start making bigger terrains you will be wasting a lot of mesh density further from the camera and also outside of the frustum. Most terrain systems use a Level of Detail system where density of the terrain decreases far away from the camera. You can also do some visibility tests to reject parts of the terrain outside the view frustum. Recently I worked on a terrain system, height was stored on a texture (then it was sampled on the VS) normals where also calculated from this texture. The terrain was divided into chunks (so I could apply frustum culling) I experimented with tessellation for LOD but I didn't have enough time to polish it (however I've got acceptable results). With this, I was able to render quite large terrains at a nice frame rate. I can't give you exact numbers, you may want to experiment with different techniques. For example if you intend to make some kind of procedural and deformable terrain you may want to implement it as marching cubes etc.
  8. Alright thanks for clarifying it
  9. Alright, my confusion was, that I though that it will force to have 14CBV declared in the root signature and fill the unused with null views.
  10. Yeah I get that, but what about that restriction? It forces you to make a root signature with lets say 14 CBV? Or it just forces you to make sure each declared CBV has a view?
  11. Hi, (from: https://msdn.microsoft.com/en-us/library/windows/desktop/dn899109(v=vs.85).aspx#Null_descriptors) Does this mean that, I need to declare root signatures with all the slots even if I don't use them, or does it mean that every entry in the root signature must be populated? Sorry if I it is too obvious but I've read things related to this from different sources and I'm a bit confused :S. Thanks.
  12. Hi, I'll double check the barriers thanks for the tip Hi, that may be useful I will bookmark it. Thanks!
  13. Hello! Jumping from one bug the the next . I wonder, If having the same descriptor table is a bad idea or if it should be avoided? In my rendering code, I'm only using one command list (graphics), depending if the current call is a Draw* or a Dispatch, I set the Descriptor table with SetComputeRootDescriptorTable or with SetGraphicsRootDescriptorTable. I'm asking this because I encountered a bug where, if I perform a draw call in between some compute, the following compute work will be all messed up and not working properly. This problem may not be related at all with the main question (I think there is something going on with my depth buffer). Thanks!
  14. I just wanted to give an update on this problem. I finally solved the issue. First, as I said in my previous comment, I removed all the remaining dx11on12 which was causing PIX and NSight to crash. After that I did some debugging and realised that our rendering API can expect a NULL resource to be set (and I was ignoring it) this caused many problems with the bindings etc. Right now, instead of using null descriptors, I'm setting a dummy texture of size 1 (which seems to work fine). I also found another bug that was affecting the hole thing. During RootSignature creation, the resources are added in order to the signature, but during the binding I was setting them in a wrong order sometimes. And that was it for this bug. Thanks!
  15. Yeah that is strange, the spec says... OutputWindow Type: HWND An HWND handle to the output window. This member must not be NULL. Maybe that swap chain is invalid but then how you are able to get the surface...