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 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.
I'd say it depends on whether the content is already premade when you drag it over into your project, or whether you're outsourcing some of the work, but obv. outsourcing is it's own issue with it's own set of potential problems. The thing that gets me is that the design briefs and constraints / requirements stated therein that are shipped out to third parties are often beyond lacklustre when it comes to actually stating important key aspects (design in terms of asset scales or so, and technical stuff, like data formats or so) that are important to get the third party content to play nice in people's projects from the get-go. With already premade stuff? Yeah no thanks, you should only use that for prototyping / pitching / vertical slice kinda deals. I'm currently working for a game dev studio, in QA, where I constantly see the same problems crop up in third party assets we get sent over, and these issues often only get picked up at the QA-ing phase because besides there not being a thorough enough tech. art assessment of new assets before implementation, there's no process in place to collate and assess all these issues and formulate better standard briefs we send out to outsource, alongside not having a dedicated outsourcing producer (or at least someone that has that as one of their core duties, alongside others) that can assist in doing so. And of course, that ends up creating loads of problems with new assets in the game that then have to be fixed up, sometimes by people that haven't yet dealt with that specific issue and / or don't know important details regarding our project relevant to the fix they need to implement, leading to a sense of constantly having to reinvent the wheel and "discover" the same tribal information after a couple of rounds of a ticket going back and forth between QA / art / dev. It's infuriating, and could be headed off 90% of the time by better briefs being sent out to outsource, with very specific requirements and constraints - not to excuse the other steps in this process that could also be shored up and improved. It probably won't surprise you to know that I've already suggested being that outsource producer to our project lead, having had experience in IT process management before as well.
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.
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?
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)
@@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.
@@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.
@@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).
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".
Third Party assets have their place in my opinion. It just has to be dealt with care to avoid the said content debt.
@@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.
I'd say it depends on whether the content is already premade when you drag it over into your project, or whether you're outsourcing some of the work, but obv. outsourcing is it's own issue with it's own set of potential problems. The thing that gets me is that the design briefs and constraints / requirements stated therein that are shipped out to third parties are often beyond lacklustre when it comes to actually stating important key aspects (design in terms of asset scales or so, and technical stuff, like data formats or so) that are important to get the third party content to play nice in people's projects from the get-go. With already premade stuff? Yeah no thanks, you should only use that for prototyping / pitching / vertical slice kinda deals.
I'm currently working for a game dev studio, in QA, where I constantly see the same problems crop up in third party assets we get sent over, and these issues often only get picked up at the QA-ing phase because besides there not being a thorough enough tech. art assessment of new assets before implementation, there's no process in place to collate and assess all these issues and formulate better standard briefs we send out to outsource, alongside not having a dedicated outsourcing producer (or at least someone that has that as one of their core duties, alongside others) that can assist in doing so. And of course, that ends up creating loads of problems with new assets in the game that then have to be fixed up, sometimes by people that haven't yet dealt with that specific issue and / or don't know important details regarding our project relevant to the fix they need to implement, leading to a sense of constantly having to reinvent the wheel and "discover" the same tribal information after a couple of rounds of a ticket going back and forth between QA / art / dev. It's infuriating, and could be headed off 90% of the time by better briefs being sent out to outsource, with very specific requirements and constraints - not to excuse the other steps in this process that could also be shored up and improved.
It probably won't surprise you to know that I've already suggested being that outsource producer to our project lead, having had experience in IT process management before as well.
Some really helpful info in this talk, thanks for that.
this is going to be awesome. original serious sam was ground breaking... thanks for doing this.
The Talos Principle is the most underrated Game. It will alter one's way of thinking about life.
great stuff
Fantastic talk! Are the slides available? Some of the screenshots would be helpful to see in higher resolution.
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.
Does anyone have any resources on the VSM Behavior Control he mentions @42:00? Is that a per-material or per-object setting?
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?
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)
@@TomislavBozicDev
I see, thank you for the comprehensive explanation. Great speech and very interesting topic indeed!
@@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.
@@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.
@@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).
Hey Unreal Engine can u pls Pin Me
Extremely unpleasant person. Too much of an ego-shower. Ugh.
I’m listening right now, and I’m not sure what you mean? He seems fine at the moment
It's not ego it's called knowledge. But you have to have some to recognise it in others
He seems like a nice guy and he was willing to put together this presentation and share it with everyone. Show some respect, cat avatar.
I think maybe it's just you projecting.. he seems ok to be. 🤷
@@Cloroqx nope