Re: Textures with transparency and glBlendFunc

[Dair G. <da...@re...>]

=46rank Condello wrote:

>That would be my #1 request, as long as it's generic (i.e. you can do=20
>light maps and bump maps, but aren't limited to light maps and bump=20
>maps). It should use true hardware multitexturing when possible, but=20
>also break down into multiple passes to keep it robust.

Yes, it would be the normal set of texture units and operators.


>>   - Hosting geometry data on the card
>
>Again, would be nice but not typically needed unless you're dealing=20
>with insane in-view polycounts (it also requires a decent AGP pipe to=20
>be worth the effort IIRC).

Assuming you have your gross culling sorted out, minimising the amount
of time you spent blocking waiting for GL to take your geometry data is
they key to getting good performance.

Rather than purely just having static data on the card, I was thinking
more along the lines of going straight to VBOs and skipping the interim
ideas in this area (fences and the like).


>Even object/group based frustum culling would be a good a start.

Yes, the IR should respond to that selector and cull any groups that
aren't visible.


>If it makes more sense, perhaps this stuff should be done in a new=20
>plugin renderer? It could just duplicate the IR renderer to start, and=20
>be built up from there to keep the default QD3D behaviour in tact=20
>without worrying about breaking it every time something is=20
>added/changed.

Hmm, I'd say a better way to spend time would be to set up a test
harness to ensure you can tell when something breaks. Otherwise you have
the same problem when NewIR needs to be rewritten for some future
thing... :-)


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/