What are you working on? v67 - March 2017

[laserpanda]

I decided to go with Stronghold. I was initially against RTS because of the complexity and because it wouldn't be terribly fun to watch with most games, but Stronghold is more about building good defenses than APM. I think it should be fun to try to make a bot that analyzes the map and builds a castle accordingly.

[helifreak]

Parser for Ultra Defrag's reports because the developer is an idiot and thought that HTML + JS is a good way to have a sortable table of 6000 files.
[t]https://www.helifreak.club/image/20170430062832116.png[/t][t]https://www.helifreak.club/image/20170430062851353.png[/t][t]https://www.helifreak.club/image/20170430062907476.png[/t][t]https://www.helifreak.club/image/20170430062934383.png[/t]
Button text is like that because I didn't bother writing the localisation files.

[jwki]

Actually having fun with Python - trying out to roll a little one button build system that manages dependencies etc automatically.
Currently goes from empty directory to fully working executable with a single console command (well, concatenation of git clone && cd into cloned directory && execute build script).
It automatically downloads dependencies, generates VS project files (or a makefile) using premake and builds the generated project. Need to have it fetch dependencies from a json or whatever now instead of hardcode them.

[ben1066]

It has been quite some time since I've posted anything here, but I've got something interesting. I've been working on a raytracer using photon mapping for some coursework. This is rendered using 5 million photons, and 500 photons for each radiance estimate.

[img]http://i.imgur.com/6ciRs2Y.png[/img]

And then 100,000 photons, with 100 photons for each estimate

[img]http://i.imgur.com/9k6PFZD.png[/img]

[CmdrMatthew]

Been working on a general purpose IDE/Editor with the intention of making it multiplatform.

Currently working on GDB integration

[img]http://i.imgur.com/0Ne2lYB.png[/img]

And yes, that is GWEN.

[Fewes]

Line lights!

[img]http://puu.sh/vBry6.jpg[/img]

[img]http://puu.sh/vBrQw.jpg[/img]

[img]http://puu.sh/vBsmI.jpg[/img]

[Fewes]

Directional light with some basic 2D shadows:

[img]http://puu.sh/vBYwg.jpg[/img]

[Tamschi]

[QUOTE=Darwin226;52166798]Is there an established physics model that says what's possible if you just "turn off" conservation of momentum? Seems like it would make the whole thing very inconsistent.[/QUOTE]

I don't think it's possible since, as I mentioned, it's a theorem that's based on other observations (i.e. how mass, forces and space/connectivity work).
It breaks automatically if you modify the underlying physics in certain ways, but otherwise it's a necessary conclusion from the observations that exist so far.

Introducing portals (that work like the ones in Portal or, if I understand correctly, are Visser-Solution wormholes) breaks [URL="https://en.wikipedia.org/w/index.php?title=Conservative_force&oldid=776321885"]conservativity[/URL] for pretty much all forces and with that conservation of momentum and energy. Overall not much would change, since all local-area physics are preserved (all forces stay the same), but you'd still be able to make a perpetuum mobile. If you look at them in a general relativity context, you'd get some additional gravity/time weirdness though, since the endpoints at different potential would necessarily 'desync' in all cases where no (extremely) strong gravity exists in the portal.

[paindoc]

[URL="http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/05/Most-common-mistakes-in-Vulkan-apps.pdf"]Found a rather nice presentation on Vulkan programming tips[/URL]. I have [I]no[/I] idea how I found it exactly, because I was searching for unrelated terms and it looks like the title of the presentation is in Polish? I dunno. Might be something that's easy to find if one uses sensical keywords, but I stumbled upon it randomly and I've found myself oddly good at finding good learning resources somehow.

There was a potential that we were going to get to implement an improved radio subsystem for [URL="https://en.wikipedia.org/wiki/VBS2"]VBS2[/URL] at work, but that contract fell through. Pretty bummed, I was hopeful I'd get a chance to work on game engine stuff at work since that'd be kinda fun and would be good to have on my resume. Even with having to translate Polish comments and work with a codebase that I'm pretty sure isn't the prettiest lol. Instead, I'll probably be back to doing random things at work over the summer to help complete our small R&D projects. Which is nice for the sake of variety, and for getting a break from programming the same application lone-wolf style for the past several months, but means I'll be doing a ton of random unrelated jobs and writing a [I]ton[/I] of LaTeX papers. Which means they'll be pretty papers buuut... LaTeX.

[editline]edited[/editline]

I'm [I]so[/I] close to having my Vulkan renderer up and somewhat working. I have a few things to fix (like checking the rule-of-five for my vulkan objects), and need to add a few helper features and such, but I'm hoping to get it working sometime today, probably on my lunch break. At which point I'm going to try to start getting most of the Vulkan demos and examples I can find working, since that seems like a good way to check the completeness of my project and make it well-rounded and accessible. Already I have some ideas for doing disgusting things with templates and metaprogramming to make vertex attribute binding less fugly and full of boilerplate code, but that'll have to wait for me to get things actually working.

quick question though - does anyone know how copying Vulkan object handles works? Is that valid or okay? I feel like it [I]should[/I] be given that vulkan-hpp seems to do it by just copying the underlying API handle, but copying handles for graphics APIs is something I'm not entirely comfortable with. I prefer sticking with move ctors and operators for most of my objects anyways since it helps me think carefully about initialization and resource management, but there are places where copy constructors would be useful.

[Solokiller]

[url]https://www.reddit.com/r/cpp/comments/68liwi/here_we_go_the_20s_are_going_to_be_fascinating/?st=j26gky30&sh=f694d586[/url]
[url]https://www.reddit.com/r/cpp/comments/68ljh4/there_is_no_interface_keyword_in_c_herbsutter/?st=j26h8dny&sh=18f9d86d[/url]

This is some pretty neat stuff. There are a lot of useful applications for this that'll make writing the boilerplate so much easier for any projects you can make.

[Lily]

So I commented out the entire block of code that uploads the UI texture to the GPU. That reduced my frametime by a whopping 4-6ms... [i]and the UI still works[/i]. MSVC incremental linking :ok:.

[editline]1st May 2017[/editline]

I mean, I'll take it. I have absolutely no idea which part of my giant GL backend refactor actually drove the frametime down though, since I guess some changes didn't get linked in until I touched that (I don't know how that even would've run).

[jwki]

[QUOTE=paindoc;52173032][URL="http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/05/Most-common-mistakes-in-Vulkan-apps.pdf"]Found a rather nice presentation on Vulkan programming tips[/URL]. I have [I]no[/I] idea how I found it exactly, because I was searching for unrelated terms and it looks like the title of the presentation is in Polish? I dunno. Might be something that's easy to find if one uses sensical keywords, but I stumbled upon it randomly and I've found myself oddly good at finding good learning resources somehow.

There was a potential that we were going to get to implement an improved radio subsystem for [URL="https://en.wikipedia.org/wiki/VBS2"]VBS2[/URL] at work, but that contract fell through. Pretty bummed, I was hopeful I'd get a chance to work on game engine stuff at work since that'd be kinda fun and would be good to have on my resume. Even with having to translate Polish comments and work with a codebase that I'm pretty sure isn't the prettiest lol. Instead, I'll probably be back to doing random things at work over the summer to help complete our small R&D projects. Which is nice for the sake of variety, and for getting a break from programming the same application lone-wolf style for the past several months, but means I'll be doing a ton of random unrelated jobs and writing a [I]ton[/I] of LaTeX papers. Which means they'll be pretty papers buuut... LaTeX.

[editline]edited[/editline]

I'm [I]so[/I] close to having my Vulkan renderer up and somewhat working. I have a few things to fix (like checking the rule-of-five for my vulkan objects), and need to add a few helper features and such, but I'm hoping to get it working sometime today, probably on my lunch break. At which point I'm going to try to start getting most of the Vulkan demos and examples I can find working, since that seems like a good way to check the completeness of my project and make it well-rounded and accessible. Already I have some ideas for doing disgusting things with templates and metaprogramming to make vertex attribute binding less fugly and full of boilerplate code, but that'll have to wait for me to get things actually working.

quick question though - does anyone know how copying Vulkan object handles works? Is that valid or okay? I feel like it [I]should[/I] be given that vulkan-hpp seems to do it by just copying the underlying API handle, but copying handles for graphics APIs is something I'm not entirely comfortable with. I prefer sticking with move ctors and operators for most of my objects anyways since it helps me think carefully about initialization and resource management, but there are places where copy constructors would be useful.[/QUOTE]

Why exactly do you feel uncomfortable copying handles?

[paindoc]

[QUOTE=JWki;52173766]Why exactly do you feel uncomfortable copying handles?[/QUOTE]

Because it can lead to issues with things like destructors. As in the resource being copied from has its destructor called on the exit of a loop, which (since I've just copied a handle) means the copied to object doesn't actually refer to a valid object. I had it happen a couple times with OpenGL, and just found it easier to delete the copy operators+constructors.

Which uh yeah probably means what I'm doing is fine, but I still feel really out of my league with most programming stuff tbh

[Kidd]

Making the critter AI thing. I hope to get mating and genetics but need to get the rest working first. Still has issues with finding food sometimes.

[media]http://www.youtube.com/watch?v=iAufyiRxxt4[/media]

[jwki]

[QUOTE=paindoc;52174167]Because it can lead to issues with things like destructors. As in the resource being copied from has its destructor called on the exit of a loop, which (since I've just copied a handle) means the copied to object doesn't actually refer to a valid object. I had it happen a couple times with OpenGL, and just found it easier to delete the copy operators+constructors.

Which uh yeah probably means what I'm doing is fine, but I still feel really out of my league with most programming stuff tbh[/QUOTE]

Yes if you go RAII on them you'll run into problems with copy however I'd argue you shouldn't do that in the first place. If you wrap something like a handle, the wrapper should conserve handle semantics, meaning that letting the object run out of scope should give the handle back to where it came from. A problem with many graphics wrappers is that they try to tie construction of objects to constructors while it makes more sense I think to have some central object managing resources. So if you need, say, a buffer, you ask the resource device or whatever for a buffer and it'll give you one. Now, the resource objects can hold a pointer to the resource device and in the destructor give back their handle. The device object can then do reference counting internally and release the handle when appropriate. Copy and move semantics for your resource objects get unproblematic now because lifetime of the wrapped resources is managed by the device object instead, while you keep a nice object oriented interface around the handles. So on copy, you'd just call into the device to up the reference count, on move the object being moved from just forgets its handle so you don't get double delete. You probably even have a class wrapping your Vulkan logical device anyway so that's where resource management would make sense. I'd write something out in code to make myself more clear but I'm on mobile so that'd be a horrible mess.
So the tl;dr I guess is: don't use naive RAII for graphics resources, use centralised reference counting with explicit factory methods. This allows you to add pooling of resources on the Vulkan side of things as well without having to touch your resource objects.
Fwiw, you can achieve something similar by using shared_ptr with a custom deleter I guess but I think keeping the issue of resource lifetime centralised is a good application of the single responsibility principle.

[Fewes]

Sprites can now cast directional light shadows:

[img]http://puu.sh/vCYX3.jpg[/img]

[editline]Edited:[/editline]

Clamped the lighting to some step values and added color grading, I think it looks pretty sweet!

[img]http://puu.sh/vDaej.png[/img]

[paindoc]

[QUOTE=JWki;52175621]Yes if you go RAII on them you'll run into problems with copy however I'd argue you shouldn't do that in the first place. If you wrap something like a handle, the wrapper should conserve handle semantics, meaning that letting the object run out of scope should give the handle back to where it came from. A problem with many graphics wrappers is that they try to tie construction of objects to constructors while it makes more sense I think to have some central object managing resources. So if you need, say, a buffer, you ask the resource device or whatever for a buffer and it'll give you one. Now, the resource objects can hold a pointer to the resource device and in the destructor give back their handle. The device object can then do reference counting internally and release the handle when appropriate. Copy and move semantics for your resource objects get unproblematic now because lifetime of the wrapped resources is managed by the device object instead, while you keep a nice object oriented interface around the handles. So on copy, you'd just call into the device to up the reference count, on move the object being moved from just forgets its handle so you don't get double delete. You probably even have a class wrapping your Vulkan logical device anyway so that's where resource management would make sense. I'd write something out in code to make myself more clear but I'm on mobile so that'd be a horrible mess.
So the tl;dr I guess is: don't use naive RAII for graphics resources, use centralised reference counting with explicit factory methods. This allows you to add pooling of resources on the Vulkan side of things as well without having to touch your resource objects.
Fwiw, you can achieve something similar by using shared_ptr with a custom deleter I guess but I think keeping the issue of resource lifetime centralised is a good application of the single responsibility principle.[/QUOTE]

Thanks for this, this is a really informative post! And I had already run into issues that sounds like they would be solved by a solution like this (e.g validation layers tell me object destroyed before device, vkSwapchainKHR before vkSurfaceKHR, etc). It's not something I've used before since I've only stuck with RAII (outside of my brief work on my old N-body sim I guess), so I need to do more research on it.

I had initially tried to use weak_ptr to hold pointers to parent objects, but had a few issues with this so abandoned it. I think I'm going to figure out some kind of better way to pool resources and then try seeing what the standard library can do for me in this respect.

again, cheers for the informative post!

[DarKSunrise]

i used to have a raii setup for opengl objects and it was a nightmare

switched to shared_ptrs and it solved pretty much every issue i had

[jangalomph]

We finally released a buy once and own forever option of our software. Surprisingly our sales have increased. I guess when you listen to your customers/audience good things happen.

I posted this a while back in the UE4 thread, but don't think i showed off the final version.
[video=youtube;72abXopPJ-g]http://www.youtube.com/watch?v=72abXopPJ-g[/video]

We also have a new page that better describes the software and what not!

[URL="https://jangafx.com/vectoraygen-sales/"]New VectorayGen Page![/URL]

Lastly, I've hired on a few new programmers to tackle unity integration of GPU particle and Vector Field representation and then to also tackle real time fluid simulations to rival FumeFX.

Lots of stuff happening :D

[DarKSunrise]

is that the forest map from the facepunch mapping megathread?

[jangalomph]

[QUOTE=DarKSunrise;52177688]is that the forest map from the facepunch mapping megathread?[/QUOTE]

Yes sir it is. Good ol shirk made it :)

[mastersrp]

[QUOTE=jangalomph;52177678]We finally released a buy once and own forever option of our software. Surprisingly our sales have increased. I guess when you listen to your customers/audience good things happen.

I posted this a while back in the UE4 thread, but don't think i showed off the final version.
[video=youtube;72abXopPJ-g]http://www.youtube.com/watch?v=72abXopPJ-g[/video]

We also have a new page that better describes the software and what not!

[URL="https://jangafx.com/vectoraygen-sales/"]New VectorayGen Page![/URL]

Lastly, I've hired on a few new programmers to tackle unity integration of GPU particle and Vector Field representation and then to also tackle real time fluid simulations to rival FumeFX.

Lots of stuff happening :D[/QUOTE]

The water reflection looks quite a bit pixelated? Is this intentional?

[Dr Magnusson]

[QUOTE=JWki;52173766]Why exactly do you feel uncomfortable copying handles?[/QUOTE]

Because a handler implies ownership and duplicating ownership muddies ownership responsibility for the object the handler represents.

[editline]2nd May 2017[/editline]

Whoops, my bad. Didn't realize there was another page :v

[Fireboyd78]

I've been reverse engineering a format that somehow manages to pack 3 floats into a single 32-bit integer. After finally finding the function(s) that accomplish this, I'm quite interested in how someone figured this out in the first place, and if it's based on an existing method of data compression. Basically, I'd like to know how the algorithm works, so I could possibly re-pack the data as well.

I've simplified it as best as possible and shown each step below (using a random value):

N = 0x1E2BF351

Z = (N >> 20) 
    = 0x000001E2
    = 482 * 0.0073242188
    = 3.530
    
Y = (N << 12)
    = 0xBF351000 >> 22
    = 0xFFFFFEFC
    = -260 * 0.005859375
    = -1.523
    
X = (N << 22)
    = 0xD4400000 >> 22
    = 0xFFFFFF51
    = -175 * 0.005859375
    = -1.025

  = (-1.025, -1.523, 3.530, 1.0)

Honestly, this shit is mind-blowing to me, because compression is not exactly my forte. But I'm still very interested, nonetheless. If anyone wants to try and help me understand this better, I'd really appreciate it!

EDIT: Fixed the order of XYZ, forgot it's read in backwards

[DoctorSalt]

[QUOTE=CarLuver69;52177930]
Honestly, this shit is mind-blowing to me, because compression is not exactly my forte. But I'm still very interested, nonetheless. If anyone wants to try and help me understand this better, I'd really appreciate it!

EDIT: Fixed the order of XYZ, forgot it's read in backwards[/QUOTE]

Don't really get what this is doing, but ignoring the code I can assume this is dropping precision and using parts of the int to store the same info (since no way can you make a 1:1 function between R^3 and Z). I wonder if those values were determined emprically to optimize on information loss and thus has no satisfying reason for existing.

EDIT: I'm learning more about Pegasystems business software. They have a bit where they say they encode information is base64 for security/space reasons. lol

[Fireboyd78]

[QUOTE=DoctorSalt;52178001]Don't really get what this is doing, but ignoring the code I can assume this is dropping precision and using parts of the int to store the same info (since no way can you make a 1:1 function between R^3 and Z)[/QUOTE]

Yes, precision loss is always a given when doing these sorts of things. But how does one come up with the strange values such as 0.005859375?

My observation so far is that X and Y are 10-bits while Z is 12-bits. How those strange decimals are calculated is beyond me.

EDIT:

Wow, all this brainstorming actually helped me figure it out! Basically, a 10-bit value can be -511>511 signed, and 512 unsigned. 12-bits gives us -1023/1023 signed and 1024 unsigned.
Then we have to account for the conversion back to a float. In this case, the format allows for X and Y to be -3.0>3.0 (3 / 512 = 0.005859375) and Z to be -7.5>7.5 (7.5 / 1024 = 0.00732421875).

Neat stuff!

[jwki]

[QUOTE=paindoc;52177094]Thanks for this, this is a really informative post! And I had already run into issues that sounds like they would be solved by a solution like this (e.g validation layers tell me object destroyed before device, vkSwapchainKHR before vkSurfaceKHR, etc). It's not something I've used before since I've only stuck with RAII (outside of my brief work on my old N-body sim I guess), so I need to do more research on it.

I had initially tried to use weak_ptr to hold pointers to parent objects, but had a few issues with this so abandoned it. I think I'm going to figure out some kind of better way to pool resources and then try seeing what the standard library can do for me in this respect.

again, cheers for the informative post![/QUOTE]

Using raw pointers is fine, you know. Resource objects will probably not own the device so they can safely reference to it using a raw pointer.

[paindoc]

So the [I]absolutely brilliant[/I] [URL="https://github.com/prusa3d/Slic3r/blob/master/xs/src/libslic3r/TriangleMesh.cpp#L902"]slicing/polygon generation code[/URL] I posted a page or two ago spends quite a bit of time on iterating and setting a "skip" value for certain lines and points in its various containers. Then, they do a large amount of iteration (especially in whatever the fuck the [I]thing[/I] at line 956 is) to check if a point or line can be skipped.

Are these 3 lines really that hard to use?

[cpp]
std::vector<intersection_line> cleaned_lines(lines.cbegin(), lines.cend());
auto erase_iter = std::remove_if(cleaned_lines.begin(), cleaned_lines.end(), [](const intersection_line& line) { return line.skip; });
cleaned_lines.erase(erase_iter, cleaned_lines.end());
[/cpp]

I've checked all over to see if there's any real need for the skipped points, but nope. But whoever wrote this used a few modern C++ things though, in between using "goto" and doing other awful things. This code just confuses me at this point. Like, it works better than anything I've done and Cura [URL="https://github.com/Ultimaker/CuraEngine/blob/master/src/slicer.cpp"]is just as disgusting[/URL]. They also don't really keep the lines sorted in a sensical fashion- this is all threaded, but they create a vector the right size for the amount of layers, then add intersection data to that line from within the other loops using the index corresponding to a certain layer height w/ push_back() (because its a vector of vectors lol). I haven't tried to get threading working yet, but I found it far easier to use a multimap with the key being the layer height and the entry being the intersection data. Then when I generate lines I use multimap.equal_range() to get all the intersection lines at a certain height and feed them to the polygon generator.

This should be really easily made thread-safe, too, since I can use something like concurrent_multimap (I guess), and I'm not indexing into the container from multiple threads, just inserting elements (which the concurrency runtime stuff should manage, iirc). Plus, its really easy to grab the data at a certain height since I don't have to take the slicing heights and make them integer indices somehow.

[jangalomph]

[QUOTE=mastersrp;52177778]The water reflection looks quite a bit pixelated? Is this intentional?[/QUOTE]

It's just an artifact of the video compression on the darker surface of the water. In UE4 it's quite crisp. :shrug:

[Why485]

[url=http://www.blog.sirenix.net/blog/realtime-volumetric-clouds-in-unity]I came across this tutorial on volumetric clouds by Sirenix[/url]. It’s a subject matter I’ve always been interested in but, holy [I]wow[/I] was I not expecting this to look this good or work this well. There’s a lot of shader magic that I barely understand going on here. It’s also not written in a way that’s immediately usable for a real project. I can’t render any geometry for example, it’s purely tech demo territory, but definitely something I want to experiment with some more.

If I can get this working in a practical way, it’s easy to imagine a ton of things that it could be applied to.

[vid]https://my.mixtape.moe/abqeor.webm[/vid]