As some of you may have read in my "real flash quake" thread I am building a texture atlas app to aid me in game development for my engine. My app will spit out a data file that accompanies the texture atlas. This data file will contain the UV offset of each image within the atlas.
This is where I have a chance to give a little back to Spike and Baker. I can format the data file for my atlas any damn way you guys want. I can even spit it out as if it is a file of structs data, XML, csv's (lol)...anything.
If either of you have interest in this, all you have to do is tell me how you want the file structured. I mean literally show me the structs you want me to use and any other markers that you would need in the file. For instance I believe animated textures should come as a set within the data file so, at the beginning of each entry there should be a byte that is checked for entry vs animated set. IMO animated sets should contain the min/max UVs for each image in the set and of course at least the name of the first image in the animation.
I can get tricky with this too. For instance, with some clever atlas construction [n]'s right can become [n+1]'s left, pretty much cutting the data in half.
I don't know if you guys have any use for an external texture atlas system but, if you do, I'm building it right now and I'm putting the c version of accompanying atlas data in your hands, your decision entirely on how it is structured. You tell me. Get together and create the "standard"... whatever makes you happy. Y'all have time. I am going to build this up completely to my needs (ie export as AMF2 serialized bytes) before I even think about other export methods. This app is going to take a "minute" so, there is no rush on anything you guys want me to do with this.
With enough premade atlases you could pretty much dump reading mips altogether or at least look in atlases first. A BSP file could be cut down greatly in size by simply naming a bunch of 2x2 colored squares after the real textures in the actual map so, upon compile the mips are almost non existent but, point right back to the actual texture in the atlas. Of course that would break in any engine not using the atlas system but, it doesn't have to be mandatory... more like an option for mappers. Actually why don't we make a new BSP that simply has the atlas info where miptex_t is? I bet you 100 bucks that I'm gonna do that regardless.
//other idea for the future
completely dump lightmap data - use entities_t to remake all the lights real time with 2 possibilities -
poss. 1) stay realtime
poss. 2) blink the data to a leafwide texture and remove the light
This is where I have a chance to give a little back to Spike and Baker. I can format the data file for my atlas any damn way you guys want. I can even spit it out as if it is a file of structs data, XML, csv's (lol)...anything.
If either of you have interest in this, all you have to do is tell me how you want the file structured. I mean literally show me the structs you want me to use and any other markers that you would need in the file. For instance I believe animated textures should come as a set within the data file so, at the beginning of each entry there should be a byte that is checked for entry vs animated set. IMO animated sets should contain the min/max UVs for each image in the set and of course at least the name of the first image in the animation.
I can get tricky with this too. For instance, with some clever atlas construction [n]'s right can become [n+1]'s left, pretty much cutting the data in half.
I don't know if you guys have any use for an external texture atlas system but, if you do, I'm building it right now and I'm putting the c version of accompanying atlas data in your hands, your decision entirely on how it is structured. You tell me. Get together and create the "standard"... whatever makes you happy. Y'all have time. I am going to build this up completely to my needs (ie export as AMF2 serialized bytes) before I even think about other export methods. This app is going to take a "minute" so, there is no rush on anything you guys want me to do with this.
With enough premade atlases you could pretty much dump reading mips altogether or at least look in atlases first. A BSP file could be cut down greatly in size by simply naming a bunch of 2x2 colored squares after the real textures in the actual map so, upon compile the mips are almost non existent but, point right back to the actual texture in the atlas. Of course that would break in any engine not using the atlas system but, it doesn't have to be mandatory... more like an option for mappers. Actually why don't we make a new BSP that simply has the atlas info where miptex_t is? I bet you 100 bucks that I'm gonna do that regardless.
//other idea for the future
completely dump lightmap data - use entities_t to remake all the lights real time with 2 possibilities -
poss. 1) stay realtime
poss. 2) blink the data to a leafwide texture and remove the light
Comment