Author Topic: MNG: The Good, the Bad, and the Ugly  (Read 5577 times)

0 Members and 1 Guest are viewing this topic.

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: MNG: The Good, the Bad, and the Ugly
To be more precise, the requirements are:
1. full support for 32 bits of rgba colour depth
2. Compression. Resulting file size should be less than an equivalent eff with png files.
3. The reader must be compatible with the eff/ani code.
4. Keyframe support similar to .ani

If you can write that, please, go ahead.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: MNG: The Good, the Bad, and the Ugly
well what i was thinking of would not do #1. really i kinda think 32bit rgba sounds overkill.

what i had in mind is this:
use a block compression system similar to dxt1a. these blocks would be 4*4 pixels and take up 8 bytes for 4 bits per pixel. these blocks use 16 bit (565) color and thus would not be 32 bit rgba, but still much better than 8 bit.
blocks would contain 2 5'6'5 colors, and a 2 bit color index per pixel (two other colors would be interpolated at decode time)

format:
-file
 -animation header
  -frame header
   -blocks

animation header would contain:
 image resolution -desired resolution in pixels
 block resolution -desired resolution in blocks (will be greater than or equal to resolution/4, difference will be used to mask unused block pixels as transparent)
 framerate -frames a sec
 animation length -in frames
 keyframe definitions -not sure how to approach this part yet (im thinking offset of the frame header and some kind of identifier)

frame header:
 block map (size would be (brx*bry)/8 bytes) -would contain a 1-bit map of the image blocks, logical true bits would indicate blocks that are contained in the frame. on keyframes all blocks would need to be updated and the map would contain all ones (except for unused bits).
 blocks -the compressed 4x4 blocks. at render the block map's bits will be iterated through, and for each 1 encountered the next block in the sequence will be read, decompressed, and rendered to buffer at coords derived by the bit index of the block map and data from the header.

mind you this is just a preliminary outline. i dont want to design the whole format if it wast going to be utilized. i figure compression will be better than dxt1a in a container format. i may also look into other block compression algorithms to see if i couldnt find something better, though that would not change the rest of the format. using the dxt1a style blocks would only supports 1 bit transparency. it would support looping but would mostly be intended for forward playback from any keyframe or loopback to any keyframe. streaming should be possible, provided the header is loaded and the animation sequence instance is initialized. nothings coded yet, but this isnt the first time i came up with a file format from scratch.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • I release things
    • Steam
    • Twitter
    • Mix-Hai Productions
Re: MNG: The Good, the Bad, and the Ugly
using the dxt1a style blocks would only supports 1 bit transparency.

Um.. that scares me. Now.. granted it's a bit above my ability to understand, but it sounds awfully similar to the ANI transparency limitations which drive me up a friggin wall.
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes - MjnMixael's Render Boutique
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: MNG: The Good, the Bad, and the Ugly
well thats whats in my head. if you want to half the compression i could use a dxt5 block (8bpp or the same size as ani). and like i said there are other block formats out there that i havent looked at yet. what i had in mind was something that can do everything ani can do and look better while being smaller. i didnt know you guys were after "eXtreme detail (tm)!" :D
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Fury

  • The Curmudgeon
  • 213
Re: MNG: The Good, the Bad, and the Ugly
I don't believe DXT has necessary image quality for this purpose, as this is supposed to be used in command briefing animations and such. These should be streamed off the disk, not loaded to memory as a whole and then played. DXT in most cases has way too much compression artifacts, particularly with gradients. Not saying DXT couldn't work in some animations, but people shouldn't be stuck with it if they want animations without readily visible compression artifacts.

Libmng supports jpg and png, so you get better compression in the form of jpg when frame quality is not a huge concern and png when you need or want the best quality. The fact that these files would take as much memory as uncompressed files shouldn't matter because they're supposed to be streamable, hence I don't see much point in having DXT as anything but an option, which libmng doesn't support.

But if someone intends to make their own file format to suit the needs of ani replacement, then it really should be flexible in terms of use.

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: MNG: The Good, the Bad, and the Ugly
i would only use dxt's block compression schemes, thats not to say i will be using the dds file format. say you take a 440*200 cbani. this animation would be roughly 110*50 blocks in size. keyframes would always have all blocks defined, consecutive frames would only update blocks that change significantly enough. so if only 50% of the second frame has changed from the first frame, then only 50% of that frame need be stored (this is in addition to the block compression).  this could be streamed for forward playback (this method of compression would not allow reverse playback without precaching). only the file header, current frame header(s), and frame buffer(s) need be stored in memory. no more than a few frames would be buffered in ram at any one time, during playback the file handle will be left open until the the playback session is ended, at which time the handle is closed. keyframing would be handled as a stored offset of the frame header of the keyframe.

i dont like the idea of container formats for image files of some format. they lack any form of inter-frame compression, which is how video formats manage a pretty good compression to size ratio. mng i believe does this, my only objection to that format really is the unavailability of existing tools. my alternative really isnt much better, as it only exists in the mind of a rather unfocused hack-coder, and would probibly take me forever to write proof of concept code anyway. i said before (in the previous mng thread) that mng looked good on paper, and if you guys think it will be easier to code and support (despite the difficulties with the format) than a from scatch format, have at it.

*edit*
i was looking at the compression algorithms for dxt5's alpha channel, and if i encode all four rgba channels in the same way, i can compress down the blocks to 16bpp. something like this is used with bc5 normal maps to improve quality over dxt5nm (except using 2 channels instead of 4). if i limit the color table in a block to 2 bits (instead of 3) per pixel, i can drop the compression down to 12bpp. this should still result in better quality than dxt1 since all channels are encoded separately. still looking at alternatives to dxt1a blocks which would provide more quality at a minor expense to size.

i can also do a variation on dxt1 where the two 16 bit colors are replaced with two 32 bit colors, while keeping the 2-bit color indexes. this would result in the block weighing in at 6bpp. also the 2 bit per color index could be up-sampled to 3 or 4 bits at an extra 1 or 2 bits per pixel. this could improve quality but may lead to some bizarre artifacts however (alpha would intrude into the color space). i could avoid this by using 2 bits for color and 2 bits for alpha (8bpp).
« Last Edit: March 23, 2011, 02:05:14 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: MNG: The Good, the Bad, and the Ugly
A full 8-bit alpha channel is needed to allow transparency effects as are possible with MNG.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: MNG: The Good, the Bad, and the Ugly
you guys are probibly set on mng at this point so im having some fun with this idea of mine.

block compression works by reducing the color space in a block to a specific range. same would be done with alpha. the block (8bpp) would only contain 4 shades of each color, however this is interpolated between the min and max value present in the uncompressed block at compression time. so the highest alpha value and the lowest alpha value in an uncompressed block would be identified. two other intermediate values would be interpolated and these colors would be indexed between 0-3. keep in mind that a block is only 4x4 pixels, so 4 shades of alpha could cross the whole block and look just fine. on a long alpha gradient there wouldnt be much variation in the alpha, and a hard edge would map out to a wider range and produce a sharp dropoff (which would have been desired in that instance). the 12bpp format would do this on all channels while the 8bpp would only do color and alpha ranges. the 16bbp format would provide bigger ranges (8 shades instead of 4) for each color, and within a 4x4 block you are unlikely to get that much variation.

at this point ive mostly broken away from the dxtc standards and have been looking at other formats loosley based on them. heres what i like most so far.

8bpp block:
 4 byte rgba min
 4 byte rgba max
 4 byte pixel color index (2bpp x 16)
 4 byte pixel alpha index (2bpp x 16)
 pros:
  smallest size block
  good alpha range (better than dxt3 but not as good dxt5 alpha)
  better color than dxt1 (888 instead of 565)
 cons:
  color not as good as alpha
 
12bpp block:
 4 byte rgba min
 4 byte rgba max
 4 byte pixel red index (2bpp x 16)
 4 byte pixel blue index (2bpp x 16)
 4 byte pixel green index (2bpp x 16)
 4 byte pixel alpha index (2bpp x 16)
 pros:
  same quality across all channels
  better color than 8bpp format
 cons:
  bigger
  same alpha quality as 8bpp format
 

16bpp block:
 4 byte rgba min
 4 byte rgba max
 6 byte pixel red index (3bpp x 16)
 6 byte pixel blue index (3bpp x 16)
 6 byte pixel green index (3bpp x 16)
 6 byte pixel alpha index (3bpp x 16)
 pros:
  best quality
  alpha quality on par with dxt5 alpha
  better range on color channels
 cons:
  huge!
  more range than pixels (almost)
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN