> The thing is that I myself don't even know what I want to do with it.
Embrace the next challenge: Instead of roads on parabolic (Euclidean) geometry, have roads on elliptic (non-Euclidean) geometry, like the surface of a sphere. Plus, on a sphere every line is already a circular arc anyway (no matter if straight or bent, the difference is just the center, radius and normals). Thus, this system of circular arc segments really lends itself to such a space.
Little prince style micro planets with their own miniature infrastructure will always have a special place in my heart. Half a year ago I started with laying out the basics https://github.com/Lichtso/bevy_ellipsoid_billboardhttps://github.com/Lichtso/bevy_geodesic_grid but got distracted by fixing some engine bugs in Bevy along the way. That reminds me I have to update to the newest engine version ...
anyway you can find some of the roads on spheres stuff here: https://github.com/Lichtso/bevy_geodesic_grid/blob/main/src/... it can not only generate the extrusion mesh but also calculate how the mesh overlaps with a geodesic grid of triangular tiles on the surface.
Go full science fiction and enable vertical or even upside-down roads for a 3D experience. :-)
Imagine an environment where ground/walls/ceilings always have gravity and one can build literal city mazes in horizontal and vertical directions. All that traffic going everywhere, oh my..
Really depends: In some areas it is quite advanced (rendering) and in others it is lacking / underdeveloped (editors / tooling). But there is an incredible amount of progress and also churn in keeping up with that.
Another point in case: Life only exists in liquids, not in solids (too much structure) and not in gases (too much chaos).
In fact one could argue that this is a definition of an interesting system: It has to strike a balance between being completely ordered (which is boring) and being completely random (which is also boring).
Thanks! Simon's example uses the custom voice model (creating a voice from instructions). But that comment led me eventually to this page, which shows how to use mlx-audio for custom voices:
> but [analytic anti-aliasing (aaa)] also has much better quality than what can be practically achieved with supersampling
What this statement is missing is that aaa coverage is immediately resolved, while msaa coverage is resolved later in a separate step with extra data being buffered in between. This is important because msaa is unbiased while aaa is biased towards too much coverage once two paths partially cover the same pixel. In other words aaa becomes incorrect once you draw overlapping or self-intersecting paths.
Think about drawing the same path over and over at the same place: aaa will become darker with every iteration, msaa is idempotent and will not change further after the first iteration.
Unfortunately, this is a little known fact even in the exquisite circles of 2D vector graphics people, often presenting aaa as the silver bullet, which it is not.
> I honestly cant't think of any good examples where game mechanics and stories interacted in a way that gave you significant agency while still being fun. I'd love to be given contra-examples though.
Rimworld and The Sims. Both are procedural story writers.
> I felt railroaded into comically absurd black/white choices
I agree: All these AAA titles essentially are movies where you get tons of "agency" in choices which are irrelevant to the story, but the main plot is hard scripted into a few predetermined paths.
Until we have full generative AI as game engine the only alternative remains the procedural approach mentioned in the beginning.
Not yet, I agree, but who is to say they couldn't?
Limiting life to cell based biology is a somewhat lousy definition by the only example we know. I prefer the generalized definition in "What is Life?" by Erwin Schrödinger which currently draws the same line (at cellular biology) but could accommodate other forms of life too.
> The next step is to work with chains of Bézier curves to make up complex shapes (such as font glyphs). It will lead us to build a signed distance field. This is not trivial at all and mandates one or several dedicated articles. We will hopefully study these subjects in the not-so-distant future.
If you only want to fill a path of bezier curves (e.g. for text rendering) you can do without the "distance" part from "signed distance field" [0], leaving you with a "signed field" aka. an implicit curve [1].
Meaning not having to calculate the exact distance but only the sign (inside or outside) can be done without all the crazy iterative root finding in an actually cheap manner with only four multiplications and one addition per pixel / fragment / sample for a rational cubic curve [3].
I wonder which method Apple is using for their recently introduced Bézier curve primitives for real-time 3D rendering in Metal. From their WWDC 2023 presentation [1]:
> Geometry such as hair, fur, and vegetation can have thousands or even millions of primitives. These are typically modeled as fine, smooth curves. Instead of using triangles to approximate these curves, you can use Metal's new curve primitives. These curves will remain smooth even as the camera zooms in. And compared to triangles, curves have a more compact memory footprint and allow faster acceleration structure builds.
> A full curve is made of a series of connected curve segments. Every segment on a curve is its own primitive, and Metal assigns each segment a unique primitive ID. Each of these segments is defined by a series of control points, which control the shape of the curve. These control points are interpolated using a set of basis functions. Depending on the basis function, each curve segment can have 2, 3, or 4 control points. Metal offers four different curve basis functions: Bezier, Catmull-Rom, B-Spline, and Linear. (...)
Finding the sign of the distance has been extremely challenging to me in many ways, so I'm very curious about the approach you're presenting. The snippet you shared has a "a³-bcd ≤ 0" formula which is all I get without more context. Can you elaborate on it or provide resources?
The winding number logic is usually super involved, especially when multiple sub-shapes start overlap and subtracting each other. Is this covered or orthogonal to what you are talking about?
> The winding number logic is usually super involved, especially when multiple sub-shapes start overlap and subtracting each other. Is this covered or orthogonal to what you are talking about?
Orthogonal: The implicit curve only tells you if you are inside or outside (the sign of the SDF), so that is technically sufficient, but usually you want more things: Some kind of anti-aliasing, composite shapes of more than one bezier curve and boolean operators for masking / clipping. Using the stencil buffer for counting the winding number allows to do all of that very easily without tessellation or decomposition at path intersections.
> Can you elaborate on it or provide resources?
If you are interested in the theory behind implicit curve rendering and how to handle the edge cases of cubic bezier curves checkout these papers:
> The distance is only irrelevant for plain 2D text rendering, right?
Yes, as I said it is relevant for text rendering, but not necessarily 2D. It can also be embedded in a 3D perspective as long as the text itself is planar. Meaning you can directly render text in a 3D scene this way without rendering to a texture first.
> But real shadows and lighting would require the distance aspect, no?
I think the difference is in stroke vs fill, not the illumination (as you could still use shadow mapping / projection). In stroking you need to calculate an offset curve either explicitly or implicitly sample it from a signed distance field. Thus the exact distance matters for stroking, for filling it does not.
Couldn’t you do stroking by doing a second fill operation on a slightly scaled down version of the first with the negative space color as the interior?
Yep, stroking is just filling of the space between offset curves (aka. parallel curves), and that "slightly scaled down version of the first" is the "calculate an offset curve explicitly" approach I mentioned.
Though it is very unpractical because the offset curve of a cubic bezier curve is not a cubic bezier curve anymore, instead it is an analytic curve of degree 10. Thus, in practice the offset curves for stroking are either approximated by polygons or implicitly sampled from signed distance fields.
One more thing: Offset curves are different form classical scaling from a center point in all but the most trivial cases where there exists such a center; namely regular polygons. And cubic bezier curves can be concave, even have a self intersecting loop or form a cusp.
I'm assuming no coercion. In my scenario, tier 1 doesn't need any of that except natural resources because they can self-produce everything they need from those in a cheaper way than humans can.
If someone in tier 1, for instance, wants land from someone in tier 2, they'd have to offer something that the tier 2 person values more than the land they own.
After the trade, the tier 2 person would still be richer than they were before the trade. So tier 2 would become richer in absolute terms by trading with tier 1 in this manner.
And it's very likely that what tier 2 wants from tier 1 is whatever they need to build their own AIs.
So my argument still stands. They wouldn't be poorer than they are now.
The real limiting factor is the willingness of people to actually follow the system, which I think he mentions but doesn't examine much. It'd be interesting to see if any of the papers test the better systems to see how they fair with noncompliant passengers.
Embrace the next challenge: Instead of roads on parabolic (Euclidean) geometry, have roads on elliptic (non-Euclidean) geometry, like the surface of a sphere. Plus, on a sphere every line is already a circular arc anyway (no matter if straight or bent, the difference is just the center, radius and normals). Thus, this system of circular arc segments really lends itself to such a space.
Little prince style micro planets with their own miniature infrastructure will always have a special place in my heart. Half a year ago I started with laying out the basics https://github.com/Lichtso/bevy_ellipsoid_billboard https://github.com/Lichtso/bevy_geodesic_grid but got distracted by fixing some engine bugs in Bevy along the way. That reminds me I have to update to the newest engine version ...
anyway you can find some of the roads on spheres stuff here: https://github.com/Lichtso/bevy_geodesic_grid/blob/main/src/... it can not only generate the extrusion mesh but also calculate how the mesh overlaps with a geodesic grid of triangular tiles on the surface.
reply