Obscure Techniques for Better Development Experience and Visual Candy

Obscure Techniques for Better Development Experience and Visual Candy | Unreal Fest 2024

Рет қаралды 17,552

Күн бұрын

Пікірлер: 24

@BradfordSmith3D 3 ай бұрын

The third party content conundrum is often mis-understood during the early production phases, and I'm so glad to see this discussed. The truth is, that third party content generally doesn't scale, creates lots of content debt, and often can't be fixed easily (due to lack of source, or lower overall quality of source). To me, the over-reliance on 3rd party / marketplace data reminds of the saying "Buy cheap, buy twice".

@TomislavBozicDev 3 ай бұрын

Third Party assets have their place in my opinion. It just has to be dealt with care to avoid the said content debt.

@Cloroqx 3 ай бұрын

@@TomislavBozicDev Making an Exclude folder from the begining is one of the best ideas. If you need Marketplace assets (like Ultradynamic Sky), have them in an Exclude folder, do your edits and integration there, and then move to production folders.

@nfarquhar 3 ай бұрын

Some really helpful info in this talk, thanks for that.

@Ready_Fire_Aim 3 ай бұрын

this is going to be awesome. original serious sam was ground breaking... thanks for doing this.

@DanGant 3 ай бұрын

Fantastic talk! Are the slides available? Some of the screenshots would be helpful to see in higher resolution.

@rossknowles5608 3 ай бұрын

great stuff

@aloluk 3 ай бұрын

For your problem of only wanting your own materials in a build, where you made the output pink, and you found some still were cooking when very near shipping. It would have been fairly straight forward to implement an automation test on your packaged builds to verify your materials. So you'd never need to even run the build to find them. Jiras can auto be created for the people that created the materials to fix them.

@kennyn886 3 ай бұрын

Does anyone have any resources on the VSM Behavior Control he mentions @42:00? Is that a per-material or per-object setting?

@mingyenwu9621 3 ай бұрын

44:10 If WP streaming is disabled, doesn't that mean the entire level will be loaded upon game start? How is that not impacting performance? I'm a bit confused - is he talking about rendering performance or loading time performance? Surely the application will have a longer loading time if streaming is disabled?

@TomislavBozicDev 3 ай бұрын

In theory, all the actors in the level are loaded. Although 99% of our meshes were Nanite which are extremely efficient in rendering on the GPU, and the number of actors was, I guess, low enough not to cause Initview or SceneRendering performance issues. Another thing is that all of our foliage was rendered with HISMs, with, of course, appropriate culling distances set. You could say that setup is not as optimal as a "proper" WP, but in our testing, with heavily optimized content, it made no difference. I assume that larger worlds, with 10s of thousands of actors, even 100s, would require WP for streaming, but for out levels, it appeared not to be necessary. (For full disclosure, main Talos Principle 2 levels use WP streaming with HLODs, but our Road to Elysium DLC levels DO NOT use streaming - but are still WP levels)

@mingyenwu9621 3 ай бұрын

@@TomislavBozicDev I see, thank you for the comprehensive explanation. Great speech and very interesting topic indeed!

@Fafhrd42 3 ай бұрын

@@TomislavBozicDev I'd guess it's less to do with low actor count than low unique asset count. If you're re-using a lot of the same textures and meshes you can have thousands of instances loaded in the world at once and won't see much difference in overall memory use, and if streaming is disabled you're also not taking the game thread hit from actor creation and destruction as you walk around the world loading the different cells. I haven't played Talos II, so I can't make an educated guess on your world sizes, but I'd guess that disabling streaming probably isn't going to scale super well to larger worlds and/or higher resolution landscapes.

@shannenmr 3 ай бұрын

@@TomislavBozicDev I assume you still optimised the distance based culling of most objects (especially smaller ones) via culling volumes / manual settings but as you said you ultimately didn't have too many Actors/Mesh's where that culling impacted your CPU performance too much. If you are using a lot of highly modular meshes having the ability to automatically swap them to HLOD's along with using the HLOD for the shadows proxy instead (especially if they end up being large/casting large shadows) can also be a good reason to continue to use the system fully.

@tommyjackson111 3 ай бұрын

@@shannenmr Aside from foliage and landscape grass that has its own distance culling, we never used culling volumes or set culling distances individually on actors. We might've gotten some more performance out of it, never did any experiments to confirm that, but I guess Nanite was really helpful there so we didn't need to apply that on our levels. Generally, for Talos2, it appeard as WP streaming wasn't useful that much, but really depends on the needs of individual projects. Remember, HLODs themselves incur their own memory and disk space cost, aside from being really annoying to work with (plenty of problems with various merging methods for HLOD).