On Jan 11, 2008 7:11 AM, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 2:52 PM, Kevin Gillette <[EMAIL PROTECTED]> > wrote: > > i think if we don't care about pie2 compatibility, then we at least need > to > > drop the BSP stuff > > Already done. > Alright. I think it would be a good time to get rid of PIE and poly "types" that are unused, and fill them in with new functionality, or reorder them to fill in the gaps, while also making it part of the spec that things like twosided polys are *only* specified via the poly flag, instead of hacks such as the point-repeat method that i believe it uses now. > what i would like to see is the ability to specify > > any number of texpages that may go with a pie (maybe up to 16) > > What would be the gain of doing this? I am thinking that reuse of > textures is and is probably going to be minimal between different > models in any case, so why not use a single texture for each model (or > several models per texture, as now)? There is a high performance > penalty on switching texture pages while drawing, and the drawing code > for when we get VBOs will need to be more complicated to deal with it. for example, there could be a decal texpage, with multiple sizes of symbols, emblems, etc (such as one per team) that all models could optionally reference. take http://forums.wz2100.net/?topic=538.msg5113#msg5113 as a reference for this -- the white project logo part could just be a floating poly (better would be direct support for decaling existing polys) -- that logo could be replaced by collective or paradigm logos, for example, depending on the player. besides which, 3ds supports multitexturing even from different source files, so full support for such a format could bleed the framerate *much* further than this. if there's that much of a worry, i could propose a specific decal part of the spec (to be used *instead* of general support for multiple texpages, since decalling is the most likely use), when used with a texpage referenced as a "decal page", could be optimized to allow the engine to render decals for all models onscreen in one pass per decal page, thereby minimizing the negative effect to almost nothing What do we do with the existing animations, then? > an example, if you go sed any pie 2 file with "s/LEVEL/FRAME/g", then you just made that aspect compatible with my proposal. from a programmer's point of view, it's a stupid idea, yeah. but it would greatly decrease the learning curve for new artists, and the number of questions that we'd get on the forums about how things in PIE work. One idea that has been dancing around in the back of my head is that > we could use 3DS as our native model format, and add animation/team > colour information in a separate file. We would probably have to > regenerate/recreate the extra file whenever the 3DS file is less than > trivially changed, but with a simple tool this may not be tool much > hassle. Then artists may view and edit models in their favourite tool > of choice, and only need to use an external tool when they are done > and want to test it. i agree that switching to something like 3ds may be a worthwhile pursuit.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
