Small Edits to Shader Parameters

Lake

My shader has a very large texture as a parameter--basically a texture atlas with lots of sprite graphics. I want to make small edits to it each frame - a pixel or two here and there so you can see run-time custom sprites being drawn in and compiled. I can do the drawing using set_pixel() in a texture's corresponding image data, but it looks like I then have to update the texture, and re-set the parameters on the shader for it to take effect. This is very very slow. I suspect I end up creating and passing a new, very large texture each frame.

Is there any way around this? Any way to be setting pixels continuously GPU-side? And if not, is there a workaround for being able to dynamically update shader information?

Megalomaniak

Parameters/uniforms are passed from cpu to gpu, this will always be uhh rather slow. 1 option might be to have 2 copies of the node and load the next texture on the hidden one then switch visibility on them respectively when ready..? I mean an option for hiding the slowness of it from players.

Lake

Hmmm... I wonder if it would work any better doing the custom drawing on a large Subviewport rather than on an image resource, since Subviewport is already in GPU memory, I assume. Then, if the shader's on a Sprite Node using a SubViewport texture pointing at the drawing, I shouldn't have to pass it through the CPU, right? Question is if a really large SubViewport like that would have its own complications. Then maybe I'd just not clear my drawing between frames. But then, how would I clear pixels if I needed too. Bah, this stuff is hard.

cybereality

Can you explain what you are trying to accomplish? I'm not sure I understand. In general, any drawing will be done on the CPU and passed to the GPU, which is too slow for real-time (unless in very limited cases). Some functions are completely on the GPU, like the basic drawing of the camera and those are fast. But for custom stuff (like a paint application) it's more likely this goes through the CPU.

One potential solution is to have a separate buffer. This can be a simple Array, which is passed as a uniform. As you are not allocating a resource (like a texture) this can still be fairly fast, as long as it's not too much data. In the Array, you can store a vector with the pixel position (x, y) and then use the 3rd or 4th values to define the changes. You may need to write conversion functions to convert a float value to a color or something along those lines, but it is possible.

Lake

Basically, I'm implementing my own tilemap in it's own shader with features I doubt the engine will ever implement - palette swapping for one, but 4.0 tilemaps aren't really built for flipping and transposing tiles either (the alternate tiles system is just awful for my purposes). Doing it this way would also couple closer with actual shader effects in the shader, which are meant to mimic SNES-style scanline effects.

The shader has: - a 1024x1024 tilemap texture (each pixel is one tile) representing all layers - one palette texture of about 64 tables x 16 colors - and another texture for actual tile graphics in indexed color for use with the palettes. Think of it a bit like 16-bit fantasy console. The problem is that swapping tiles in and out of the tilemap each frame, for animation, say, would pass the whole 1024x1024 tilemap each frame, which is unreasonable.

What you're suggesting, in your latter paragraph, as I understand it, is that I have shaders on the Subviewports holding my textures, and that I pass an array holding instructions for each change, that I'd loop through and implement for for however each pixel is effected by each change, right? That makes sense. Only, I'm not sure how I could overdraw the render target with a transparent value if it's opaque underneath, or else, clear it, and still be able to draw what had been there before it was cleared if there are no changes to be made.