• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Uncharted 4 Trailer runs in-engine, in-game, in realtime on a single PS4 at 1080p60

Status
Not open for further replies.
Reveal
image_the_last_of_us-17877-2408_0004.jpg

Final
iYYmkIcCzKBbm.png


Joel's realtime model looks better in the final release

edit: found a clearer image.
 

doofy102

Member
And it says nothing about gameplay. This was showcasing an in-engine cutscene and they never claimed that the gameplay would look like that.

C'mon dude, everyone knows it's a marketing techniques meant to "trick" people into thinking it's talking about gameplay by being so vague, and then give the devs an easy way to escape the responsibility by pointing out they never actually said it was gameplay.
 
Reveal
image_the_last_of_us-17877-2408_0004.jpg

Final
iYYmkIcCzKBbm.png


Joel's realtime model looks better in the final release

edit: found a clearer image.

Nice, yeah it definitely looks better. I think the only 'misleading' aspect of the initial reveal trailer is that it starts zoomed in super close on a bunch of incredibly detailed leaves, and then the leaves in game look like this:

30777842.jpg
 

Raistlin

Post Count: 9999
Lol, ok ! If you understand, this is the most important thing.

They didn't literally take the PS3 engine and drop it in PS4. That is impossible. It can't compile.



When talking about an engine, think of it at a really high level. For example, consider a deferred rendering engine. There are multiple passes used in a specific order, each pass addressing very specific features of the scene. This is your 'rendering pipeline'. Think of it as a block diagram that describes the high level logic of how you render your image each frame.

Here's some from a google search:


Now if you step back further, you have a similar logic flow that dictates the processing of the other aspects of a game. It's not all graphics. You have control reads, I/O, AI, animation, physics, etc. Basically think of these various blocks at different granularity levels as all being black boxes. That is your 'engine'. It's a logical process flow describing what you are doing. It's the how that is very different on PS4.


So first of all, they needed to port the high level logic. That isn't some sort of code dump activity since it's a different architecture. But yes, that port isn't a particularly complex task since they already have the design. Plenty of hits and misses along the way to get it optimized, but they already have the design. For the most part it's purely a programming task. The crux however, is each of these black boxes need to actually be implemented on PS4, and that very much is coding from scratch. Similarly, the specifics of what each step produces is not necessarily going to be the same. For example, a modern game is going to use some sort of LOD for performance and graphics fidelity. Their PS3 engine was limited. They obviously didn't have HW tessellation so they needed to do it by swapping assets, and memory constraints dictate how many swap points you have. In the case of PS4, this box will be different in implementation. Assuming it's purely SW, it will have far more swap points since we have way more memory available. I suspect though it may at least use some HW tessellation, so now they are going to running some sort of combination. Or think of anti-aliasing. It may occur in the same 'passes' as the prior engine, but that doesn't mean the implementation is at all the same. Same with lighting. It may be processed at the same passes ... but what is being processed, what features are included, can be quite different.


Also note, when it is stated it's the same 'engine', that doesn't really speak to what level the granularity remains the same. They could easily be adding in new features. Logically they are. For example, It's not like they are only going to use the same shader routines. Many will be improved, and new ones created due to the hardware availability. Not too bad, but it's very likely much more complex items will also be changed. The lighting will be quite different, post-processing effects will change, etc.


You mention that using the the prior 'engine' inherently stifles things, and cite the move of UE3 to UE4. That argument only holds water if there were major features missing in the prior engine. That isn't the case though, at least not for what is needed in this game. Their engine already supported a lot of advanced features that are only now hitting other engines. They were only limited by the processing and memory constraints of PS3. For example their animation system supports both physics and hand drawn animations, the main feature beings its ability to blend between animations in real-time (as opposed to either finishing a canned animation which sucks for gameplay, or interrupting the animation with a new one which looks janky). In the case of PS4, the new implementation will allow for more advanced physics calculations on the compute units, a ton more hand drawn animations due to memory, new processing to improve the blending between interrupts, all on a much more advanced skeletal tracking system (need a skeleton to determine how to blend animations - can't have arms bending backwards, etc). These are all things that have to be coded.


Basically:
  • An engine is not what you think it is. It is the high level, mid level logic flow
  • They are using it because at least for this game, there's no reason to start over. It already supports crazy features others are just starting to implement
  • Calling them lazy if ridiculous. A ton of coding was necessary for this. Besides being objectively wrong, it's also quite dismissive, disparaging, derogatory, and down right rude.
  • If anything, they should be lauded for designing such a forward thinking engine
 
They didn't literally take the PS3 engine and drop it in PS4. That is impossible. It can't compile.



When talking about an engine, think of it at a really high level. For example, consider a deferred rendering engine. There are multiple passes used in a specific order, each pass addressing very specific features of the scene. This is your 'rendering pipeline'. Think of it as a block diagram that describes the high level logic of how you render your image each frame.

Here's some from a google search:



Now if you step back further, you have a similar logic flow that dictates the processing of the other aspects of a game. It's not all graphics. You have control reads, I/O, AI, animation, physics, etc. Basically think of these various blocks at different granularity levels as all being black boxes. That is your 'engine'. It's a logical process flow describing what you are doing. It's the how that is very different on PS4.


So first of all, they needed to port the high level logic. That isn't some sort of code dump activity since it's a different architecture. But yes, that port isn't a particularly complex task since they already have the design. Plenty of hits and misses along the way to get it optimized, but they already have the design. For the most part it's purely a programming task. The crux however, is each of these black boxes needs to implemented on PS4, and that very much is coding from scratch. Similarly, the specifics of what each step produces is not necessarily going to be the same. For example, a modern game is going to use some sort of LOD for performance and graphics fidelity. Their PS3 engine was limited. They obviously didn't have HW tessellation so they needed to do it by swapping assets, and memory constraints dictate how many swap points you have. In the case of PS4, this box will be different in implementation. Assuming it's purely SW, it will have far more swap points since we have way more memory available. I suspect though it may at least use some HW tessellation, so now they are going to running some sort of combination. Or think of anti-aliasing. It may occur in the same 'passes' as the prior engine, but that doesn't mean the implementation is at all the same. Same with lighting. It may be processed at the same passes ... but what is being processed, what features are included, can be quite different.


Also note, when it is stated it's the same 'engine', that doesn't really speak to what level the granularity remains the same. They could easily be adding in new features. Logically they are. For example, It's not like they are only going to use the same shaders. Many will be improved, and new ones created due to the hardware availability. The lighting will be quite different, post-processing effects will change, etc.


You mention that using the the prior 'engine' inherently stifles things, and cite the move of UE3 to UE4. That argument only holds water if their were major features missing in the prior engine. That isn't the case though, at least not for what is needed in this game. Their engine already supported a lot of advanced features that are only now hitting other engines. They were only limited by the processing and memory constraints of PS3. For example their animation system supports both physics and hand drawn animations, the main feature beings its ability to blend between animations in real-time (as opposed to either finishing a canned animation which sucks for gameplay, or interrupting the animation with a new one which looks janky). In the case of PS4, the new implementation will allow for more advanced physics calculations on the compute units, a ton more hand drawn animations due to memory, new processing to improve the blending between interrupts, all on a much more advanced skeletal system. These are all things that have to be coded.


Basically:
  • An engine is not what you think it is. It is the high level, mid level logic flow
  • They are using it because at least for this game, there's no reason to start over. It already supports crazy features others are just starting to implement
  • Calling them lazy if ridiculous. A ton of coding was necessary for this. Besides being objectively wrong, it's also quite dismissive, disparaging, derogatory, and down right rude.
  • If anything, they should be lauded for designing such a forward thinking engine

Great post, isn't this a similar situation for RockSteady and choosing to continue UE3? I was hoping more devs would do this.
 

Raistlin

Post Count: 9999
Great post, isn't this a similar situation for RockSteady and choosing to continue UE3? I was hoping more devs would do this.
Well it's a bit different since it isn't their engine, but I imagine they have heavily modified for their usage. IIRC it was announced that teams under Warner Bros (NetherRealm, Rocksteady) will use it until '2014' ... so it's more of a Warner Bros / Epic contract situation?


That said, I assume they made that deal because they felt the current engine does what they need for the games being developed in that time frame. It's quite possible their next projects will use some other middleware. Comes down to what features they need in those new titles.
 
Nice, yeah it definitely looks better. I think the only 'misleading' aspect of the initial reveal trailer is that it starts zoomed in super close on a bunch of incredibly detailed leaves, and then the leaves in game look like this:

30777842.jpg

In that reveal the leaves were a focal point in that shot. Of course you would want to make them look more detailed. Random trees throughout the game while you are playing are not.
 

Stallion Free

Cock Encumbered
Not only that, but whnever an update is released, you have to start your project from scratch to adapt to the new update and this is with the same engine, let alone shifting from UE3 to UE4. even

Sorry man, but you are spouting complete bullshit there. You do not have to restart a project when moving to a new revision of UE4. I literally move from 4.1 to 4.2 without touching a thing on my project and it was just fine.
 
In that reveal the leaves were a focal point in that shot. Of course you would want to make them look more detailed. Random trees throughout the game while you are playing are not.

I absolutely agree with you, and it makes sense how it was handled. But I think that shot of the leaves (which was the first image they released even ahead of the trailer) set people up with some unreasonable expectations.
 

i-Lo

Member
The same model looks a bit better in this shot:

The-Last-of-Us-release-date-set-back.jpg


But the real time model is fantastic. I think the biggest differences are the foliage in the beginning and the IQ.

True, but I believe that biggest difference comes from the IQ and upgraded texture quality (once again aided by super sampling) in those shots. Given the scene shown for U4 is not created using the same method, it will be very interesting to see what the gameplay sequences look (albeit my lack of expectation of 60fps) like at the end of the day.
 

LeBart

Member
I absolutely agree with you, and it makes sense how it was handled. But I think that shot of the leaves (which was the first image they released even ahead of the trailer) set people up with some unreasonable expectations.

It's not unreasonable if the trailer itself says "captured on PS3." You can't expect every single person who watches a video game trailer to know the difference between an in-engine target render and actual real time gameplay. I mean, after 3 Uncharted games some people are still confused when you explain to them that the cutscenes aren't rendered in real time. Had they said "this is how we hope the game will look", I think it would have been far more honest, but I guess it makes for a less exciting announcement trailer.
 
Sorry man, but you are spouting complete bullshit there. You do not have to restart a project when moving to a new revision of UE4. I literally move from 4.1 to 4.2 without touching a thing on my project and it was just fine.

Yes, Of course it will work, only if you are only limited the basic features the engine provides and the launcher version of the engine and the blueprints mode. If you use the compiled version and C++ mode and you use your own custom features or plugins or other external plugins, everything has to be rewritten in source files to make it work with each new update.
 
Important points.

1. Was UC4 trailer prerecorded for e3 or was it rendered realtime at trailers reveal (Cannot claim it was rendered realtime at e3 if so)
2. If it was pre-recorded, what are the chances that it was touched-up to make it look more presentaple ( framerate locked [gamespeed locked to rendering speed] rendering to get rid of tearing that might have been there in realtime rendering. If framerate is not yet optimal enough rendering every 60 frames in more than a second. Added AA to remove remaining jaggies. etc)

It could be realtime or not. If it was pre-recorded footage it is by definition pre-rendered.
If the showing is too good to be true(perfect 60fps, perfect iq), it propably is not true.
Or it is very well made cutscene where every aspect of it is well inspected and refined until it is perfect.
 

Deepo

Member
"Each hair on his upper lip has been individually programmed to move dynamically, according to both Sully's movement and the effects of the world around him. If you swipe up on the track pad, all the hairs will move upward-"

*crowd goes apeshit*

Day one.

Moustache-AI. The hairs move away when approached.
 
Important points.

1. Was UC4 trailer prerecorded for e3 or was it rendered realtime at trailers reveal (Cannot claim it was rendered realtime at e3 if so)
2. If it was pre-recorded, what are the chances that it was touched-up to make it look more presentaple ( framerate locked [gamespeed locked to rendering speed] rendering to get rid of tearing that might have been there in realtime rendering. If framerate is not yet optimal enough rendering every 60 frames in more than a second. Added AA to remove remaining jaggies. etc)

It could be realtime or not. If it was pre-recorded footage it is by definition pre-rendered.
If the showing is too good to be true(perfect 60fps, perfect iq), it propably is not true.
Or it is very well made cutscene where every aspect of it is well inspected and refined until it is perfect.

No one would be dumb enough to run something real-time for a conference unless it was a gameplay demo. Also it said "captured", not "being rendered right now by".
 
No one would be dumb enough to run something real-time for a conference unless it was a gameplay demo. Also it said "captured", not "being rendered right now by".

I am just saying what words they can use.

So footage was pre-rendered. Now the important question is how it was rendered when recorded.

We may never know.

Edit:
Answered in the OP.
(Running in real time.)

If the video feed came from ps4, they could say that video feed indeed was rendered in realtime.
If it was all realtime, mad respect to them.
But I see no reasoon why their PR would not tell them to pretty their footage up for trailer.
In the end, I do not think it will make a difference. In some ways the final product will most likely look even better.
 
Yeah, I'm talking about the actual animations not the movement systems.

I agree with you, Drake is usually quite skittish and wooly to control if you don't follow the planned route. It's broke the immersion for me many times when the animation loses its way, but I love it and forgive it anyway because the controls feel great.
 

Squozen

Member
I really don't know shit about computer graphics, so I don't even know if this is plausible, but could they have come up with their own proprietary AA solution? Given the closed box nature of the console and not having to worry about compatibility issues?

I don't know much either, but my guess is that they've invented a way to do on-the-fly texture modification. If you know which angle a texture will be at, why not code the anti-aliasing into the texture and continue modifying it as the texture rotates? Obviously that would need a lot of bandwidth between the RAM, CPU and GPU, but the PS4 has that.

Just a guess. Now those who know more can explain to me why it's not possible. :)
 

i-Lo

Member
Hopefully, we'll see more footage this year that will lend credence to their claims. I really want it to be true for the final product. That said, I would not mind one bit if the final game much like KZ and inFSS was locked down to 30fps. Not once did I think that the franchise needed to 60fps while playing all the three games.

heh, my dev-friend was like 'Well, it looks good, but not that groundbreaking'. It's hard to please some people.

Sounds like Shandy and NemesisPrime had a kid.
 

kaskade

Member
Naughty Dog would be one of the few companies I would think could actually pull off what they showed. Their character model for Joel was amazing.
 

Xun

Member
The model in 3rd person wouldn't be that detailed unless you get up close, so it's definitely believable that it's in-engine/realtime.

The game will look fantastic.
 

RoboPlato

I'd be in the dick
The model in 3rd person wouldn't be that detailed unless you get up close, so it's definitely believable that it's in-engine/realtime.

The game will look fantastic.
The more I think about it this game is probably using some really advanced tessellation solution for detail scaling. Only way to explain the fact that this is only a 60k poly model, smooth edges, and 60fps.
 

Teeth

Member
The more I think about it this game is probably using some really advanced tessellation solution for detail scaling. Only way to explain the fact that this is only a 60k poly model, smooth edges, and 60fps.

Tesselation isn't magic, it literally just adds complexity to closer things, incurring the same performance hit. It's more of a workflow efficiency tool than a performance efficiency tool (basically giving on-the-fly level of detail models without having to model them separately).

A model tesselated up to a million vertices right in front of the camera is going to have nearly the same hit as one modeled at a million vertices.
 

i-Lo

Member
The more I think about it this game is probably using some really advanced tessellation solution for detail scaling. Only way to explain the fact that this is only a 60k poly model, smooth edges, and 60fps.

In this video, (around 00:44), the lead programmer for U2 said they were using 80K poly for Drake. I would assume that it may be for the cinematics because otherwise that would be insane. As such, I do expect the real time Drake's model in that trailer to be at least 80K.
 

RoboPlato

I'd be in the dick
Tesselation isn't magic, it literally just adds complexity to closer things, incurring the same performance hit. It's more of a workflow efficiency tool than a performance efficiency tool (basically giving on-the-fly level of detail models without having to model them separately).

A model tesselated up to a million vertices right in front of the camera is going to have nearly the same hit as one modeled at a million vertices.
Didn't realize it was the same performance hit. It could still be a good solution for smoother LoD transitions which would be a huge benefit to this game.

In this video, (around 00:44), the lead programmer for U2 said they were using 80K poly for Drake. I would assume that it may be for the cinematics because otherwise that would be insane. As such, I do expect the real time Drake's model in that trailer to be at least 80K.
The Order's characters are over 100k.
 

Teeth

Member
Didn't realize it was the same performance hit. It could still be a good solution for smoother LoD transitions which would be a huge benefit to this game.
.

It's not quite the same, as proper hardware and directX/openGL implementation can create efficiencies for it, but yeah, you're basically just creating more polys.
 

i-Lo

Member
It's not quite the same, as proper hardware and directX/openGL implementation can create efficiencies for it, but yeah, you're basically just creating more polys.

True, but wouldn't the polys in the scene remain roughly consistent throughout? After all, if the camera is moving towards an object it is also obscuring other geometry in the surroundings.
 

stevil

Junior Member
Yes, Of course it will work, only if you are only limited the basic features the engine provides and the launcher version of the engine and the blueprints mode. If you use the compiled version and C++ mode and you use your own custom features or plugins or other external plugins, everything has to be rewritten in source files to make it work with each new update.

I can imagine you have to rewrite portions of optimization code or work around code or change small portions in case of api changes but to say you have to re write everything is just not how programming works unless they keep on changing the languages of choice every revision 😃
 

Teeth

Member
True, but wouldn't the polys in the scene remain roughly consistent throughout? After all, if the camera is moving towards an object it is also obscuring other geometry in the surroundings.

Errr...I don't think so?

The created mesh of a contiguous object is still calculated, even if part of it is obscured. If half of a singular object is obscured, it doesn't just tessellate the visible portion. The same would go for every background element as well.

Even if you could do that, I don't know if you would want to. Depending on the complexity of the object, necessary tessellation (for minimum optimized visual quality) varies with shape, size, and texture. I haven't heard of a dynamic load balancer for tessellation, but that doesn't mean someone hasn't done it. That might actually be a great tool, especially with an appropriate hierarchy of balanced elements.
 

hwateber

Member
Important points.

1. Was UC4 trailer prerecorded for e3 or was it rendered realtime at trailers reveal (Cannot claim it was rendered realtime at e3 if so)
2. If it was pre-recorded, what are the chances that it was touched-up to make it look more presentaple ( framerate locked [gamespeed locked to rendering speed] rendering to get rid of tearing that might have been there in realtime rendering. If framerate is not yet optimal enough rendering every 60 frames in more than a second. Added AA to remove remaining jaggies. etc)

It could be realtime or not. If it was pre-recorded footage it is by definition pre-rendered.
If the showing is too good to be true(perfect 60fps, perfect iq), it propably is not true.
Or it is very well made cutscene where every aspect of it is well inspected and refined until it is perfect.
The fuck am I reading? By your definition nothing is ever considered real time gameplay footage unless you're actually there playing it. Oh well I'm done, gotta go watch some prerendered bullshit dota 2 on twitch
 

Raistlin

Post Count: 9999
Errr...I don't think so?

The created mesh of a contiguous object is still calculated, even if part of it is obscured. If half of a singular object is obscured, it doesn't just tessellate the visible portion. The same would go for every background element as well.
At some early stage in the rendering pipeline, a good chunk of vertices that aren't visible get culled ... that way they aren't hitting the more time consuming T&L stages.





The fuck am I reading? By your definition nothing is ever considered real time gameplay footage unless you're actually there playing it. Oh well I'm done, gotta go watch some prerendered bullshit dota 2 on twitch
lol
 

Teeth

Member
At some early stage in the rendering pipeline, a good chunk of vertices that aren't visible get culled ... that way they aren't hitting the more time consuming T&L stages.

This is true, but the point still stands: tessellation adds a substantial amount of processing to a scene. It exists to generate higher fidelity visuals, not to increase visual fidelity at a lower performance hit. Tessellation is not a technique to improve visuals without extending the compute time.

I guess I just wanted to say something because I tend to see some posters thinking that by adding tessellation, the visuals will improve without any added cost. Every game that has used tessellation has come with a notable performance hit (for, in my opinion, a negligible or sometimes odd-looking visual improvement).
 

Votron

Member
It is kinda funny nowadays that 75% of what is important (or at least the first impression of games now) is first and foremost, the graphics.
How many resolution it can punch on the screen and the frame rate.

Perhaps I can't blame them now that innovation in games is [almost] pretty much rehearses and sequels..
 

BigTnaples

Todd Howard's Secret GAF Account
It is kinda funny nowadays that 75% of what is important (or at least the first impression of games now) is first and foremost, the graphics.
How many resolution it can punch on the screen and the frame rate.

Perhaps I can't blame them now that innovation in games is [almost] pretty much rehearses and sequels..


Must suck to be so jaded.

Also, video games have always been about graphics and gameplay. There was a vocal minority on the internet that argued that one was more important than the other. Most realize they are important in equal measure.


Gameplay, graphics, storyline, art, all meld together to immerse you in the medium.


Just like Jurassic Park wouldn't have been as good or as renowned if it had been made using claymation techniques from the beginning of film.
 
Status
Not open for further replies.
Top Bottom