-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
Use GPU to compute and edit maps #17
Comments
For future reference, my terrain editor takes this approach so feel free to use whatever you can from this: I agree with many points Zylann raises here. The first one (blend modes) was added a week or two ago (render_mode blend_disabled). The second one, you can actually "upload" them with a trick, just place a TextureRect in your viewport that you size to the portion you want to update and set a texture to it. With the above blend_disabled and a nifty shader you could even make it just update one channel. In a way that is exactly how I end up painting terrain. Download is a problem, I might see if I can come up with something and submit a PR. The 3rd is a pain. I've accepted it, it just uses more memory in the editor though careful choosing of how you use your channels can mitigate it. But yeah, would love to be able to specify I want a 32bit, 1 channel texture for my heightmap instead of mucking about with packing the height into multiple 8bit channels. The 4th one (potential issues with color space conversion) only applies to 3D viewports, there is no color conversion on 2D viewports. There can be a conversion on loading/unloading textures. So far it's worked fine for me. For 3D viewports I've added a "keep_3d_linear" setting on the viewport that disables the color conversion provided you have not set anything in the environments tone mapper. The 5th one, this is difficult in the architecture of Godot especially if you turn multithreading on and the viewport look runs in a separate thread. I haven't found it difficult but what I really miss is not being able to query whether the viewport was updated so I can react on it. |
I found a way to sculpt with a Viewport at small cost (i.e without having to render the entire terrain each time), so I'm now working on rewriting the brush system using the GPU and shaders. How it works
Doing things this way allow undo/redo to keep working as it does, and does not require large renders. Minor issues with texture formatIdeally, the viewport's framebuffer should match the format of the texture we paint on, but Godot 3.x can only offer us either RGBA8 or RGBAH. So there is a bunch of unused bandwidth when calling Heightmaps require 16-bit or 32-bit rendering with a single channel, but only 16-bit and 4 channels are available. Besides, only the 3D mode allows HDR so we also have to waste a bit of memory for unused things like the depth buffer. Again, doesn't cause much trouble beyond memory usage in the end. Problem with color paintingI'm having a problem with the colormap though: Turns out, on all terrain shaders, the colormap was hinted with Removing |
The re-implementation is now available to test in branch |
This is now in master. The only thing remaining are the following:
|
I don't really know what I can do here. It's not broken, but it's a compat-breaking change that happened because being forced to workaround the conversion is a pain, and I'd like to be able to paint in linear like before, but my last attempts failed... |
I would add my linear conversion to your default shaders and call it a day. It's unusable now. Things will probably change when vulkan is released, so you can figure out a more elegant solution then. |
Map = texture used for terrain data
Calculating heightmap normals, painting or sculpting the terrain is basically down to processing images, in ways that extend a bit further than using the classic drawing functions.
This is utterly slow in GDScript (but relatively usable on small maps and currently works fine with undo/redo etc).
Using C++ would improve this, and is a reason why issue #14 exists, however it can't get around the fact it needs to reupload changes to the graphics card, which takes time and memory since there has to be a copy of the images in RAM.
An alternative to using C++ would be to use render target Viewports. The GPU is many orders of magnitude faster at this than C++, and it would dispense the need for the plugin to have a GDNative library to maintain and ship with.
However there are limitations in the engine that prevent this to be used more widely in this plugin:
The text was updated successfully, but these errors were encountered: