-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Avoid reimporting lightmap textures every getter call #77788
Avoid reimporting lightmap textures every getter call #77788
Conversation
8a63989
to
12f4934
Compare
e69af72
to
5f105f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally (rebased on top of master
329652b), it works as expected. I no longer get a crash with the MRP.
However, we will need to implement a compatibility handler so that users aren't forced to rebake lightmaps when upgrading. (This can take a long time on complex levels with high quality settings, especially if you have a slow GPU.)
This indeed needs some compatibility code added. The old methods should still be registered as compatibility methods for GDExtension, and existing data should ideally be parsed and converted to the new format (which can be done via the |
0718e58
to
865c25a
Compare
I don't know what went wrong during the time I last tested this branch, but it no longer works. It crashes with an out of bound error seemingly when there are more than one lightmapped meshes in a scene.
MRP (don't mind the namings, I reused an old MRP): crash.zip |
This crash issue seems not related to this PR. I only refactored the old porting PR (#61861) and removed unnecessary importing operations. You may create a new issue and fill in details about the issue and MRP. |
This issue does not happen in c5a7462, which is the parent of this PR's branch. That should confirm that this issue is caused by something during all those rebases and forced pushes. The stack trace also points to a file touched by this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above
865c25a
to
c165f0c
Compare
Needs to be verified but should fix the issue
@AThousandShips I tried out your fix on my end and it still crashes with the exact same log, but seems to have progressed a little more. Before, it only said "Retrieving textures", but it now shows reimport progress of the lightmap. A finally decided to actually test it with a debugger. Here's what I got: On line 1088:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs further evaluation, ensure that the code is correctly transferred and correct
New version works now. Turns out I applied it wrong by also commenting out |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. Kobewi confirmed in chat that it looks fine as well. I'm comfortable going ahead with this
Thanks! |
Also improves #61861. The
_get_light_textures_data
function is trying to reimport lightmap textures on every getter call which sounds irritable to me (e.g. when the engine is reading the property via duplicating).