> Hand-drawn 2D animations often have watercolour backgrounds. Can we convincingly render 3D scenery as a watercolour painting? How can we smoothly animate things like brush-strokes and paper texture in screen space?
There are various techniques to do this. The most prominent one IMO is from the folks at Blender [0] using geometry nodes. A Kuwahara filter is also "good enough" for most people.
> When dealing with a stylised 3D renderer, what would the ideal "mesh editor" and "scenery editor" programs look like? Do those assets need to have a physically-correct 3D surface and 3D armature, or could they be defined in a more vague, abstract way?
Haven't used anything else but Blender + Rigify + shape keys + some driver magic is more than sufficient for my needs. Texturing in Blender is annoying but tolerable as a hobbyist. For more NPR control, maybe DillonGoo Studio's fork would be better [1]
> Would it be possible to render retro pixel art from a simple 3D model? If so, could we use this to make a procedurally-generated 2D game?
I've done it before by rending my animations/models at a low resolution and calling it a day. Results are decent but takes some trial and error. IIRC, some folks have put in more legwork with fancy post-processing to eliminate things like pixel flickering but can't find any links right now.
Prediction: the best AI teacher (or just teacher in general) will be the one that is able to emotionally read and guide/manipulate the student towards learning and self improvement.
If such an AI teacher style becomes widespread, this means that they have the potential to replace the parental relationship (in the same manner AI girlfriend/boyfriends threaten romantic relationships).
I see people talk about the dangers of the AI girlfriend/boyfriend, but not the dangers of introducing AI teachers to (especially young) kids. Nominal adults are already being affected by this (see Replika and company) and they are not even the "best".
If I wear my cynical hat for a second, I'm willing to bet that this parental replacement is a certainty, as an extension of the "screen" parenting that already exists. But this time, it might actually be helpful for the child so it will be socially acceptable and encouraged.
Have you taken a look at the paper "Foreign Function Typing: Semantic Type Soundness for FFIs" [0]?
> We wish to establish type soundness in such a setting, where there are two languages making foreign calls to one another. In particular, we want a notion of convertibility, that a type τA from language A is convertible to a type τB from language B, which we will write τA ∼ τB , such that conversions between these types maintain type soundness (dynamically or statically) of the overall system
> ...the languages will be translated to a common target. We do this using a realizability model, that is, by up a logical relation indexed by source types but inhabited by target terms that behave as dictated by source types. The conversions τA ∼ τB that should be allowed, are the ones implemented by target-level translations that convert terms that semantically behave like τA to terms that semantically behave like τB (and
vice versa)
I've toyed with this approach to formalize the FFI for TypeScript and Pyret and it seemed to work pretty well. It might get messier with Rust because you would probably need to integrate the Stacked/Tree Borrows model into the common target.
But if you can restrict the exposed FFI as a Rust-sublanguage without borrows, maybe you wouldn't need to.
Speaking as an aspiring solo gamedev: these extra menus in programs like Blender are super important.
Sure, you can map extra keybinds, but convenient keybinds are actually a scarce resource if you're essentially the "full stack" of the art pipeline (from sculpting, modeling, retopology, texture painting, to animating). This isn't even including keybinds for any custom tooling.
One thing I really appreciate about Blender specifically is that you can search through all the available operations with F3. This offers a nice trade-off between muscle memory, keybind consumption, and not needing to use the mouse.
> so long as the only unsafe code in a well-typed λRust program is
confined to libraries that satisfy their verification conditions, the program is safe to execute.
I think the main caveat is that IIRC, the RustBelt unsafe rules do not cover ALL uses of unsafe in the wild, they analyze only a subset of Rust as whole, and of course, unsafe usage actually has to obey the rules. But I'm hardly an expert here.
That bug report basically says they broke the unsafe rules and thus the guarantee no longer holds (and there is UB).
I think there's a conflict between FFIs in practice and theoretical FFIs. The few papers I've read for sound FFIs between languages A and B rely on the fact that the common interop target is a high-level language whose features subsumes the features of A and B. ABI, calling convention, etc. are merely implementation details.
So from this perspective, the interop target should actually not be the lowest common denominator, but the opposite: a target that can describe all possible user languages in a common format.
In fact, I would actually argue that the implementation details are NOT that interesting and only a distraction: that we need an abstract way of declaring compatibility. For instance, one can imagine a high-level FFI target where function types are parameterized by their calling convention i.e.:
`foo: (VOID<C>->VOID<C>)<C>`
`bar: (UNIT<Rust> -> UNIT<RUST>)<RUST>`
and attempting to call `bar` from `foo` involves a compiler intrinsic like `RUST_CALL(bar)()` to convert the type (and the calling convention) appropriately.
There are various techniques to do this. The most prominent one IMO is from the folks at Blender [0] using geometry nodes. A Kuwahara filter is also "good enough" for most people.
> When dealing with a stylised 3D renderer, what would the ideal "mesh editor" and "scenery editor" programs look like? Do those assets need to have a physically-correct 3D surface and 3D armature, or could they be defined in a more vague, abstract way?
Haven't used anything else but Blender + Rigify + shape keys + some driver magic is more than sufficient for my needs. Texturing in Blender is annoying but tolerable as a hobbyist. For more NPR control, maybe DillonGoo Studio's fork would be better [1]
> Would it be possible to render retro pixel art from a simple 3D model? If so, could we use this to make a procedurally-generated 2D game?
I've done it before by rending my animations/models at a low resolution and calling it a day. Results are decent but takes some trial and error. IIRC, some folks have put in more legwork with fancy post-processing to eliminate things like pixel flickering but can't find any links right now.
[0]: https://www.youtube.com/watch?v=ljjUoup2uTw
[1]: https://www.dillongoostudios.com/gooengine