Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

=46rank C wrote:

>That sounds reasonable. I don't think it will come up often in=20
>real-world apps (or at least the dev/artist should try to minimize it).=20

Yes, as really any high-level geometries should be generating optimal
TriMeshes anyway (as we control their cached form ourselves).

That has had some improvements recently (e.g., we now always
pre-normalise normals, so renderers can assume that any TriMeshes they
see have normalised normals), but if we have an identifiable fast-path
we can do something like post a notice if we go off it.


>I'm _all_ for that. I think the lack of these are keeping many people=20
>from even trying Quesa in the first place. Personally I'd be happy with=20
>modulating vertex colors/alphas with textures, but multitexturing=20
>(and/or multi-pass texturing) and register combiners would be=20
>fantastic.

Yeah, I think the best approach would be to go for the full thing: the
classic behaviour and the light-usage of it can both be implemented in
terms of that.

There are some subtle differences between GL and D3D in this area, so
we'd need to assume we could be using either GL or D3D at some point and
go for the intersection in terms of specifying what Quesa allowed.

E.g., in D3D you can use a combine on a unit without a texture, provided
the combine parameters don't reference the texture. In GL you always
need to have a texture bound, or the results of the combine are
undefined.

=46or that case it's probably easier to restrict ourselves to the GL
functionality as the requirement for renderers which can support a
combine model. The more general case would only be available if a
renderer says it can do it, if it's based on D3D say.


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