Replies: 3 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 |
Beta Was this translation helpful? Give feedback.
-
@reczkok Thoughts? 🧠 |
Beta Was this translation helpful? Give feedback.
-
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
);
// ... |
Beta Was this translation helpful? Give feedback.
-
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
typegpu
itself, or in a common dependency of all the modules above (e.g.,@typegpu/common-resources
).Beta Was this translation helpful? Give feedback.
All reactions