Brett (ggtgp@yahoo.com) on 3/15/11 wrote:
---------------------------
>Seni (seniike@hotmail.com) on 3/15/11 wrote:
>---------------------------
>>Brett (ggtgp@yahoo.com) on 3/15/11 wrote:
>>---------------------------
>>>Multi-texturing helps dramatically here, this allows you to separate the high frequency
>>>texture changes from the low, so your texture does not look like mud.
>>>The classic example is shirt/pants textures, you have a cloth texture, but you
>>>also need the pockets to stand out, and some pre-backed shadows in the arm pits.
>>>As one combined texture this will look like crap after compression, as two or three
>>>or more separate textures the character will start looking good.
>>>(You also may need a gloss map for metal armor, etc.)
>>
>>You're doing it wrong. The pocket is a separate piece of cloth and should have its own separate polygon sheet.
>>It will stand out automatically, because it has different surface normals where
>>it meets the underlying cloth, and thus responds differently to the lighting.
>>
>>Trying to flatten this into a texture like you have a polygon shortage or something is just lame.
>
>The poly count for a character in my last game (PS2 era) was 1,500.
>You would use that many polys for the pocket to get it to look right.

PS2 era was a long time ago. Most of the limitations the PS2 had no longer apply.
If you still do things the way you did on the PS2, your graphics will look like PS2 graphics.

>>>Give me some 1 bit textures and I will give you a game with graphics that will make your jaw drop.
>>
>>I have just given you 0-bit textures. But given your short-sightedness and total
>>lack of vision, I'm not expecting anything jawdropping.
>
>Your 0-bit texture requires more bandwidth than a 32 bit texture for all the geo.

Could you show the calculations behind this claim? It doesn't seem plausible to me.

I figure about 20 vertices per average letter is probably sufficient for a reasonable font. And the screen resolution will be about two million pixels.
Let's say you have a sign that says "BIG SALE 10% OFF" and takes up about 5% of the screen.

>Using a full font system pipeline would reduce the bandwidth,
>but the computational and cache demands of a font pipeline would kill you.
>
>Maybe a decade from now this will be possible, but 1 bit textures could be done TODAY.
>
>All you need is one instruction, which I would call flag expand.
>It would expand 4 bits out to 4 masks of 32 bits, so you could do a select on the the two colors.
>Would fit perfectly in todays GPU pipelines, even without a good flag expand instruction
>you can write the code to do this today.
>Your texture fetch shader program grabs flags and expands that out to colors.
>
>I have to wonder why people are not doing this today.

If you mean Nvidia and ATI, it's because they don't care about this particular issue.
Could be that no one ever brought it up. Maybe if you talk to them you can get it supported in DX13 or 14.
Or could be they've done tests and found it makes no real difference to rendering times and isn't worth the bother.

>>>>3) Dynamic/runtime-computed textures. These are Z-buffers, frame buffers, shadow
>>>>maps, environment maps, etc. These tend to be uncompressed, or minimally compressed
>>>>by the shaders (maybe Z-compression works here?).
>>>>
>>>>I always assumed that #3 used most of the texture bandwidth on modern engines,
>>>>due to the lack of compression and (sometimes) lack of mip-mapping.
>>>
>>>#3 dominates by an order of magnitude, sometimes two orders of magnitude.
>>>On a high end stealth shooter you have to support things like shooting out lights.
>>
>>This "problem" was solved years ago by dynamic lighting. Even Doom 3 lets you
>turn lights on and off without problems.
>>Why are you still using an obsolete technique and then complaining about its known flaws?
>>
>>It's like "My horse is too slow to keep up with traffic on the highway!" Stop riding a horse and get a car.
>
>Worked at a port house in the PS2 and Wii era.
>This hardware was not fast enough to run a modern PC game engine.
>Just trying to give people an idea of the complexity involved in rendering.

Ok, I see where you're coming from.
The PS2 was IIRC released in 1999 or 2000.
Since then, we've gone through 5 or 6 generations of process tech, so now you can fit 32-64 times as much stuff on a GPU. And clock it 2-3 times faster.
So vertex counts, fillrates, and so on have increased by a factor of about 100.

Going from 100 vertices per model to 10,000 per model is a big change. It requires a change in the way you do the artwork.