"Yes, but how many polygons?" An artist blog entry with interesting numbers

[Cloofoofoo]

@Cloofoofoo please post the same info about the test of Soul Calibur 2 models and textures on Dreamcast that you posted on Sega 16 forum! Technically is a real proof SC2 could run on DC!

Not sure why you're getting so excited but yeah someone was working on exporting a couple of models to test how soul calibur 2 models run on DC. They exported to DC the snake pit , running 2 Siegfried models plus 2 soul edge on screen. Runs at steady 30 fps . Models and textures are from the Xbox version.

Probably with some downgradign it would run fine.

 

[Newguy]

Is it possible what someone can upload some screenshots and data obot polygon count from Everquest, Everquest 2, Guild Wars, Guild Wars 2, World of Warcraft Classic, World of Warcrafr Retail and The Elder Scrolls Online?

I can do some wow classic/vanilla ones, anything in particular?

 

[Newguy]

Some bosses now, Ragnaros, Hakkar, C'thun and Kel'thuzad poly count and wireframe. Notice the character scale difference from the floor too

 

[xaeroxcore]

Not sure why you're getting so excited but yeah someone was working on exporting a couple of models to test how soul calibur 2 models run on DC. They exported to DC the snake pit , running 2 Siegfried models plus 2 soul edge on screen. Runs at steady 30 fps . Models and textures are from the Xbox version.

Probably with some downgradign it would run fine.

I´m not a technical person, and know nothing about coding, programming games or whatever related....So i must ask, how close is this to maybe put some form of SC2 playable on actual DC?

 

[Cloofoofoo]

I´m not a technical person, and know nothing about coding, programming games or whatever related....So i must ask, how close is this to maybe put some form of SC2 playable on actual DC?

Not even close? No animation, physics or any of it's logic, ai. It's the models textured and lit. The person who did this isn't planning on making it playable it was just a test.

 

[Nesh]

Not sure why you're getting so excited but yeah someone was working on exporting a couple of models to test how soul calibur 2 models run on DC. They exported to DC the snake pit , running 2 Siegfried models plus 2 soul edge on screen. Runs at steady 30 fps . Models and textures are from the Xbox version.

Probably with some downgradign it would run fine.

30fps you wouldnt call it fine for a fighting game

 

[function]

30fps you wouldnt call it fine for a fighting game

It's probably double buffered, so anything less than 60 becomes 30.

@Cloofoofoo didn't actually say it ran fine, he said that with some downgrading it probably would. Using two of the same character (as in this hackerbro's test) would have saved a good amount of main ram and vram. It seems likely that some reduction in textures and model geometry from the Xbox version which was used here would have been needed to get two characters and SC2 stages all nicely into DC ram.

 

[Nesh]

It's probably double buffered, so anything less than 60 becomes 30.

@Cloofoofoo didn't actually say it ran fine, he said that with some downgrading it probably would. Using two of the same character (as in this hackerbro's test) would have saved a good amount of main ram and vram. It seems likely that some reduction in textures and model geometry from the Xbox version which was used here would have been needed to get two characters and SC2 stages all nicely into DC ram.

Did the XBOX version differ in Geometry from the PS2 version?

 

[function]

Did the XBOX version differ in Geometry from the PS2 version?

Dunno! All I know is that at some early point SC2 was being made with DC in mind.

It actually won an official poll of preferred platforms. Won the poll. Was the only platform on the poll that didn't get the game.

 

[Cloofoofoo]

It's probably double buffered, so anything less than 60 becomes 30.

@Cloofoofoo didn't actually say it ran fine, he said that with some downgrading it probably would. Using two of the same character (as in this hackerbro's test) would have saved a good amount of main ram and vram. It seems likely that some reduction in textures and model geometry from the Xbox version which was used here would have been needed to get two characters and SC2 stages all nicely into DC ram.

eh you kinda assumed wrong it's two instances loaded of the same character true but it's more for simplicity sakes , there's more than enough ram to hold more models and textures.( If anything he mentioned he had loaded at least 3 unused models/ it's textures) in ram before he cleaned up code)There was no reduction in geometry from the Xbox version and there's two transparent sould edges on screen. The stage can be completely zoomed out and performance stays rock solid 30 fps. All textures all default expect for about 3 textures which where changed from 1024*512 to 128 * 64. DC can only efficiently compress square textures ( basically a 1024*1024 16bit texture can be compressed from 1mb to less than 100kb but cannot do that for rectangles).

The scene has 3 light sources ( 1 for the stage and 2 for the character) and a complexity of about 45k triangles ( around 62k vertices for the scene zoomed out culled down to around 45k) . The model complexity is exactly as it was for Xbox in these scenes.

You mistook my comment for something else. I was saying DC handles this kind of geometry without flinching at 30 fps but to reach 60 fps redoing the assets would definitely be a must.

 

[Cloofoofoo]

It

n
30fps you wouldnt call it fine for a fighting game

It's probably not a big issue you're making it out to be but for this existing franchise they would probably have to rework the animations since iam pretty sure they are likely to be tied around 60 fps. Not a small under taking I bet.

Even vf has ran below 60fps using the same animations in the case of the 32x version. It's just a matter of designing around it. Wouldn't be the first time a fighting game is 30 fps

 

[TapamN]

DC can only efficiently compress square textures ( basically a 1024*1024 16bit texture can be compressed from 1mb to less than 100kb but cannot do that for rectangles).

The PVR can handle compressed non-square textures if you don't use mipmaps. If there's a requirement that a non-mipmapped texture must be square when compressed, that's an engine/file format problem. I know the official .PVR texture file format has very limited support for small codebook compressed textures, so maybe it has other problems. Only mipmapped textures (compressed or not) are required by the hardware to be square, but you REALLY want mipmaps for anything that's minified. I did a test a while ago to see how texture format (bit depth, compression, mips) affects rendering speed (the scene I used was the first image here), I got these timings:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
 9.49 ms (16 bit uncompressed with mips)
 9.20 ms (16 bit VQ with mips)
 8.80 ms (8 bit VQ with mips)
 8.61 ms (16 bit small codebook VQ with mips)
 8.53 ms (4 bit uncompressed with mips)
 8.53 ms (4 bit VQ with mips)
 7.91 ms (4 bit small codebook VQ with mips)
 7.81 ms (Untextured)
(Small codebook means using a 512 byte codebook instead of 2048, to reduce texture cache misses on compressed textures.)

The timing would be very dependent on the scene, but for this one, no mips 640x480 was 19.7 ms and adding mips dropped the render time to 9.2 ms. 1280x480 with mipmaps (12.78 ms) was faster than 640x480 without mipmaps.

Also, an uncompressed 1024x1024 16-bit texture without mips is 2MB, not 1MB. Compressed would be 258 KB. Adding mips would be 344 KB.

If you want to know how large a compressed texture is, use these formulas:

  No mips: size_bytes = w * h * bytes_per_pixel / 8 + codebook_size
With mips: size_bytes = w * w * bytes_per_pixel * 4/3 / 8 + codebook_size + 1

Codebook_size is typically 2048, but can be less to help compression ratio or performance at the cost of texture quality.

The arcade version of VF1 was also 30 FPS, so the 32X version was arcade accurate in that area. If you made a DC version of SC2, you'd want lower poly models to keep 60 FPS.

 

[Cloofoofoo]

The PVR can handle compressed non-square textures if you don't use mipmaps. If there's a requirement that a non-mipmapped texture must be square when compressed, that's an engine/file format problem. I know the official .PVR texture file format has very limited support for small codebook compressed textures, so maybe it has other problems. Only mipmapped textures (compressed or not) are required by the hardware to be square, but you REALLY want mipmaps for anything that's minified. I did a test a while ago to see how texture format (bit depth, compression, mips) affects rendering speed (the scene I used was the first image here), I got these timings:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
 9.49 ms (16 bit uncompressed with mips)
 9.20 ms (16 bit VQ with mips)
 8.80 ms (8 bit VQ with mips)
 8.61 ms (16 bit small codebook VQ with mips)
 8.53 ms (4 bit uncompressed with mips)
 8.53 ms (4 bit VQ with mips)
 7.91 ms (4 bit small codebook VQ with mips)
 7.81 ms (Untextured)
(Small codebook means using a 512 byte codebook instead of 2048, to reduce texture cache misses on compressed textures.)

The timing would be very dependent on the scene, but for this one, no mips 640x480 was 19.7 ms and adding mips dropped the render time to 9.2 ms. 1280x480 with mipmaps (12.78 ms) was faster than 640x480 without mipmaps.

Also, an uncompressed 1024x1024 16-bit texture without mips is 2MB, not 1MB. Compressed would be 258 KB. Adding mips would be 344 KB.

If you want to know how large a compressed texture is, use these formulas:

  No mips: size_bytes = w * h * bytes_per_pixel / 8 + codebook_size
With mips: size_bytes = w * w * bytes_per_pixel * 4/3 / 8 + codebook_size + 1

Codebook_size is typically 2048, but can be less to help compression ratio or performance at the cost of texture quality.

The arcade version of VF1 was also 30 FPS, so the 32X version was arcade accurate in that area. If you made a DC version of SC2, you'd want lower poly models to keep 60 FPS.

Thank you tapamn for dropping knowledge like always.

I was just saying 1 mb because thw 3 to 4 texture he had to replace were 1024*512. So I just did rough !ath of h x w x 2 byte( 16bit color) . You're right about the 1024 * 1024 size, I guess I was going off memory of 512 x 512 vq which is like 70s kb.

I suspect he's probably using DC era official converters which probably don't allow ( winpvr I think he mentioned) which might not allow export of non square vq.

That's even better so it's originally was 30 fps then reworked the same animations to suit a 60 fps for the sequel. It really is about developers effort but I really doubt they would have gone out their way to make two different versions with different timings for sc2dc case. Like you said about 60 fps , it probably would have been a graphical hit

 

[function]

The PVR can handle compressed non-square textures if you don't use mipmaps.

Awesome post dude. This bit stuck out. Do you think this might be a reason some games don't use mipmaps on some/all textures?

I'd always put it down to the ~33% more memory needed for mipmaps, but if rectangular textures were the best memory / IQ tradeoff that might mean that in some cases mipmaps were simply unavailable.

 

[Cloofoofoo]

Awesome post dude. This bit stuck out. Do you think this might be a reason some games don't use mipmaps on some/all textures?

I'd always put it down to the ~33% more memory needed for mipmaps, but if rectangular textures were the best memory / IQ tradeoff that might mean that in some cases mipmaps were simply unavailable.

Or you could just break up the problem texture into two smaller square texture and redo the uv mapping. It's not really an issue. It's what the ps2 did with the wall texture for soul calibur 2 instead of having the same Rez as Xbox.

 

[milk]

Probably many devs simply prefer the aliasing and shimmer from no mips over the over blurring from lack of aniso.

 

[Liandry]

I can do some wow classic/vanilla ones, anything in particular?

Thanks for info you already posted. That's great. Interesting what characters so low poly. Maybe you can post some info for other races in game, some mobs and objects? Also interesting to know if that possible average polycount for one scene, I mean how many polygons are on screen.

 

[Sonicfan]

The PVR can handle compressed non-square textures if you don't use mipmaps. If there's a requirement that a non-mipmapped texture must be square when compressed, that's an engine/file format problem. I know the official .PVR texture file format has very limited support for small codebook compressed textures, so maybe it has other problems. Only mipmapped textures (compressed or not) are required by the hardware to be square, but you REALLY want mipmaps for anything that's minified. I did a test a while ago to see how texture format (bit depth, compression, mips) affects rendering speed (the scene I used was the first image here), I got these timings:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
 9.49 ms (16 bit uncompressed with mips)
 9.20 ms (16 bit VQ with mips)
 8.80 ms (8 bit VQ with mips)
 8.61 ms (16 bit small codebook VQ with mips)
 8.53 ms (4 bit uncompressed with mips)
 8.53 ms (4 bit VQ with mips)
 7.91 ms (4 bit small codebook VQ with mips)
 7.81 ms (Untextured)
(Small codebook means using a 512 byte codebook instead of 2048, to reduce texture cache misses on compressed textures.)

The timing would be very dependent on the scene, but for this one, no mips 640x480 was 19.7 ms and adding mips dropped the render time to 9.2 ms. 1280x480 with mipmaps (12.78 ms) was faster than 640x480 without mipmaps.

Also, an uncompressed 1024x1024 16-bit texture without mips is 2MB, not 1MB. Compressed would be 258 KB. Adding mips would be 344 KB.

If you want to know how large a compressed texture is, use these formulas:

  No mips: size_bytes = w * h * bytes_per_pixel / 8 + codebook_size
With mips: size_bytes = w * w * bytes_per_pixel * 4/3 / 8 + codebook_size + 1

Codebook_size is typically 2048, but can be less to help compression ratio or performance at the cost of texture quality.

The arcade version of VF1 was also 30 FPS, so the 32X version was arcade accurate in that area. If you made a DC version of SC2, you'd want lower poly models to keep 60 FPS.

I think, If anything, they'd drop the polys of the background elements to keep the 60fps up before making the player models suffer first. More attention would be on the player models than the stages on average in a fighter.

 

[Shifty Geezer]

Probably many devs simply prefer the aliasing and shimmer from no mips over the over blurring from lack of aniso.

Modern kids don't understand what we suffered through. They have all the fancy graphics without having earned them, and so they can't respect them.

 

[Deleted member 11852]

Modern kids don't understand what we suffered through. They have all the fancy graphics without having earned them, and so they can't respect them.

I used to play my Atari 2600 on a 14" B&W TV and you could see individual pixels literally from 40ft away. I also used to walk to and from school each way, which involved traversing a 2,000 ft mountain full of wolves.