gdalgorithms-list

[Algorithms] Character customization Vs Number of primitives

[Benjamin R. <ben...@gm...>]

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

Re: [Algorithms] Character customization Vs Number of primitives

[Matt J <mjo...@gm...>]

They use segmented meshes? I'd be interested in how they do it using seamless..

Matthew

> 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

Re: [Algorithms] Character customization Vs Number of primitives

[Sylvain G. V. <vi...@ii...>]

There's a free unofficial WoW model viewer if you want to get an idea
how they do. Several of the customization only alter textures. A few
create additional meshes.

A simple way is to have as many different customization in big atlas
textures so that you just use UV shifting for most stuff.

If you need additional meshes, you may try to use common lods (like only
1 body armor at lod level 1 instead of 10 at lod level 0) for further
character and to merge most used armors and bodies together in a new
vertex buffer.
For even further object the armor could be always displayed, but on an
aditionnal bone which matrix will be scaled down a lot when the armor
must be hidden.

The goal is to display as few fully detailed characters, and for those
happy fews that stay quite long near the camera, you may want to
generate a new VB.

That's just a few ideas to extend...

----- Original Message -----
From: Matt J <mjo...@gm...>
Date: Wednesday, June 13, 2007 11:49 am
Subject: Re: [Algorithms] Character customization Vs Number of primitives
To: Game Development Algorithms <gda...@li...>

> They use segmented meshes? I'd be interested in how they do it 
> using seamless..
> 
> Matthew
> 
> > 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-list
> 

Re: [Algorithms] Character customization Vs Number of primitives

[Megan F. <sha...@gm...>]

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-list
>


-- 
Megan Fox
Idyllon, LLC
http://www.shalinor.com/
http://www.idyllon.com/

Re: [Algorithms] Character customization Vs Number of primitives

[Jay P. <Jp...@bl...>]

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=3Dgdalgorithms-li=
s
t
>


--=20
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=3Dgdalgorithms-li=
s
t

Re: [Algorithms] Character customization Vs Number of primitives

[Chris L. <cla...@fl...>]

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: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

Re: [Algorithms] Character customization Vs Number of primitives

[Chris L. <cla...@fl...>]

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: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

Re: [Algorithms] Character customization Vs Number of primitives

[Benjamin R. <ben...@gm...>]

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: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
>

Re: [Algorithms] Character customization Vs Number of primitives

[Chris L. <cla...@fl...>]

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 

 

Re: [Algorithms] Character customization Vs Number of primitives

[Jon W. <hp...@mi...>]

Benjamin Rouveyrol wrote:
> - 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.

We built a system to do #2, including a designated artist stick to make 
sure they don't go overboard. Then we're actually running it in mode #1, 
and it works fine. We target 30 fps on some pretty low-end hardware, too.

Cheers,

       / h+

Re: [Algorithms] Character customization Vs Number of primitives

[Ivan-Assen I. <iva...@gm...>]

> 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)....

30 characters times 6 (1 body + 5 armor?) times 4 passes (color,
shadowing, glow, lighting) = 720 draw calls per frame. That's
perfectly reasonable - don't overengineer until you can prove this is
a bottleneck.

We have a mode in our engine where we draw just the first triangle
from each drawcall to judge whether we're drawcall- or something
else-limited.

Best regards,
Assen

Re: [Algorithms] Character customization Vs Number of primitives

[Benjamin R. <ben...@gm...>]

On 13/06/07, Ivan-Assen Ivanov <iva...@gm...> wrote:
>
> > 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)....
>
> 30 characters times 6 (1 body + 5 armor?) times 4 passes (color,
> shadowing, glow, lighting) = 720 draw calls per frame. That's
> perfectly reasonable - don't overengineer until you can prove this is
> a bottleneck.
>
> We have a mode in our engine where we draw just the first triangle
> from each drawcall to judge whether we're drawcall- or something
> else-limited.
>
> Best regards,
> Assen
>

Agreed, but to the 720 Draw calls, you should add the rest of the scene, the
GUI, the FX ...
This could still be reasonable, but we are also targeting vs_1_1 machines
where you can only render 20 bones per draw call. Since most of our
characters will have ~45-50 bones, this would lead to a much bigger number
of draw calls. It's true that we are not draw-call limited yet, but
optimizing the texture available is often easier than optimizing the number
of draw calls.

Ben