What are you working on? v67 - March 2017

[paindoc]

ages ago now I did anti-ambient occlusion

https://i.imgur.com/TR44LT9.png

[Phygon]

https://files.facepunch.com/forum/upload/111926/8e2bbe4f-33d1-420d-a69f-3a21b8d74946/Bounding bois.PNG

https://files.facepunch.com/forum/upload/111926/583c16e4-bd3f-4d67-97fd-352c92568a8b/bounding bois 2.PNG

Figured out a pretty dang optimized way to split a mesh into its segregate components, in preparation for frustum culling. This increases draw calls temporarily, but I'm going to get them back down by re-combining meshes with the same material hash by just merging their index buffers at draw time post-cull. Anyone have any recommendations for particularly fast ways to merge large collections of gl triangle indices?

[reevezy67]

I made a gamejam game for the first time in like 5 years.
Wacky Spooky Multiplayer Fun Time Respiratory Game by Evan Reeve..

[paindoc]

I would personally recommend doing some kind of indirect drawing in this case. You can then bind the indirect draw buffer in a compute shader and potentially modify that for your frustum culling. The stride size through an indirect draw buffer can also be made larger than an indirect draw command, so you could add some of your unique data used to do testing against.
My obj model loader/renderer is here - https://github.com/fuchstraumer/VulpesSceneKit/blob/master/src/geometries/ObjModel.cpp#L108
I used a multiset for the sets of indirect draws: the key is the material index in my list of descriptors, so I bind a material, dispatch all the indirect draws (in most cases I can combine all indirect draws for a material into a single drawcall, using multidrawindirect). It cut my drawcalls down from 242 (1 per obj model part) to 68 (without multidrawindirect) and 24 in the best cases.
I'm working on porting this optimized clustered forward system from DX12 to Vulkan. He gets it up to something like 2 million lights in the scene before it drops below 60 fps: 90% of this ridiculous number seems to come from offloading everything onto the fucking GPU using Compute shaders. Updating the light positions and parameters? Do it in a compute shader. Generating all the AABBs and Volume partitions? Do it on the GPU. Encoding data using a Z-order curve? Do it on the GPU. It seems obvious in hindsight, but it's to just start doing all of this on the CPU and not think about doing otherwise.
I've still got a bit to go, and it's a rather complex system, but I enjoy the challenge of implementing this sort of stuff and it should give me a ton of overhead for doing large-scale planet rendering stuff again once I get back into that, along with adding things like AO + shadows.

[Phygon]

I'm a little bit hesitant to use compute shaders; this is for a class, and it has to work multi platform and also on computers without a dedicated card. Maybe Unity has just poisoned my experience with them, but don't they tend to affect the portability of the project to other systems?

[paindoc]

I mean using indirect draws does not require compute stuff at all.
I actually moved to Vulkan in no small part because the Vulkan spec requires all implementations/drivers to support the full set of graphics AND compute capabilities, so that's not something I think about anymore and I used CUDA far more than I ever used OpenGL's compute stuff. so, I'm not of any help there. I'd just give indirect drawing a shot, most platforms should support it by now.
Man I forgot how much I disliked wrangling OpenGL stuff like this lol

[Karmah]

Huh, I've never heard of the indirect rendering calls like glDrawArraysIndirect. I take it when used properly, calls like that are more performant than the non-indirect calls?

[paindoc]

Yes, because it loads more data onto the GPU and lets you potentially modify what will actually be drawn using compute shaders and shit etc. Regardless, dispatching a drawcall is an expensive operation for the CPU so reducing our drawcall quantity is generally a good thing.
Looking at the structure usually used to dispatch indexed indirect draws also helps explain why it can be more powerful (this is the vulkan structure, but iirc open gl is nearly the same):
typedef struct VkDrawIndexedIndirectCommand {
uint32_t indexCount;
uint32_t instanceCount;
uint32_t firstIndex;
int32_t vertexOffset;
uint32_t firstInstance;
} VkDrawIndexedIndirectCommand; 
So in this case, we tell the GPU where to start reading indices from, and how many indices to read. vertexOffset is an offset applied to all of the indices in the range supplied. It gets a boost in utility because we can supply an instance count too, so we can use this same draw command to perform instanced rendering.
Its really multidraw indirect stuff that ups the power, though. Besides being able to dispatch multiple instances for rendering, you can do things like this:
// Get all the VkDrawIndexedIndirectCommand objects stored in our multimap that use "idx", the currently bound material
auto draw_ranges = indirectCommands.equal_range(idx);
// using the retrieved range, issue this single drawcall to draw ALL the objects using the same material
const uint32_t num_commands = static_cast<uint32_t>(std::distance(draw_ranges.first, draw_ranges.second));
// I believe the equivalent OpenGL command will be glMultiDrawElementsIndirect
vkCmdDrawIndexedIndirect(cmd, indirectDrawBuffer->vkHandle(), commandOffset, num_commands, sizeof(VkDrawIndexedIndirectCommand));
commandOffset += static_cast<uint32_t>(sizeof(VkDrawIndexedIndirectCommand)) * num_commands;
So in this case, I could have a bunch of different indirect draw structures loaded in my buffer, each describing different geometry that only happens to share a material. Whereas conventional indexed rendering might have you rendering each of these individual objects with a "glDrawIndexed" command, we can accomplish the same here without any of that.
You can also use things like "gl_DrawIDARB" to get the index of the current indirect draw (in the above, this would differ for each member of the range dispatched even though we only issued one drawcall). This can let vary behavior and such in your shader, too. If you want to get really fancy, the best possible thing you could (potentially) do is have ALL your models textures in a single 2D texture array. Then, have some uniform buffer containing the indices of the layers from the 2D array to use per indirect draw (so, access the array with gl_DrawIDARB). Since you now don't need to bind a unique texture per material, you can potentially dispatch all of your drawcalls for however many parts/materials you have in a single go.
With this stuff, most of the performance gains are based on just doing less work on the CPU. The latter section on using the 2D array texture can reduce state/binding changes, and is only really possible by using indirect drawing. So it both reduces CPU work, but also can be used to increase GPU performance and utilization

[im_smelly]

Don't remember the last time I posted, but here's a thing I did that we were talking about once:

https://www.youtube.com/watch?v=NlsjchX_tXo

https://github.com/Elizabwth/win-shader-wallpaper

[Scratch]

MULTITRACK BROADCASTING

https://youtu.be/qUzIUl9cZRs

https://files.facepunch.com/forum/upload/1755/7c978de9-0d56-4db2-a106-72d94ad7efd2/18-03-05_20-43-03-FX_Web_Access_-_Waterfox.png

UI still has basic functionality, most the shit works to a minimal extent. Otherwise I have no idea proper methods of actually tinkering with views

[reevezy67]

So you may know of the game Celeste that came out recently, well. It was made in Monogame, here is the code for the player.
https://gist.githubusercontent.com/alessonforposterity/832da4fab11e10609dad/raw/258df12378399919ae088ba8731a7571d9c2c947/drgn.txt

[proboardslol]

https://files.facepunch.com/forum/upload/132997/868baf84-f119-4415-81fd-4844c5ac96c0/725.jpg

I made an arcade joystick setup in a cardboard box. next I'll solder the LEDs together so it lights up and then I'll put it in a nicer wooden box.
What are some neat input types I can use instead of just buttons and joystick?

[Karmah]

Well you got all the fundamentals for a fight stick, but if you truly want all the input mediums you could add a slider, dial, toggle button, dpad, pressure sensitive buttons, turbo buttons
Just channel your inner madcatz

[proboardslol]

What do the slider, dial, and toggle buttons do? I have some toggle switches lying around

[Karmah]

nothing good I'm sure
Create some artificially difficult combos where you have to set a slider to 75% and a dial to 35.7 degrees

[Zero-Point]

A slider for throttle, perhaps?

[proboardslol]

basically all of the inputs on my board are 1/0. I'm using a USB Joystick board from a kit

[Karmah]

I finally managed to fix a bug that plagued my engine for months.
I had this issue with supporting resizing my app - lighting effects became unusable until next launch. Last week I implemented the system for engine-variable listeners, which I hoped would have inadvertently solved the problem, but no dice.
Through a week of debugging, I narrowed the problem down to the lighting shadowing factors fucking up, which didn't help at all since the shadow system is unrelated to window size. I verified every uniform and buffer attribute before and after resizing making sure they were all the same, and made sure all rendertargets were the correct size.
In the end, by happenstance I found out that my GBuffer resize logic used RGB instead of RGBA. This had a subtle effect as I had the view-depth stored in the alpha channel, which was used to derive view-position -> world-position.

A week of productivity lost because of a single letter missing

[Zyx]

I haven't made anything on this in a long time, but thought I'd give it another go. This time I tried ray picking

https://i.imgur.com/kYydqqk.gif

I just have to make a simple mesh for ray picking. Each individual element has to have its own unique texture name, and then I export it to an .smd file (Thanks Source engine).
Then I combine the collision mesh and the reference mesh together into one big file and load that.

[Phygon]

Progress on getting glMultiDrawElementsIndirect functioning:
At first I couldn't get it to render at all, but now parts of meshes will flash sometimes flash and my FPS is 1/1000th of what it was

https://files.facepunch.com/forum/upload/111926/91a64b58-1aaf-4f08-b630-80b8415b6666/image.png

So I'd say that's some pretty good progress

[Tlean]

Updated some items/resources, they still look like shit but at least they have textures and PBR materials, older ones are on the right

https://files.facepunch.com/forum/upload/1287/7f65bcc8-d315-4779-8c57-ee7ff20ca28b/imagen.png

Aluminium, Carbon fiber, Metal sheets, Niobium. Those are the some of the materials used in the game to make rockets

[paindoc]

Using RenderDoc can be invaluable when debugging these sorts of things: iirc, the newest release will let you view what index counts and such are being set in the indirect draw commands, and you can already view the mesh data to make sure that's ending up correct.
One of my earliest issues was not laying the data out in memory correctly, since I wasn't really ordering the indices/vertices quite right. That and I also used the vertex offset when I had no need to. How often are you updating the buffer containing your indirect draw data structures? You shouldn't really have to update it too often, but if you're doing it every frame you might be getting flickering since the pipeline is trying to use that data while you're still writing to it from the host.

[Lancerue]

I've been learning how to do fixed-point arithmetic
#include <stdio.h>

char *Q_string(unsigned num, int frac_bits) {
  static char str[64];
  int index = 0;

  sprintf(str, "%u.%n", num >> frac_bits, &index); // Write the integer part and store the chars written
  num &= (1 << frac_bits) - 1;                     // Mask out the interger

  while (num) {
    num = ((num << 2) + num) << 1;                 // Fast multiply by 10
    str[index++] = '0' + (num >> frac_bits);       // Write the leading digit
    num &= (1 << frac_bits) - 1;                   // Mask out the leading digit
  }

  str[index] = '\0';                               // Terminate the string

  return str;
}

int main() {
  int pi = (355 << 20) / 113;

  printf("%s\n", Q_string(pi, 20));

  return 0;
}

[Phygon]

I love RenderDoc but for some reason with glMultiDrawElementsIndirect it just crashes the second I try to inspect sub-calls, and the output doesn't display anything.

[NoRegard]

working on my rts/rpg/action game again

https://i.imgur.com/YP0XK0a.gifv

This time not really gonna do any graphics or animations before I have the fundemental gameplay down. All the stuff is done through scripting.

[garry]

Made a mini profiler, integrated it with this site

https://files.facepunch.com/garry/a293d4c2-caa1-4978-94d1-1d11ad556145.png

Gotta work out how to wrap/log sql queries now.

[Phygon]

It looks like shit but look at those frames
This is on a laptop with no dedicated graphics and it's still running the entire PBR shader, even if it looks like shit.

https://files.facepunch.com/forum/upload/111926/378cc3f6-801c-40d5-b7ab-1ad3483ea75b/image.png

[proboardslol]

Dude you getting into N64 modding???

[proboardslol]

My coworkers wrote their resumes in LaTeX for some reason and asked me why I don't do mine in LaTeX.

[NoRegard]

Yeah so did I. Why didn't you? It looks better.