New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow different size image sources for Kage #1870
Comments
CC @SolarLune |
Hello! I asked this in connection with my 3D software renderer, so it's a bit of a niche use case. Instead, if we were to look at this request from a general perspective, I could see people needing to, say, composite two images of different sizes in a shader (like, perhaps, an image of a sprite sheet and some kind of detail or color map for switching palettes). If it's not possible currently, that's OK - there are ways to work around it, so it's not critical, but I think I could see the utility if it wouldn't drastically hurt performance or API readability. |
Sure, let me de-prioritize this. Thanks, |
Now we added the pixel mode (#1431), it should be easy to treat different sizes of source images. |
This might conflict with the idea of utility functions of normalization (#2644) |
Hmm, the biggest problem is that the current design of Probably we have to deprecate |
Just mentioning that, as I exposed on #2646 and other places, I consider separate |
So imageSrc1At(texCoord) will be // Texels
newImageSrc1At(((texCoord - src0Origin) * src0Size) / src1Size + src1Origin)
// Pixels
newImageSrc1At(texCoord - src0Origin + src1Origin) I'm not sure this is acceptable. If we didn't have the pixel mode, I would deny this idea. |
I generally agree; the simpler and less "magic" is done, the better. However, ideally, that's not because the function that did the magic is broken up into smaller functions, but rather that the magic is no longer necessary.
I thought that it was decided to turn off atlasing when shaders were used; if so, then you wouldn't need any origin manipulation, right? As for the concept of arbitrary texture sizes in Kage, allow me to make a case for it. Support for arbitrary input texture sizes in a shader system is an inherent, relatively basic feature that is used heavily in shaders. There's many use cases where it's useful; for example, if you render a sprite (one Another use case would be if you render a sprite (one (The above example probably uses mathematical functions rather than a noise texture to get the effect, but you could do the same thing with a texture.) I believe this is a fairly important issue now because the alternative basically means wasting CPU / GPU time and memory. You have to maintain additional buffer images and/or render textures to large buffers to ensure buffer sizes are the same. This effectively hamstrings the shader system dramatically for any non-trivial and real-world usages. |
Quick reply:
No we have not decided yet. And, we were talking about atlasing for a destination image, not a source image. Unatlasing a destination image would not solve the issue. |
I think before anything else is done, we need to come to a conclusion on |
I think we have never discussed about atlasing source images. This sounds a new topic. If you have a suggestion about this, please file a new issue or a new discussion. Thanks, |
My current idea is to allow different source sizes only for the pixel mode.
We can discuss 2. later. There is no action item for 1. as this is already done. So, simply allowing different sized source images for the pixel mode is what we have to do. My concern is that the notion of 'normalization' of pixels to the range [0, 1] will be more complicated, if we work on #2644 , but I don't have a clear idea about this. |
This sounds perfectly understandable; thank you for working with me on this! EDIT: Also, thanks for the clarification on atlasing, I must have been mistaken. |
@SolarLune Do you think it is ok to allow various source sizes only for DrawTrianglesShader? DrawRectShader is a little special and would break some assumptions if it accepted various sized sources (#2166 (comment)) |
I think that would be fine, yeah. Of course, the documentation should mention the difference, but if it's only feasible that way, then that would be the way to go. |
Note to myself:
|
Assuming different size source images are available only with the pixel mode,
Any thoughts? |
I think it's reasonable within the current API. I also think it shows how the API for working with images in shaders needs an eventual revamp:
So, I think the friction and weirdness and potential confusion is unavoidable due to previous design decisions, which didn't have the benefit of the insight we have at the current point in time. The only change I'd consider here is using |
Thank you for feedbacks!
My intention is that imageSrcNSize returns the region's size, not the texture size. So imageSrcNTextureSize doesn't make sense... |
Existing functions:
New functions:
|
This is a preparation to specify different sizes of source images. Updates #1870
I'm not sure we could do it.
The text was updated successfully, but these errors were encountered: