Godot: Rainbow sparks in the Visual Script editor

[kreaninw]

Godot version:

Godot v3.2.4-beta2

OS/device including version:

• Windows 10 (64-bit) version (build) 2009 (10.0.19042).
• Intel® UHD Graphics 620 driver version 27.20.100.8935.
• GLES3

Issue description:

In some of my scripts, rainbow sparks appear in the Visual Script editor, as shown here. I expected to see no sparks in the editor.

Note: I don't know if this will be related. In Godot v3.2.4-beta1, the Visual Script editor crashed on me every time which I reported in #43108. In Godot v3.2.4-beta2, it's not crashing anymore. However, I got the sparks as I had described.

In Godot v3.2.3-stable, no crash and no rainbow sparks occur.

Steps to reproduce:

1. Open the project.
2. Open the script (Look.vs). The rainbow sparks will appear.

Minimal reproduction project:

3D Targeting System.zip

[Calinou]

It's likely a regression from GLES3 batching. cc @lawnjelly

[lawnjelly]

I can't actually see it reproducing but it may be similarish to this issue I fixed the other day:
https://github.com/godotengine/godot/issues/42899#issuecomment-726597797

I can probably track it down with some extra asserts for this condition, so I'll take a look.

Still not been able to reproduce this, even with the asserts where I thought this would be happening. I'll keep trying. It looks like the lines are coming out of an origin position 0, 0... I don't think it should be GPU dependent (if it is batching input data), so the fact it shows on yours but not mine is interesting.

[kreaninw]

I disabled the batching in the project setting. However, the issue still appears as shown here.

[lawnjelly]

Yes I was coming round to the conclusion maybe it wasn't to do with the batching input data. Could have been the attribute inputs to the shader being uninitialized. But doh yeah should have asked you earlier to test without batching! :grin:

That does narrow it down somewhat. You say you couldn't open the project in 3.2.4 beta 1, ah silly me you say it worked 3.2.3. There have only been very limited changes to the legacy renderer since then. I'll see if I can figure out any possible culprits.

[lawnjelly]

Just having a look in what time I had available this evening, the only thing I can think of is the buffer orphaning in the legacy renderer, it is possible I changed something I will look over tomorrow and see if anything could be problematic in comparison to any previous code. But in the meantime there are settings in the beta for changing buffer orphaning method:

project_settings->rendering->options

When not using batching (which should be the focus for finding this bug as it simplifies things), try different combinations of the bools in api_usage_legacy. They were primarily put in for mac users but it is worth trying in this case.

There was a refactoring from 3.2.3 to 3.2.4 for unified batching, but that shouldn't (hopefully) have affected any of the functionality or logic in the legacy renderer. So hopefully there are only a few possibles that could be causing this difference.

[kreaninw]

Just having a look in what time I had available this evening, the only thing I can think of is the buffer orphaning in the legacy renderer, it is possible I changed something I will look over tomorrow and see if anything could be problematic in comparison to any previous code. But in the meantime there are settings in the beta for changing buffer orphaning method:

project_settings->rendering->options

When not using batching (which should be the focus for finding this bug as it simplifies things), try different combinations of the bools in api_usage_legacy. They were primarily put in for mac users but it is worth trying in this case.

There was a refactoring from 3.2.3 to 3.2.4 for unified batching, but that shouldn't (hopefully) have affected any of the functionality or logic in the legacy renderer. So hopefully there are only a few possibles that could be causing this difference.

With the batching and the buffer orphaning turned off, the issue still appears as shown here.

Turning on flag stream will not help either, as shown here.

I tried different combinations as suggested by:

• With both the flag stream and the buffer orphaning turned on while the batching is turned off, the issue still appears as shown here.
• With the flag stream turned off and the buffer orphaning turned on (default setting) while the batching is turned off, the issue still appears as shown here.

[lawnjelly]

Thanks for testing! :+1:

There are some small differences since 3.2.3 I'll go over it with a fine toothed comb today, and add some error checking on the calling parameters and see if we can find out what is causing it.

Notably a couple of the old drawing funcs did not use buffer orphaning at all, which could lead to stall (which we were trying to prevent on mac), but may have ensured the buffer was filled with stale data which hid calling bugs.

[lawnjelly]

I'm just making a windows build which I'll post here which should emulate the old legacy behaviour when you switch rendering->options->api_usage_legacy->orphan_buffers to false.

Link to build

https://github.com/lawnjelly/misc-builds/releases/tag/godot_rainbow_v1

Then it will be interesting for you to try it (with batching switched off).
I'm not holding out massive hopes on it fixing the issue, because orphaning should at worst cause a stall and performance problems, it shouldn't affect the visual result. But it may indirectly affect it if there was another existing bug depending on the old behaviour.

If it doesn't have an effect then I'm getting stumped. There weren't really a lot of changes in the legacy renderer. And it is also possible that it is something outside the renderer that is causing the problem (being called incorrectly, or driver problem). Really this is falling into that category of problems that is hardest to fix because I can't reproduce it here, and we haven't pinned down what is causing it - even knowing the primitive type would help massively. I am slightly suspecting the grid in the visual script editor but I'm not sure you can turn it off. So if you notice any problems in running projects or outside this particular feature in the editor that would help massively.

Just to double check, did you restart when turning off batching in the editor? The editor needs to restart for the change to take effect. And that is kind of easy to miss.

[kreaninw]

I'm just making a windows build which I'll post here which should emulate the old legacy behaviour when you switch rendering->options->api_usage_legacy->orphan_buffers to false. I'll post it up here when ready.

Then it will be interesting for you to try it (with batching switched off).
I'm not holding out massive hopes on it fixing the issue, because orphaning should at worst cause a stall and performance problems, it shouldn't affect the visual result. But it may indirectly affect it if there was another existing bug depending on the old behaviour.

If it doesn't have an effect then I'm getting stumped. There weren't really a lot of changes in the legacy renderer. And it is also possible that it is something outside the renderer that is causing the problem (being called incorrectly, or driver problem). Really this is falling into that category of problems that is hardest to fix because I can't reproduce it here, and we haven't pinned down what is causing it - even knowing the primitive type would help massively. I am slightly suspecting the grid in the visual script editor but I'm not sure you can turn it off. So if you notice any problems in running projects or outside this particular feature in the editor that would help massively.

Just to double check, did you restart when turning off batching in the editor? The editor needs to restart for the change to take effect. And that is kind of easy to miss.

I did restart the editor when turning off batching in the editor, as well as when I turning on or off the Api Usage Legacy options because the editor prompted me with the yellow message.

I can't find any option to turn the Visual Script's grid off.

Out of my curiosity, I downloaded the source and compiled Godot 4.0 (with target=release_debug) to test out this issue. However, I can't even open my script (Look.vs) there as it always makes the editor crash, while I can open player.vs without crashing. And in 3.2.4 beta2, only Look.vs shows rainbow sparks while player.vs don't show any spark at all. I don't know whether it will be related to this issue, it's just the only thing that I noticed.

EDIT: I tried it with your build, the issue still appears as shown here.

[lawnjelly]

And in 3.2.4 beta2, only Look.vs shows rainbow sparks while player.vs don't show any spark at all.

It is all good relevant info. :+1: There might be an element in one script that is causing it and not the other. Or it may be a bit of Heisenbug and only appear when the conditions are right and it is just coincidence that one script causes it.

Trying it in Godot 4 won't yield that much useful info here sadly, as the vulkan renderer is completely different (and the driver).

What is interesting is that no one else has chimed in saying they've seen the same thing. That could be indicative of a driver bug, or at least we should consider it. If we don't get any more info from you running the test build, I think we'll just have to leave this open for a bit and see if anyone else reports it, or you see it in a different circumstance.

Also updating your graphics drivers is always a good thing to try, just in case.

I also put a load of extra validation code in the batching and ran it on the project but it didn't pick up anything amiss.

[kreaninw]

And in 3.2.4 beta2, only Look.vs shows rainbow sparks while player.vs don't show any spark at all.

It is all good relevant info. 👍 There might be an element in one script that is causing it and not the other. Or it may be a bit of Heisenbug and only appear when the conditions are right and it is just coincidence that one script causes it.

Trying it in Godot 4 won't yield that much useful info here sadly, as the vulkan renderer is completely different (and the driver).

What is interesting is that no one else has chimed in saying they've seen the same thing. That _could_ be indicative of a driver bug, or at least we should consider it. If we don't get any more info from you running the test build, I think we'll just have to leave this open for a bit and see if anyone else reports it, or you see it in a different circumstance.

Also updating your graphics drivers is always a good thing to try, just in case.

I also put a load of extra validation code in the batching and ran it on the project but it didn't pick up anything amiss.

I tried the test build with the latest Intel driver, but the issue still appears as shown here.

[lawnjelly]

I tried the test build with the latest Intel driver

Ah well it was worth a try, thank you for trying. :+1:

Did you have any luck with the special build linked here?
https://github.com/godotengine/godot/issues/43702#issuecomment-731601461

When you try it be sure to turn legacy orphan_buffers to off and use_batching_in_editor to off.

[kreaninw]

I tried the test build with the latest Intel driver

Ah well it was worth a try, thank you for trying. 👍

Did you have any luck with the special build linked here?
#43702 (comment)

When you try it be sure to turn legacy orphan_buffers to off and use_batching_in_editor to off.

Wow, I tried the special build with the batching turned off which I had reported doesn't fix this issue.

However, I tried it again with both the batching and the orphan buffers turned off, I see no rainbow sparks anymore.

(Turning both the batching and the orphan buffers off in the current 3.2.4 beta2 won't fix this issue, it only works in your special build.)

Thanks for looking into this issue. 👍

EDIT: In your special build, even with the batching turned on, I don't see any rainbow sparks at all. Only when I turned the orphan buffers off, the sparks disappeared.

[lawnjelly]

Ah that is great news. :partying_face:

That really pins it down, and if worst comes to worst, we can revert the legacy behaviour regarding orphaning. My hunch is that the new rendering code may actually be correct but something calling it is giving duff parameters, and the old lack of orphaning is hiding the bug.