Thread: RE: [GD-Consoles] Textures vs. Polygons
Brought to you by:
vexxed72
From: Tom F. <to...@mu...> - 2001-11-20 15:09:25
|
DX/OGL vertex shaders have limits as well, and in some cases they're possibly lower than the VU ones. So yeah, splitting meshes up like this is something people have to do. I don't know of any magic stuff that wil help. There's detail textures - but that just adds some "noise" to things - it's good for gravel and grass and other landscape stuff, but probably not very useful for people until you get horrendously close (cloth weave, fingerprints, pores, etc). If you're aiming for ultimate realism, they will be useful, but my impression is that you're having trouble well before then. Having different bits of the body at different sizes on thetexture can work well. We always have faces take up about four times the texture area (i.e. twice as big in each direction) as equivalently-sized body parts, because people look at faces much more closely, so you notice pixellisation much quicker there than elsewhere. They're still on the same texture as the rest of the body though. For really high detail there's not much that cn beat just using a big texture. Obviously you can compress them with the S3TC/DXtn stuff for space advantages. Another compression trick I've been thinking about is to take a huge texture made by the artist, then extract the luminance as a separate texture. Then quantise it to 4 bits. Then remove that influence from the original texture, downsample the texture quite a bit down to more sensible sizes, and compress using S3TC/DXTn. Then we can render the combo using multitexture hardware. The colour and subtle gradient info is encoded in the (relatively) low-res RGB texture, and the high-frequency luminance info is in the high-res monochrome texture (some hardware may not understand A4 texture, so it might need expanding to A8 unfortunatelky). It's the same trick as used by television of course, and I believe there's a Sony sample using this method too. Tom Forsyth - Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=86 > -----Original Message----- > From: Jamie Fowlston [mailto:ja...@qu...] > Sent: 20 November 2001 11:26 > To: gam...@li... > Subject: RE: [GD-Consoles] Textures vs. Polygons > > > I had a half insane idea for character rendering on PS2. I'm > probably not > the only one who's had it, but I'll share it anyway :) > > One of the limitations on PS2 is the number of matrices you > can fit on VU > for skinning (don't worry, this will get relevant to your > problem). So to > counteract this, you could split the character geometry > according to which > matrices it uses. This way you'd never _need_ more than 3 * M > matrices on VU > at any one time (where M is the maximum number of matrices applied per > vertex). You may, of course, choose to lump in a few more matrices. > > From a texturing point of view, this should fairly naturally split the > geometry into chunks which are skinned, so you can then use > textures more > efficiently, and use several per character effectively. > > Disclaimer: I haven't actually done this :) > > Jamie > > > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On > Behalf Of R > & D (GameBrains) > Sent: 20 November 2001 06:19 > To: gam...@li... > Subject: [GD-Consoles] Textures vs. Polygons > > > List has been quiet of late and I have a semi-OT question.... > > Technology has come far enough in close-up character > rendering that the > skins for characters seem to take up too much precious space > for the quality > they show on screen and I was wondering if there are > solutions around this. > For example, when you see a character up close that has been > skinned, even > with a hi-res texture you can see pixelation around the > places like the neck > etc. and the pixel filtering makes it look really not natural > when compared > to the individually textured environments in the background. > The "easy" > solution is to not use skins, but to individually texture > each part of the > character, but then the subtle detail of clothing seams and > shadows is gone. > To get around this we could use shadow maps, decaled textures, vertex > coloring, etc. > > 1. How have others solved this problem, especially on > consoles such as the > PS2 where texture cache is limited? > 2. For those using skins, what has been a good resolution > for the skin for > consoles? For PC? > 3. Can multi-texturing and other solutions actually solve > this problem? > > Any advice that those have to offer would be welcome:) Most > of our previous > games have used rigid body objects rather than organic > characters, so we are > new to the problems that are likely old-hat to everyone else... > > Thanks! > Brett > > > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > > > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > |
From: Jacob T. (C. D. Ltd) <Ja...@Co...> - 2001-11-21 08:36:38
|
I looked into luminance splitting compression method for textures and it is a massive saving for 24-bit textures, but not that big a gain if you using 256 colour paletted textures. Just for the record we texture each face individually on a character (well actually the artists do the texturing ;-) ) and let the artists use as big a texture as they want and then we split it up into 256x256 chunks when we build the game data. This allows the freedom to put more texture detail into those parts that need it e.g. faces, hands, feet. Jake > From: Tom Forsyth <to...@mu...> > To: Jamie Fowlston <ja...@qu...>, > gam...@li... > Subject: RE: [GD-Consoles] Textures vs. Polygons > Date: Tue, 20 Nov 2001 15:07:53 -0000 > > DX/OGL vertex shaders have limits as well, and in some cases they're > possibly lower than the VU ones. So yeah, splitting meshes up > like this is > something people have to do. > > I don't know of any magic stuff that wil help. There's detail > textures - but > that just adds some "noise" to things - it's good for gravel > and grass and > other landscape stuff, but probably not very useful for > people until you get > horrendously close (cloth weave, fingerprints, pores, etc). > If you're aiming > for ultimate realism, they will be useful, but my impression > is that you're > having trouble well before then. > > Having different bits of the body at different sizes on > thetexture can work > well. We always have faces take up about four times the > texture area (i.e. > twice as big in each direction) as equivalently-sized body > parts, because > people look at faces much more closely, so you notice > pixellisation much > quicker there than elsewhere. They're still on the same > texture as the rest > of the body though. > > For really high detail there's not much that cn beat just using a big > texture. Obviously you can compress them with the S3TC/DXtn > stuff for space > advantages. Another compression trick I've been thinking > about is to take a > huge texture made by the artist, then extract the luminance > as a separate > texture. Then quantise it to 4 bits. Then remove that > influence from the > original texture, downsample the texture quite a bit down to > more sensible > sizes, and compress using S3TC/DXTn. > > Then we can render the combo using multitexture hardware. The > colour and > subtle gradient info is encoded in the (relatively) low-res > RGB texture, and > the high-frequency luminance info is in the high-res > monochrome texture > (some hardware may not understand A4 texture, so it might > need expanding to > A8 unfortunatelky). > > It's the same trick as used by television of course, and I > believe there's a > Sony sample using this method too. > > Tom Forsyth - Muckyfoot bloke. > > What's he up to now (and can I have a go)? > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > |
From: Tom F. <to...@mu...> - 2001-11-21 12:09:37
|
There is no typical size! We've tended to use 512x512 for a whole person in the past, but that was for StarTopia, which is very RTS-like in its viewpoint - you're high up, and there's lots of small people running around on the screen. For Blade2 we have something like eight 256x256 textures to cover the main character - Blade, but that's for a console title, where you just don't have enough pixels on the screen to see any higher detail. For a PC version, we'd probably upsample a few of those, because people will want to run at 10x7. Tom Forsyth - Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=86 > -----Original Message----- > From: R & D (GameBrains) [mailto:res...@ga...] > Sent: 21 November 2001 00:09 > To: gam...@li... > Subject: Re: [GD-Consoles] Textures vs. Polygons > > > Thanks to everyone for posting some help. Some follow-up.... > > 1. Tom: What is a typical size for a head texture and body skin? > 2. Jamie/Awen: Sorry, I am not clear on what you mean by > splitting the geomtry matrices, could you explain this in more detail? > > Thanks! > Brett > > > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > |
From: Alistair M. <kr...@kr...> - 2001-11-22 00:41:40
|
That's huge! We're normally using a single 512x256 texture for our main characters, which can sometimes take up to 50% of screen space when you get in close, and they still look magnificent. Lighting has a lot to do with it, adding subtlety and tint where none exists, and the fact that we're on PS2 displaying through a TV helps a lot too! On some of the more "background" filler textures, we were surprised that 4-bit palettised textures with dithering still looked really nice with a good quantisation algorithm and judicious use of lighting. The image-splitting trick you mentioned in a previous email also looks great, but we haven't used it in-game yet. If you reduce the colour map to 25% (1/16 area, that is), then use 2 bits per pixel for the detail map, you can get it down to 4 bits per pixel, which is nice. You could even reduce that further by palettising the colour map, but that can start looking messy. The really neat thing about this method is that you can get continuous level of detail by controlling the alpha value when multiplying-in the detail map. Fade out the alpha for further-away objects, and you have a visually seamless cut-off point where you don't need the detail any more. Alistair Milne Dogfish Entertainment Ltd > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Tom Forsyth > Sent: 21 November 2001 12:08 > To: R & D (GameBrains); gam...@li... > Subject: RE: [GD-Consoles] Textures vs. Polygons > > > There is no typical size! We've tended to use 512x512 for a whole > person in > the past, but that was for StarTopia, which is very RTS-like in its > viewpoint - you're high up, and there's lots of small people > running around > on the screen. For Blade2 we have something like eight 256x256 textures to > cover the main character - Blade, but that's for a console title, > where you > just don't have enough pixels on the screen to see any higher > detail. For a > PC version, we'd probably upsample a few of those, because people > will want > to run at 10x7. > > Tom Forsyth - Muckyfoot bloke. > |
From: R & D \(GameBrains\) <res...@ga...> - 2001-12-06 03:23:13
|
I was wondering if anybody knows any tips and tricks they would like to = share on using PS2 dev kits. I don't think it violates any NDA to = discuss shortcuts, etc. Specifically, when I boot my TOOL I get the network info screen. Once I = start coding it goes away. Is there an easy way to get it redisplayed? = Is there a better place to ask questions like this? I have searched the SCEE and SCEA web sites and cannot find any docs = telling you all the things and ways to use the TOOL, but if anybody = knows where such a doc lives, let me know. Cheers, Brett |
From: R & D \(GameBrains\) <res...@ga...> - 2001-11-21 00:09:25
|
Thanks to everyone for posting some help. Some follow-up.... 1. Tom: What is a typical size for a head texture and body skin? 2. Jamie/Awen: Sorry, I am not clear on what you mean by splitting the = geomtry matrices, could you explain this in more detail? Thanks! Brett |
From: Awen L. <ali...@ed...> - 2001-11-21 08:57:28
|
>2. Jamie/Awen: Sorry, I am not clear on what you mean by splitting the geometry matrices, could you explain this in more detail? Hope i'm going to describe what Jamie had in mind... Ok: objects verts/polys/etc are sorted and stripped using some criterions (polys batched on a per-material basis is a common practice). Strip best size, and neihgbouring choice, is generally choosen using many params considerations (GPU cache size ?). More specifically on a PS2, if you choose to use VU to do your mesh mathematics, the VU mem size may be one of these params. For an object, you need to compute the storage required by the VU to process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and usually a matrix or two, to rotate and light your stuff. You have to be smart with you VU and make some decisions on what could stay for a while, and what must be quickly discarded to minimize DMA traffic. Matrices may be considered more 'static' than verts flow. For an animated object your need to add some skinning consideration to that point, and configure your mesh to require the least possible matrices swapping. And it shows naturally the way you choose to strip/sort your mesh polys. Ant it's a bit related to your texture details problem, since if you NEED to split your mesh into chunks because of matrices, why not having many materials per object, if you're a king of parallelization and swapping texture buffer, text upload cost stuff may be masked. Sorry to stay a bit vague, it begins to touch some dungeon secrets, around here ;) |
From: R & D \(GameBrains\) <res...@ga...> - 2001-11-21 09:41:17
|
Awen, Thanks for explaining. We are doing as you said and stripping based = upon material already, and sorting everything else to minimize state = changes, etc. What I am not doing yet is looking at how skinning will = effect what changes I need to make to our morphing and kinematic data, = structure and the matrices. Your note has helped me forsee some stuff I = need to look at, thanks much! Brett ----- Original Message -----=20 From: "Awen Limbourg" <ali...@ed...> To: <gam...@li...> Sent: Wednesday, November 21, 2001 4:58 PM Subject: RE: [GD-Consoles] Textures vs. Polygons > >2. Jamie/Awen: Sorry, I am not clear on what you mean by splitting = the > geometry matrices, could you explain this in more detail? >=20 > Hope i'm going to describe what Jamie had in mind... > Ok: objects verts/polys/etc are sorted and stripped using some = criterions > (polys batched on a per-material basis is a common practice). Strip = best > size, and neihgbouring choice, is generally choosen using many params > considerations (GPU cache size ?). More specifically on a PS2, if you = choose > to use VU to do your mesh mathematics, the VU mem size may be one of = these > params. For an object, you need to compute the storage required by the = VU to > process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and = usually > a matrix or two, to rotate and light your stuff. You have to be smart = with > you VU and make some decisions on what could stay for a while, and = what must > be quickly discarded to minimize DMA traffic. Matrices may be = considered > more 'static' than verts flow. > For an animated object your need to add some skinning consideration to = that > point, and configure your mesh to require the least possible matrices > swapping. And it shows naturally the way you choose to strip/sort your = mesh > polys. >=20 > Ant it's a bit related to your texture details problem, since if you = NEED to > split your mesh into chunks because of matrices, why not having many > materials per object, if you're a king of parallelization and swapping > texture buffer, text upload cost stuff may be masked. > Sorry to stay a bit vague, it begins to touch some dungeon secrets, = around > here ;) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles >=20 |
From: Jamie F. <ja...@qu...> - 2001-11-21 13:45:14
|
Sounds like what I was getting at :) Nice to discover (occasionally) areas where the PC guys have more difficulty than the PS2 guys :) Jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Awen Limbourg Sent: 21 November 2001 08:58 To: gam...@li... Subject: RE: [GD-Consoles] Textures vs. Polygons >2. Jamie/Awen: Sorry, I am not clear on what you mean by splitting the geometry matrices, could you explain this in more detail? Hope i'm going to describe what Jamie had in mind... Ok: objects verts/polys/etc are sorted and stripped using some criterions (polys batched on a per-material basis is a common practice). Strip best size, and neihgbouring choice, is generally choosen using many params considerations (GPU cache size ?). More specifically on a PS2, if you choose to use VU to do your mesh mathematics, the VU mem size may be one of these params. For an object, you need to compute the storage required by the VU to process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and usually a matrix or two, to rotate and light your stuff. You have to be smart with you VU and make some decisions on what could stay for a while, and what must be quickly discarded to minimize DMA traffic. Matrices may be considered more 'static' than verts flow. For an animated object your need to add some skinning consideration to that point, and configure your mesh to require the least possible matrices swapping. And it shows naturally the way you choose to strip/sort your mesh polys. Ant it's a bit related to your texture details problem, since if you NEED to split your mesh into chunks because of matrices, why not having many materials per object, if you're a king of parallelization and swapping texture buffer, text upload cost stuff may be masked. Sorry to stay a bit vague, it begins to touch some dungeon secrets, around here ;) _______________________________________________ Gamedevlists-consoles mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles |