Refactor Application.cpp

[HifiExperiments]

Closes #931

(apologies to whoever reviews this)

Application.cpp has gotten totally out of control over the years (in many cases because of my dumb decisions). This is an attempt to corral it. I've organized the code as best I could into sections - Assets, Camera, Entities, Events, Graphics, Plugins, Setup, and UI - and divided the implementations into separate, smaller files. I completely rebuilt the includes from scratch so we only have what's necessary. I broke some of the classes into their own files. Overall, I changed very little functionally. I removed a few unused variables and functions but nearly everything is directly copy-pasted.

Testing-wise, things should just work as before. In particular, anything related to startup, login UI, and plugins.

Funding

This project is funded through NGI0 Entrust, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.

[HifiExperiments]

oh yeah @daleglass it didn't look like this was ever set to true, so I deleted it + the one place it was used, is that ok?

[daleglass]

Oops, that looks like something I screwed up.

Memory is a bit rusty right now about why I added that, but I take it PROFILE_RANGE_IF_LONGER and similar are not safe to call before some sort of initialization is done, so a _profilingInitialized=true; is supposed to go somewhere in the startup code after some profiling system init code is called.

[HifiExperiments]

it seemed to be working ok for me without it, maybe if it's a problem during testing I can add it back?

[daleglass]

Sure, it's simple enough that it'd be easy. I did quite a lot of rearranging of that code, and right now can't recall if maybe I just fixed this in some other way in the end.

[HifiExperiments]

hm

/__w/overte/overte/interface/src/scripting/PerformanceScriptingInterface.cpp:14:10: fatal error: QtQML: No such file or directory
   14 | #include <QtQML>
      |          ^~~~~~~

I'll look into that...

[ksuprynowicz]

This is really awesome :)
Application.cpp needed refactoring badly and this will make future work a lot easier.
I didn't find any problems, but I have few questions and I found what I think is earlier thread safety issue in the code.

[ksuprynowicz]

In some places, for example in EntitySendThread there's withReadLock around findEntityID call. getEntityModelProvider is called from Graphics.canUpdateModel so it can be called from any script engine thread. I wonder if it needs a lock here.

[ksuprynowicz]

Maybe as a later PR we should do a thread safety audit of all the places where entity tree is used?

[HifiExperiments]

oh wow great catch. EntityTree::findEntityByID actually calls EntityTree::findEntityByEntityItemID which does internally use a read lock, but then EntityTreeRenderer::renderableForEntityId looks like it needs it? I filed #1015

[ksuprynowicz]

Do jsdoc config files need to be updated to point to new files?

[HifiExperiments]

huh maybe? how do I do that?

[ksuprynowicz]

I'm also having trouble building it on Linux using Overte-builder:

[ksuprynowicz]

I tested it on Windows, and it asks to log in every time. A different than usual login screen is used for this:

Kraftwerk world becomes entirely white after skybox loads:

No audio devices are detected:

[ksuprynowicz]

It also seems that login screen that it uses in VR is intended for desktop?

[ksuprynowicz]

The good thing about that different login screen though is that it has option to continue anonymously. Ours is badly missing this.

[HifiExperiments]

I believe I've fixed the audio device issue. for the login screen, it turns out I had accidentally deleted _disableLoginScreen which was always set to true. so whatever that fullscreen login page was for, it appears to have been disabled intentionally at some point. I've re-disabled it to just avoid messing with stuff, but maybe we should look into re-enabling it properly at some point. I'm not sure if this also fixed the VR login screen, if that's still a problem could you send me a screenshot?

I wasn't able to reproduce the issue in kraftwerk; I wonder if the download got corrupted or something? does it still happen if you clear your caches, including ktx cache?

[JulianGro]

I gave this a test on Linux and so far, everything works fine. I tried clearing shader cache and ktx cache as well. In both scenarios, Kraftwerk renders properly.

[ksuprynowicz]

I tested it again and now everything works well :)

[ksuprynowicz]

Would someone like to test in VR on Windows? I don't have a VR setup at the moment. If all works well we could merge it.

[HifiExperiments]

there are some conflicts now, I’ll probably wait until after the next release to rebase and resolve them just to avoid causing any problems

[Armored-Dragon]

Would someone like to test in VR on Windows? I don't have a VR setup at the moment. If all works well we could merge it.

I did some brief testing in VR and everything seems to work as expected.

there are some conflicts now, I’ll probably wait until after the next release to rebase and resolve them just to avoid causing any problems

I will also take a look at this again after the rebase!

[HifiExperiments]

I've rebased this and it's all ready to be reviewed + tested again!