{"id":13629339,"url":"https://github.com/moehriegitt/hob3l","last_synced_at":"2025-06-21T17:03:59.866Z","repository":{"id":41497728,"uuid":"150784217","full_name":"moehriegitt/hob3l","owner":"moehriegitt","description":"100x Faster Slicing of SCAD Files for 3D Printing","archived":false,"fork":false,"pushed_at":"2024-06-23T11:22:34.000Z","size":11055,"stargazers_count":254,"open_issues_count":1,"forks_count":16,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-06-21T17:03:37.083Z","etag":null,"topics":["3d-printing","csg","fast","openscad","plane","polygon","polygon-boolean","polygon-clipping","polyhedron","slicing","stl","webgl"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/moehriegitt.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-09-28T19:09:45.000Z","updated_at":"2025-06-06T17:51:41.000Z","dependencies_parsed_at":"2024-06-11T01:55:37.060Z","dependency_job_id":"a4b1ba2b-effd-4570-b018-f3518a3b60f6","html_url":"https://github.com/moehriegitt/hob3l","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/moehriegitt/hob3l","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moehriegitt%2Fhob3l","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moehriegitt%2Fhob3l/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moehriegitt%2Fhob3l/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moehriegitt%2Fhob3l/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/moehriegitt","download_url":"https://codeload.github.com/moehriegitt/hob3l/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moehriegitt%2Fhob3l/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261162060,"owners_count":23118219,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["3d-printing","csg","fast","openscad","plane","polygon","polygon-boolean","polygon-clipping","polyhedron","slicing","stl","webgl"],"created_at":"2024-08-01T22:01:07.922Z","updated_at":"2025-06-21T17:03:54.825Z","avatar_url":"https://github.com/moehriegitt.png","language":"C","funding_links":[],"categories":["C"],"sub_categories":[],"readme":"# Hob3l\n100x Faster Slicing of SCAD Files for 3D Printing\n\n## What is This?\n\nHob3l is a command line tool for reading SCAD files and writing STL\nfiles for 3D printing.  The focus is on speed and robustness.\n\nOpenSCAD can convert SCAD to STL, too, but it is very slow, because it\nfirst produces a 3D object.  And the CGAL library used by OpenSCAD is\nnot very robust: I often get spurious error messages due to unstable\n3D arithmetics: 'object may not be a valid 2-manifold'.\n\nInstead, Hob3l uses stable arithmetics to produce an STL file suitable\nfor 3D printing.  It first pre-slices the basic 3D objects from the\nSCAD file into layers and then uses 2D operations on each layer.  The\n2D operations are much faster than 3D operations, and arithmetically\nmuch simpler, and thus easier to get stable.\n\nHob3l is very robust -- the 2D base library was fuzzed to get rid of\nnumeric instability problems.  Hob3l uses integer arithmetics and a\nsnap rounding algorithm to stay within the input coordinate precision.\nIt reads and writes normal floating point numbers, and the float\u003c-\u003eint\nconversions are exact within `float` precision (the native STL binary\nnumber format).  If necessary, the precision can be scaled (by\ndefault, the unit is 1/8192mm).\n\n## How Is It Fast?\n\nTo be faster than OpenSCAD, Hob3l replaces 3D operations by faster 2D\noperations.  For this, Hob3l first cuts slices and then applies the\nboolean operations.\n\nInstead, [OpenSCAD](http://www.openscad.org/) applies 3D operations to\ncompute a single 3D object.  This is very expensive math, and often\narithmetically unstable.  But for 3D printing, that single 3D object\nis not needed: it is cut into slices anyway.\n\nSo hob3l reverses the internal workflow.  Instead of 'compute in 3D, then slice':\n\n![3D CSG](img/csg1-old.png)\n\nit does 'slice, then compute in 2D':\n\n![2D CSG](img/csg1-new.png)\n\nThe idea is explained in more detail\n[in my blog](http://www.theiling.de/cnc/date/2018-09-23.html).\n\nHob3l's main output formats are\n\n  * STL for printing\n  * JavaScript/WebGL for viewing and prototyping\n\nHob3l reads OpenSCAD's native SCAD format, it can import STL files\n(for 3D imports), and SVG files (for 2D imports).\n\n## SCAD Input Format\n\n[My SCAD format documentation](doc/scadformat.md) defines what exactly\nis supported by Hob3l, and what is different from OpenSCAD.\n\nFor the full SCAD format syntax, OpenSCAD can be used as a\npreprocessor: OpenSCAD can read the full SCAD format and write a\nsimplified version, with only structurs that Hob3l supports.  This is\na fast preprocessing step, and still avoids OpenSCAD's expensive 3D\noperations:\n\n```\n    openscad thing.scad -o thing.csg\n    hob3l thing.csg -o thing.stl\n```\n\nSee [Using This Tool](#using-this-tool-command-line-options).\n\n## Valid 2-Manifolds\n\nHob3l produces only valid 2-manifolds.\n\nWell, if the input polyhedra are really bad, like missing faces, then\nHob3l may fail to produce a valid output.  But you need blatantly\nbroken input polyhedra for this.  This cannot happen unless you use\n`polyhedron()` manually in SCAD.  Hob3l is not supposed to fail just\nbecause you subtract an object from another object and the two share a\npart of a face (when you get flickering in\n[OpenSCAD](http://www.openscad.org/)): Hob3l either subtracts\neverything properly, or it leaves a small (valid) polyhedron -- but it\ndoes not become unstable and fail on you.\n\nIf Hob3l shows unstable behaviour, then that is a bug.  Getting it\nstable took the majority of the development time, because I found this\nthe most annoying problem with OpenSCAD (or the underlying CGAL\nlibrary).\n\n## Status, Stability, Limitations, Future Work, TODO\n\nThis tool has been tested very thoroughly for stability and arithmetic\nrobustness, in order to get rid of any floating point instabilities,\nusing a fuzzer and many millions of tests.\n\nThe tool can read the [specified subset of SCAD](doc/scadformat.md)\n(possibly from a preprocessing step by OpenSCAD's to resolve\nunsupported syntax).  Hob3l then slices the input objects, applies the\n2D boolean operations (AKA polygon clipping), and then triangulates\nthe resulting polgygons.  Then it writes STL format or WebGL/JS.\n\nAfter that, Slic3r (and probably PrusaSlicer and Cura) can read the\nSTL files Hob3l produces.  This step is still necessary, although\nHob3l slices the input file, too, because the slicer also does the\npath planning and G-code generation, which Hob3l does not do.\n\nThe input polyhedra must be 2-manifold.  However, Hob3l accepts quite\na few non-2-manifold input polyhedra.  Polyhedra with holes (i.e.,\nmissing faces), however, will not work.  OpenSCAD (or the CGAL\nlibrary) probably now has more constraints on well-formedness than\nHob3l.  E.g., Hob3l's algorithms are robust against wrong handedness\nof faces.\n\nHob3l can import STL files (both text and binary formats) for 3D\nobjects and SVG files for 2D objects.  Because SVG is a very complex\nformat, only a useful subset is supported, e.g., no CSS styling is\nimplemented.  E.g, SVG files written by Inkscape can be read by Hob3l.\n\nThe output STL contains separate layers instead of a single solid.  In\nthe future, Hob3l may generate one contiguous object. It would be more\nprocessing and is not strictly necessary.  But if you hit `split` in\nSlic3r on the current output of Hob3l, you'll get many separate layer\nobjects -- which is not useful.\n\nMemory management has leaks.  I admit I don't care enough, because\nHob3l basically starts, allocates, exits, i.e., it does not run for\nlong, so the memory leaks do not build up.\n\nThere are never enough tests.  However, Hob3l's core algorithms have\nsurvived many millions of fuzzing tests with\n[afl](https://lcamtuf.coredump.cx/afl/).\n\n## Supported Output Formats\n\n`STL`: This is the main output format of Hob3l for which it was first\ndeveloped.  The input SCAD files can be converted to STL and then used\nas input to a slicer for 3D printing.  Both ASCII STL (more precise)\nand binary STL (smaller) are supported.\n\n`PS`: For debugging and documentation, including algorithm\nvisualisation, Hob3l can output in PostScript.  This is how the\noverview images on this page where generated: by using single-page PS\noutput, converted to `PNG` using `GraphicsMagick`.  For debugging,\nmainly multi-page debug PS output was used, which allows easy browsing\n(I used `gv` for its speed and other nice features). Also, this allows\nto compare different runs and do a step-by-step analysis of what is\ngoing on during the algorithm runs.  The PS modules has a large number\nof command line options to customise the output.\n\n`WEBGL/JS`: For prototyping SCAD files, a web browser can be used as a\n3D model viewer by using the WebGL/JavaScript output format.  The SCAD\nfile can be edited in your favourite editor, then for visualisation,\nHob3l can generate WebGL data (possibly with an intermediate step to\nlet OpenSCAD simplify the input file using its `.csg` output), and a\nreload in the web browser will show the new model.  This package\ncontains auxiliary files to make it immediately usable, e.g. the\nsurrounding .html file with the WebGL viewer that loads the generated\ndata.  See the `hob3l-js-copy-aux` script.\n\n`SCAD`: For debugging intermediate steps in the parser and converter,\nHob3l can write SCAD format of several of its processing stages.  In\nintermediate stages, however, Hob3l's polyhedra may not be strictly\ncorrect when printed in SCAD debug output (they may use wrong\nhandedness of polyhedra faces) and then loaded into OpenSCAD for\ninspection.  (But STL and WebGL/JS output do produce correctly oriented\nfaces.)\n\n## JavaScript/WebGL Output\n\nHere's a screenshot of my browser with a part of the\n[Prusa i3 MK3](https://github.com/prusa3d/Original-Prusa-i3)\n3D printer rendered by Hob3l:\n\n![Mk3 Part](img/curryjswebgl.png)\n\nThere is an [online version available\nhere](http://www.theiling.de/cnc/gl-curryhob3l/curry.html) to play\nwith.\n\nThe conversion from `.scad` to `.js` takes about 0.7s on my machine,\nso this is very well suited for prototyping: write the `.scad` in a\ntext editor, run 'make', reload in browser.  To run this conversion\nyourself, after building, run:\n\n```\n    make clean-test\n    time make test-out/curry.js\n```\n\nThis should print something like:\n\n```\n./hob3l.exe scad-test/curry.scad -o test-out/curry.js.new.js\nInfo: Z: min=0.1, step=0.2, layer_cnt=75, max=14.9\nmv test-out/curry.js.new.js test-out/curry.js\n\nreal  0m0.650s\nuser  0m0.592s\nsys   0m0.044s\n```\n\n## Building\n\nBuilding relies on GNU make and gcc, and uses no automake or other\nmeta-make layer.  Both Linux native and the MinGW Windows cross\ncompiler have been tested.\n\nMake variables can be used to switch how the stuff is compiled.  Some\nGCC extensions are used, but I tried not to overdo it (`({...})` and\n`__typeof__` are used frequently, though), it should be compilable\nwithout too much effort.\n\nCompilation is straight-forward:\n\n```\n    make clean\n    make\n    make test\n```\n\nParallel building is supported using the `-j` option to make.\n\nSome Perl scripts are used to generate C code during compilation.\n\nThe resulting executable is called 'hob3l.x'.  It is renamed during\ninstallation (`hob3l` on Linux, `hob3l.exe` on Windows).\n\n### Different Build Variants\n\nThe makefile supports 'normal', 'release', and 'devel' build variants,\nwhich can be switched using the `MODE=normal` (default),\n`MODE=release`, or `MODE=devel` command line variables for make.  The\nselection is stored in a file `.mode.d`, so next time you invoke\n'make' without a `MODE` parameter, the previous build variant will be\nchosen.\n\nE.g.:\n\n```\n    make clean\n    make MODE=release\n    make test\n```\n\n### Different Compiler Targets\n\nTo compile with the standard 'gcc', whatever that is, for x86:\n\n```\n    make\n```\n\nTo compile with gcc for x86_64 (e.g., 64 bit x86 Linux):\n\n```\n    make TARGET=gcc64\n```\n\nTo compile with gcc for i686 (e.g., 32 bit x86 Linux):\n\n```\n    make TARGET=gcc32\n```\n\nTo compile with Clang:\n\n```\n    make TARGET=clang\n```\n\nTo cross compile for Windows 64 using MinGW:\n\n```\n    make TARGET=win64\n```\n\nTo cross compile for Windows 32 using MinGW:\n\n```\n    make TARGET=win32\n```\n\nYou can set the exact compiler name by overriding `CC`:\n\n```\n    make TARGET=win32 CC=my-funny-mingw-gcc\n```\n\n### Tweaking Compiler Settings\n\nThe Makefile has more settings that can be used to switch to other compilers\nlike clang, or to other target architectures.  This is not properly documented\nyet, so reading the Makefile may be necessary here.\n\nThe most likely ones you may want to change are the following (listed\nwith their default setting):\n\n```\nCFLAGS_ARCH  := -march=native\n```\n\n## Running Tests\n\nAfter building, tests can be run, provided that the 'hob3l.x'\nexecutable can actually be executed (hopefully).  On systems where it\nworks, use\n\n```\n    make test\n```\n\nfor that.  This runs both the unit tests as well as basic SCAD\nconversion tests.  For full set of checks (asserts) during testing,\nthe 'devel' build variant should be used in addition to the actual\nbuild variant.\n\nAfter installation, the SCAD conversion tests can be run with the\ninstalled binary by using\n\n```\n    make check\n```\n\nEach time `make check` is invoked, it will first remove the old test\noutput files to make sure that the check is actually run.  `make\ncheck` also honours the `DESTDIR` variable to construct the path to the\ninstalled executable in the same way as `make install`.\n\n## Installation\n\nThe usual installation ceremony is implemented, according to the GNU\nCoding Standard.  I.e., you have `make install` with `prefix`, and all\n`*dir` options and also `DESTDIR` support as well as\n`$(NORMAL_INSTALL)` markers, and also `make uninstall`.\n\n```\n    make DESTDIR=./install-root prefix=/usr install\n```\n\nFor better package separation, the `install` target is split into\n`install-bin`, `install-data`, `install-lib`, `install-include`\n(e.g. to compile a separate `-dev` package as in Debian\ndistributions).\n\nUnfortunately, there is no `install-doc` yet.  FIXME.\n\n## Using This Tool, Command Line Options\n\nWhen in doubt, use `hob3l --help`.\n\nTo convert a complex SCAD file into the subset that Hob3l can read,\nstart by using OpenSCAD to convert to a flat 3D CSG structure with all\nthe syntactic sugar removed.  This conversion is fast.\n\n```\n    openscad thing.scad -o thing.csg\n```\n\nYou can now use Hob3l to process it:\n\n```\n    hob3l thing.csg -o thing.stl\n```\n\nThe result can then be used in your favorite tool for computing print\npaths.\n\n```\n    slic3r thing.stl\n```\n\n## Speed comparison\n\nDepending on the complexity of the model, Hob3l may be much faster\nthan using OpenSCAD with CGAL rendering.\n\nSome examples:\n\nThe x-carriage.scad part of my\n[Prusa i3 MK3](https://github.com/prusa3d/Original-Prusa-i3)\nprinter from the Prusa github repository: let's first convert it\nto `.csg`.  This conversion is quickly done with OpenSCAD, and the\nresulting flat SCAD format is what Hob3l can read:\n\n```\n    time openscad x-carriage.scad -o x-carriage.csg\n    0m0.034s\n```\n\nTo convert to STL using openscad 3D CSG takes a while:\n\n```\n    time openscad x-carriage.csg -o x-carriage.stl\n    0m45.208s\n```\n\nDoing the same with Hob3l in 0.2mm layers is about 50 times faster:\n\n```\n    time hob3l x-carriage.csg -o x-carriage.stl\n    0m0.824s\n```\n\nThe most complex part of the i3 MK3 printer, the `extruder-body.scad`,\nbefore it was reimplemented as `step` file, takes 2m42s in openscad to\nconvert to STL, while Hob3l takes 1.24s, again with 0.2mm layers.\nThat is 130 times faster.\n\nFor one of my own parts `useless-box+body`, which is less complex, but\ndoes not care much about making rendering fast (I definitely set up\ncylinders with too many polygon corners):\n\n```\n    time openscad uselessbox+body.scad -o uselessbox+body.stl\n    0m53.433s\n\n    time hob3l uselessbox+body.scad -o uselessbox+body.stl\n    0m0.610s\n```\n\nThis is 85 times faster.  Over half of the time is spent on writing\nthe STL file, which is 23MB -- STL is huge.  Loading and converting\nonly takes 0.23s.\n\nYou can push the difference in speed by making the model more complex,\nparticularly when using high detail levels.  E.g., the test31b.scad\nexample uses `$fn=99` for a few ellipsoids, causing openscad to slow\ndown:\n\n```\ntime openscad scad-test/test31b.scad -o test31b.stl\n4m30.198s\n```\n\nIn contrast, the different algorithms used by Hob3l do not slow down\nmuch:\n\n```\ntime ./hob3l.exe scad-test/test31b.scad -o test31b.stl\n0m0.748s\n```\n\nThis is 350 times faster.  The difference is of course that with\nHob3l, the result is sliced into layers, as the following image\ndemonstrates.  The top is the OpenSCAD F6 view, the bottom is Hob3l's\nWebGL output in my web browser.\n\n![OpenSCAD output](img/test31b-openscad.jpg)\n\n![Hob3l output](img/test31b-hob3l.jpg)\n\n## Rendering Differences\n\nThe difference of the conversion technique is visible in the model\nview of the STL, where the 2D CSG slicing technique clearly shows the\nlayers, e.g. for a real-life example sliced a 0.2mm with Hob3l.  The\ntop is OpenSCAD's output in Slic3r, the bottom is Hob3l's output in\nSlic3r:\n\n![OpenSCAD model](img/useless-model-openscad.jpg)\n![Hob3l model](img/useless-model-hob3l.jpg)\n\nThe final result of the slicer, however, is indistinguishable (I was\nunable to replicate the exact same view, so the Moir\u0026eacute; patterns\nare different -- but the result is really the same), again OpenSCAD\noutput top, Hob3l bottom:\n\n![OpenSCAD preview](img/useless-preview-openscad.jpg)\n![Hob3l preview](img/useless-preview-hob3l.jpg)\n\n## Algorithms\n\nThe polyhedra (from SCAD input files) are processed using IEEE double\nprecision floating point coordinates.  The 2D algorithms, however, now\nuse 32-bit integer coordinates for exact math (and can handle 31-bit\nsigned values without overflow).  Therefore, the coordinates in a\npolygon slice from a polyhedron are converted from `double` to `int`\nby multiplying by a power of two -- this way, the upper bits of the\nfloating point mantissa (53 bits for `double`) can be used directly as\nints with minimum rounding error.  When converting back from `int` to\n`double`, the integer coordinates are divided by the same power of\ntwo, meaning that no rounding error occurs: the integer is used\ndirectly as the upper mantissa bits for the floating point number (the\nlower bits are 0).  A round trip from int to double to int is then\nloss-less.  As binary STL uses `float` coordinates (with a 24 bit\nmantissa, smaller than 32-bit integers), care was taken to scale in\nsuch a way that a wide range of float coordinates also convert to STL\nwith no rounding error.  And the ASCII STL is printed with many\nsignificant digits to ensure that the information gets into the slicer\nwithout any loss of precision.  All integer operations check for\noverflow so that the scale value can be adjusted if necessary for\nweird input files.\n\nThe slice algorithm to cut a polygon slice from a polyhedron is a\nsimple ad-hoc algorithm that works by iterating each face, making a\ncut at a given z height, sorting the cut points, and interpreting them\nas line segments.  The subsequent algorithms need no particular order\nof edges, so a very simple algorithm is enough here.\n\nThe polygon clipping algorithm is a Bentley-Ottmann 1979 (Algorithms\nfor reporting and counting geometric intersections) plane sweep\nalgorithm using exact fractional math for the intersections.  Ideas\nfrom Mart\u0026iacute;nez, Rueda, Feito 2009 (A new algorithm for computing\nBoolean operations on polygons) were used to extend Bentley-Ottmann to\ncorner cases like overlapping edges.  Also, the inside/outside\ninformation is tracked in a way similar to that paper, extended by\nideas from Sean Conelly's polybooljs project.  The input/output\ninformation was then extended to handle more than two polygons at\nonce, by using a boolean function represented by a bit array.  This\nspeeds up the 2D processing.\n\nThe ideas from Boissonnat and Preparata 2000 (Robust Plane Sweep for\nIntersecting Segments) helped examine the complexity of the numeric\nproblems and to construct a data type for storing intersection points\nexactly: with a 160 bit fractional (32 bit integer + 64 bit\nnumerator + 64 bit denominator).  This avoids overheads from generic\nexact math libraries and it is quite fast.\n\nAfter the intersection algorithm, the snap rounding algorithm by de\nBerg 2007 (An Intersection-Sensitive Algorithm for Snap Rounding) is\nrun to fit the intersection coordinates back into the input bit width\n(32-bit integer coordinates).\n\nTo get a triangulation (fro the output polyhedron in STL format), the\ntriangulation algorithm of Hertel \u0026 Mehlhorn 1983 (Fast Triangulation\nof the Plane with Respect to Simple Polygons) was used and extended to\nsupport coincident vertices, because these cannot be avoided.  Also,\nsequences of collinear edges are resolved.\n\nThe same algorithm was adapted also for constructing a polygon outline\nfrom the set of edges produced by the preceding algorithm, if no\ntriangulation is needed.  This is used in the SCAD language\nprocessing, e.g., with operations like `extrude` or `project`, where\nthe result of the 2D boolean algorithm is fed back into the CSG tree.\n\n## Development\n\nThis is a project for me to relax and have fun, to be a distraction\nand to be different from my day job (which also involves programming).\nThe project follows some policies to avoid stress. for me to continue\nto have fun.\n\n### XNIH: Exclude What's Not Implemented Here\n\nNo external libraries or tools are used for this project, except a C\ncompiler, Perl, and libc/POSIX.  All functionality is either\nimplemented here, or not at all.\n\nThis policy helps me focus on programming, instead of battling APIs.\nEvery API incompatibility will be my own fault.  There will be no\nstress when upgrading to a newer version of a library, because there\nare none.\n\n### C and Perl\n\nThis project is implemented in C with gcc extensions, for a reasonably\nmodern C standard.  Perl is used for scripts.  GnuMake is used for\nbuilding.\n\n### Linux\n\nMy development platform is Linux.  Other platforms are not excluded,\nand the Makefile has direct support for Clang and for MinGW\ncompilation.  But I cannot debug problems specific to platforms I do\nnot use.\n\n## Name\n\nThe name Hob3l derives from the German word 'Hobel', meaning 'plane'\n(as in 'wood plane').  The 'e' was turned to `3` in recognition of the\n`slic3r' program.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoehriegitt%2Fhob3l","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmoehriegitt%2Fhob3l","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoehriegitt%2Fhob3l/lists"}