Some presentations from GDC08

[Mintmaster]

Or the extra space is used to hide the loading of data by using prerendered/prerecorded video streaming.

Hence my post saying much of the disc space last gen was for FMV (full motion video). With better realtime graphics this gen, there is less advantage to doing FMV, and it's more seamless without it.

But I did not.

But you did.

Look at the paragraph that I quoted from you along with your earlier post. You say there's a dispropotional increase in assets, so large media is needed to store it. Without knowing how big those assets were last gen, you can't tell if the increase goes well beyond DVD, especially with FMV savings.

So here's the rough count for a certain popular PS2 game I happen to have intimate knowledge of: MPEG-2 video 5GB, ADPCM audio 2.5GB, game data 1GB. Roughly 1/3 of which is duplicated data.

My back of the envelope calculations say that if we did the same game in HD, it'd take up roughly 20GB

You're missing the point I'm making. Lots of FMV isn't really needed now. Realtime cutscenes are a tiny fraction of the space, are more seamless, and don't look as bad as last-gen. These are all factors which increase the cost and reduce the benefit of storing video instead.

Let me know what fraction of that 1GB is textures and geometry and then we can talk about something that's comparable to the slides that Crossbar posted. Lots of game data doesn't need to scale.

 

[Panajev2001a]

Which firmware (2.0 or 2.10)?

Less 15 MBs ps3 will be equivalent to x360 OS.

You still have to take into account the percentage of VRAM the PS3 OS uses.

Let's hope they find some GOOD uses for all the OS reserved RAM sooner rather than later. Another possible outcome would be that Sony cans some of the extra features, frees up the RAM and decides later on to add more RAM to a future PS3 re-design PSP Slim&Lite style so that it gains some RAM back to use for OS related functionality.

 

[Fafalada]

With better realtime graphics this gen, there is less advantage to doing FMV, and it's more seamless without it.

That's only true as long as you don't allow FMV to store anything other then high-end CG.

 

[Panajev2001a]

That's only true as long as you don't allow FMV to store anything other then high-end CG.

You are talking about background asset loading like Heavenly Sword and Uncharted do in their cut-scenes ?

I personally find it to be a very smart trick .

 

[Heinrich4]

it's just XDR OS footprint

Yes you right,I forgot VRAM,but they still using VRAM 32MB reserved?

 

[Heinrich4]

You still have to take into account the percentage of VRAM the PS3 OS uses.

Let's hope they find some GOOD uses for all the OS reserved RAM sooner rather than later. Another possible outcome would be that Sony cans some of the extra features, frees up the RAM and decides later on to add more RAM to a future PS3 re-design PSP Slim&Lite style so that it gains some RAM back to use for OS related functionality.

This would be very good for the console, maybe more textures cam be added since OS down from 64MB to 47MB in XDRAM (not counting probably less footprint in VRAM).

 

[inpHilltr8r]

You're missing the point I'm making. Lots of FMV isn't really needed now. Realtime cutscenes are a tiny fraction of the space, are more seamless, and don't look as bad as last-gen. These are all factors which increase the cost and reduce the benefit of storing video instead.

I covered that in my reply to ShootMyMonkey. I should note that, while I believe it's a worthy goal, I don't think we're going to be removing all FMV this gen. For some games it's still going to make sense. Assuming you can afford the disc space.

Let me know what fraction of that 1GB is textures and geometry and then we can talk about something that's comparable to the slides that Crossbar posted.

I can't break that 1GB down smaller, as I'd have to rebuild a few levels to get the required data, rather than just pulling old logs from directories I haven't gotten around to cleaning up. However, from memory, the other major components of that game data, are going to be animation, and memory resident audio, both of which are getting bigger. the 'Assets' column on that slide, is what I refer to as 'game data'.

Lots of game data doesn't need to scale.

Like what? Anything that was large enough to make an impact last gen? Nothing that I've seen so far. Collision and logic was already dwarfed by the other assets last generation. Maybe we don't scale audio, and just rely on better codecs. We had 2MB of memory allocated to resident audio, so less than 10% of our game data can have been audio, which still leaves 90% that's going to scale up significantly.


This is all kind of academic though, as we've seen excellent quality titles fitting on a single 360 DVD.

 

[Fafalada]

I personally find it to be a very smart trick

It's not really a trick - even if you have no loadtimes to hide, it's just simply more cost effective/faster to make things that way (barring disc space limitations of course).

I should note that, while I believe it's a worthy goal, I don't think we're going to be removing all FMV this gen.

My question is why it's a "worthy" goal?
In terms of development, "worthy" is something with tangible benefits, not some bragging rights nonsense (oh look at me, I'm all realtime).
Vast majority of the time you can render your in-engine cutscenes offline, and it will be cheaper&faster to tune and perfect them, easier to integrate with the gameplay, and possibly allow you to do things that would be impossible otherwise (eg. hide any data loads).

I'm not advocating it should be all FMV either - there are places where you might want/need RT (eg. if you want to show gameplay effects like costume changes or environment effects caused by gameplay). It's just that striving for the "worthy goal", is clearly counter productive (unless as I mentioned above, disc space is your main problem).

 

[Crossbar]

But you did.

Look at the paragraph that I quoted from you along with your earlier post. You say there's a dispropotional increase in assets, so large media is needed to store it. Without knowing how big those assets were last gen, you can't tell if the increase goes well beyond DVD, especially with FMV savings.

Yes I assumed those assets were stored somewhere but I made no reference to the DVD limitations.

The reference to BRD was in a separate paragraph and I carefully worded it to reference possible future titles that are aiming for higher fidelity.

 

[inpHilltr8r]

My question is why it's a "worthy" goal?

They don't scale well, they take up shitloads of disc space, and they don't reflect character or environment state. I could hide even more loading if our cutscenes were in-engine. Plus, I could change the camera dynamically, instead of everything being baked.

I consider having to drop back to FMV to be a failure of our cut-scene pipeline. We make interactive fantasies. MPEG is not interactive.

Also yeah, the bragging thing, although that's not the drive here.

Still not going away this gen though.

 

[Laa-Yosh]

Well if it's about bragging, we're still going to be able to outdo you realtime guys for quite a time

 

[inpHilltr8r]

I should bloody hope so, given that you generally have more than a fraction of a second to render a frame.

Seriously though, bragging rights really is the least of it.

 

[-tkf-]

They don't scale well, they take up shitloads of disc space, and they don't reflect character or environment state. I could hide even more loading if our cutscenes were in-engine. Plus, I could change the camera dynamically, instead of everything being baked.

I consider having to drop back to FMV to be a failure of our cut-scene pipeline. We make interactive fantasies. MPEG is not interactive.

Also yeah, the bragging thing, although that's not the drive here.

Still not going away this gen though.

The thing with "realtime" cutscenes is that you have to load the assets before you can display them. (Sorry if im repeating something here you already know.) Streaming a prerendered Video will in many cases be the best solution for the player and the developer.

 

[Arun]

The thing with "realtime" cutscenes is that you have to load the assets before you can display them. (Sorry if im repeating something here you already know.) Streaming a prerendered Video will in many cases be the best solution for the player and the developer.

If you listened to Carmack though, you really don't need that many assets ready in advance... But yeah, prerendered videos are definitely there to stay for quite a few reasons, including that one, IMO.

 

[Fafalada]

We make interactive fantasies. MPEG is not interactive.

Neither are 99.99% of cutscenes through the ages.

I'm not advocating CG use here at all - but baking your RT scenes can save tons of time and effort to make, remove the limits to the scope&scale of cutscenes(think how "easy" it would be doing something like Gears ending cinematics completely RT at same quality) as well as take away the load from programming team (removing cutscene specific tasks, such as sfx or other things that may be required and are never even used in gameplay).
And yea - they never have a load-delay, no matter what you do

 

[inpHilltr8r]

The thing with "realtime" cutscenes is that you have to load the assets before you can display them. (Sorry if im repeating something here you already know.) Streaming a prerendered Video will in many cases be the best solution for the player and the developer.

You have to pre-buffer video too, otherwise you get black or held frames up front. We typically didn't have enough space for two levels and an MPEG decode buffer*, so playing an MPEG was about as much work as loading a level was. Also, many of our MPEGs were in the same location that the player was already in, so the asset load would have been fairly small.

*For situations where we would play an MPEG, and end up in a different location afterwards, we would have to make space for both levels, and the playback buffer, and load the next level, before buffering and playing the MPEG. MPEG isn't easier for everyone in the pipeline.

Neither are 99.99% of cutscenes through the ages.

Lets push things forwards, eh?

And yea - they never have a load-delay, no matter what you do

Look up. (excuse me if I'm being irony-deficient here)

 

[Fafalada]

We typically didn't have enough space for two levels and an MPEG decode buffer*

Maybe I'm reading wrong into this, but shouldn't it be like:
Level1 + Mpeg (Level1 showing, buffering Mpeg) -> MPeg (Mpeg buffered, first frame just showed) -> Mpeg + Level2 (Level 2 is loading while Mpeg is playing)?

That said, movie player memory requirements are another story. I know there are some that can be obscenely greedy, but that doesn't necessarily mean those are physical limits.
Now - I admit I only did this stuff with SD movies, but for buffering an I-Frame only MPeg2 (typically few times higher bitrate then normal streams), I used streaming buffer ~400KB(for video only - which takes like, in order of 0.1s to fill the buffer?).

 

[-tkf-]

You have to pre-buffer video too, otherwise you get black or held frames up front. We typically didn't have enough space for two levels and an MPEG decode buffer*, so playing an MPEG was about as much work as loading a level was. Also, many of our MPEGs were in the same location that the player was already in, so the asset load would have been fairly small.

*For situations where we would play an MPEG, and end up in a different location afterwards, we would have to make space for both levels, and the playback buffer, and load the next level, before buffering and playing the MPEG. MPEG isn't easier for everyone in the pipeline.


Lets push things forwards, eh?

Look up. (excuse me if I'm being irony-deficient here)

Ahh ok, well i guess i was thinking to much about HD based consoles and had Heavenly Sword in mind. Afaik they streamed video while caching next level asset to the HD.

I never heard of anyone using prerendered video this way until Heavenly Sword. I have seen plenty of "forced" realtime cutscenes like in Metroid prime and in GTA:SA to hide the loading. In both cases it was very primitive and simple stuff.

 

[inpHilltr8r]

Maybe I'm reading wrong into this, but shouldn't it be like:
Level1 + Mpeg (Level1 showing, buffering Mpeg) -> MPeg (Mpeg buffered, first frame just showed) -> Mpeg + Level2 (Level 2 is loading while Mpeg is playing)?

That said, movie player memory requirements are another story. I know there are some that can be obscenely greedy, but that doesn't necessarily mean those are physical limits.
Now - I admit I only did this stuff with SD movies, but for buffering an I-Frame only MPeg2 (typically few times higher bitrate then normal streams), I used streaming buffer ~400KB(for video only - which takes like, in order of 0.1s to fill the buffer?).

This was on PS2, and we didn't mux gamedata into MPEG. We probably could have done, but the MPEG player was our red-headed stepchild. Ported from unreadable Japanese sample code, by Europeans who insisted on wrapping it in their own framework, which I had to rip out and replace with our own. It took long enough to fix it so that we could buffer everything in the background. There was still a couple of frames of delay starting the damn thing, and it required something like a 4MB heap (it may have been less, it may only have been 1MB, but I'm not at work and don't have the code to check against).

As to 0.1s, I have to ask if you're including seek times, and allowing for audio stream maintenance? Reading the data is one thing, getting the read head to it on time, reliably, was usually the problem.

 

[inpHilltr8r]

Ahh ok, well i guess i was thinking to much about HD based consoles and had Heavenly Sword in mind. Afaik they streamed video while caching next level asset to the HD.

At this point, I wouldn't be at all surprised if we ended up doing something similar for PS3. I think they just ate the MPEG buffering too. I got a little obsessed with being able to start playing an MPEG the same frame it was requested. In hindsight, I dunno if anyone actually cared that much.