Jump to content
Ultimaker Community of 3D Printing Experts


  • Posts

  • Joined

  • Last visited

Personal Information

  • Country
  • Industry

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

nubnubbud's Achievements



  1. no, I only copied and pasted ironing moves from different files to make a frankenfile. I edit the part, and export it once for every layer, each time one layer higher, then take the ironing moves from the last layer in each file and paste it at the end of the corresponding layer in the full print. that's why they're cubes. if it's a tower, the ironing moves will be the same every layer! (hence the ignored corners being cloudy all the way up) I set it to relative, letting me put a flag at the end of each layer so I could just replace the flag with the same ironing gcode each layer using a script. It was still inaccurate, but after about a minute of sanding, I got those parts in the images above. any tower shaped object works like this, but the relative extrusion mode is a bit inaccurate at times, or more likely, the inaccuracies build up over time. this is why I'm pretty sure it would work. I was literally using Cura's own ironing algorithm on every layer for my tests.
  2. thanks again for the help, and expect a thing here and there from me from now on!~
  3. glad to hear! yeah, my first foray into it was my friend vetting some clothing choices to me, and realizing how much I took full color vision for granted. Since he's also using this, I'm glad there's a decent chance this'll get accepted. it's currently up to date with the master, but so long as the main themes don't change it'll stay that way. As a visual effects artist, the whole "how things look for other people/first time viewers/users" is my home field, so if there are any changes it needs, I'll gladly take suggestions.
  4. Alright, got my first fork made! it's a simple one- a theme to help out people affected by colorblindness. I noticed everything was red next to green, or blue next to yellow, a bit of a pain for people with more serious color-blindness. I asked one of my friends (I swear color blindness is way more common among tech workers somehow) and he said he generally has a bit of trouble with the greens and yellows being really bright and always next to each other. -so I made a theme that works for the two most common kinds of colorblindness (Deuteranopia and Protanopia), and works as well as I could make it for Tritanopia (because each one is missing a primary color, one of them had to use alternating shades and hues of the same color for them all to at least work). I also duplicated it so there's be one to match ultimaker light and one to match ultimaker dark. The colors are a little wonky looking, mostly orange, yellow, purple and turquoise, but it's not meant for me, so the jury's still out on aesthetics. In any case I'm hoping this is worth a pull request-worst case scenario, it's rejected/ignored I guess. I'll wait a day to see if you guys tackle me in case I'm being dumb, cause I'm not sure if it's okay to just submit a pull request out of the blue for a feature not often asked for. Then again, where does that put iron every layer?~ you can check it out here, though unless you're colorblind or have colorblindness simulation software, it's not really visible how useful it can be: https://github.com/nubnubbud/Cura Or if you just wanna slap them in your themes folder use these. I think it should work. JSON's nice like that. https://github.com/nubnubbud/cura-themes
  5. well, it would be the same as ironing, hopefully. here's what ironing does: moves the printhead in a pattern over the entirety of the prints upper surface. this means it will not go back and forth over the air unless there's a disconnected part. the pattern can be changed, but it's usually concentric or zig-zag. the movements must make the flat part of the printhead move over every surface at least once. this means for a .4mm nozzle, for example, it must be treated as if it was a .1 to .2 mm nozzle to make enough lines close together printhead must be able to move to the very edge usually much slower than the original layer, (10-20mm/s) if the top surface is zigzag or lines, iron perpendicular to it. extrudes a tiny amount. (usually expressed as a percent, like 10% normal line flow) this helps it fill in and even out the surface, partially annealing and filling gaps that would normally cause bubbles and fracture points Ironing is already enabled in Cura, just load in a calibration cube and see what it does to the topmost layer. you'll see it even without travels enabled because it renders the tiny extrusions made to fill gaps
  6. the entire reason I wanted to do both is because I'm under the impression you need to edit both the frontend "Cura" and engine to add a new setting like ironing (or an option of said setting). feel free to correct me if I'm wrong though. any information is like gold to me. I'll probably learn as I poke around more, though. and I've gotten compiling the engine to a science, without a single issue, now that the little hiccup with the protobuf tests is out of the way. (id does work with both vs 2015 and 2019, and there's no noticeable downside to having a current sip version) and yeah I know I got a little butthurt earlier, but you're right. as for the frontend stuff, it looks like I need opengl2 or better, virtualbox doesn't support it though...so it'll be a day or two while I clean up my own computer till cmake and nmake are functional again. (edit never mind turns out vbox has its own implementation of gl)
  7. I plan to accomplish the act of getting better at C++, Python, and version control, as well as contribute the tasks I have set for myself when I've done it. What I'm lacking is the syntax, mainly, but I do sit down with my friends and help them debug their code and work on solutions, because while syntax isn't my forte, I'm relatively strong at use cases and roughly what background processes are needed to produce a certain qualitative result. I have taken some classes but sadly they've all focused on the code itself, and even several courses in no one formally introduced us to collaborative work or anything beyond basic compiling in an IDE, or even working with dependencies, so here I am, pursuing it solo, because I learn far better from doing than any other way. There are features that I want, and being in the industry of VFX myself, at some point I'll probably need to know scripting, build workflows, and such to develop tools anyway. I won't (and can't!) force you to help me, and I know by this point it could be considered meddling, because I've actually impacted the work of others, but this is the same as jumping in some water to learn to swim, but I stand to help other people and advance general FDM technique if I'm successful. It's also why I had the angle, earlier, that better build directions could result in more rapid development/interest. I got these issues repeatedly by following the build guide exactly on a clean install of windows, so I had reason to doubt this most recent error was my own ineptitude for once. I had an entire day of the same issue. I didn't bother pulling because I was doing it from scratch and cloning everything about once an hour. I stopped trying to go to sleep at 4AM, which ended up being about the same hour the commit you mentioned happened, hence my surprise when it suddenly worked today!
  8. I did this, as the build guide said: git clone https://github.com/Ultimaker/CuraEngine.git C:/dev/CuraEngine so it should have gotten me the latest version, right? if this isn't the most up to date version, what is? (edit: I tried it with curaengine-master and it worked! this does mean that the provided curaengine from the guide is defunct as a build source though.) now I just have to figure out how to run it, seeing as python app_cura.py throws errors about sip and UM
  9. I'm probably getting it from here, the header file that cmake produced. it's trying to include this because there's no if statement. I removed the include line, and that just made it ask for a bunch of "friend tests" so I can't just do that... it has to be generated correctly. is the easiest workaround just to enable tests? or could it be that mentioning them at all is tripping the flag? (edit- ah, I see what you mean now. I don't know where it's coming from either. This happened while I was using VS 2019, but I thought it was just because that version wasn't the recommended one, so I started from scratch and just followed the directions closely, copying and pasting all the commands just in case. It might be nice to see if someone else gets the same result, but I understand that's a lot of work just to troubleshoot this with me =3=)
  10. alright, so just checking, I've never done it outside of CMake gui, so do I just change -Dprotobuf_BUILD_TESTS=OFF to -Dprotobuf_BUILD_TESTS=ON or is it on by default? furthermore, there's an #include in the code that makes use of it, so is there a reason the guide says to set it to off? it looks like that would break the compile every time, seeing as I did not build tests, and it still looked for it.
  11. alright, I spun up a windows VM to make the environment as clean as possible, and it all worked until compiling the engine, which ended up throwing these errors. I tried it a second time, and though the percentages changed, the files supposedly causing the issues did not (I assume because it was skipping completed files) I can't find gtest_prod.h, so the program is right and it's absolutely not there, but no other file in any of the dependencies include it or anything of the same name. I remember there being some options in a cmake file about an optional test, that could be switched off. Is this related? (edit, they don't seem to be. gtest looks like it handles gcode export testing which seems super important, so now I'm even more confused as to why it was never made.) man, I feel a lot closer this time, and I bet this is the only thing missing, too.
  12. Thanks! There are still a few things unanswered for me though. What is the deal with using 32 bit everything to build cura? I understand if you're building a program most people should be able to use it, but at this point, 64 bit has been the majority for the better part of a decade, and 32 bit support is being dropped more and more, so I'm curious why it's preferred. The only things I can think about are issues with building or that something requires it to be 32 bit. speaking of that, I do have a couple questions as an outsider reading the guide. I can work them out on my own, but it's mostly curiosity. it says to download the correct shapely library, but what counts as a "64 bit install"? just python as I assume, or is it referring to everything, or the expected final cura version? I don't remember libsavitar and charon from my previous attempts, I think they're proprietary file loading and marketplace stuff? also as someone from the outside, I want to thank you so much for a few features in particular: noting that uranium does not need to be compiled is huge. I was so confused about it. noting the function and reason of commands instead of blindly following them means building cura might even be good for learning how to build and contribute to open source projects. Even blender doesn't go into such depth. the blurb on how nmake is used through the VS dev prompt is great. all in depth information is both succinct and in actual everyday english. it may be overlooked often, but most of the time, in-depth and accurate terminology only serve to alienate the people who can't causally breathe code. reminding us to verify if things are installed. I'm dense and forgetful. this is really useful. I'm getting some issues regarding wonky installs and cl.exe apparently being broken? It's most likely me being super dumb and installing things and vs not uninstalling properly and I've left my computer a mess. In any case, I'm setting up a windows virtual machine. I've decided it's the best way to develop in a stable, repeatable manner. that's why I'm being so long-winded (looking at you, storage allocation bar.), it'll take a day just to set up the machine and install visual studio/get it optimized to the point I can open a file folder in under a minute. I'll get back to you to tell you how it goes.
  13. That would be great. It's not just for me I imagine. A large number of the issues on github are build issues, and in any case, the easier it is to work on, the more features casual users will begin to work on... hopefully. The most confusing parts for me are cross-compiling (if it's easiest to build in linux but most users have windows this is important I think) and what happens to CuraEngine once it's made. It doesn't seem like it's properly installable, so do you move it to some folder in Cura or is there some step where you point the compiler at it? I haven't gotten that far yet but it's aomething that I haven't figured out after reading everything.
  14. And considering all that, I think the wisest choice may be simply to wait until you guys are done migrating it. As you can guess, I'm no career developer. I've only really compiled Blender and Slic3r before. Unless I can get this working by following the directions mostly blindly, (or at least fail with a descriptive error message) I'm not going to have much luck troubleshooting. I'll keep trying through the normal workflow. I've found some alterntate ways to make prints just a little clearer without overextruding, but all of this was for the purpose of adding "iron every layer" and a few settings to make PETG and other "boogery" materials print better- essentially temperature modulation depending on the structure (lower/higher temps on supports may help.) i also want to take a look at the delayed layer code to see if anything's up because it doesn't seem to work for me, and see if running the side of the print head around the outer edges can change surface quality somehow.
  15. I know where it is, no need to babysit me quite that much XD... though I do appreciate you guys being my safety helmet. I was able to use cmake on cure-dev-environment, but when I use make I get "make: *** No targets specified and no makefile found. Stop. " and sure enough, there are actually no makefiles in build, just cmakecache, lib64, and all the dependency files. lib64 is only 3 bytes, so I can't imagine everything worked perfectly.
  • Create New...