PS3 vs 360 - differences in modelling & texturing?

Asmuel

Hey dudes

I was wondering if anyone knows in practical terms, how creating content for either platform may differ for a artist? I haven't heard too much about the subject and I was wondering if anyone has any experience with this?

Rick Stirling

For me so far, none. (No difference, not no experience)

EarthQuake

The 256mb texture memory limit dosent have any different effect for you guys rick? No need to scale down your textures, are you only using 256 on the 360 too?

rube

I seem to remember someone saying that you don't need power of 2 textures on the ps3.. so that could be used to squeeze more info into the 256mb

Rick Stirling

You wouldn't make your assets any differently - it's not like you are going to have one art asset taking up all the memory anyway.

Castor

ps3 or xbox 360. it matters not.. the question is the resoultion of the game that is going to be played + average size (pixel occuping space) of the model viewed most of the time.. When you build just one model . it matters not how big is the texture.. but for the game, it's a different story. How many characters, models .. different models viewed at one time per level load and how many do you have to draw etc becomes more important.

Tulkamir

I'm not as experienced as you guys, but for the exact same game assuming one system has significantly less texture memory than the other would you not have to scale down your textures?

Doesn't seem that far off to me. Even though one texture won't take it up if it has to load a whole bunch and bottle necks because of less texture memory than the other system you obviously have a problem...

Or am I completely off on how all this works?

Rick Stirling

Although the 512MB memory of the 360 can be used for anything, and the PS3 has 256MB of texture memory, you DON'T have double the memory on the 360. Games don't use all the memory for graphics.

So yes, you probably do have more texture memeory on the 360, but tools and engines are wonderful things for artists.

arshlevon

cough cough

EarthQuake

[ QUOTE ]
Although the 512MB memory of the 360 can be used for anything, and the PS3 has 256MB of texture memory, you DON'T have double the memory on the 360. Games don't use all the memory for graphics.

So yes, you probably do have more texture memeory on the 360, but tools and engines are wonderful things for artists.

[/ QUOTE ]

Right i guess i was just wondering if you ran into any issues where you were maxing out the memory on the ps3 and had to downsize, but i guess developing for both you're really going to be only pushing the max at the lowest end right?

Arsh: Could you elaborate on that a bit more, you're saying you can use a lot more texture memory than if you were making a multiplatform game, but not directly comparing it to say a 360 exclusive game right? And whats with the smaller texture thing, is the ps3 just really good at streaming small files in and out of memory, so you can throw more stuff at it or something? Developing for pc i've always been told the less, larger textures i use the better.

Asthane

I believe Arsh's point was, the 360 has 512 megs for everything (Plus like, 10 on the vidcard), while the ps3 has 256 texture memory, _AND_ 256 generic. So assuming a balanced load, there really should be no real difference. In fact, I don't see why the PS3 couldn't put some textures into its main memory if you really needed to, considering that's what the 360 does.

[dicscalaimer: the previous info is based on ten seconds of googling, and could be totally wrong :P]

HarlequiN

PS3 may have another advantage as far as texture memory goes. On the 360 a mip-mapped texture (which should be most of them) that is 8x8 pixels will take up the same memory as a mip-mapped 128x128. In fact any mm'd texture smaller than 128 pixels on a side will be inflated to fill the same memory as one that is -Something to do with this making them faster to retreive and process. There are ways around this to a degree - but that's what MS says in its documentation.

So, PS3 doesn't have this restriction (that I'm aware), so while on the 360 you might make a texture larger then you actually need it to be (and why not, it's going to work out the same size anyway), on PS3 you might actually have your light texture you're only going to see from 300 feet away take up a lot less space in memory than it would on the 360 with no visual loss in quality.

Eric Chadwick

Weird.

arshlevon

butter

ThatDon

Who do you work for again arsh?

Ghostscape

[ QUOTE ]
PS3 may have another advantage as far as texture memory goes. On the 360 a mip-mapped texture (which should be most of them) that is 8x8 pixels will take up the same memory as a mip-mapped 128x128. In fact any mm'd texture smaller than 128 pixels on a side will be inflated to fill the same memory as one that is -Something to do with this making them faster to retreive and process. There are ways around this to a degree - but that's what MS says in its documentation.

So, PS3 doesn't have this restriction (that I'm aware), so while on the 360 you might make a texture larger then you actually need it to be (and why not, it's going to work out the same size anyway), on PS3 you might actually have your light texture you're only going to see from 300 feet away take up a lot less space in memory than it would on the 360 with no visual loss in quality.

[/ QUOTE ]

Yeah, but who cares? Anything less than 2048x2048 isn't next-gen.

Petter T

[ QUOTE ]

Yeah, but who cares? Anything less than 2048x2048 isn't next-gen.

[/ QUOTE ]

Yeah, in a next gen game EVERY single asset must have 2048^2 textures or bigger. (BTW, does next gen mean next generation, or this current generation of consoles, that has been around for quite some time?)

Joshua Stubbles

[ QUOTE ]
Yeah, but who cares? Anything less than 2048x2048 isn't next-gen

[/ QUOTE ]

Are we still using "next gen" to describe THIS gen? :P

Great visuals don't come strictly from texture resolution. While they increase the overall fidelity of a scene, they are in no way the single cause of the eye candy
Lighting, imo, is truly what makes or breaks a scene. With great lighting, even low res textures look amazing. You can use super high res textures, but it will look like crap if the lighting is bad.
A great example of this, is the old PS2/Xbox environments that Malcolm has made. The textures were low res due to the console's restraints, but he still had some damn fantastic lighting. IMO, without that lighting, the scenes would not have looked as good.

You can ignore that all, if your comment was merely sarcasm

HarlequiN

I'm pretty sure it was sarcasm.

FatAssasin

So Harlequin, are you basically saying that there's no point in creating textures less than 128x128 for the 360 because the memory is the same either way?

Ghostscape

[ QUOTE ]
So Harlequin, are you basically saying that there's no point in creating textures less than 128x128 for the 360 because the memory is the same either way?

[/ QUOTE ]

Yes, that is what he's saying.

anything less than a 128x128 gets padded out to a 128x128, making it take up the same amount of memory.

Which means if you want to texture things smaller than 128x128, you should combine them into 1 texture.

Also I was being entirely serious about using 2048x2048 textures. Anything less than that is just pretending to be next-gen.

And by next-gen I meant this gen. Next-gen is a marketing term that refers to this gen.

SuperOstrich

I'll add a little more to this 128x128 on the 360 stuff: If your engine uses interleaving and you're mipmapping all your textures, anything smaller than 128 is most likely going to take up 0KB after interleaving anyway.

SuperOstrich

Arsh: I haven't heard of a game in development being fill bound in ages. Hence I can't see how the extra fill rate of the PS3 is really going to equal better graphics, more polys, etc.

Also, isn't fill-rate just how quickly the pixels are rendered to video memory? How does increased fill rate equal more polys?

Edit: Keep in mind I'm actually asking, knowing full well my understanding of fill rate could be wrong or I simply didn't understand it.

Penzer

[ QUOTE ]
I'll add a little more to this 128x128 on the 360 stuff: If your engine uses interleaving and you're mipmapping all your textures, anything smaller than 128 is most likely going to take up 0KB after interleaving anyway.

[/ QUOTE ]

What is interleaving? I looked it up on wikipedia (http://en.wikipedia.org/wiki/Interleaving), but don't understand how it reduces file size. From what I understood from that description, it's used to reduce errors and data loss.

arshlevon

sandwich

Asmuel

I just want to thank you guys for the responses so far, I'm glad I started this thread its very informative cheers

SuperOstrich

[ QUOTE ]
[ QUOTE ]
I'll add a little more to this 128x128 on the 360 stuff: If your engine uses interleaving and you're mipmapping all your textures, anything smaller than 128 is most likely going to take up 0KB after interleaving anyway.

[/ QUOTE ]

What is interleaving? I looked it up on wikipedia (http://en.wikipedia.org/wiki/Interleaving), but don't understand how it reduces file size. From what I understood from that description, it's used to reduce errors and data loss.

[/ QUOTE ]

You might want to look up "texture interleaving" or something. Basically it takes the black space of a mipmapped texture and fills it in with smaller textures so that the black space doesn't go to waste.

Penzer

Okay, that makes perfect sense, I didn't know thats what it was called. Thanks

SuperOstrich

I put together these two pics real quick to show you in a very basic form what interleaving does. The first image shows a texture and the subsequent mip maps created for it. The second image shows how you can fit two more textures and their mips within the same texture to take up no more memory. So if your game supports interleaving, then the chances are textures smaller than 128x128 aren't taking up any memory anyway. Unless you don't mip-map.

HarlequiN

You're quite right Ostrich, you can interleave to save memory on the smaller textures. However (from what I've been led to understand by our friendly neighbourhood rendering chap) each time you interleave into the mips below 128 on the 360 you're using a smidgen of processer time to get it back again - since as far as the 360's concerned that memory is accounted for and you're actually tricking it into using it for something else, which slows things down.
So, for smaller textures, you're trading off memory for performance - though only a small amount).
My understanding of it is limited, and what little I do know about it I can't talk about much due to my NDA as it's engine specific (curses), it's worth mentioning that not every game's engine will have interleaving - but probably a good idea to ask your rendering guys what the situation is with storing smaller textures on the 360.

Note that if you're not mip mapping for any reason the 360 doesn't care how small your texture is, and will store it in the expected amount of RAM

SuperOstrich

Yeah, I think it does take a small CPU hit to interleave, but it's what programmers like to call "negligible."

Notice I put "unless you don't mip map" at the bottom of my last message.

HarlequiN

Yep, I felt it worth reiterating

Negligable is a sliding scale - it all depends what else the engine is doing at the same time...

SuperOstrich

I don't believe so. I'm pretty sure that just about any engine that is mip-mapping would benefit from interleaving. Any performance hit is so small that the memory savings would outweigh it.

warby

hmmm i had no idea that mipmaps actually have that black space FILLED i always toughed that is just photoshops way of representing it when opening a dds file
because i read ( i believe on wikipedia) that mipmaps fragment your memory with an extra 33% of your original textures memory usage. and therefore i toughed we should finally come up with something better than mipmaps ... using no mipmaps but 16x anisotropic filtering on everything looks good in my eyes ...but than i realized that people use mipmaps for more than just removing jitteryness on stuff in the distance but also as a kind of memory-releaving-lod trick.

SuperOstrich

Mip-mapping textures helps GPU performance too. It's not just a technique used to reduce swimming pixels. If a character is displayed very small on-screen but he has a 1024x1024 texture on him, the in-game process of shrinking that texture down on the character is GPU intensive.

Joshua Stubbles

Yuppers, that would kill the fillrate, having to do it realtime. That's also why it's important for models to have equal pixel density throughout the texture. If there are big changes, performance gets hit bad.

CrazyButcher

regarding mip-maps, that "black" area, does not exist in memory, that would be insanely wasted. The 1/3 extra cost is more true, not two times as the image suggests. Texture data is I think stored in blocks of a fixed size, it could be that below this size data is indeed interleaved, but not before, as that would make no sense.
While I don't knot xbox360 or ps3 low-level rendering apis, for directx/opengl on PC you do not have any "access" to specifiy how mipmaps are stored at all, it's completely up to the driver.

the reason mipmaps are faster is due to texture caching, if such a block is cached, accessing texels in it is way faster. Because texture cache has a fixed size, you can think of mipmaps helping texture cache to be more efficient (less jumping of blocks compared to the big textures, because a small texture is made of less blocks). There is no runtime downscaling as mentioned here, when no mipmap is used, simply finding the proper pixel in the big texture. Which, if the texture is small on screen, will result into many different "blocks" being used.

thats also the reason why compressed textures are actually faster at runtime, as less blocks are needed for a texture (more data stored into block) and block access/caching is slower than the few instructions needed to "decompress" a texel.

edit: in a ms presentation on xbox360 the only note regarding mipmaps was:
"Mip tail packing
All MIPs smaller than 32 texels on a side are packed into one memory page"
so below a certain size they are indeed packed, but 32 texels means way less "black" space as suggested in the images posted here

arshlevon

capital vanguard

Black_Dog

Scene splitting on the 360 is done isn't done because of fillrate. The GPU on that machine has 10MB of EDRAM dedicated to render targets which isn't quite large enough to fit a 4x multisampled screen size buffer into - to get the whole screen rendered with 4xMSAA you need to render two smaller tiles and composite them, a technique known as "predicated tiling".

GoW doesn't use this technique as far as I know.

arshlevon

nope

CrazyButcher

lol arshlevon, but the "he is dumbing down for me", really adds a lot of room for interpretation, which naturally leads to problems, and some untruths to be told. But I think it happens all the time, one just has to be aware of the own lack of knowledge (drunk or not hehe).

SuperOstrich

Haha, I hear ya Arsh. My explanation of interleaving is directly from our lead rendering programmer. My diagram is even a ripoff from him. So it's definitely second hand.

CB doesn't seem to think it's correct, but I'm gonna stand behind it for now. This guy is rarely wrong.

CrazyButcher

it could be some special low-level access for xbox360 / ps3, but that blocksize mentioned in that ms paper was 32x32.

regular OpenGL or DirectX, do not offer any kind of "interleaving" possibilities, nor anything regarding storage of data. But well they are standards that need to work on different hardware, compared to consoles...