On Fri, Mar 7, 2008 at 2:23 PM, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 7, 2008 at 9:35 PM, Freddie Witherden <[EMAIL PROTECTED]> > wrote: > > I was speaking to Per about this one actually. He seemed quite > > certain that the current way we do it is better than doing it at run > > time. I believe we do it for runtime with map tile sets, and it does > > seemed to have increase load time somewhat. > > The idea I have been toying with for some time is that we use the > Warzone Studio application to stich together the terrain tiles into > texture pages, instead of doing it on runtime. That way we can also > apply whatever texture compression we like (some of those algorithms > are very time intensive). Combining a ton (700+) of small images of > varying size during runtime may prove to be quite a lot more time > intensive than what we do now for terrain tiles. Just the scattered > file reads alone would add up. > That still doesn't change the possibility of texpage muckups. If i create a mod you like, and you want to add my mod as a dependency -- adding models that use my texpages -- then it's all well and good until i get into warzone studio and add another image for the software to push into the texpage -- when i do this, the texpage may get rebuilt in a different way, and although my models will have their own texpage filenames and coordinates mangled correctly to match the new texpage, anyone who depends on my mod won't have that same benefit, and they'll have to ask me for my studio file or will have to retexture their model (though they'll probably be lucky enough to only need to translate each mesh as a whole to a new location). Nonetheless, I believe that any kind of "automagic" behavior, especially with this kind of individual images -> composite texpage transparency leave the possibility of problems if not added on the engine level. I understand that it's unmanagable to do anything along these lines in the engine unless caching is involved. i'll be thinking about a way implement a cache with reasonably well performing cache-invalidations. I have been working on a new model format lately. See > http://wiki.wz2100.net/WZM_format and check out the utilities in > tools/conversion and tools/display. I would love to see the blender > plugin ported to this new format, as well, if you have the time. > > I do not think having multiple texture pages per model is a good idea. > For one thing, it is not necessary. Secondly how would you use VA/VBO > drawing with multiple texture pages, if you don't have > multi-texturing? Will you limit the number of texture pages allow to > the minimum number of texture pages required to run Warzone? > Hmmmm... i should've thought that over a bit more -- i was thinking one texpage per poly, certainly (so in the proposed extension, each poly would have a texpage field, which could only refer to one texpage), and in my fatigue, i was thinking of units as a whole, instead of the individual pies which make up a unit. nonetheless, there are certain places, such as creating new propulsion models where you would only need to redo a few textures, but can reuse most of the original textures (compared to replacing the existing texpage with a modded version, which really works quite well, admittedly), or redundantly including all the useful original textures in a new model-specific texpage alongside the new textures. i've got some new ideas about how multiple texture support (not 'multitexture') could work without actually modifying the pie format, aside from allowing more than one TEXTURE directive. I have several recommendations (including philosophical) for the WZM format. i'll post them when i get some time, hopefully tonight.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
