Replies: 4 comments
|
okie, agreed. I think conceptually it makes more sense to have these common accessors in a separate module, however it would be more convenient for us to just have it in typegpu. it would also make it easier to find these accessors for the creators of external utils I think |
0 replies
|
I agree with @mhawryluk. I also think the first example would get a lot simpler if we allowed const pipeline = root
.with(getViewportSizeForBlur, viewportSizeUniform)
.with(getViewportSizeForRaymarch, viewportSizeUniform)
.with(getViewportSizeForEffect, viewportSizeUniform)
// ...would become: const pipeline = root.with(
[
getViewportSizeForBlur,
getViewportSizeForRaymarch,
getViewportSizeForEffect,
],
viewportSizeUniform
);
// ... |
0 replies
|
We can use |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
With our goal to provide a standard set of modules that perform common tasks, they can have some configurations that are common between them, like:
Lets say a handful of these libraries export an accessor for the viewport size:
For every module that wants to use the viewport-size, we need to populate its accessor with the appropriate value either when creating a pipeline, or on the root itself.
One way we can mitigate this ballooning of duplicated common accessors, is to house these common accessors either in
typegpuitself, or in a common dependency of all the modules above (e.g.,@typegpu/common-resources).All reactions