Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jul 2013
Offline Last Active Yesterday, 03:52 PM

#5276240 Vulkan is Next-Gen OpenGL

Posted by on 17 February 2016 - 07:44 PM

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.




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.

#5269358 When you realize how dumb a bug is...

Posted by on 05 January 2016 - 02:09 AM

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....

#5232179 When you realize how dumb a bug is...

Posted by on 01 June 2015 - 10:46 AM

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);

#5226869 Using the 'latest' extensions for a game

Posted by on 02 May 2015 - 01:16 PM

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.

#5225140 Using the 'latest' extensions for a game

Posted by on 23 April 2015 - 05:11 PM

@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?

#5221376 When you realize how dumb a bug is...

Posted by on 04 April 2015 - 01:10 PM


Yesterday I'm setting up a new Opengl/SDL/Linux app.  Step one: draw xyz axis lines and rotate them with the mouse.  Easy.  So I copied a lazy-foo example, stuck in my own stuff, and segfault.  What???


The code isn't even doing anything.  Hours later, after unsuccessful attempts to read logs, get error callbacks, step through the code, and at least an hour trying and failing to install a visual opengl debugger, a coworker looks over the code.


"Shouldn't you call glDrawArrays() instead of glDrawElements() when you don't have an index array?"



lol, I had something very similar happen to me, only it was between glMultiDrawArraysIndirect and glMultiDrawElementsIndirect and there wasn't a segfault because C#


I kind of feel dumb for never forgetting how my code works. Maybe I forget the details, but if I take a quick look I remember everything immediately =/



Other times people copy/paste with minor modifications rather than turning the functionality into a reusable function.

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.


There was a discussion about that kind of constant just last week. When things should be numbers, or constants in code, or values in data, is a question debated by everyone, even professionals, and it all comes down to implementation details.

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.

#5221134 When you realize how dumb a bug is...

Posted by on 03 April 2015 - 10:25 AM

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.

#5216056 RenderQueue + Multithreading in OpenGL?

Posted by on 12 March 2015 - 08:30 AM

Sorry for the late reply.

Thanks for your advice L.Spiro.

I did mean to talk about Command Buffers, I just suck at terminology :P

I understand that there isn't much to be gained on the OpenGL side, but I think this should help speed up my resource loading since that data will have more time to get loaded before it's needed (then again, since I recently learned how designing the model format so it could be put straight on to the GPU without much parsing would help load times, not sure how much this will matter with that in place as well).

#5104715 Anyone here a self-taught graphics programmer?

Posted by on 26 October 2013 - 11:34 PM

Truly neat topic!

I'm a completely self taught programmer and well I can't possibly have a degree anyway because I'm just 16, I'm in my last year of high school. I am mainly a C# programmer although I can also work with Java,C,C++ and Python.


I started learning programming about 5 years ago, I was into playing a lot of video games, then I got GTA San Andreas which wouldn't run on my computer because my machine was too old, it made me wonder why it wouldn't run, this led to research (on a dial up connection) I found out about BASIC and started doing some basic (pun intended) programming in it, however I didn't find it to be powerful enough for what I expected so I stopped, then a few months later our computer teacher began teaching us the basics of C++ (which never really worked out because he didn't know much himself, he just used the cprogramming.com tuts). This peaked my interest in programming again, I tried C++ but couldn't make much of it but I ended up discovering C#, I bought a few books about it and learned the basics, I go Visual Studio only to find out that my computer could barely handle it, this slowed my development a lot, eventually I gave up and went back to playing games.


Then I discovered Midtown Madness mods, I learned how to use zmodeler to make my own mods, soon I moved on to blender, then when I visited my sister at new york, she gave me her laptop which was quite recent (it's only about 2-3 years old), finally able to do things faster, I went back to C#, I quickly got used to it and started programming things on a daily basis (one project a week however most are still incomplete), then I got involved in the PSP hacking scene, it was a bit hard to get the basics of things like MIPS assembly (not to mention the fact that C/C++ were still incomprehensible to me) but I managed to figure everything out, then I got a PS Vita and a few months later PlayStation Mobile was launched. PSM  used C# which attracted me to the platform, that's where my 3d graphics adventure began. Along with a friend, I created Aperture Studios and we are currently working on our first title (and a 3d game engine) and very recently (infact a few days ago) I gave C++ a go again to find out that I properly understand everything!,


Anyway here's a video of what we have so far:


#5104706 Real-time Global illumination for games discussion

Posted by on 26 October 2013 - 10:22 PM

1. Definitely worth looking at, there are so many techniques out there, each one with some advantages and disadvantages plus it gets you thinking about how you could improve the algorithms (because of how painfully slow many GI methods are)

2. Trig, basic understanding of rays, ray propogation, matrices, vectors, sometimes the very basics of calculus and that should get you through most algorithms

3. theres ray tracing, path tracing, voxel cone tracing, metropolis light transport, ambient occlussion, photon mapping