Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualBGB

Posted 03 December 2013 - 02:51 PM

Good question - i would also would like (to ask) - how much geometry- assets is in it and how much texture 2d data, how much video and how much sound (But geometry data amount most interesting for me)

 

in my case...

 

geometry: modest.

most small models are generally either simple solid shapes (~ < 100 triangles) to maybe a few hundred triangles.

 

a lot of my character models are around several thousand triangles, though most of this is due to occasional round shapes having used a lot of surface subdivision. a lot of commercially made models seem to get a bit more mileage out of their triangle budget.

 

generally they are animated with a skeletal system, and the animations are fairly compact data-wise.

 

 

my worlds at present are voxel based (in the 3D array of block-types sense), and generally compress down to about 20MB per km^2, but will Deflate-compress to about 6-8 MB per km^2.

the 20MB statistic is mostly due to my current "region" format using naive byte-based RLE compression.

raw uncompressed voxel data would be around 1GB per km^2, so most of it generally needs to be kept in a compressed form when not in use.

 

geometry requirements tend to be small vs the voxel data involved (despite triangles being much bigger than voxels, there are much fewer of them, as the vast majority of the voxels don't end up contributing any geometry).

 

 

most sound effects are short, and compressed with a custom audio codec (block-based, CBR, 88/132/176 kbps).

there is about 12MB of audio data in this form.

uncompressed, there is probably somewhere around 1 hour worth of sound effects.

 

 

most of my textures are anywhere from 128x128 to 512x512, with some smaller (32x32 or 64x64), or larger (1k to 4k, *).

*: generally, my large textures are for things like grass, which cover a several-meter area.

 

for release, the textures are generally compressed with an extended JPEG variant (with alpha support and similar). they are decompressed and converted to DXTn on load. so, it is about 30MB worth of JPEGs.

 

the amount of space required for texture data would be a fair bit larger if DDS were used instead of JPEG.

 

 

 

I also have some number of video textures (~ 26), currently mostly using custom codecs.

 

previously, most were using an extended M-JPEG variant, but this has being displaced by another codec (*2).

like with normal textures, video textures tend to range from 128x128 to 512x512, with 256x256 being most common.

 

*2: BTIC1C, which is basically an extended form of Apple Video / RPZA, mostly with extensions useful to texturemaps (alpha and mipmaps), and optional (not-backwards-compatible) tweaks to improve compression. a considered extension has been supporting cube-map videos, but this hasn't yet been done. theoretically, it could also be used for textures.


#2BGB

Posted 03 December 2013 - 02:42 PM

Good question - i would also would like (to ask) - how much geometry- assets is in it and how much texture 2d data, how much video and how much sound (But geometry data amount most interesting for me)

 

in my case...

 

geometry: modest.

most small models are generally either simple solid shapes (~ < 100 triangles) to maybe a few hundred triangles.

 

a lot of my character models are around several thousand triangles, though most of this is due to occasional round shapes having used a lot of surface subdivision. a lot of commercially made models seem to get a bit more mileage out of their triangle budget.

 

generally they are animated with a skeletal system, and the animations are fairly compact data-wise.

 

 

my worlds at present are voxel based (in the 3D array of block-types sense), and generally compress down to about 20MB per km^2, but will Deflate-compress to about 6-8 MB per km^2.

the 20MB statistic is mostly due to my current "region" format using naive byte-based RLE compression.

raw uncompressed voxel data would be around 1GB per km^2, so most of it generally needs to be kept in a compressed form when not in use.

 

geometry requirements tend to be small vs the voxel data involved (despite triangles being much bigger than voxels, there are much fewer of them, as the vast majority of the voxels don't end up contributing any geometry).

 

 

most sound effects are short, and compressed with a custom audio codec (block-based, CBR, 88/132/176 kbps).

there is about 12MB of audio data in this form.

uncompressed, there is probably somewhere around 1 hour worth of sound effects.

 

 

most of my textures are anywhere from 128x128 to 512x512, with some smaller (32x32 or 64x64), or larger (1k to 4k, *).

*: generally, my large textures are for things like grass, which cover a several-meter area.

 

for release, the textures are generally compressed with an extended JPEG variant. they are decompressed and converted to DXTn on load.

 

the amount of space required for texture data would be a fair bit larger if DDS were used instead of JPEG.

 

 

 

I also have some number of video textures (~ 26), currently mostly using custom codecs.

 

previously, most were using an extended M-JPEG variant, but this has being displaced by another codec (*2).

like with normal textures, video textures tend to range from 128x128 to 512x512, with 256x256 being most common.

 

*2: BTIC1C, which is basically an extended form of Apple Video / RPZA, mostly with extensions useful to texturemaps (alpha and mipmaps), and optional (not-backwards-compatible) tweaks to improve compression. a considered extension has been supporting cube-map videos, but this hasn't yet been done. theoretically, it could also be used for textures.


#1BGB

Posted 03 December 2013 - 02:41 PM

Good question - i would also would like (to ask) - how much geometry- assets is in it and how much texture 2d data, how much video and how much sound (But geometry data amount most interesting for me)

 

in my case...

 

geometry: modest.

most small models are generally either simple solid shapes (~ < 100 triangles) to maybe a few hundred triangles.

 

a lot of my character models are around several thousand triangles, though most of this is due to occasional round shapes having used a lot of surface subdivision. a lot of commercially made models seem to get a bit more mileage out of their triangle budget.

 

generally they are animated with a skeletal system, and the animations are fairly compact data-wise.

 

 

my worlds at present are voxel based (in the 3D array of block-types sense), and generally compress down to about 20MB per km^2, but will Deflate-compress to about 6-8 MB per km^2.

the 20MB statistic is mostly due to my current "region" format using naive byte-based RLE compression.

raw uncompressed voxel data would be around 1GB per km^2, so most of it generally needs to be kept in a compressed form when not in use.

 

geometry requirements tend to be small vs the voxel data involved (despite triangles being much bigger than voxels, there are much fewer of them, as the vast majority of the voxels don't end up contributing any geometry).

 

 

most sound effects are short, and compressed with a custom audio codec (block-based, CBR, 88/132/176 kbps).

there is about 12MB of audio data in this form.

uncompressed, there is probably somewhere around 1 hour worth of sound effects.

 

 

most of my textures are anywhere from 128x128 to 512x512, with some smaller (32x32 or 64x64), or larger (1k to 4k, *).

*: generally, my large textures are for things like grass, which cover a several-meter area.

 

for release, the textures are generally compressed with an extended JPEG variant. they are decompressed and converted to DXTn on load.

 

the amount of space required for texture data would be a bit larger if DDS were used instead of JPEG.

 

 

 

I also have some number of video textures (~ 26), currently mostly using custom codecs.

 

previously, most were using an extended M-JPEG variant, but this has being displaced by another codec (*2).

like with normal textures, video textures tend to range from 128x128 to 512x512, with 256x256 being most common.

 

*2: BTIC1C, which is basically an extended form of Apple Video / RPZA, mostly with extensions useful to texturemaps (alpha and mipmaps), and optional (not-backwards-compatible) tweaks to improve compression. a considered extension has been supporting cube-map videos, but this hasn't yet been done. theoretically, it could also be used for textures.


PARTNERS