Performance issues 3.2.3 rc4

[Reapetitive]

Godot version: 3.2.3 rc4

PC, API: Windows 10 64bit, ryzen 1700x, nvidia geforce gtx 1070, gles3

Issue description: Performance issues in 3.2.3 rc4 compaired to 3.2.2 stable.

I am making a big 2D, physics and graphics heavy game, that uses pretty much everything Godot has to offer and some more.

After some testing i see a huge performance diffirence compaired to 3.2.2.

The heaviest rooms went from 60-100+ fps to 30-60.

3.2.2:

3.2.3 rc4:

[clayjohn]

Can you provide an MRP for other users to try to reproduce?

[Calinou]

You can also try bisecting the regression by trying all the earlier 3.2.3 betas and RCs. (Make sure to backup your project before opening them in an older or newer version.)

[Reapetitive]

@clayjohn I cant :/ Ive got huge scenes only, packed with tons of stuff. The rooms are enabled/disabled completely by activator areas and are parts of huge levels. Everything uses visabilty enablers and other methods to optimize. So practically, only the things on screen are active and relevant. In this current room are some light2ds and occluders, static and kinematic objects 2d and a lot of Area2Ds and RayCast2Ds, tilemaps, particles,shaders and ofcourse some sprites and polygons2d. Some stuff is animated by AnimationPlayers, Tweens and Timers are used too, as you can see, and ofcourse the simple ui using basic Godot nodes.

So basically, its pretty much impossible for me to simply tell what part of the new Godot build causes the performance issues, since i didnt do the changes myself.

I just wanted to let you guys know, something went wrong.

@Calinou working on my game pretty much 24/7. Just passing by to tell - there are some problems. I can surely try out the other RCs though and tell you how it went.

[clayjohn]

Thank you.

In order for us to help you we need to be able to pinpoint what went wrong. This typically requires, at the very least, an MRP. But if you can test multiple releases and pinpoint which release caused the regression we may be able to deduce what is causing your performance issue.

Right now we can't really do anything at all which is unfortunate for everyone.

[Reapetitive]

Ok, so ive just tested rc1-3. Same issue.

[clayjohn]

Thank you!

So that means the issue like came in between 3.2.2 and RC1.

[Reapetitive]

@clayjohn i also tested 3.2.3 beta 1 just now, same issues there too

[akien-mga]

Changes between 3.2.2 and 3.2.3 beta 1: https://github.com/godotengine/godot/compare/3.2.2-stable...89f57ae12244f3269c9e3fe4684e16ec1fd2c989

As others mentioned, without having access to any scene that can reproduce the issue, we can't debug further ourselves, so we'll need your help to dig deeper. If you can share the project privately with some contributors, or extract one of the heavy scenes in a standalone project you could share, this would help a ton to pinpoint the regression.

Can you use the engine profiler to see what is taking up frame time in 3.2.3 beta 1 that wasn't doing it in 3.2.2?

Alternatively, if you can compile the engine from source, can you bisect between 3.2.2-stable and 89f57ae12244f3269c9e3fe4684e16ec1fd2c989 (the commit for 3.2.3 beta 1)?

What kind of features do you use for rendering and physics? (CC @madmiraal as there are a couple 2D physics changes in 3.2.3 beta 1 like de284ea5d22b2d5ca15dd22be993afe1b04c4f7c.)

[Reapetitive]

@akien-mga according to the profiler, physics time, audio thread, physics process and my own physics functions, which determine when objects should move and when not etc, have higher frame times compaired to 3.2.2.

For physics i pretty much only use kinematic objects 2D -> move_and_slide and the only heavy thing i use for rendering are lights2d. The amount of physics objects which are moved at once can be pretty high though, dozens of them, sometimes up to around 100.

Generally the game is pretty well optimized and doesn't usually dipp below 50 fps even on weak pcs, on my pc it runs between 90-400 fps for the most time.

Thanks to the test i just did for the performance comparison between the Godot builds i was able to optimise some more and squeez out around 15 more fps on the lowest frames. :)

[Reapetitive]

So, after some hours of testing i could narrow the issue down to one element. Those press machines you see in the gifs. When the animations are playing i get horrible fps, as soon as they stop fps just skyrocket. I tested a lot of other stuff and places in the game on 3.2.3 rc4. Overlall the performance seems decent, maybe even better compaired to 3.2.2. I thought the problem might be in the particle effect, and turned them down a huge amount. No luck though.

[Reapetitive]

I think the issue might be the audio.

As you can see, the animations of those press machines play multiple sounds. The room contains around 80 of them.

[Reapetitive]

Hmm, well i guess it had something to do with collisions, i tested another Room, with around 40 of those press machines, and had good-great fps over there on 3.2.3 rc4. So i started optimizing and reworking the scene of press machine, since i realized, the only big diffirence between those rooms was, that in one room the machines were hitting against tilemaps, mostly not even touching them, while in the room with poor performance, they were hitting towards each other. So i slapped two flyes with one hit, i fixed the collision problems of objects that are being pressed by them AND it fixed the performance issues on 3.2.3 rc4. So the performance issues definitely have something to do with the physics changes.

Edit: well, nope. I generally optimised my game even better through testing, but after running the same room on 3.2.2 again, i see a gap of 30-40 fps between it and RC4. :'(

[madmiraal]

there are a couple 2D physics changes in 3.2.3 beta 1 like de284ea.

de284ea ensures that changes to collision layers and collision masks are applied. Are you making a lot of changes to collision layers and collision masks?

[madmiraal]

The only other physics 2D change I can find is ccdfaf2, which removes items from the Area callback list one at a time instead of all together. Do you have a lot of Area2Ds that the KinematicBody2Ds (or other Area2Ds) are entering and leaving?

[Reapetitive]

@madmiraal i pretty much don't change collision layers/masks. Yes, i do have a huge amount of Area2Ds hanging on KinematicBody2Ds as an extra detection layer for some stuff. Pretty much every object, especially player, uses a ton of Area2Ds and RayCast2Ds for diffirent puposes.

[madmiraal]

It would be surprising if Map::erase() was that inefficient that it was the source of the problem. It would require a lot of Areas or Bodys entering and leaving each Area each frame, and it's no less efficient than Map::insert() that is ultimately used to add them each frame.

Still, replacing monitored_areas and monitored_bodies' Maps with Lists, would make it faster, and List would be a better data structure for these queues. However, that will require a bit of refactoring, because Area2DSW::BodyKey and Area2DSW::BodyState would need to be merged.

[Reapetitive]

@madmiraal Thank you! I keep looking on my side, i will keep you up to date. To be honest, my project might be a little bit unusual, the player controls so many objects at once, collisions and other things occure like crazy everywhere, im actually pleasantly surprised, how well the engine handles it overall, and how much i can get out of it. Still have to optimise a ton though. At around 80+ Kinematic Bodies, fully packed with particles, sounds and Area2Ds etc, when the player starts moving them around like crazy, especially when dozens of objects cluster on a close space (same islands), fps goes to hell, even in 3.2.2. It might be because of the Area2Ds attached to the KBs, no idea, but i will surely try detaching the Area2Ds and reorganizing the functionalities they managed.

[Reapetitive]

@madmiraal @akien-mga so, i reworked my base physics scene and removed the base Area2D, that checked a lot of stuff. Now the room gives me around 90-130 fps on RC4, still, there are 160+ Area2Ds in this room alone and 3.2.2 gives me around 20 FPS more.

[Ranoller]

I test with my own project. Is a bullet hell - twin stick shooter in a advanced development state with 3.2.2 and 3.2.3 RC4. I can have 1000 bullets on screen, a ton of characters with a large scene trees.... same fps in both versions (more or less, some randomized things don´t allow me to measure fps between different gameplays)

• I use several tilemaps with collisions in every level scene, animated textures inside that tilemaps, Y-Sort, KinematicBody2D, CanvasLayer, Label, RichTextLabel with RichTextEffect, Area2D (with polygons and shapes), Navigation2D, Raycast2D, Sprite, AnimatedSprite, AudioStreamPlayer2D, one unique "add" canvas material and other common things .....

• I never use for performance reasons: Light2D with a mode different that "mix", Particles and any Environment. I think that i do not draw any Polygon2D but i´m not sure now, the project is sized barely out of my control and can have any polygon in some scene made time ago. I do not use any Shader.

My project is GLES2, only GDScript. Using batch rendering, single thread for rendering and single thread for physics, nvidia rect flicker workaround -> on, pixel snap, no filter in shadows (I do not use shadows), no other filters, no hdr.

Opening the project in 3.2.2 and 3.2.3 RC4 has not made any automatic change in project.godot or other file, so i don´t need to revert any git change (in case someone else is encouraged to try the new versions with their project to test performance changes).

I can confirm that a project with the characteristics I describe above doesn´t have any measurable performance regression between 3.2.2 and 3.2.3 RC4. I can maintain (inside a "bullet shower" with a node count of +2000 nodes in scene) 200-400 fps in a i5-3330CPU 3.00GHZ (2015) and 100 fps in a i3 lenovo laptop. Tested in 3.2.2-stable and 3.2.3 RC4 compilation from godotengine.org. Tested in windows 7 64 bit.

[Reapetitive]

I do indeed use world environment, a lot of shading and polygons2D, some of them have pretty high complexity. HDR, shadows, filters. Everything on. The Lights2D with shadows and filtering have the highest performance impact atm indeed, plus there is no batching in GLES3 yet, as far as i know, so the drawcalls can skyrocket to like 10k. Around 20k nodes per scene here.

[akien-mga]

Is this still reproducible in 3.2.4 beta 3?

[Reapetitive]

I just tested 3.2.2, 3.2.3 stable and 3.2.4 beta 3

around 270 fps, 230 fps, 100 fps... same location

3.2.3 is around 30-40 fps lower than 3.2.2, 3.2.4 beta 3 destroys the performance completely.

like 1/3 of the fps everywhere, tried with batching on and off, pretty much no diffirence.

I reworked my game to be open world and use a chunk system instead of huge levels btw.

Do i have to test some specific thing, that might interest you?

[Calinou]

@Reapetitive You could compile debug builds of 3.2.2, 3.2.3 and 3.2.4beta3 and compare what takes the most CPU time using a profiler such as VerySleepy.

[akien-mga]

Thanks for testing! It's concerning that performance keeps worsening for you, but thankfully it's not an experience that many users seem to have, so it might be well constrained to a specific feature that you're using. We just need to narrow it (or them) down and see how to solve the performance regression.

So far you identified:

• Small performance regression between 3.2.2-stable and 3.2.3-beta1 (30-40 fps). For this one it's not clear to me yet if it's due to an actual engine change or to a buildsystem change (we might have for example used a newer compiler version for 3.2.3, I'd have to check). I could try to redo builds of 3.2.2-stable and 3.2.3-beta1 with the exact same toolchain and options to be sure that we're comparing similar circumstances.

• Huge performance regression between 3.2.3-stable and 3.2.4-beta3 (130 fps), that's quite concerning. Could you try 3.2.4-beta1 and beta2 too to see if you can narrow down which one is the first bad version? (Likely beta1 as there was a lot of dev work between 3.2.3-stable and 3.2.4-beta1). If you don't have time/possibility to try an actual Git bisect to go further, I could likely make a few test builds between 3.2.3-stable and the first identified bad beta version to narrow further down.

Alternatively, if you're willing to share a private copy of your project source with me (which I would of course not share further, and delete once done with debugging), I could do a Git bisect to identify what commit(s) caused the regression(s) you're experiencing (provided that I can reproduce the issue on my hardware/OSes).

[Reapetitive]

3.2.4 beta 1 has the same issues.

[Reapetitive]

@akien-mga 3.2.4 beta 4 too

[akien-mga]

For the reference, I tried on my main laptop with a copy of @Reapetitive's project that they shared privately, but from a quick test couldn't identify a major performance drop between 3.2.3-stable and 3.2.4-beta1 or 3.2.4-beta4. I did have wildly fluctuating performance in all builds due to the use of taxing lighting features.

Machine specs:

System:    Host: cauldron Kernel: 5.10.4-desktop-3.mga8 x86_64 bits: 64 Desktop: KDE Plasma 5.20.4 Distro: Mageia 8 mga8 
CPU:       Info: Quad Core model: Intel Core i7-8705G bits: 64 type: MT MCP L2 cache: 8 MiB 
           Speed: 2509 MHz min/max: 800/3100 MHz Core speeds (MHz): 1: 2509 2: 3020 3: 2449 4: 2663 5: 2909 6: 2474 7: 2666 
           8: 2408 
Graphics:  Device-1: Intel HD Graphics 630 driver: i915 v: kernel 
           Device-2: Advanced Micro Devices [AMD/ATI] Polaris 22 XL [Radeon RX Vega M GL] driver: amdgpu v: kernel 
           Device-3: Cheng Uei Precision Industry (Foxlink) HP Wide Vision FHD Camera type: USB driver: uvcvideo 
           Display: x11 server: Mageia X.org 1.20.10 driver: intel,v4l resolution: 1920x1080 
           OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 20.3.2

I still intend to try again on a more powerful machine to see if I can find anything more concrete that could be used to pinpoint a potential regression commit.

[Reapetitive]

@akien-mga i played around with project settings and graphics card driver settings, hoping it might have some impact on how the 3.2.4 performs, without any luck. I still experience the same huge performance decrease. Might it just be an issue with Nvidia Geforce cards? I tested the build on gtx 1070 and rtx 3070.

[Reapetitive]

@akien-mga 3.2.4 beta 5 performance is horrible. :'D Might be even worse, than previous betas. There is literally a very simple spot, where i get around 160 fps on 3.2.3 and around 30 fps on 3.2.4 beta 5.

[Reapetitive]

@akien-mga i guess it has something to do with the rendering, it seems like the more shaders are on the screen, the higher is the diffirence in performance to 3.2.3. Like i said before, there is a spot, where pretty much nothing is going on, except for shaded sprites, light2Ds and lightoccluder2Ds - 30 fps instead of 160 (which is already pretty low, without light2Ds i get around 350 fps on 3.2.3).

[Calinou]

160 (which is already pretty low, without light2Ds i get around 350 fps on 3.2.3).

The difference between 160 FPS (6.25 mspf) and 350 FPS (2.86 mspf) in terms of time taken per frame is actually not that large. When comparing graphics rendering algorithms, you should always compare in mspf (milliseconds per frame) rather than frames per second. It's a more reliable, less biased way to compare performance since it doesn't have the non-linear issue that FPS measurements have.

[lawnjelly]

If you try running your game with a postage stamp sized window, and the frame rate increases drastically, this will let us know whether you are fill rate limited (e.g. by 2d lights).

But there is very little info to go on. Your problem could be caused by anything - physics, rendering, audio, build etc etc.

[Reapetitive]

@Calinou Sure, you are definitely right. Still, 160 fps for a relatively simple 2D game, that is already pretty well optimized, in a spot, where literally nothing happens, except for 1 light and some pretty low cost shaders, on a PC that runs every hardware devouring game at 100+ fps in 1440p (rtx 3070 meanwhile), is pretty damn poor. That was my point, not the comparison between 160 and 350 fps in a linear way. I just really hope to see a huge performance lift with later Godot releases, not a decrease, after decrease. A good clarification for people who didn't know still, thank you.

@lawnjelly Tiny window, or full screen 1440p, no diffirence. 3.2.4 since beta 1 just runs really bad. The game uses a chunk system and optimization for pretty much every tiny thing, it disables processes, makes things stop emitting, go invisible, get freed etc etc, when they aren't needed. As i am actively building the world of the game right now, i am able to test every aspect and element of it pretty well, performance wize. I have no idea, what changed between 3.2.3 and 3.2.4 beta 1, but it ruined the performance, so @akien-mga has a little bit older build of my project to test/bisect. What i can see right now, that in a spot, where script time is 1 ms, physics time around 2 ms, audio 1-2 ms (only 1 type of looped sound is playing), i get 30 fps. No ai is active, pretty much no processes are running. It has to be the rendering, from my uneducated guess.

[clayjohn]

@Reapetitive the fact that changing the window size did not change performance rules out a "fill-rate" bottleneck. A fill rate bottleneck means that your performance issue is the result of slow rendering from complex shaders or too many lights.

What this means is we need to look elsewhere, your bottleneck could be in script performance, audio, physics etc. Regarding rendering, it could be a CPU bottleneck due to too many draw calls (turning batching off and on would help to identify if this is the case), it could be a memory bottleneck (this can be the case when you use many large textures without mipmaps or other optimizations)

Edit: also consider differences in your testing environment, I notice that you have upgraded to a much faster GPU recently, with a change in GPU comes a change in other hardware and in GPU drivers. It is helpful for us if you can isolate the performance regression using the same drivers and the same hardware, the only variable that changes should be the version of Godot that you use.

Without access to a test scene others can't help you right now and you will have to do the work yourself.

As a side note, the majority of users have seen huge performance increases in recent releases due to the improvements to batching (especially with batching being added to GLES3). The fact that you see such stark decreases in performance points to there being something unique about your project that isn't in other projects. If you can figure out what that is, then it is very likely that someone can find a solution for you.

[Reapetitive]

@clayjohn Ok, thanks for the clarification. I also tested batching, no diffirence. Memory is fine too, at least according to monitoring etc. I tested it before upgrading the gpu, and after, with various drivers, and driver setups. No luck so far.

[Reapetitive]

Ok, i loaded up the game and created a scene with just a spawnpoint for the player, ran it. 0 ms script, 0.1 ms audio, 0 ms physics. 150 fps on 3.2.4 beta 6, around 500 fps on 3.2.3. Even while profiling, frame time shows up as around 3 ms, ocasionally jumping up to 7 ms, yet fps are at 150... I removed everything except for hud, menu and the player. Interesting fact: the player character has two basic modes, one of them uses four tiny Lines2D. I lose 10 Fps, when they appear. So i thought, it might be something as simple as that, and tried turning visibility of tiny polygon2Ds on the player off. And what would you think? Back at 500 fps. The spot that gave me 30 fps instead of 160 has a lot of shaded polygon2Ds in it, some of them have a big amount of points. Tested the spot and turned the polygons visibility off - 160 fps (with players polygons still turned on). I guess, when there is a problem, that might be fixed in it, overall performance should have a huge step up also for my project with 3.2.4. Seems to be a huge update. Thank you for your hard work guys!

[Zireael07]

Wasn't there an open issue about polygon2d's being a rendering bottleneck? I don't recall if that was fixed or not...

[lawnjelly]

Wasn't there an open issue about polygon2d's being a rendering bottleneck? I don't recall if that was fixed or not...

I seem to remember batching them (in 3.2.4) but I have a feeling there is some that cannot be batched (using anti aliasing I think it was). Simply turning off anti-aliasing for these polys may help with performance if this is the problem.

[Reapetitive]

@lawnjelly Indeed, turning AA off does help, it didnt eliminate the performance hit completely it seems, but it brought frame time down just enough, down to 1/3. But... i really want to use the AA. I guess, i can expect it to be fixed some time in the future? Or is there no way to combine batching and polygon AA?

[Calinou]

But... i really want to use the AA. I guess, i can expect it to be fixed some time in the future? Or is there no way to combine batching and polygon AA?

You could use Polygon2Ds with a specially crafted filtered texture applied to achieve antialiasing. You'd have to generate a proper UV map for them so that the texture's edges can be mapped to the polygon's edges though.

With Line2D, this is easy to achieve as UV mapping is handled for you out of the box.

[lawnjelly]

There's no easy way to combine (per poly) anti aliasing with poly batching, as for anti aliasing it draws lines around the edge of the poly with GL_HINT_SMOOTH. Once you batch a bunch of polys together, there is no longer a concept of an edge. I'm not planning on trying to fix it in the near future.

Also note that anti-aliasing is a GL hint only, it is not guaranteed to work, and isn't even requested on non-desktop platforms (where GLES_OVER_GL is not defined).

You could also use fullscreen anti aliasing etc. EDIT : Ah it seems you may not be able to in 2d, see Calinou later post.

[Reapetitive]

@Calinou @lawnjelly Thank you guys! I will adjust to it. Might aswell use sprites and tell shaders to draw only where the texture is visible, or just go without AA. I already tried full screen AA, at least FXAA. Didnt do much. Gonna try MSAA. Edit: MSAA doesnt work in my cases too. Edit nr.2: the complexity of a polygon/amount of points has a huuuuuge impact on perf. Simplified three polygons of an asset, fps jumped from 50 to 250 in one spot. I guess i can let it be for the time being, the game has a long way to go anyway, gotta wait for what the future has to offer. :P

[Calinou]

Might aswell use sprites and tell shaders to draw only where the texture is visible, or just go without AA. I already tried full screen AA, at least FXAA. Didnt do much.

FXAA only affects 3D. It's not designed to work in 2D as it'll make everything blurry without much benefit.

MSAA also only affects 3D for now, although this could be changed for 4.0.

The only full-scene antialiasing method that works in 2D right now is supersampling, which is the most demanding method out there. See the 3D Viewport Scaling demo for an example (it also works in 2D).

[Reapetitive]

@lawnjelly can't we potentially have an option to exclude Polygon2D from batching? It would potenitally allow to use some Polygon2Ds with AA, while still batching the rest. After some testing with and without batching, i see a good performance improvement without antialiasing on polygons and if the polygons have low points count. But when i turn batching off, i get around 1/4 of the FPS compared to 3.2.3. Seems kind of wierd to me.

A new thing i discovered yesterday - screen_texture/ImageTexture of Viewport based shaders seem to behave really wierd too. I am using a shader to add reflections of the world to glass etc. Sometimes i use Polygon2Ds to apply the shader to, sometimes Sprites. Polygon2Ds seem to display the shader result pretty well, while Sprites flicker around and display objects sporadically. Increasing the Z_Index of the sprite helps, but doesnt resolve the issue. I ve been having an issue with screen_texture not displaying everything on screen properly anyway, even while using Backbuffer Copy. So i assigned ImageTexture of Viewport to a shader variable through script. But this workaround seems to be half broken now too.

[akien-mga]

But when i turn batching off, i get around 1/4 of the FPS compared to 3.2.3. Seems kind of wierd to me.

3.2.3 also had batching for GLES3 enabled by default, but the setting name was different. If you turn it off in 3.2.4 beta 6, and test in 3.2.3 without also turning it off there, you're comparing GLES3 no batching (3.2.4) to GLES3 batching (3.2.3).

But indeed it might be that batching in 3.2.3 did not handle AA properly, and the fact that it now does hits performance for your use case.

[lawnjelly]

@lawnjelly can't we potentially have an option to exclude Polygon2D from batching? It would potenitally allow to use some Polygon2Ds with AA, while still batching the rest.

This is exactly how it currently works. Any polys with AA are rendered via the legacy renderer (providing you are running on a platform with GLES_OVER_GL, in other platforms such as mobile, there is no anti aliased polys).

After some testing with and without batching, i see a good performance improvement without antialiasing on polygons and if the polygons have low points count.

Yes the legacy polygon rendering is very slow, so reducing the number of polys / number of points will increase performance.

But when i turn batching off, i get around 1/4 of the FPS compared to 3.2.3. Seems kind of wierd to me.

That is interesting, but as Akien says you may not be comparing like with like. I can't say without examining your project. In theory when turning batching off you should get a similar rendering performance to e.g. 3.2.1, but there could be some other difference between the presets (perhaps to fix a bug).

The long and short is though, that anti-aliased polys is not something Godot currently does well for games, and I wouldn't recommend its use except for small numbers. The AA won't appear outside of desktop anyway, and could be very slow on some platforms.

[Reapetitive]

A new thing i discovered yesterday - screen_texture/ImageTexture of Viewport based shaders seem to behave really wierd too. I am using a shader to add reflections of the world to glass etc. Sometimes i use Polygon2Ds to apply the shader to, sometimes Sprites. Polygon2Ds seem to display the shader result pretty well, while Sprites flicker around and display objects sporadically. Increasing the Z_Index of the sprite helps, but doesnt resolve the issue. I ve been having an issue with screen_texture not displaying everything on screen properly anyway, even while using Backbuffer Copy. So i assigned ImageTexture of Viewport to a shader variable through script. But this workaround seems to be half broken now too.

Seems to be fixed by using textureLod instead of texture (in combination with increased z_index)!

[Reapetitive]

A new thing i discovered yesterday - screen_texture/ImageTexture of Viewport based shaders seem to behave really wierd too. I am using a shader to add reflections of the world to glass etc. Sometimes i use Polygon2Ds to apply the shader to, sometimes Sprites. Polygon2Ds seem to display the shader result pretty well, while Sprites flicker around and display objects sporadically. Increasing the Z_Index of the sprite helps, but doesnt resolve the issue. I ve been having an issue with screen_texture not displaying everything on screen properly anyway, even while using Backbuffer Copy. So i assigned ImageTexture of Viewport to a shader variable through script. But this workaround seems to be half broken now too.

Seems to be fixed by using textureLod instead of texture (in combination with increased z_index)!

Seems to be working with normal SCREEN_TEXTURE instead of the work around with ViewportTexture set in a uniform now. :)

[Reapetitive]

@lawnjelly @akien-mga any idea what might hit the rendering performance in the rc3? 30 fps most of the time, instead of 200. Fun fact, the performance normalized itself twice, without me doing anything, seemingly random. But every time i start the game, it is horrible again.

[lawnjelly]

@lawnjelly @akien-mga any idea what might hit the rendering performance in the rc3? 30 fps most of the time, instead of 200. Fun fact, the performance normalized itself twice, without me doing anything, seemingly random. But every time i start the game, it is horrible again.

To be clear, did you get 200fps in RC2 and 30fps in RC3? When did the performance regression start in terms of betas / RCs? There have only been a limited number of changes e.g. between RC2 and RC3.