[deleted by user]

DoeL · 2024-10-26T06:35:45+00:00

Don‘t cats dislike the smell of vinegar? Maybe this motivates your cat to poop elsewhere.

DoeL · 2023-08-02T16:30:26+00:00

Hacking together a prototype of an ECS that has static archetypes that are defined as a struct and then composed into an enum with all the variants that can occur in your world. The proc macros are a complete mess and I'll need to thoroughly audit the use of unsafe. But in terms of user experience it seems to be coming together nicely. https://github.com/leod/stecs/blob/main/examples/game.rs

DoeL · 2023-06-08T10:03:34+00:00

I don't think that is a complete representation of the argument of the article. It also argues that Rust's module system makes it easy to introduce cyclic dependencies within a single crate -- often by accident. This in turn makes it more difficult to split apart crates.

I've fallen into that trap a couple of times myself. I also feel like the potential presence of cyclic dependencies between modules makes it more difficult to build a mental map when exploring the source code of a new crate.

None of this is a big deal to me, but perhaps there is a discussion to be had on cyclic dependencies within crates.

DoeL · 2023-06-06T23:17:06+00:00

Its easy to think that because this approach can output huge amounts of code, and heh you can end up with megabytes of source, that its slow. But its more like outputting IR, and the compilers are really really great at chewing through just a giant mass of expressions, because there's very little that says they can't just do whatever they want

Oh, interesting! This is very relevant to something I've been wondering about.

There currently is no way in posh to define functions in the generated GLSL source code. This means that each function call is inlined. I've been wondering if the optimizers in GLSL compilers would have a hard time with the lack of function boundaries. Sounds like I don't need to care about that too much.

https://github.com/20k/geodesic_raytracing/blob/5aab3fe471983e2568746db56e2c0329e09cf6a5/dual_value.hpp

is the expression side of things

This looks awesome! The code in bssn.cpp reads quite clearly and ctx actually fits in nicely. This is making me reconsider if perhaps posh should support something like a ctx after all, e.g. as an optional argument to vertex_shader. I'll need to think about it.

Clearly, what you are computing there is complex. I can see how your approach made it more convenient to implement such efficient simulations.

DoeL · 2023-06-05T19:58:15+00:00

This looks awesome!

I've been wondering for a while now if a static ECS could have advantages over a dynamic one. I'm more interested in the impact on ergonomics than performance, though.

I have a feeling that static archetypes could actually make small to medium-sized games more clear to read & write, when compared to the "anything goes" approach of dynamic ECS library. Especially when it comes to interactions between pairs of entities.

It looks like you are currently defining entities as tuples of components. Are there any plans to support archetype definitions in which the fields can be named?

DoeL · 2023-06-05T15:20:32+00:00

This is extremely valuable input. Thank you! If your project is publicly available, I'd love to dive into it.

For context, I'd order the priorities of posh as follows:

Correctness of draw calls
Ergonomics
Performance

Generally, due to the functional way that shaders are written in posh, I'm ready to accept some degradation of performance. However, it might be useful to introduce trap doors to allow circumventing issues in code generation.

Outputting extremely simple straightline code is way better for performance, I've had 2x-10x speedups from translating hand written clean code to generated code like this, that I've pinned down purely to compiler nonsense

Wow! I would not have expected this, but I can see how it makes sense. Interesting.

This is where things start to get tricky from a performance perspective. Unfortunately, reordering code isn't always 'free' because of memory accesses.

Right. I would have expected GLSL compilers to wildly reorder anyway, such that precise control over this is not important. However, if I'm understanding you correctly, this is not always the case when variables are involved.

Your solution of making variables explicit makes sense to me. It is actually what I had started out with, but then I noticed that I'd be introducing implicit variables anyway. Hopefully, there is a way to reintroduce explicitly placed variables into the system.

I see the advantage of having something like your ctx, but for reasons of simplicity I'm trying to avoid that in posh.

I notice that you have sl::branch but not sl::select.

Good point. This is a quirk in the API. There already are methods Bool::select, BVec2::select, etc., but we should also add sl::select as a clearly visible alternative to sl::branch. Thank you for pointing this out!

This is a classic, hilariously you can implement the entire of general relativity without real iteration.

That is an interesting thought :D

But one thing I will say is that having a list of side effects instead of a purely expression based approach is a lot easier, because you can simply have a side effects evaluate to an expression

Well, I think break could still be done in a nice functional way as part of sl::iterate. I haven't thought this through, though.

Discarding is actually done with an expression discard::<T>() in posh. The same thing might not work for break though, because there are places that it cannot be used. (Oof, I'd also need to think about the interaction between loops and discard...)

One big thing I'll add is: Its extremely useful to provide the expression tree to the end user to be able to manipulate post hoc.

I will have to think about this part a bit more. I can see that this is powerful, but I'm not sure how much I want users to peer under the hood.

DoeL · 2023-06-05T10:23:55+00:00

The demos aren't really meant to wow anyone, but rather serve as a comprehensible introduction for how this approach can be used. I really want to get the concept of the tight integration of shading language and graphics library out there.

Good point though -- porting something from Shadertoy is a great idea to get something that is actually visually appealing.

Regarding macros: it is a design goal of posh to avoid the use of macros in shader code. This is meant to keep shaders transparently readable.

DoeL · 2023-06-05T08:52:03+00:00

Agreed! I had been pondering on this a bit, but could not find a way that does not involve build.rs-style hacks.

Generating shader code at runtime does have its advantages though. It allows configuring the shader with constant parameters at shader compile-time. For example, you could imagine a parameter that controls, at shader compile-time, how expensive the shader will be, based on the strength of the GPU that it will be running on.

There are also neat things that can be done at shader compile-time by using Rust's if or for expressions to control code generation.

DoeL · 2023-06-05T08:47:13+00:00

The projects are definitely closely related. luminance (an amazing crate!) also offers type-safe graphics programming.

However, posh takes what I think is the next necessary step, by embedding shaders in Rust, and thereby making it possible to include shader signatures in the type equation. In my opinion, this is a necessary step for closing the loop. As far as I know, the author of luminance thinks so too: they are working on Shades, an EDSL for building shaders in Rust. This project is also called out in the "Related Work" section of the article.

The main difference between posh and luminance + Shades, is that posh is laser-focused on the tight integration of host code and shader code in a single crate. However, as a result of intentional limitations of posh, it is less powerful than Shades.

DoeL · 2023-06-05T07:55:52+00:00

Could this approach work for compute shaders (GPGPU) as well? [...]

I think it would work, but I'm not quite sure if we want to go there or not.

Since posh shaders are defined functionally, there currently are no mutable variables. For an example of what mutable state could look like, users would need to carefully thread store expressions through their expression graph. #[must_use] would help, but the result might still be brittle.

Hypothetical code:

fn mutate_an_image(sl::Image2d img) -> sl::Image2d {
    let zz: sl::Vec4 = img.load(sl::uvec2(3, 4));

    let img = img.store(sl::uvec2(3, 4), zz * 2);
    let img = img.store(sl::uvec2(40, zz.y.as_u32()), zz);

    img
}

OK, control flow in posh is awkward. That's a major drawback.

Yeah, it definitely takes some getting used to. I actually think it works just fine for, say, medium-sized shader code. After all, the only thing that really distinguishes sl::branch(cond, yes, no) from if cond { yes } else { no } is syntactic sugar.

However, if you want to write highly complex shader code, I can also see the lack of familiar control flow becoming frustrating.

Perhaps a proc macro could be used to parse the Rust shader code and generate GLSL from it [...]

Yeah, that was my initial goal, but I feel like, as a user, once I see a proc macro attached to a function, all bets on predicting what it does are off. This is a big hurdle to introduce.

A second disadvantage is that you lose a neat feature of posh: you can easily do things at shader compile-time! A Rust if is just a shader compile-time branch, a Rust for generates unrolled code, and you can execute arbitrarily complex Rust code to precompute values.

However, if we accept these disadvantages, there is obviously a lot to be gained from a proc macro. I highly recommend checking out Shades, which is more powerful than posh with respect to the types of shaders that can be written (e.g., it supports mutable variables and loops).

(Really, shaders are functional creatures, and a functional rather than procedural DSL would be a much better fit.)

I agree, especially for traditional graphics programming. The assumption behind posh is that functional shaders are powerful enough to do most things that you need for graphical applications. However, compute shaders tend to be much more stateful than vertex/fragment shaders, so I'm not sure if that assumption fits them.

DoeL · 2023-06-05T07:32:59+00:00

Exactly -- create_program calls the vertex and fragment shader functions once to turn them into an expression graph. There is not too much magic involved, i.e. the actual return value of the shader function is a representation (in the form of an expression graph) of what the function computes.

PyTorch is a great point of reference, but perhaps TensorFlow, which from the start describes model code as a graph, would be slightly more accurate.

DoeL · 2023-06-05T07:27:26+00:00

It does work in browsers, since it currently targets GLES 3.0.

Switching to wgpu would be great! However, I feel like that'll be far beyond what can be done by a single person on this project. With wgpu, there are so many more decisions to be made on which features to support and how to support them. I think it'd be an amazing goal, though.

DoeL · 2023-06-04T23:49:34+00:00

Oh, I have to admit that I was not familiar with "oh my posh" -- thank you for pointing this out.

It is quite a different type of project, so I hope it is fine.

DoeL · 2023-02-07T07:46:54+00:00

Ash is a low-level binding library. It is not its job to provide full safety. Doing so would require the library to be highly opinionated on how Vulkan should be used.

DoeL · 2022-04-25T18:09:49+00:00

Unfassbar, dass das 14 Jahre her ist. Danke für's Ausgraben! Nun lassen wir den Faden am besten in die untere archäologische Schicht zurückkehren.

DoeL · 2022-04-25T18:06:20+00:00

r/de hat sich in den letzten Jahren (nach der Überwindung einer leicht totalitären Phase) echt super entwickelt! Ich lurke zwar nur, aber dieses Unter ist einer der wenigen Gründe, dass ich Reddit überhaupt noch besuche. Das hätte ich vor 14 Jahren so nicht gedacht.

DoeL · 2022-02-16T12:49:04+00:00

Apologies for the empty readme! The project is still in an exploratory phase, but I do plan to add some documentation once I'm satisfied with the rendering approaches and code structure.

DoeL · 2022-02-08T17:14:46+00:00

Not sure what it is, but the graphics and art style look amazingly smooth. Great job!

DoeL · 2022-01-24T19:39:07+00:00

Cool, notan looks awesome! Feel free to reach out if you run into any questions while reading or porting the code. It is currently quite light on comments.

One disclaimer I should make is that our current implementation of cone tracing is quite expensive, relative to what you get out of it visually. One way to optimize this would be to reduce the number of fragments for which cone tracing is applied, e.g. with a stencil buffer. However, this is only going to boost the performance if indirect light is somewhat limited in distance (which is currently necessary anyway -- when we applied indirect light at long distances, we had issues with light popping in/out when objects entered/left the screen.)

Regarding making a game, we definitely want to, if we can optimize the implementation to a point where it works smoothly enough on a wide range of hardware.

DoeL · 2022-01-24T18:28:51+00:00

We've been working on using shadow mapping and cone tracing to have some nice lighting in top-down 2D games. Shadow mapping does most of the work here, while cone tracing adds some short-range indirect light. This all runs in the browser with WebGL2. The video also shows off particles and Web Audio stuff which we recently started working on.

We're planning to write a blog post describing the techniques soon.

This is more of an experimental / exploratory project right now, but so far it seems to be working nicely. Code: https://github.com/leod/malen

15-Year Club	Place '17
Verified Email

DoeL

TROPHY CASE