[URL="http://fuchstraumer.github.io/high-density-hilbert-infill.html"]Yay fractal infill generation is working[/URL] (warning, fuckhuge file again)! I haven't run any simplification on this, admittedly, despite spending quite a while writing that "intelligent" polygon simplification algorithm. Despite consisting of several thousand points, the bulk of the size of that HTML file (3.6mb) is due to the detail of the contour path being wayyyy too high. I'm pretty proud of the implementation of the infill generator too. Its designed to make adding new infill types as easy as possible - and I'm going to find a way to load python scripts w/ boost::python for generating new infill types. I think the scientist types at work will like that. It'll be slow as hell, I think, but that's better than forcing them to figure out C++. Right now, the Infill generation class has an "infillFunc" class member that's just:
[cpp]
std::function<std::vector<glm::vec2(const glm::vec2& min, const glm::vec2& max)>;
[/cpp]
Then, you can either use an enum name to load one of the predefined infill functions I've written or pass the actual function itself in the infill generator constructor. From there, I use the given function to generate lines that should fill an AABB around each component of a sliced layer - then use a polygon intersection and some cleanup to neatly merge things back together. The point was to remove as much of the painful cleanup and verification work from the user. The only sticking point, I guess, is that you can't access any of the parent class fields or methods and each function (almost a "module", really) should define its own constants and helper functions as lambdas in the function body. In the above example, that infill is a hilbert-curve generated by this method (linked, b/c longpost is already long): [url]https://gist.github.com/fuchstraumer/d837ba2f58cf7d9f7c99c8746eab7ad8[/url]
I need to tune perimeter generation still, since thats a rather delicate operation, but I should be have something capable of generating Gcode for printers shortly. And honestly, despite my lack of education and general inexperience in C++ it should compete with Cura and Slic3r. Especially in maintainability and how expandable it is, given how hard I tried to keep it clean, modular, and full of modern C++ paradigms. Its faster than I expected, too (and still single threaded)! Slicing a 21mb octopus STL into 261 layers, generating basic perimeters, and creating infill takes less than 13 seconds: comprising a total of 2.75mil points generated for 23.8k polygons. RAM usage stays low as hell too, which is nice since Cura seems to have terrible memory leaks and Slic3r just explodes randomly for no reason.
[QUOTE=paindoc;52207019][...], the bulk of the size of that HTML file (3.6mb) is due to the detail of the contour path being wayyyy too high. [...][/QUOTE]
You might also want to consider not using tens of thousands of individually styled straight line elements to render this :v:
Even if you don't collate segments into ordered lines, you can still move a <path>'s cursor without it drawing very easily, which would reduce the file size by at least half.
[QUOTE=Tamschi;52208848]You might also want to consider not using tens of thousands of individually styled straight line elements to render this :v:
Even if you don't collate segments into ordered lines, you can still move a <path>'s cursor without it drawing very easily, which would reduce the file size by at least half.[/QUOTE]
I did not know this, tbh. The debug SVG class is just some real quick implementation I slapped together, especially since its just for debug usage, but if I can get this to work fairly quickly it could still be helpful for reducing the size of the clutter on my hard drive.
[editline]edited[/editline]
as mentioned, that file I sliced is also obnoxiously huge and really heavily detailed. Its a mesh that is frankly far too complex for its own good.
I'm starting to feel more and more proud of my work on this application, though (probably not entirely justified). Bit bummed that I don't have anyone to show it off to, though, since no one in my division at work programs much. And I've been here longer than most of them, so they don't really realize how much work its taken to go from "What is a C++?" and a blank project file to where its at today. I can't really show my programmer friends, either, since its not yet released and I can't really show too much of it in this thread. And I feel like its not that interesting, tbh, so many projects that are way neater in this thread.
[QUOTE=paindoc;52210086]I did not know this, tbh. The debug SVG class is just some real quick implementation I slapped together, especially since its just for debug usage, but if I can get this to work fairly quickly it could still be helpful for reducing the size of the clutter on my hard drive.[/QUOTE]
Use [URL="https://developer.mozilla.org/de/docs/Web/SVG/Element/path"][I]<path>[/I][/URL] with [URL="https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d"][I]d[/I][/URL] ([I]M[/I] and [I]L[/I] in your case, for example [I]d="M50,20L10,40M60,10L20,20"[/I] for lines from (50, 20) to (10, 40) and from (60, 10) to (20, 20)).
Of course if you collate the lines (which I assume you'll have to do anyway to some extent to do the printer output), you'll be able to drop a lot of those [I]M[/I]x[I],[/I]y instructions. This seems like a good way to debug that, too.
You could likely make the file a bit smaller with relative positioning too ([I]m[/I] and [I]l[/I]), but that's possibly little gain for a medium to high (depending on optimisation level) implementation complexity.
[QUOTE=Tamschi;52210912]Use [URL="https://developer.mozilla.org/de/docs/Web/SVG/Element/path"][I]<path>[/I][/URL] with [URL="https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d"][I]d[/I][/URL] ([I]M[/I] and [I]L[/I] in your case, for example [I]d="M50,20L10,40M60,10L20,20"[/I] for lines from (50, 20) to (10, 40) and from (60, 10) to (20, 20)).
Of course if you collate the lines (which I assume you'll have to do anyway to some extent to do the printer output), you'll be able to drop a lot of those [I]M[/I]x[I],[/I]y instructions. This seems like a good way to debug that, too.
You could likely make the file a bit smaller with relative positioning too ([I]m[/I] and [I]l[/I]), but that possibly little gain for a medium to high (depending on optimisation level) implementation complexity.[/QUOTE]
I think this is more than good enough, no need for relative positioning lol. cheers for the tip!
[t]http://i.imgur.com/CtUICew.png[/t]
the points have to be collated for most things to work at all, and the first pass of motion optimization makes sure to collate the paths. that and I think all the clipper algorithms require them to be collated. I spent quite some time making sure the ordering was well-maintained between conversions and casts to different types/containers of point/line/polygon data (I should [I]probably[/I] add some explicit constructors...)
*passionate graphics discussion contribution*
[editline]10th May 2017[/editline]
also, Python GUI is in my future somewhere.
who doesn't need a 7.2KHz refresh rate? They said vulkan was fast but they didn't say it went sanic speed
[t]http://i.imgur.com/3bhCnos.png[/t]
okay so maybe thats just rendering two textured planes but i did get depth testing working so thats nice. then everything explodes when I try to build in release mode, which results in the slightly odd exception occurring at the [I]completely[/I] sane address below:
[code]
Unhandled exception at 0x000000006C5DDDCB (nvoglv64.dll) : 0xC0000005: Access violation reading location 0xFFFFFFFDE4E17798
[/code]
gotta love driver crashes, because then you don't even get anywhere to start with debugging, yay (kill me)
Experimenting with baking 2D ambient/sky occlusion:
[img]https://puu.sh/vMDtW.jpg[/img]
[img]https://puu.sh/vMDue.png[/img]
[editline]11th May 2017[/editline]
Storing the result in a mesh:
[img]http://puu.sh/vMIlk.jpg[/img]
Kind of a minor thing, but in LibNoise's program, they want to assert that Mountains_Amount is greater than Hills_Amount. This is all fine and dandy, it even says so in the comments of the code, shit it even has an assert to try and check for it right? So you'd think all is good? Nah.
Problem:
[code]
assert(MOUNTAINS_AMOUNT < HILLS_AMOUNT );
[/code]
Is the actual line they have in their program. So uhh, what? Idk how you manage that kind of bug but lol. That sorts out the mountain placement bug I was having. Guess I'll either fix the function call or just delete that assert and run my own check, either way.
[QUOTE=F.X Clampazzo;52216515]Kind of a minor thing, but in LibNoise's program, they want to assert that Mountains_Amount is greater than Hills_Amount. This is all fine and dandy, it even says so in the comments of the code, shit it even has an assert to try and check for it right? So you'd think all is good? Nah.
Problem:
[code]
assert(MOUNTAINS_AMOUNT < HILLS_AMOUNT );
[/code]
Is the actual line they have in their program. So uhh, what? Idk how you manage that kind of bug but lol. That sorts out the mountain placement bug I was having. Guess I'll either fix the function call or just delete that assert and run my own check, either way.[/QUOTE]
Their philosophy must be 'less is more' :v:
[QUOTE=F.X Clampazzo;52216515]Kind of a minor thing, but in LibNoise's program, they want to assert that Mountains_Amount is greater than Hills_Amount. This is all fine and dandy, it even says so in the comments of the code, shit it even has an assert to try and check for it right? So you'd think all is good? Nah.
Problem:
[code]
assert(MOUNTAINS_AMOUNT < HILLS_AMOUNT );
[/code]
Is the actual line they have in their program. So uhh, what? Idk how you manage that kind of bug but lol. That sorts out the mountain placement bug I was having. Guess I'll either fix the function call or just delete that assert and run my own check, either way.[/QUOTE]
"Our mountains are huge, they're the biggest, the absolute best."
So I've never used the VS code analysis feature before. I was pretty concerned when it was telling me that I was like 8x over the maximum stack size. Then I did some math and realised that the program was just fucking stupid because it was bitching about like .8 MB being needed for stack memory. I mean, yeah I should [I]probably[/I] stick below 1MB of stack memory, but uhh, my program's maximum need is that ~0.8 so whatever.
Should I chunk that down and allocate 99% of it to heap? Meh, probably. But all of that allocation is needed basically the entire duration of the program anyway so idk. No real reason doing so I don't think since my program can't even run on a 32-bit OS so I'm not in any danger of running out of physical memory.
[QUOTE=F.X Clampazzo;52216797]So I've never used the VS code analysis feature before. I was pretty concerned when it was telling me that I was like 8x over the maximum stack size. Then I did some math and realised that the program was just fucking stupid because it was bitching about like .8 MB being needed for stack memory. I mean, yeah I should [I]probably[/I] stick below 1MB of stack memory, but uhh, my program's maximum need is that ~0.8 so whatever.
Should I chunk that down and allocate 99% of it to heap? Meh, probably. But all of that allocation is needed basically the entire duration of the program anyway so idk. No real reason doing so I don't think since my program can't even run on a 32-bit OS so I'm not in any danger of running out of physical memory.[/QUOTE]
The stack size is configurable [I]somewhere[/I], but I don't know where. I think it's a PE file metadata field though.
I got .obj file importing working with Vulkan, but I'm still stuck on a crash during release mode. Its only when optimization is enabled, too, so it must be due to uninitialized values or something. I used the "/Zo" flag in MSVC so that I could have more debug information even in release mode, but that wasn't enough. I even found a ton of rather big bugs elsewhere (e.g the awful choice of putting Vk function calls in my VkAssert() macro D:), but those weren't the ones causing the issue :/
Made a pretty house show up though, as the conclusion of the Vulkan tutorial:
[t]http://i.imgur.com/28TY7hW.png[/t]
I'm not quite sure what to do next, but I've been playing with model importing libraries. I quite like tinyobj because its so simple to use, but I'm wondering if moving to Assimp is better. I don't like a lot of Assimp's syntax and how it looks, but it works fairly well and covers a huge range of model formats (which is also why the default build configuration gives you a 400mb static debug-mode library). I've got both Assimp and tinyobj working right now, but are there any other model importing systems that are worth looking at? I'm mainly planning on sticking with obj for now, and maybe trying collada/.dae stuff once I have the capability to use more of the data that format stores.
[sp]I also made a horrible thing involving a e s t h e t i c and something lewd that should probably make someone revoke my Vulkan privileges tbh[/sp]
Someone has weirdest crashes with my Half-Payne mod so I asked to send me crash dumps. I load one of them in Visual Studio 2015, don't get much ideas and try to load another one
it doesn't
it says it doesn't see my dll file
even when I open the dialogue window that wants that dll file and double click it - nothing fucking happens
sometimes it shows a window a couple of times that seems to look for dll in the specified directory and then just closes
it's been awhile since I was that mad at technology. what the hell am I missing here and why did it work JUST ONCE
My current at-home project for the past (almost) 2 weeks is also what brought me to this forum; a UI to manage GMOD servers & mods. Because I don't want to remember steamCMD and gmad commands any more, and I couldn't find such a thing from a (lazy) Google search.
It currently downloads gamefiles, extracts and packages *.gma files, compares extracted mods for potential conflicts (including full file diffs), and copies extracted mods into a server - optionally creating a full copy of the server and then copying the mods in.
There's still a couple of things I want it to do with functionality, then move to a cross-platform GUI (and not a crappy WinForms thing)
[QUOTE=suXin;52219215]Someone has weirdest crashes with my Half-Payne mod so I asked to send me crash dumps. I load one of them in Visual Studio 2015, don't get much ideas and try to load another one
it doesn't
it says it doesn't see my dll file
even when I open the dialogue window that wants that dll file and double click it - nothing fucking happens
sometimes it shows a window a couple of times that seems to look for dll in the specified directory and then just closes
it's been awhile since I was that mad at technology. what the hell am I missing here and why did it work JUST ONCE[/QUOTE]
I've had that problem a few times, VS doesn't like it when you try to use a crash dump with a dll that isn't the exact same one that caused the crash. Try using WinDbg instead.
I hope you kept PDB files for your releases, because you'll need them to make sense of things.
[QUOTE=Tamschi;52218022]The stack size is configurable [I]somewhere[/I], but I don't know where. I think it's a PE file metadata field though.[/QUOTE]
I figured it out. It's configurable in the linker section of project properties and the analysis limit is configurable iirc in the c++ section.
Wrote a multi-threaded github network spider.
Here's a scraped output displayed on ORA-LITE, number of stars as color:
[t]http://i.imgur.com/2ATT7Lk.png[/t]
[QUOTE=paindoc;52219209]I got .obj file importing working with Vulkan, but I'm still stuck on a crash during release mode. Its only when optimization is enabled, too, so it must be due to uninitialized values or something. I used the "/Zo" flag in MSVC so that I could have more debug information even in release mode, but that wasn't enough. I even found a ton of rather big bugs elsewhere (e.g the awful choice of putting Vk function calls in my VkAssert() macro D:), but those weren't the ones causing the issue :/
Made a pretty house show up though, as the conclusion of the Vulkan tutorial:
[t]http://i.imgur.com/28TY7hW.png[/t]
I'm not quite sure what to do next, but I've been playing with model importing libraries. I quite like tinyobj because its so simple to use, but I'm wondering if moving to Assimp is better. I don't like a lot of Assimp's syntax and how it looks, but it works fairly well and covers a huge range of model formats (which is also why the default build configuration gives you a 400mb static debug-mode library). I've got both Assimp and tinyobj working right now, but are there any other model importing systems that are worth looking at? I'm mainly planning on sticking with obj for now, and maybe trying collada/.dae stuff once I have the capability to use more of the data that format stores.
[sp]I also made a horrible thing involving a e s t h e t i c and something lewd that should probably make someone revoke my Vulkan privileges tbh[/sp][/QUOTE]
You can try out glTF.
Also that bug sounds A LOT like an incorrectly initialized create info struct somewhere.
[QUOTE=JWki;52220089]You can try out glTF.
Also that bug sounds A LOT like an incorrectly initialized create info struct somewhere.[/QUOTE]
I found the bug. [I]Thank [B]god[/B][/I] for the super smart russians that seem to make up most of the /r/vulkan subreddit. What a bug:
[quote]
IMAGE(ERROR): object: 0x0 type: 0 location: 6800 msgCode: 1413: vkCreateGraphics Pipelines: pCreateInfo[0].pVertexInputState->vertexAttributeDescriptions[0].form at (VK_FORMAT_UNDEFINED) is not a supported vertex buffer format.
Adding "static" at the begging of line 26, in AttrDescr() function in the VertexTypes.h file, helped in my case and the release code started working. It should be something like:
// line 26: static const std::array< const VkVertexInputAttributeDescription, 3> result = {
It looks like in release mode it returns a reference (??) to a local variable that gets deleted when we get out of the function (which makes sense), but in debug mode it correcly returns a copy of an array (??) or a reference to an un-deleted (??) local object? This behaviour is very strange because it should be valid to return a copy of a variable of type std::array<> as far as I know. But adding a "static" keyword confirms that it's something similar to the above problem. OK, after some more digging I know what has happened. You returned a copy of a variable but immediately assigned a pointer to this variable in line 215 of the Quad.h file in this same line:
vertex_info.pVertexAttributeDescriptions = VertexBase2D::AttrDescr().data();
Changing it to something like this would help (instead of adding "static" word as described above):
auto desc = VertexBase2D::AttrDescr(); vertex_info.pVertexAttributeDescriptions = desc.data();
You shouldn't assign a pointer to a variable that gets destroyed in another line of code. Hope this helps ;-). Good luck!
[/quote]
Fairly clear in hindsight - I shouldn't have been trying to shortcut the pointer like that. I thought doing it with a "constexpr static" method + return object would be fine but nah.
[editline]13th May 2017[/editline]
I thought this was an odd perk of C++ and resigned it to "lol C++", but then people told in the discord channel got in a terse debate over that and all I learned is I'm a bad and should feel bad. so some actual clarification would be welcome
From what i understand VertexBase2D::AttrDescr() returns an std::array, which is an rvalue in the scope of the calling function and, being unassigned to anything, gets destroyed right away after the execution moves to the next line regardless of the type of function that yielded it(or it may not even be initialized due to certain release optimizations). So assigning a pointer to it's data is a clear example of undefined behavior.
[QUOTE=paindoc;52222768][...]
I thought this was an odd perk of C++ and resigned it to "lol C++", but then people told in the discord channel got in a terse debate over that and all I learned is I'm a bad and should feel bad. so some actual clarification would be welcome[/QUOTE]
C++ is one of the few languages where you can do this (somewhat, since it doesn't make sure you do it properly) safely at all, since its variables are alive [I]all[/I] throughout the current scope.
In C# for example, where variables are only valid until their last use, you'd have to do one of the following:
- call [I]GC.KeepAlive(desc)[/I] later if [I]desc[/I] is inherently pinned (messy, non-standard),
- use a fixed statement to pin it,
- use a [I]using[/I] directive on [I]desc[/I] assuming it implements [I]IDisposable[/I] (not exactly standard for simple arrays, I think, unless you have a custom way of pinning it to isolate/centralise [I]unsafe[/I] code),
- make desc.data() a custom data type that pins [I]desc[/I] while alive (nice interface, but more work and slower since you still have to unpack it in the Vulkan wrapper).
Doing (just about) anything else (potentially) creates a race condition between the main program and the GC thread.
Similar limitations apply to any other languages that don't have scope-level RAII (which are most, really).
More Breath of the Wild reverse engineering..
[vid]https://my.mixtape.moe/iiitvf.mp4[/vid]
Me and Matt have been working on this for a bit, I've done most of the terrain stuff. I'm just now loading in the LOD's properly. It's honestly not the most intuitive format, and it changed in the last version update.
One step closer to a proper editor :)
EDIT: That's also not normal mapped or textured-- Breath of the Wild just has that much terrain data. About 5.2 GB worth of height + metadata and around 1.5gb of height alone.
Not strictly waywo but might be relevant, AMD just open sourced their opencl stack which is pretty legit
[url]https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/blob/amd-master/README.md[/url]
[QUOTE=Quiet;52221454]
[/QUOTE]
If you can fit that in 512 bytes (510 really) you should be hired by ubisoft so you can fix their shit code.
[QUOTE=Sombrero;52223780]If you can fit that in 512 bytes (510 really) you should be hired by ubisoft so you can fix their shit code.[/QUOTE]
Thank you! The whole program is 458 bytes.
Got a better image!
[t]http://i.imgur.com/8H5pvdc.png[/t]
Also a star scoreboard:
[img]http://i.imgur.com/cc21xEf.png[/img]
I'm so glad I enrolled in this elective, learned a bunch about web apis and stuff. Had fun too.
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
