17 ms·

Everyone's building on the "bigg" (bgfx + imgui + glfw + glm) stack ;) https://github.com/yuki-koyama/bigger https://github.com/yuki-koyama/bigger

slimsag 5y ago
author here, I do think that's a reasonable choice of tech in general, but I won't be using most of those for Mach for various reasons: * glm -> zig has native vector types with SIMD support and I think in the long-term these could be much nicer. * bgfx is truly awesome, but I'm keen to is WebGPU for the reasons outlined in the post. * imgui - I do think it's the best thing out there currently, but I have something up my sleeve for a much better UI library built around vector graphics and have done a lot of research in this area.
- vg_head 5y ago
  I am really interested in your research related to vector graphics!
  - slimsag 5y ago
    It'll be a bit before I can publish the paper, libraries, tooling etc. around this - it's been maybe 8 years in the making but slow - the general idea is: 1. GPUs are actually _ridiculously and stupidly_ excellent at natively rendering Bézier curves if you "limit" yourself to quadratic curves. 2. Most of the reasons designers / end users hate working with Bézier curves is because of the absolutely terrible control point manipulation that cubic curves require. 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sending to the GPU in the best case) which harms perf substantially and makes animation of curves expensive. Plus handling the intersection rules is incredibly complex. ...so maybe using the 'mathematically pure' cubic curves is not actually so great after all. :) if only we had tools and formats (not SVG) that worked on isolated quadratic curves (without care for intersection) - then GPU rendering implementations wouldn't need to be absolutely horridly complex (nvidia et. al), or terrible approximations (valve SDF), we could literally send a vector graphic model directly to the GPU and have it render (and animate!) at incredible speeds, with easier to understand tools. At least - that's the idea.
    - Jarred 5y ago
      What do you think of NURBS? eg http://verbnurbs.com/ http://verbnurbs.com/. It’s intended for 3D instead of 2D, but still kind of relevant How do you plan on doing text rendering? I feel like that’s often a challenge with cross-platform UI frameworks. Electron/Chromium does this well. Often QT apps don’t handle pixel ratio correctly, or the text looks non-native.
      - pcwalton 5y ago
        NURBS are a generalization of Bézier curves, so everything that applies to Bézier curves here applies to NURBS as well.
        wnkrshm 5y ago
        There are applications in CAD where I imagine working with degree 2 surfaces/curves only is going to be very tricky. What about differentials? How do you get a change of normal, how do you get a curvature tensor? Without a continuous 2nd derivative? Edit: In e.g. product design like e.g. cars, people want curvature continuity, i.e. C2 at minimum for their surfaces, because on machined surfaces, you see any curvature discontinuities as edges in reflected light... that's why degree 3 is kind of an industry standard.
    - Jasper_ 5y ago
      I wouldn't strictly say that. Even with quadratic curves, you still have a serial process of parsing a shape to determine interior vs. exterior. This is true of any non-convex polygon, not just those with curves. You have to solve that sort somehow, whether it be through linear search (e.g. Slug), through geometry simplification (e.g. Loop-Blinn, triangulation), through signed area tricks (e.g. red book, style stencil-and-cover), or through brute force (e.g. SDFs). Eliminating cubics eliminates some trickier problems, but I don't think it fully solves the issues.
      - slimsag 5y ago
        Yep, you probably read my comment before I edited and clarified, but you also need to eliminate overlapping geometry. Basically just build your graphics around non-overlapping convex and concave quadratic curves represented as triangles. The trick is in building tooling that makes that a pleasant experience (and do any required reductions of more complex shapes -> isolated quadratic curves at tool time, not at render time.) Existing approaches try to fit what we have (SVGs, complex polygons) onto what GPUs can do. This approach tries to take what GPUs _can do_ and make that competitive with what we have (SVGs, etc.)
- AndyKelley 5y ago
  re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra. For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector. But that's just something I heard, of course real world experience would be interesting to hear about.
  - slimsag 5y ago
    Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.
    - Jasper_ 5y ago
      Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
      - pcwalton 5y ago
        I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
        dnautics 5y ago
        Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm
flohofwoe 5y ago
(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers: https://github.com/floooh/sokol-zig https://github.com/floooh/sokol-zig This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline). Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/) And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations right into the source files instead of bundling them into separate git repositories (similar to how GL loaders for Windows work).
- slimsag 5y ago
  very cool work :) If you like, add a screenshot or two and I'll include this in the next zigmonthly.org article you might also be interested to know about stub dynamic libraries, e.g. `.tbd` files on MacOS. That's what is in the Mach SDK repos primarily[0], though I'm sure you could slim them down some more with a concrete list of symbols you depend on. [0] https://github.com/hexops/sdk-macos-11.3/blob/main/root/System/Library/Frameworks/Metal.framework/Metal.tbd https://github.com/hexops/sdk-macos-11.3/blob/main/root/Syst...
- politician 5y ago
  I love this codebase. I’ve been working with it on the side for a few weeks: it’s extremely well documented, supports Metal, has reasonable abstractions that don’t try to be the One True Way, and the Zig port looks really clean.

slimsag 5y ago

author here, I do think that's a reasonable choice of tech in general, but I won't be using most of those for Mach for various reasons: * glm -> zig has native vector types with SIMD support and I think in the long-term these could be much nicer. * bgfx is truly awesome, but I'm keen to is WebGPU for the reasons outlined in the post. * imgui - I do think it's the best thing out there currently, but I have something up my sleeve for a much better UI library built around vector graphics and have done a lot of research in this area.

vg_head 5y ago
I am really interested in your research related to vector graphics!
- slimsag 5y ago
  It'll be a bit before I can publish the paper, libraries, tooling etc. around this - it's been maybe 8 years in the making but slow - the general idea is: 1. GPUs are actually _ridiculously and stupidly_ excellent at natively rendering Bézier curves if you "limit" yourself to quadratic curves. 2. Most of the reasons designers / end users hate working with Bézier curves is because of the absolutely terrible control point manipulation that cubic curves require. 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sending to the GPU in the best case) which harms perf substantially and makes animation of curves expensive. Plus handling the intersection rules is incredibly complex. ...so maybe using the 'mathematically pure' cubic curves is not actually so great after all. :) if only we had tools and formats (not SVG) that worked on isolated quadratic curves (without care for intersection) - then GPU rendering implementations wouldn't need to be absolutely horridly complex (nvidia et. al), or terrible approximations (valve SDF), we could literally send a vector graphic model directly to the GPU and have it render (and animate!) at incredible speeds, with easier to understand tools. At least - that's the idea.
  - Jarred 5y ago
    What do you think of NURBS? eg http://verbnurbs.com/ http://verbnurbs.com/. It’s intended for 3D instead of 2D, but still kind of relevant How do you plan on doing text rendering? I feel like that’s often a challenge with cross-platform UI frameworks. Electron/Chromium does this well. Often QT apps don’t handle pixel ratio correctly, or the text looks non-native.
    - pcwalton 5y ago
      NURBS are a generalization of Bézier curves, so everything that applies to Bézier curves here applies to NURBS as well.
      - wnkrshm 5y ago
        There are applications in CAD where I imagine working with degree 2 surfaces/curves only is going to be very tricky. What about differentials? How do you get a change of normal, how do you get a curvature tensor? Without a continuous 2nd derivative? Edit: In e.g. product design like e.g. cars, people want curvature continuity, i.e. C2 at minimum for their surfaces, because on machined surfaces, you see any curvature discontinuities as edges in reflected light... that's why degree 3 is kind of an industry standard.
  - Jasper_ 5y ago
    I wouldn't strictly say that. Even with quadratic curves, you still have a serial process of parsing a shape to determine interior vs. exterior. This is true of any non-convex polygon, not just those with curves. You have to solve that sort somehow, whether it be through linear search (e.g. Slug), through geometry simplification (e.g. Loop-Blinn, triangulation), through signed area tricks (e.g. red book, style stencil-and-cover), or through brute force (e.g. SDFs). Eliminating cubics eliminates some trickier problems, but I don't think it fully solves the issues.
    - slimsag 5y ago
      Yep, you probably read my comment before I edited and clarified, but you also need to eliminate overlapping geometry. Basically just build your graphics around non-overlapping convex and concave quadratic curves represented as triangles. The trick is in building tooling that makes that a pleasant experience (and do any required reductions of more complex shapes -> isolated quadratic curves at tool time, not at render time.) Existing approaches try to fit what we have (SVGs, complex polygons) onto what GPUs can do. This approach tries to take what GPUs _can do_ and make that competitive with what we have (SVGs, etc.)
AndyKelley 5y ago
re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra. For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector. But that's just something I heard, of course real world experience would be interesting to hear about.
- slimsag 5y ago
  Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.
  - Jasper_ 5y ago
    Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
    - pcwalton 5y ago
      I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
      - dnautics 5y ago
        Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm

flohofwoe 5y ago

(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers: https://github.com/floooh/sokol-zig https://github.com/floooh/sokol-zig This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline). Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/) And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations right into the source files instead of bundling them into separate git repositories (similar to how GL loaders for Windows work).

slimsag 5y ago
very cool work :) If you like, add a screenshot or two and I'll include this in the next zigmonthly.org article you might also be interested to know about stub dynamic libraries, e.g. `.tbd` files on MacOS. That's what is in the Mach SDK repos primarily[0], though I'm sure you could slim them down some more with a concrete list of symbols you depend on. [0] https://github.com/hexops/sdk-macos-11.3/blob/main/root/System/Library/Frameworks/Metal.framework/Metal.tbd https://github.com/hexops/sdk-macos-11.3/blob/main/root/Syst...
politician 5y ago
I love this codebase. I’ve been working with it on the side for a few weeks: it’s extremely well documented, supports Metal, has reasonable abstractions that don’t try to be the One True Way, and the Zig port looks really clean.