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

Crash while saving project with large data #159

Closed
paxetgloria opened this issue Jul 25, 2023 · 14 comments · Fixed by #374
Closed

Crash while saving project with large data #159

paxetgloria opened this issue Jul 25, 2023 · 14 comments · Fixed by #374
Assignees
Labels
big terrains Issues that need to be addressed for big terrains important High priority waiting for godot Bug or missing feature in the engine
Milestone

Comments

@paxetgloria
Copy link

I get this error in the console
image

I'm using the Demo scene so all the settings are the same.
Repro:

  • import terrain_8k.exr and ter_texture_8K.png with "Import Position" at -8192 0 - 8192
  • import second batch at 0 0 -8192
  • save the project -> crash
    Note that it doesn't crash when saving after importing only one 8k tile.

Data to reproduce the crash was already shared with the devs.

@TokisanGames TokisanGames self-assigned this Jul 25, 2023
@TokisanGames
Copy link
Owner

TokisanGames commented Jul 25, 2023

If you click the arrow on the right of the storage resource and click save, that's when it crashes. CTRL+S just calls the resource saver to save independent of our code.

It's a known engine bug

The crash occurs after 1,073,741,824 bytes (~1gb) and with only 8k by 16k we're looking at 1.4gb or 2.8gb for 16k x 16k.

Proposed solution, replacing int with uint64:

Pending PRs that might fix this:

@TokisanGames
Copy link
Owner

I built Godot using the two PRs mentioned and it no longer crashes, but it does corrupt the file and still overruns the cowdata limits. Follow up here godotengine/godot#74582

@TokisanGames TokisanGames added the big terrains Issues that need to be addressed for big terrains label Jul 25, 2023
@CsloudX
Copy link

CsloudX commented Nov 29, 2023

Maybe storage can save/load from a dir, and separate data by region?
This has 2 advantages for large terrain:

  1. can load data runtime in a const time (don't load all data one time).
  2. the data file won't be too large, it was good to vcs(like only modify 1 region, not big file need commit)

other. don't need waiting godot fix this issue ^V^.

@TokisanGames
Copy link
Owner

Using multiple files is possible, but I'm not excited about 256 data files. And when we expand the max region size, I don't want up to 2000 data files. Regions viewed in the distance still need to be loaded. We'll see. There are other more urgent things to build first.

@TokisanGames TokisanGames moved this to 1.0-Stable Release in Terrain3D Roadmap Dec 16, 2023
@TokisanGames TokisanGames moved this from 1.0-Stable Release to Future Ideas in Terrain3D Roadmap Dec 16, 2023
@TokisanGames
Copy link
Owner

New 64-bit cowdata PR to watch.
godotengine/godot#86730

@TokisanGames
Copy link
Owner

Juan's PR is ready to merge in 4.3. There's a new Godot-cpp PR to work with it. This is promising and needs to be tested against a large resource file.

godotengine/godot-cpp#1357

@TokisanGames
Copy link
Owner

TokisanGames commented Jan 19, 2024

Both Juan's 64-bit cowdata PR and the godot-cpp PR have been merged. We can try testing big data again.

@Saul2022
Copy link

. We can try testing big data again.

Great!! It fixes the original godot issue so that may make it, through do you know of any file with such size to test this ?

@TokisanGames
Copy link
Owner

It just needs saving a terrain with >100 regions. 16k is 256.

@TokisanGames
Copy link
Owner

The new PRs do not yet allow saving resource > 1gb w/o crashing. godotengine/godot#62585 (comment)

@TokisanGames
Copy link
Owner

TokisanGames commented May 7, 2024

Godot won't be fixing this until at least 4.4, probably 6 months away minimum. And so far no pending PRs fix it so it could be much longer.

However, splitting regions into separate data files #356 will fix it. Since the opengl limit on layers is 2048, we won't have more than that number of files, which is reasonable. As long as any given region with the maps and foliage data is <1gb it won't crash, which will be very hard for users to hit. Time frame on this is 1-2 months realistically. After I finish foliage in #340, 0.9.2 will be released. Then this and dynamic collision are the top priorities.

@CsloudX Your idea was correct, but it took me a while for me to realize it for myself. Having one large file sucks for teams and git.

@TokisanGames TokisanGames removed their assignment Jun 1, 2024
@Saul2022
Copy link

Maybe while it known that the separate sotrage regions will fix this, atleast it seems that things are improving godotengine/godot#94598

@TokisanGames
Copy link
Owner

@Saul2022 Thanks for the heads up, but that won't affect us. It would help if we wanted region sizes >32k. We'll probably have a limit of 2k or 4k. This issue is with writing resource files to disk.

@TokisanGames
Copy link
Owner

This has finally been fixed in #374 and #476. Rather than waiting for Godot to fix saving resource files >800mb, we split data into one file per region and can now save a 16km^2 terrain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big terrains Issues that need to be addressed for big terrains important High priority waiting for godot Bug or missing feature in the engine
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants