Skip to content
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

Render to texture functionality on demand #16828

Closed
gtsiam opened this issue Feb 19, 2018 · 2 comments
Closed

Render to texture functionality on demand #16828

gtsiam opened this issue Feb 19, 2018 · 2 comments

Comments

@gtsiam
Copy link

gtsiam commented Feb 19, 2018

I am trying to implement a ping pong texture (a texture that is sent to the gpu, goes through a shader, and again, and again, and so on).

I know it is possible to do by setting up multiple Viewports and ViewportTextures, but it is a bit wasteful. if you want to do a few of those per frame.

So maybe it would be a good idea to have viewports that can render on demand. Compute shaders would be nice, but I assume it is a bit too much to implement.

I am willing to work on this myself, but I would like a few pointers, since I am not too sure where the rendering happens in the engine (or to know if there is an obvious alternative method I missed).

EDIT: Actually, I just remembered this post, so I can probably do without the pointers...

@Zylann
Copy link
Contributor

Zylann commented Dec 12, 2018

I kind of miss this, everytime I have to use shaders for texture generation. It is very inconvenient to setup a bunch of viewports and have them working in the correct order to execute a series of steps, sometimes with multiple iterations, without knowing for sure when the final frame is ready (each _process, I assume?), and even worse if you need to have that output fed into further passes.

My current use case is terrain generation: I want to support erosion in my terrain generator, but this requires to run a slope-dependent blur shader a lot of times on the same image, and the more I tweak my generator, the more I think I'll need a node-based system which however feels very cumbersome to setup with the current viewports, because unlike the recently added visual shader editor which only has to generate one shader to one output, I would need to plug outputs of different shaders to the inputs of others...
So for now I try to get along with a single viewport or two, waiting dozens of frames for everything to complete in order, which causes pseudo-laggy edition behavior, and quickly becomes unusable.

About rendering on demand, I found there is VisualServer.draw(), which was used for onion-skinning so the editor is able to draw the entire scene again with some alpha (the entire editor is also redrawn btw). So, in order to have render on demand, it would mean to have this feature per viewport, instead of being global.

This could benefit to any baking tool as well which needs to run iterations on textures.

@clayjohn clayjohn added this to the 4.0 milestone Oct 1, 2019
@Calinou
Copy link
Member

Calinou commented May 26, 2020

So maybe it would be a good idea to have viewports that can render on demand. Compute shaders would be nice, but I assume it is a bit too much to implement.

Godot 4.0 makes use of compute shaders and will likely expose a compute shader API of some sort.


Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants