Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

553 Good

About hgoel0974

  • Rank

Personal Information

  • Role
  • Interests
  1. Sorry for the late reply, today has been a busy day at university. I made the changes you guys recommended, namely, switching out the elementat call for an array access and moving the BoundingBox 'new' call outside of the loop. These two changes have indeed helped increase performance but it still isn't up to the point I was thinking voxel raycasting would be at. I have the following output on the profiler now, the GIWorld.Update call doesn't even show up on the list, I'm looking into how to get the External code portions to show more detail though. http://imgur.com/dLwm01m   Additionally, it seems there's a bug in the actual raycasting code, as a result of which the results are incorrect. I was hoping to use voxel raycasting on the CPU to do an additional low resolution indirect lighting bounce and then upload that to the GPU for compositing, which is beginning to seem like a not too great idea.
  2. Sorry about that, just noticed and fixed the link. EDIT: Ah, a minute too late. EDIT: The boundingbox class doesn't actually do any calculations on the data, but I'll give your suggestion a try in the morning.
  3. I've been implementing CPU based voxel ray casting on a BSP tree, in the end a node consists of about 30 voxels, however, the performance is terrible, I ran the program through the Visual Studio Community Edition CPU profiler and got the following output: http://i.imgur.com/SbZIJCn.png Since it just says that '[External Code]' is taking most of the CPU time, I'm not sure how to proceed. I can't identify many serious performance issues, and I find it hard to believe that the recursion could be the problem. My Ray-AABB intersection tests don't appear to be too slow either. My code: BSP Tree code (yes, I know the filename says Octree): VoxelOctree.cs GI_IntersectionTests.cs GIWorld.cs Any suggestions on how I should approach figuring out this issue would be appreciated. The ray casting and tree traversal code is in the RayCast function in VoxelOctree.cs
  4. I'm sorry, I should have been more clear, I was referring to the circle like area where the reflection is suddenly different around the ship. The changing filter type idea did give me the idea to see if that was due to missing information by disabling texture wrapping, which did eliminate the issue, sort of, it replaced the circle with stretching, which works better.
  5. I was playing around with some shader code when I ended up with something that seemed to be working rather well as a reflection shader. However it has artifacts near the camera due to the transformation by the projection matrix, however, if the transformation is not there, while the artifact is gone, the reflections are no longer perspective correct. I'm not sure how to deal with this.   Code: #version 430 core in vec2 UV; layout(location = 0) out vec4 reflection; uniform sampler2D colorMap; uniform sampler2D normData; uniform sampler2D specularData; uniform sampler2D worldData; uniform sampler2D envMap; uniform sampler2D depthMap; uniform vec3 EyePos; uniform mat4 View; uniform mat4 Projection; void main(){ vec3 n = 2.0 * texture2D(normData, UV).xyz - 1.0; n = normalize(n); vec3 worldCoord = texture2D(worldData, UV).rgb; vec3 v = EyePos - worldCoord; v = normalize(-v); float depth = texture2D(depthMap, UV).r; vec4 vis = vec4(0); vec3 refNorm = (Projection * View * vec4(reflect(v, n), 0)).rgb; refNorm = 0.5 * refNorm + 0.5; vis = texture2D(colorMap, refNorm.xy); reflection = vis; } Without Projection matrix: http://i.imgur.com/FUxqgdy.png   With Projection Matrix: http://i.imgur.com/Q2jsnxC.png   The artifact kind of gets hidden as I start to move faster, but it'd still be nice to get rid of it. Just had the thought while writing the question, is the artifact possibly due to missing information?
  6. hgoel0974

    Vulkan is Next-Gen OpenGL

    Well, since I couldn't wait to play around with Vulkan but the AMD drivers seem to be broken at the moment, I generated some quick C# bindings for it, they're partly unusable because of the way the tool translates types but now it's just a matter of a bunch of cleanup work.   https://github.com/himanshugoel2797/Vulkan.NET   Also, AMD has a new version of their Vulkan drivers, which claim to fix the issues with the latest SDK version.   EDIT: Said drivers still aren't working for me, applications launch but freeze on launch.
  7. I'm working on a voxel engine and have some of the basics done with everything drawing decently fast. However there are two issues I'm having trouble coming up with a solution for:   First is stutters during chunk generation, I do chunk generation on a separate thread and once the vertices are ready, I tell the main thread to pull them into VBOs. This sounds like it would work fine however the pulling stuff into VBOs part (glBufferData) causes a slight stutter even though I'm uploading on average about 2000 vertices per frame (each vertex is also packed into a single int using the Int2101010Rev format, this yielded a massive performance increase). I tried using persistent mapped buffers but they cause the framerate to drop to 60 which is unacceptable considering that I have nothing but dot product lighting going on. I tried it (separately) with the coherent bit and with the unsynchronized bit but neither had much of an effect. So, my first question is, How can I reduce those stutters to the point that they are no longer noticeable?   Second is increasing the size of vertex batches, while profiling in CodeXL, I see that my batches are far too small compared to the recommended size of ~40k vertices. My batches are more around the 1k vertices mark. (about 20% of vertices with about 50% of batches). Increasing that should help with performance and it would also reduce draw calls but I'm unsure of how to do that considering the way I generate my data: 1. Fill an array with the voxel ids 2. Loop over the array and build a mesh using 'greedy' meshing, generating faces relative to the chunk 3. Calculate the normal of the face and place it in a list appropriately 4. Finally, combine the vertex information for all the faces into one list, keeping track of which normal is at which offset 5. Put this data into a VBO 6. In the vertex shader, use the normal grouping information passed in as uniforms along with gl_VertexID to determine which normal to pass along, a world transform positions the chunk properly.   As you can see, because of this, I can't just reduce my draw calls since at least two things depend on the current call. The normal however can be worked around by just batching in groups of normals, however the World transform remains an issue. I think I might be able to do something using MultiDrawIndirect but my problem with that is that I have never understood how I might determine which draw call I'm at if on hardware that doesn't support gl_DrawID. I have read about the trick with using a base instance however I don't see how that's correct since a vertex attribute isn't considered dynamically uniform and thus won't be usable as an index into a UBO. So my second question is, how do I increase the size of my batches and reduce my draw calls?   The relevant code is at (mainly Chunk.cs and BlockManager.cs) https://github.com/himanshugoel2797/Messier-Game/tree/BruteForce/Messier/Engine The master branch has the persistent mapping based approach implemented.
  8. hgoel0974

    When you realize how dumb a bug is...

    Not exactly a bug but today I was working on a greedy isosurface extractor and I ended up with this issue with not being able to determine the normals. Spent an entire day trying first taking the cross product of two edges but that didn't give me the final direction properly, then went for weird tricks with the slopes and attempting to detect triangle winding and trying to get the direction from the center of the voxel until I realized just how much I was over thinking it, the one unused axis for each face is the normal direction and all I needed to do was check if adjacentvoxels were empty... As much as I liked having solved the issue, it's sad it took so long to realize something so simple.   Edit: And another bit of stupidity: for (; (a[d] == Side - 1) ? a[d] >= 0 : a[d] < Side - 1; a[d] += (a[d] == Side - 1) ? -1 : 1) { if (VoxelMap[MaterialMap[this[a]]].Visible) { done = true; } if (done) break; } I wonder why that loop is taking so long....
  9. hgoel0974

    When you realize how dumb a bug is...

    So I just spent almost a full 12 hours trying to figure out why the logarithmic depth buffer wouldn't work with the tessellation shader, it'd work fine without the tessellation stage and with it, it'd seem like the far clip plane was being set to 100. So naturally, I kept looking for problems with the depth buffer setup, but found nothing.   Then, just a few minutes ago, I looked at the function to calculate the tessellation level, this was what it was:   float GetTessLevel(float Distance0, float Distance1) { float AvgDistance = (Distance0 + Distance1) / 2.0; return 10 - clamp(AvgDistance/10, 1, 10); } See it?  These kinds of bugs IMO are the most painful, they're simple but not at all obvious.     The bug is in the return statement, tessellation of 0 doesn't draw anything, thus making things look just like far clipping. The correct version would be: float GetTessLevel(float Distance0, float Distance1) { float AvgDistance = (Distance0 + Distance1) / 2.0; return 10 - clamp(AvgDistance/10, 0, 9); }
  10. Sorry for the late reply. I thought about those things after reading your post and reached the conclusion that you were right, I shouldn't mess around with GL4 features since I can't expect everyone to have it. The reason I'm using a custom engine is because I prefer to do everything myself. I ended up switching back to the normal GL 3 backend for my engine and am just focusing on making a game and optimizing the engine accordingly.
  11. @Hodgman, Thanks for the links, they'll be a nice resource so bookmarked.   @vlj I did read it needed hardware support although I hadn't thought about the fact that it would introduce an overhead. @cozzie, Yeah, I've been trying ot make sure I don't end up just going for the latest extensions. Bindless textures seemed to be the easiest way to do what I needed, the next most viable option being texture arrays + a lot of management code, which is what I ended up going with. I'm still working on it though.   Basically, I specify a maximum resolution a texture can have (the dimensions of a single texture on a texture array) and then assign it an ID based off of the layer, this, along with offsets and size information is all written into a uniform buffer and accessed in the shader, which has the same effect as bindless textures.   Currently I was upgrading my shading language library to handle uniform buffers and while the GLSL output looks valid, but I guess passing a flat shader variable from the vertex shader doesn't count as a dynamically uniform expression? How else can I get the per draw index over to the fragment shader then in such a way that it's still considered dynamically uniform?
  12. I'm working on a 3d game engine. So far it uses MultiDrawElementsIndirect for the rendering with no fallback, assuming minimum OpenGL 4 required. I am now considering using bindless textures to be able to have individual textures per object. But I'm not sure if that's a good idea since it isn't core, how much support can I expect for it considering that it's ~3 years old? Also, for anyone who has tried it, is it worth the work or am I better off using texture arrays? (I want to avoid textures because of how each layer has to be the same size, but all my textures won't be like that, which makes it seem very wasteful)   I would go ahead and implement both but I'd prefer not to have to do more work than necessary yet.
  13. I should have been more clear, by offset I meant baseVertex, but yeah, I found the problems (one of which was assuming that baseVertex was *3, the others being tons of bugs in the code that manages memory in the persistent mapped buffer) and got it all working again.
  14. hgoel0974

    When you realize how dumb a bug is...

      lol, I had something very similar happen to me, only it was between glMultiDrawArraysIndirect and glMultiDrawElementsIndirect and there wasn't a segfault because C#   By general rule, the moment you decide to copy and paste is probably the moment to take the code and isolate it into its own function because that is most likely the point when you can tell that a piece of code is worth to be made reusable. If you haven't needed to repeat the code yet then it's probably better to not waste the time doing it though.   Of course, easier said than done. If you're the only person touching the code then it's not really a problem since you'll most likely consistently remember that rule, the problem is trusting other programmers to be doing the same.   I don't forget how my code works, I just forget which code I have, when I look at the code, I instantly remember how it works and all the quirks about it, the problem is remembering that I had the code. I usually look over my engine's file tree quickly before I start working. As for copy pasting bits of code, usually I would separate it into a separate function, but it didn't feel reasonable here since it was just a single loop that filled an array with data extracted from Assimp's representation.   I create a const variable (since C# doesn't have #define style values) for when I think a number might be too specific to remember why it was there later, or else I place a comment. But something like i+=3 in my opinion didn't need it because it'd always be obvious why the 3 was there.
  15. hgoel0974

    When you realize how dumb a bug is...

    Once when I was working on a 3d model loader for my game engine, I kept getting messed up normals on anything but a sphere or plane. I looked through everything, began suspecting that they were getting messed up when exporting from Blender, then I looked it up and turned out there had been a bug like that once. Tried another format (since the loader was just Assimp.NET), but nothing changed. Then after 3-4 days of trying different things and fixing possible issues, I noticed:   for(int i = 0; i < Normals.Count * 2; i+=2){ .... }   :|  It felt so stupid that I suspected sabotage from my roommates lol. Now that I think about it, I probably forgot to change the values if I copied the loop for the UVs. (and yes, later I did realize how horrible the idea of looping over everything like that was, and so I've written a proper custom model loader)   Also, a few days ago I was having trouble getting MultiDrawIndirect working. I spent an entire day on it and finally gave up and went to sleep. Then, as soon as I woke up, it hit me, I was using Model q = new Quad(0,0,1,1); to test the drawing, but with the way everything was setup, it wouldn't necessarily be the first thing I saw when I launched the game. I remembered that I had a fullscreenquad class (which was what I intended all this time), so I changed it to Model q = new FullScreenQuad(); and suddenly, it works! It made me get worked up about my skill as a programmer though, not even remembering parts of my own game engine.    Another time, I was having issues with the buffer object memory manager, I came up with all sorts of complicated ways I could get around the issue, then I noticed that I could just remove one check to get the same effect, that was yet another wasted day.
  • 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!