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

GPU texture override #687

Open
jrmoulton opened this issue Nov 13, 2024 · 7 comments
Open

GPU texture override #687

jrmoulton opened this issue Nov 13, 2024 · 7 comments

Comments

@jrmoulton
Copy link
Collaborator

Vello has support for overriding an image with a WGPU texture as a method of rendering a texture directly in scene.

I think we can do something simliar in vger.

To implement this I think we can just add a method to the Render trait called override_image that matches the vello::Renderer::overide_image and then leave it up to implementers of View to handle creating the image and calling the override.

@alexthegoodman

@alexthegoodman
Copy link

@jrmoulton I think it'd be a great add. Although my wgpu integration was a bit more involved than rendering only a texture, I should say. I'm not sure how commonplace it is for people to want to integrate with the wgpu Surface, Frame, Resolve Frame, etc. but that's what my projects required.

@alexthegoodman
Copy link

@jrmoulton I also had to re-pipe the GPU Resources through to pass into my app, so I had access to Device and Queue.

@andi23rosca
Copy link
Contributor

andi23rosca commented Dec 7, 2024

+1 to this use case, I'm building an alternative to Substance Designer, and I'd like to be able to render textures to the screen directly from the GPU instead of wasting cycles pulling them back into the cpu

i'm using vello right now for that reason but i'd love to switch to something more high-level like floem

@alexthegoodman
Copy link

@andi23rosca If you'd like to see how I achieved a full wgpu integration with Floem, you can take a look at my fork: https://github.com/alexthegoodman/common-floem It is not necessarily the cleanest, but it works great. You can find me integrating common-floem in my game engine here: https://github.com/alexthegoodman/midpoint-editor

Yes, for now it requires a fork and a fair bit of work, but I think the benefits outweigh that.

@andi23rosca
Copy link
Contributor

@alexthegoodman Awesome! Forking floem and extra work is definitely easier than me reimplementing a view model in vello
Will take a look, thanks 🙏🏻

@jrmoulton
Copy link
Collaborator Author

@alexthegoodman

if floem provided access to the device, the encoder, and an api for using a wgpu texture for a view, would that cover your use case?

wgpu Surface, Frame, Resolve Frame,

Why is it that you need direct access to the main window handle? (I've looked through your code but I don't totally understand it)

@alexthegoodman
Copy link

@jrmoulton It would get us closer, I think. I use the Surface to load in my own shaders and build a separate Pipeline, and the Frames must be shared between the Floem pipeline and mine. (I also enabled multisampling by the way)
If you check out these lines here: https://github.com/alexthegoodman/midpoint-editor/blob/master/src/main.rs#L984C9-L1004C93
You'll see how I am interacting with the window handle. I also set some handlers here: https://github.com/alexthegoodman/midpoint-editor/blob/master/src/main.rs#L1396-L1441
I might not need the full window handle anymore, but be aware that I am attaching an Any type to the window handle, so I can integrate any of my various projects: https://github.com/alexthegoodman/midpoint-editor/blob/master/src/main.rs#L55-L81 I think this is critical for sharing data around everywhere its needed.

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

No branches or pull requests

3 participants