You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After initial investigations, it looks like the path towards making the terrain editable would be to load the heightmap (and other textures) into memory first from a path, and then load them into the terrain from memory. Right now, the terrain loader seems to load the heightmap directly from a path which is non-conducive to making it editable.
If the heightmap data were loaded into memory first and then that struct were used to build the terrain (like AddAttachmentFromMemory or something similar) then a system could be built to edit that heightmap in memory and hot-reload the tiles/chunks every ~200ms as needed. Once that is done, the only thing left to do would be to add some sort of manual or auto save/export feature that could export the heightmap in memory back out to a file as the editor desired.
thoughts?
The text was updated successfully, but these errors were encountered:
For example , terrain config storing a path as a string is not ideal for this topology. Same goes for TileConfig. I think that disk paths need to be further decoupled in order to achieve this. Experimenting ...
Sorry for replying so late. I am still waiting for bevys asset system 2.0, before I will continue working on asset related features.
Editable terrain will be a massive change to plugin. I do not think that CPU side processing will be fast enough. We will have to move the entire preprocessing code to the GPU. Ideally in a streamable and efficient manner.
After initial investigations, it looks like the path towards making the terrain editable would be to load the heightmap (and other textures) into memory first from a path, and then load them into the terrain from memory. Right now, the terrain loader seems to load the heightmap directly from a path which is non-conducive to making it editable.
If the heightmap data were loaded into memory first and then that struct were used to build the terrain (like AddAttachmentFromMemory or something similar) then a system could be built to edit that heightmap in memory and hot-reload the tiles/chunks every ~200ms as needed. Once that is done, the only thing left to do would be to add some sort of manual or auto save/export feature that could export the heightmap in memory back out to a file as the editor desired.
thoughts?
The text was updated successfully, but these errors were encountered: