Jump to content

Recommended Posts

Am really interested to see how collisions are being handled in these insanely detailed worlds. A multiplayer game with lots of players doing collision tests against this kind of geometry must be expensive as fuck. Or they have just offloaded modelling time onto making collisions instead...

Link to post
Share on other sites
  • Replies 68
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Not yet... they really need to study what valve did with the in-editor modeling and UV'ing tools of source2. UE4 modeling system (Brush editor) is still too primitive and clunky. They need to sit

Say what? 👀 This is confirmed by Tim Sweeney to be real time footage from a playable demo captured straight from the PS5 dev kit. https://www.unrealengine.com/en-US/blog/a-first-look-at-unrea

Early renders with UE5 are ...

Posted Images

1 hour ago, Vilham said:

Am really interested to see how collisions are being handled in these insanely detailed worlds. A multiplayer game with lots of players doing collision tests against this kind of geometry must be expensive as fuck. Or they have just offloaded modelling time onto making collisions instead...

Good question. I don't see why collision couldn't be "LODable", just like the render geo is with Nanite, it's just triangles. 

Link to post
Share on other sites
1 hour ago, ┌HP┘ said:

Good question. I don't see why collision couldn't be "LODable", just like the render geo is with Nanite, it's just triangles. 

True, which is fine for something like a single player game.

Collisions generally need to be loaded in on the server at all times and is something that is tested against constantly to let the server be authoritative (assuming you don't want loads of hacking). So super complex player collisions will decrease server performance and therefore increase costs on servers (I actually think this is why the art style in games like overwatch is so good, the map effectively can be super simple in terms of collisions but still looks really good).

So I assume the player collision in these maps need to be way simpler than what is shown and the more detailed the world the more effort needs to go into authoring those collisions to maintain accuracy between collisions and visuals. Maybe their auto collision are massively improved? They aren't great in UE4, most of the time anything more complex than a cube needs a complex collision authoring for it. Or maybe they have some kind of new way of testing complex player collisions cheaply.

If not and we just have super complex geometry and super simple collisions (even with IK systems) we are going to end up with the visual fidelity not being matched by the fidelity of player movement. Going to look jank.

Edited by Vilham
Link to post
Share on other sites
6 hours ago, FMPONE said:

tldr Should they steal the brush tools and hotspot stuff? Yes of course. I can’t argue with their priorities though, they solved some big fucking problems and the performance looks totally legit

When it actually ships in a stable version.

An acquaintance has already downloaded it and said: “200gb drive, you need 32gb ram min, runs at 15fps”

~

I'm wondering is this gonna impact the Artist market, in the sense will we see lots of cinema FX people move to games, so more competition, or will lots more jobs be needed anyway to not make a difference.

Link to post
Share on other sites

Some mentions of collision and the likes here under proxy mesh category. That is the complex collision mesh, for a multiplayer game you probably want to author the collision by hand as usual.

https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/

 

Tested it out for 3 minutes. The UI is a big upgrade. Still no magnetic pin connections in node editors, guess marketplace will still be the way to go if you don´t want to practice hitscan when making materials or scripting :hurg2:

Edited by Evert
Link to post
Share on other sites

I doubt collision is going to change. It's still going to be a bunch of convex primitives attached to the geo.

Collision LODing is an interesting idea but we kind of already do it today by broad and narrow phase collision tests. Usually when you do a collision lookup with a raycast you first test against an AABB (a bounding box) and only if that broad phase passes do you attempt to do a convex hull test. Then finally, if you are crazy a third per-poly test.

For the sake of argument, if you DID really want to do a per-poly collision test on nanite level ultra-high resolution geo there are data structures that make it relatively fast. They can essentially split the high poly mesh into regions and throw out a bunch of the regions based on where the ray hits. In fact I believe Unity already does this for their per-poly collision tests because one of the build steps is to make a collision representation of a per-poly collision mesh. I'm guessing they did this because so many people kept enabling per-poly collision because they were lazy and didn't understand the implications then wonder why their CPU performance is so bad.

With these optimizations,  one of the bigger issues becomes needing a lot of memory to store all the structure in a way that can be quickly looked up.

Link to post
Share on other sites

Yeah, if they aren't making any improvements to how collisions are handled then their marketing is just that. Nanite sounds great for people making nice looking scenes. If anything making games is going to be MORE complex for the overall team as it removes a constraint that tied collisions and render together previously. Now you either have uber high res complex geometry with simple collisions which is just going to look bad in motion and gameplay (which doesn't add any more work) or this new visual fidelity is going to require you to author more complex collisions to match these unconstrained visuals (which is what most people will want to do to prevent their games looking jank).

Link to post
Share on other sites

looks like it is doing a pretty good job at that though
unknown.png

Authoring collision for large cliff meshes and rocks is such a pain in the ass, especially for the battlefield games where you can go prone and shit, couldn't be too detailed because performance, and if it were too simple you either intersect with the geo and see through it or hide inside it or you would be floating above it. Remote QA didn't understand any of it and would create an endless amount of jiras. Tried countless automated solution, but they are garbage besides giving you a starting point

Link to post
Share on other sites

So I've been playing with UE5 and I must say Lumen is one of the most exciting things I've seen in a game engine in possibly decades. Such a workflow game-changer. Runs amazing on my mobile 2000 series nvidia card. I'm gonna test it on a 970 this weekend.

Truly impressive implementation. It's rare you see stuff like this that takes such an unique/interesting approach to global illumination/reflection.

Looks like the day I never have to bake is finally coming!

Edited by AlexM
for some reason the forums doubled the text on my post
Link to post
Share on other sites
8 hours ago, AlexM said:

Runs amazing on my mobile 2000 series nvidia card. I'm gonna test it on a 970 this weekend.

You mean runs well for an “old” card or overall it runs well? I’ve heard of ppl struggling (15fps) with a serious rig.

Are you running your own tests, like a small map instead the demo Epic included?

Just asking cos I thought I’d download it and try, get maybe accustomed to the new UI - I would be only interested in practicing and learning how to make UI/HUDs if I was

Link to post
Share on other sites
6 hours ago, blackdog said:

You mean runs well for an “old” card or overall it runs well? I’ve heard of ppl struggling (15fps) with a serious rig.

Are you running your own tests, like a small map instead the demo Epic included?

Just asking cos I thought I’d download it and try, get maybe accustomed to the new UI - I would be only interested in practicing and learning how to make UI/HUDs if I was

Yeah running my own tests specifically without nanite so I can get a feel for how Lumen performs. The example project isn't a good test because it has so many other features (nanite being the main one).  I didn't write a test runner though, just used perception.

Were the people you heard that had issues using the example project? Because if so that's probably not a good test for Lumen specific performance numbers.

 

Link to post
Share on other sites
15 hours ago, AlexM said:

Were the people you heard that had issues using the example project? Because if so that's probably not a good test for Lumen specific performance numbers.

Think they’re just overall running the whole demo stuff. I mean I’d be surprised if it was running fine, always read that early builds run at 2fps or something, expecting that it would run like UE4 is naive.

Link to post
Share on other sites
On 6/3/2021 at 2:49 AM, AlexM said:

I'm gonna test it on a 970 this weekend.

I understood Lumen supports 1070 and higher so it'd be interesting if you manage to run it at all right now
 

Quote

Currently requires an NVIDIA GeForce GTX-1070 or greater card for performance in Early Access. Lumen has many options for scaling down but requires further development recommended for use.

https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Lumen/TechOverview/#lumenplatformsupport

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...