Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

I guess that might not work in games as well as we'd hope though. In real life you might see the same brands of cans or bags, but they'll be in different states of crumpledness. Seeing the same can with exactly the same distortions might, maybe, start to be recognised across games.
Not really a serious concern. The maginal benefit for small clutter is so small -- a few dozen or hundred players might see it and say "oh, that's funny" -- is that worth $300-1000 to avoid? Or even $20 in a hypothetical AI workflow case? Surely there is something better an artist could spend a day on than selecting a different library asset or re-texturing a bag.

(Would be cool to me if we simmed a lot more of this stuff though. I'd love if asset packs moved towards a default posed bag and physics presets that you're expected to generate a crumple for, for your game or scene.)
 
i don't mind reuse of assets if that means higher level of details in games, and make the worlds a lot more believable.
Maybe 1% of players do like me and look around all the little details in pure enjoyement.
i played through Robocop in 30fps mode and started a new game plus in 60fps mode, and i'm happy to see that the level of details seems to have remained the same, just at a little lower resolution.

matrix awakens/robocop
 

Attachments

  • matrix.jpg
    matrix.jpg
    685.3 KB · Views: 21
  • robo1.jpg
    robo1.jpg
    676.3 KB · Views: 21
I am one of those jerks who notices the repetition in "fluff" objects in the world. I can't help it, after I've seen the 17th perfectly identical piece of clutter it starts to mildly annoy me. MIldly annoy me in the sense of I wish it were somehow different, but then I'm happy to continue playing along because so many games don't even bother with real objects for the "fluff".

I wouldn't mind a virtual world where something not so complex as AI, maybe just a basic precomputed ML algorithm could create some quantity of random permutations of the clutter objects. Misshapen in different ways, discolored, maybe it's a partial object rather than the whole object? Common examples in my head would be kitchenware in the TES and Witcher series, or the random trash in the Fallout and Cyberpunk series. There's gotta be a way to configure an arbitrary object to be able to "mutate" slightly, within certain bounds, without getting it egregiously wrong. And it doesn't need to be so burdensome as a full AI model, just an RNG and a bit of logic which allows some texture and color blending along with some vertex adjustments.

Of course, I say it must not be that hard, and yet here I am not ever gonna write such a thing :D
 
Is it? A few varying skins to wrap around the mesh, blended between eachother if that makes sense or otherwise just straight swaps, along with a "dirt" skin to blend in at varying weight, a few vertices in the mesh identified for allowing perturbation, and an RNG with weighting to make it happen.

It "feels" easy. But what do I know?
 
I'd immediately think noise. Can apply noise to deformations and multitextures to add wear. This is what I was expecting two gens ago with procedural content!! But it's better the power available now is spent more on decent lighting I think.
 
Noise is where my uneducated head went for sure. And yes, there was a period of time not so long ago in which "procedural content" was one of the bigger buzz-phrases.

I feel like the power needed for good lighting isn't the same power we'd be using for "noisy" meshes though. I mean, rastering / raytracing all of it of course needs GPU power, but the actual deformation of the mesh and decision tree on which texture(s) to apply would be a CPU process, and in fact IMO could be a pre-compute stage -- a decision which is made at the first point the instanced object in question is "materialized."
 
Yes, you'd instantiate the object and deform. Would only need to happen once, probably repeated when an area is revisited. Back in the day this was going to be enabled by compute. Given so many cores sitting unused these days, it might well be a CPU capability, to just randomise filler content. Heck, just talking about it, it sounds like a plugin. Can sit on the asset import side of a library and run some standardised noise on assets on instantiation. The actual noise functions are well understood via automation in 3D tools, so it really just needs devs to care enough to integrate them, but it's also work for no real returns; you'd have to really care. Maybe we need Kojima to make a city game?!
 
Maybe we need Kojima to make a city game?!
Given his history, there's a 50/50 chance On The Beach is only located on the beach for the first 20 minutes and the rest of the game will take place in Raiden City. And then a beach will show up in the middle for a little bit, but it will claim it's name isn't Beach, but something like CC Bloom.
 
....it really just needs devs to care enough to integrate them, but it's also work for no real returns; you'd have to really care. Maybe we need Kojima to make a city game?!
Yeah, this is really the limiting factor IMO. Why does it matter? Who is gonna notice? Are those few hundred additional lines of code and engine overhead for tracking (hundreds? thousands? more?) of discretely randomized and instanced objects really worth it?

Sounds like something Bethesda should do in TES 6 to me. When I stack eight hundred paintbrushes to get over that next invisible wall, I want them to ALL BE UNIQUE!! :D
 
Yeah, this is really the limiting factor IMO. Why does it matter? Who is gonna notice? Are those few hundred additional lines of code and engine overhead for tracking (hundreds? thousands? more?) of discretely randomized and instanced objects really worth it?

Sounds like something Bethesda should do in TES 6 to me. When I stack eight hundred paintbrushes to get over that next invisible wall, I want them to ALL BE UNIQUE!! :D
Well you also have to test and review it throughout development (to make sure your deforms look good on all your asests), you have to use either gpu time per frame or mesh memory * deform count memory or mesh size on disk * deform count disk space and streaming bandwidth (and if you're not calculating these per frame these are both the kinds of things that add stutters in worst case scenarios,) and there's a bit of a design can of worms in some cases -- in elder scrols I know all 500000 pieces of bread I see have the same marginal benefit if I eat them, will I ever be confused/frustrated/annoyed when a weird shaped bread i've never seen catches my eye and turns out to be the same item I saw a thousand times before? Will deformed items ever look confusingly similar to *other* items?

These are small problems and small costs, but they go along with a vanishingly small benefit. :)
 
Instancing is a pretty important optimization for most rendering pipelines (even offline/movies). As you make things more unique (either up front with more meshes or with dynamic deformation) things become more expensive, *especially* for things like raytracing that need to rely on heavy instancing to have a reasonable memory footprint. Kitbashing or mesh scatter implementations currently have to rely on heavy instancing with only rigid transforms changed.
 
I hadn't actually thought about instanced geometry, but of course as soon as each mesh is its own thing, you either have to have a complete copy in RAM or realtime processing of the stored model.
 
Instancing is a pretty important optimization for most rendering pipelines (even offline/movies).
This. But even before you render stuff, all art has to be reviewed by someone - both in terms of looks but also real time cost. If you don't do that, you'll end up with either odd assets that don't match but are hard to spot through gameplay (in the first case) or inch-size pebbles that have 1000 tris each (something I encountered profiling one project). This is time consuming and, by extension, costly. If you can get away with 3 different cans of soda instead of 30, you do that.

I can imagine engine that's designed to let LDs put all sorts of warped clutter in the scenes. But then you end up with a serious design problem: how do you communicate to the player that something can be interacted with when levels are so absurdly busy? If you don't - gamers will complain. If you use yellow paint - gamers will complain. You can't win. ;P
 
Back
Top