PS2 question

[archie4oz]

OK let me try and phrase this another way.

Hehehe... Give it up... Faf and I have tried and failed to convince 'em...

IMO the PS2's biggest weeknesses from a texturing standpoint are the lack of some obviously useful destination blend modes on the GS, and the difficulty involved in implementing decent filtering.

Bingo! That's pretty much hitting it on the button. A few more MIP levels wouldn't hurt either... (7 is a bit too few...)

Sony no doubt had reasons to do things the way they did, but all their competition now use something much better for texture storage. In terms of quality/bit there is no comparison.

What would you expect them to do? I mean S3TC was debuting on S3 Savage hardware right around the time the GS was completed so it's not that wouldn've been a viable option... Trying to come up with some method of incorporating a texel unpack hardware on a physical design like the GS in it's timeframe would've possible caused more design headaches than it would have solved. Better to just improve performance with tried and true technologies (besides lots of older hardware, like Voodoos suffered cycle penalties for accessing lookup tables back then)

If PS2 had DXTC textures 4-bit and 8-bit CLUT textures would instantly be dead formats for almost everything except some special effects achievable by palette manipulation.

I'd have to disagree here... I think they'd still be around and in active use. However the other formats (32, 24, 16-bit, etc...) would've probably become rather depreciated...

You mean trilinear / anisotropic, etc kind of texture filtering? How difficult is it to achieve trilinear filtering?

It's not at all really... It's just that the performance hit sucks enough that it's really not worth it...

 

[chaphack]

A question, is CLUT officially supported by Sony, in PS2 hardware(like VQ in DC)? or programmers are using it since it is the least intensive format

 

[Grall]

Teasy the problem is another...

the EE's main bus has a 2.4 GB/s bandwidth... and since GS data passes onto that busyou have to take that 1.2 GB/s away

Not entirely correct. GS data generated by VU1 does not go over EE's internal bus unless you for some stupid reason decide to make it so. VU1 has a dedicated path to the GIF unit (which handles EE<->GS transfers). As far as memory transfers are concerned, if you run a GB+ of data every second from memory to GS, it won't matter you tie up a GB+ of bus bandwidth because you'd tie up a GB+ of memory bandwidth also; it's not as if the EE is being deprived of anything it could otherwise have put to some other use.

Besides, I'm not sure the so-called "path3" connection to the EE really touches the internal EE bus. It may go straight from the DMAC to the GIF unit. I could be mistaken here, I'd have to look at the Ars Technica blackpaper on PS2 first and I am too tired to arsed to do that right now.

*G*

 

[chaphack]

Well it's not a JPEG for one thing, however it is pretty ugly even for a 4-bit CLUT... This one is better...

4-bit CLUT

Still, it looks muted, grainy and dithered compared to the rest. hey! that is exactly what i would described PS2 textures. Well, it is CLUT afterall.

There are a number of other bottlenecks you need to overcome before you get anywhere near needing to worry about the bus to the GS being a bottleneck.

Taking things outta context, you mean PS2 has more bottlenecks than the poor GIF bus?

IMO the PS2's biggest weeknesses from a texturing standpoint are the lack of some obviously useful destination blend modes on the GS, and the difficulty involved in implementing decent filtering.

Is grainy textures and shimmering the result of poor filtering

 

[Teasy]

Hehehe... Give it up... Faf and I have tried and failed to convince 'em...

You do realise ERP was replying to me there right? When did you or Faf try to convince me of anything in this thread?

 

[archie4oz]

You do realise ERP was replying to me there right? When did you or Faf try to convince me of anything in this thread?

Yes, and with regards to Faf and myself, the comment was mostly related to the numerous time both of us have pointed this out yet it keeps coming up and not to you in particular...

Still, it looks muted, grainy and dithered compared to the rest. hey! that is exactly what i would described PS2 textures. Well, it is CLUT afterall.

Well yeah, it's supposed to look that way... I mean that's what happens when you quantize images down to that # of colors! My beef was with Simon's CLUT which had a relatively poor diffusion, and some BAD quantize errors around the face.

Taking things outta context, you mean PS2 has more bottlenecks than the poor GIF bus?

Sure... You can even create them with poor resource utilization... But then I'm sure you already new that... The same applies to all consoles...

Besides, I'm not sure the so-called "path3" connection to the EE really touches the internal EE bus. It may go straight from the DMAC to the GIF unit. I could be mistaken here, I'd have to look at the Ars Technica blackpaper on PS2 first and I am too tired to arsed to do that right now.

Well considering that the EE bus pretty much *is* path3 to the GIF, I guess you could say that it touches it. Besides both the DMAC and GIF are EE bus clients (kinda hard to circumvent, ne?)

A question, is CLUT officially supported by Sony, in PS2 hardware(like VQ in DC)? or programmers are using it since it is the least intensive format

Well considering it's a documented storage mode (not to mention that the IPU can quantize images in main mem down to IDXT8 CLUTs on the fly) I'd say yeah...

 

[Simon F]

I dont know but....the CLUT jpeg looks really depressing.

Well it's not a JPEG for one thing, however it is pretty ugly even for a 4-bit CLUT... This one is better...

4-bit CLUT

Indeed! What tool did you use? The only PC other product I had produced an even worse result than the gimp, and I think the NetPBM tools on Unix only use Heckbert's method which doesn't work well when there is only a small palette.

I've sometimes wondered if I should use the VQ compressor to just generate palettes to see if the algorithm I used could do a better job.

 

[andypski]

What would you expect them to do? I mean S3TC was debuting on S3 Savage hardware right around the time the GS was completed so it's not that wouldn've been a viable option...

I don't know exactly when the GS was completed, so I couldn't comment on the difficulties involved - Savage3D appeared around July 1998, Playstation 2 was released in March 2000. The timelines may well have been too tight to make an attempt to include S3TC. Like I said, I'm sure Sony had their reasons.

If PS2 had DXTC textures 4-bit and 8-bit CLUT textures would instantly be dead formats for almost everything except some special effects achievable by palette manipulation.

I'd have to disagree here... I think they'd still be around and in active use.

What for?

Don't get me wrong - I can see a few uses for CLUT textures where they would be more appropriate than S3TC, but there are few really general cases. One general example that does spring to mind would be textures for HUDs which might have overlapping primary colours that would compress badly with S3TC but well with a CLUT. On the other hand I would have thought that using 16-bit textures for HUD displays would cause few problems.

 

[Simon F]

It's pretty obvious from those images that 4bpp-CLUT just doesn't cut it for high-color textures, even when compared to 2bpp-VQ.

Don't forget that PS2 has 2x more memory than Dreamcast, so using 8bit clut in cases like this (which are super-rare btw, because when do you need a *texture* that looks like this picture?) is acceptable if you want to compare textures to Dreamcast.

I don't think the recent discussion was meant to be a console VS console debate, just a debate on the relative merits of various texture compression schemes .....

....but now that you mention it, PS2 may have 1.5x (not 2x, IIRC ) as much mem as DC, but DC had 2bpp textures which means that it is still better off.

Seriously though, the texture compression situation really applies more to the texture storage in GS's on-chip memory, which is why Sony themselves have recommended 4bit palette textures.

It did surprise me that Sony went with such a primitive scheme when better ones were in existence. For example, the VQ texturing paper "Rendering from compressed textures" (Beers et al) was published in Siggraph 96.

 

[Simon F]

Actually if my memory serves me right, I once read an interview with the developers of Unreal where they said that they actually deliberately chose to work exclusively with CLUT textures. I don?t remember the exact reason and it IS a old interview, but a bit curious anyhow.

It could be for software rendering support: You can arrange your LUT so that scaling the pixel index (i.e. toward zero) can make it behave as if you were scaling/shading the pixel's colour.

They also used indexed textures for their dynamic/procedural textures, i.e. like "dirty water". The software moved the pixel's indices around to cause the texture to animate. I remeber there was a discussion ages ago on one the past Beyond3D (or was it Dimension3D) boards about the relative merits of S3TC and VQTC for doing the same tricks.

I just think that on average (and that is what counts, right?) most textures in a frame from a modern videogame could easily be described with 16 colours.

Maybe, maybe not. You can still have what look like monochromatic or low chromaticity images that require quite a number of colours.... This has bitten me on the proverbial a few times in the past !

If PS2 had DXTC textures 4-bit and 8-bit CLUT textures would instantly be dead formats for almost everything except some special effects achievable by palette manipulation.

Just to back that up with another example, although Sega specifically requested that DC have support for both 8bpp and 4bpp palette textures, I think the utilisation of those modes dropped off once developers got to grips with VQ. <shrug>

 

[cybamerc]

Simon F:

> Indeed! What tool did you use?

I dunno what he used but Adobe Image Ready will produce a similar result and so will Photoshop with a little more work.

 

[marconelly!]

....but now that you mention it, PS2 may have 1.5x (not 2x, IIRC ) as much mem as DC, but DC had 2bpp textures which means that it is still better off.

Seriously though, the texture compression situation really applies more to the texture storage in GS's on-chip memory, which is why Sony themselves have recommended 4bit palette textures.

I was thinking more of the approximately available memory space for textures (8MB on DC vs. say 16 or 20 MB on PS2, because noone actually keeps textures in the GS on-chip memory, but uses it as a cache) Overal memory comparision would be 16+8 on DC and 32+4+2+2 on PS2 which is 1.7x more.

 

[Simon F]

Overal memory comparision would be 16+8 on DC and 32+4+2+2 on PS2 which is 1.7x more.

Sorry for drifting off-topic here, but what are the "2+2" blocks of memory on the PS2?

 

[Phil]

Sorry for drifting off-topic here, but what are the "2+2" blocks of memory on the PS2?

IOP and SPU2.

 

[Simon F]

IOP and SPU2.

And in English?

Seriously though, I'm hazarding a guess that the first is some form of I/O processor and the second is a sound processor. If so, just why these were included as part of the memory which could be used for textures is a little beyond me....

 

[Phil]

ahm sorry, it is Input/Output Processor (IOP) and Sound-Processing Unit 2 (SPU2).

I suppose the reason as to why it is seperated from main RAM is that it does not intefear with the other memory/buses. Basically, they are completely independend units and have their own memory to work with. That's my take, although to be more specific, I'd have to take a glimps in the hardware docs...

Also, the IOP is basically the PSX on a chip... I guess that's another reason as to why it has its own memory.

 

[Simon F]

What I meant was I didn't bother to include the DC's sound RAM since it's obviously irrelevent to texture compression, so it seemed a bit silly for the OP to mention PS2's equivalent

 

[Phil]

aha, well I suppose Marconelly! should answer that - for the sake of the comparasment, I think his statement of (16+ MB [PS2] vs 8 MB [DC]) is quite accurate. Even considering what compression methods both use, PS2 should have the edge in texturing (considering both use equal amount of geometry)..?

 

[London Geezer]

aha, well I suppose Marconelly! should answer that - for the sake of the comparasment, I think his statement of (16+ MB [PS2] vs 8 MB [DC]) is quite accurate. Even considering what compression methods both use, PS2 should have the edge in texturing (considering both use equal amount of geometry)..?

well the thing is, the PS2 would push more geometry anyway on top of that... and do we really care if a small texture is 4bpp Clut or VQ or S3TC or whatever else when there are games that exploit the other strength of the hardware such as ZOE2, and other games like SH3 with an amazing texture detail.......

well i guess it's all for the sake of argument really... :?

 

[Johnny Awesome]

But it doesn't when you look at what comes out on screen.

Seriously, that fact that DC developers used VQ over CLUT when both were available speaks volumes for which is generally more useful.

Honest question: Are there any full-3D games on the PS2 with good IQ and texture variety? ICO and MGS2 have limited colors for example, even though they have reasonably good IQ.

Many of you think that my comments about PS2 are harsh, but it's very difficult not to see the problems with PS2 texturing/filtering when you have an HDTV setup. The difference between Xbox/Cube quality vs. PS2 quality is like night and day for all but a very small handful (maybe 3-4) PS2 titles.

Geometry and particles can only get you so far when you are still using Bilinear filtering, 4bpp CLUT, very little mip-mapping, and no bump-mapping or per-pixel lighting.

To be fair though, many Xbox games that are technically good, suffer from really poor art direction (Quantum Redshift comes to mind), so I can understand why the average Joe with a regular 25" NTSC set doesn't see what I see, but it's baffling that people on this board can't tell the difference.