Re: Textures with transparency and glBlendFunc

[Frank C. <dev...@ch...>]

On 14-Sep-04, at 3:32 PM, Dair Grant wrote:

> Frank Condello wrote:
>
>> not that fog works on _any_ transparent triangles at the moment ;)
>
> It seems to be working OK for the cone in Geom test - do you have a 
> test
> case?

Sorry you're right - it does work (kinda) but there are problems:

Fog isn't explicitly checked for and set during the transparent pass, 
so it just uses the last fog state - which isn't necessarily the 
correct fog state. While we're at it, it's the same deal for 
illumination...

Phong shading on transparent triangles also breaks when fogged, since 
you get an additive effect over the entire polygon (I'm not sure if 
this can be fixed using the built-in specular extensions and fog). This 
is similar to the problem with ARGB textures in fog, but that can be 
worked around if you could explicitly assign blend modes.

>> I'd love to see a "MultipassShader" object that can reference one or
>> more texture shaders and apply them in layers with different blend
>> functions and UV transformations
>
> Yes, we really need to bring the shading API up to date with what's
> currently possible on average hardware. The current feature set is
> basically what was around a couple of years ago, so you're missing out
> on:
>
>   - Multitexturing (light maps, bump maps, etc)

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

>   - Vertex programs
>   - Fragment programs

Would be nice, but to be honest I can do without these for a long while 
still...

>   - Hosting geometry data on the card

Again, would be nice but not typically needed unless you're dealing 
with insane in-view polycounts (it also requires a decent AGP pipe to 
be worth the effort IIRC). I think some built-in geometry partitioning 
and culling would be far more beneficial at this point. Even 
object/group based frustum culling would be a good a start.

> What we really need is a QD3D-style API for expressing this, which can
> then be implemented by a renderer using their particular feature set.

Yes, one or more new shader objects that can be applied in place of 
TextureShaders would be very cool. It appears Apple had the intent of 
supporting all sorts of shader objects but QD3D was dropped before they 
implemented them.

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

Frank.