Re: [Algorithms] Character customization Vs Number of primitives
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Character customization Vs Number of primitives
|
From: Chris L. <cla...@fl...> - 2007-06-13 22:04:10
|
Hi Benjamin,
By blend commands, I mean our tokenized command buffer of blend operations.
Instead of reading 8-bit mask texture pixels to calculate the blend amount
(and method) at runtime, we have a preprocess step for a given blend
texture:
- Load the 8-bit mask texture
- Determine each 4x4 block's mask overlap type (fully black or fully white,
or everything else)
- String together as many same-type contiguous blocks as possible into a
single command:
- For fully black or fully white blocks, just perform a copy
from one of the inputs
- For blocks that aren't solid white or black, decompress
the block for blending and recompress after
So the optimized, preprocessed blend command list is simply a series of
commands like "memcpy dest for 2480 blocks, blend for 1 block, memcpy src
for 120 blocks, blend for 60 blocks, etc." This sort of operation really
lends itself to worker threads, and you can parallelize the different
texture types, too.
-Chris
From: gda...@li...
[mailto:gda...@li...] On Behalf Of
Benjamin Rouveyrol
Sent: Wednesday, June 13, 2007 1:13 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Character customization Vs Number of primitives
That's really interesting. We were wondering whether we would work in
uncompressed space and then compress the whole image, or else directly work
in compressed space. Looks like decompressing / blending / recompressing
only the blocks needing the blend is a good trade-off.
One thing I don't understand: "The blend commands are generated offline". By
"the blend commands", you mean the functions that will be used during
blending ?
On 13/06/07, Chris Lambert <cla...@fl...> wrote:
I should clarify. For performance and quality reasons, we don't blend in
DXT compressed space anymore. We tokenize the blend operation into a serial
list of commands. That is, if n contiguous 4x4 blocks don't require a blend
(since they lay fully inside or outside the mask area), they are simply
copied in a large chunk. Only the blocks that overlap the mask edges are
decompressed, blended, and recompressed. The blend commands are generated
offline. The blend operation takes place in a worker thread.
-Chris
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...] On Behalf Of
> Chris Lambert
> Sent: Wednesday, June 13, 2007 11:51 AM
> To: 'Game Development Algorithms'
> Subject: Re: [Algorithms] Character customization Vs Number of
> primitives
>
> What Jay said. We do our texture blends (often during gameplay, due to
> equipping different armor bits) in DXT compressed space on worker
> threads.
> In addition, we do a final colorization step on the albedo texture,
> also in
> another thread.
>
> Similar requirements: fixed resolution for the slots, fixed texture
> format
> per texture type (albedo, specular, etc.).
>
> We only split batches for shaders/materials (eg, skin vs. metal) and
> bone
> counts.
>
> -Chris
>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto: <mailto:gda...@li...>
gda...@li...] On Behalf Of
> > Jay Patel
> > Sent: Wednesday, June 13, 2007 10:02 AM
> > To: Game Development Algorithms
> > Subject: Re: [Algorithms] Character customization Vs Number of
> > primitives
> >
> > What Megan said. Then add in a VB optimize and texture compress step
> in
> > a separate thread.
> >
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li... ] On Behalf Of
> > Megan Fox
> > Sent: Wednesday, June 13, 2007 9:23 AM
> > To: Game Development Algorithms
> > Subject: Re: [Algorithms] Character customization Vs Number of
> > primitives
> >
> > If it's something that's fixed for a given scene post-load, the most
> > direct approach would be to store each texture separately, and
> > construct them all into a single (or multiple) atlas(es), and then
> > make a single mesh per player out of the parts.
> >
> > For a similar system but with no bound on number of potential
> > customizations / characters in a scene (eg. RPG), we just built a
> > system to merge part textures into a per-character atlas, and
> > similarly, merge mesh parts into a per-character single mesh. For
> the
> > sake of sanity, we just required that each "part" have a texture that
> > met with a particular dimensional requirement for all variants of
> that
> > part (head, arms, legs, whatever), and then we basically did a giant
> > photoshop merge operation to flatten all the bits into a single
> > texture, where we always knew that the arm texture could be found
> > within rectangle X or whatever else. That saved us the work of
> > offsetting the UVs in the mesh, they could be fixed.
> >
> > Note that thinking of it like a photoshop merge has another advantage
> > - you can do some rather incredible tinting with creative use of
> > "layers," amongst other things. It's a great deal more flexible when
> > you can just have a grey "base" for a part, and then a couple of
> > different color mask textures to apply over it to add detail.
> >
> > On 6/13/07, Benjamin Rouveyrol < ben...@gm...> wrote:
> > > Hi all,
> > >
> > > The game I'm working on has around 30 customizable characters that
> > will be
> > > displayed during a match.
> > >
> > > Each character has an armor, made by 5 different fragments (arm,
> > legs,
> > body,
> > > head, name). The first 4 fragments have 3 different levels (81
> > different
> > > possibilities) and the name is unique. I was wondering how you guys
> > deal
> > > with this kind of customization. I see two options (I may be
> missing
> > other
> > > solutions though :) ):
> > > - Have different primitives for each fragment: I'm afraid that the
> > number of
> > > draw calls would increase a lot, since each character will also be
> > rendered
> > > for shadowing, for lighting and for glowing, but the textures will
> be
> > shared
> > > in memory
> > > - Group all the different primitives into one single primitive:
> this
> > will
> > > reduce the number of draw calls, but the textures must be grouped
> > together
> > > into a single texture, that may never be shared (and there are
> > > diffuse/normal/gloss textures for every characters) and the memory
> > cost can
> > > become huge if the artists want a pretty big resolution.
> > >
> > > When I see games like World of Warcraft where the number of
> > characters
> > is
> > > pretty big, and the customization can be important, I assume that
> I'm
> > > missing something :) .
> > >
> > > Any wisdom to share about this ?
> > >
> > > Thanks,
> > >
> > > Ben
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> --
> > -
> > -
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > GDAlgorithms-list mailing list
> > > GDA...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > > Archives:
> > >
> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> > lis
> > t
> > >
> >
> >
> > --
> > Megan Fox
> > Idyllon, LLC
> > http://www.shalinor.com/
> > http://www.idyllon.com/
> >
> > ---------------------------------------------------------------------
> --
> > -
> > -
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> > lis
> > t
> >
> > ---------------------------------------------------------------------
> --
> > --
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> > list
>
>
> -----------------------------------------------------------------------
> --
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> list
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
|
