Re: Distribution files on sourceForge

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

=46rank C wrote:

>The transparent renderer is very broken in the current CVS source - I'd=20
>highly recommend waiting till it's fixed!

Can you log some bugs demonstrating how?


>Problems with the transparent renderer that I've seen so far:
>
>1). the new localToFrustum transforms in ir_geom_transparent_add aren't=20
>working right - I'm consistently seeing jumbled geometry (I'll make an=20
>example app that shows this if no one else sees it, but all you have to=20
>do is draw some transparent geometry that approaches or clips the=20
>frustum).

I had a look at this with the bug you logged before: and wasn't able to
reproduce any problems with geometry intersecting the frustum.

The flicker in that particular case (three overlapping transparent
boxes) was due to the sorting order: see the notes on that bug for more
info.


>2). No fog. This is almost better than the additive fog on transparent=20
>textures in previous releases, but it should be fixed with an=20
>additional pass.
>
>3). The lighting state is never taken into consideration, so stale=20
>states from the last solid objects are used - null shaders can come out=20
>lit and vice-versa (this is an old bug).
>
>4). Facet normals don't appear to be handled properly (i.e. "none"=20
>interpolation style)

Can you log three bugs for these three issues, with appropriate sample
models to reproduce them?

=46og and lighting will probably be wrong ta the moment (since we're
letting GL handle that for us, we will need to record the state that was
active when a transparent triangle was seen and save it away: or do our
own lighting).

Either way will be quite expensive though.


>5). Sorting is less than spectacular - it can't handle a rotating cube=20
>properly.

If you have a particularly poor sorting case, please log a bug and
attach a model.

However bear in mind that some models just can't be sorted correctly:
e.g., interpenetrating geometry can't be sorted without splitting it up
and introducing new polygons.

One solution to this might be to allow applications to provide a sorting
callback: the technique we currently use is "good enough" for most
cases, but if you have a particular problem case (and a solution) then a
callback would let you sort whatever way was appropriate.


>Points 2, 3, & 4 above all point to a similar problem; the state simply=20
>isn't managed well for transparent triangles.

Yes, strictly speaking we need to capture every bit of state that will
affect the final rasterisation when a transparent triangle is submitted.

That obviously makes transparent triangles quite expensive, as you have
to a)record a lot more state and b)switch state more often when
processing them (since they a sort-by-depth ordering probably won't
correspond to a sort-by-state ordering)


>The only thing I'm concerned about is how and when the light state is
>updated - looking through the code it appears to happen once per
>frame, but in practice it updates for every mesh - so I'm missing
>something here...

Where do you see it being updated on each mesh? The lights should be
converted once per frame, by IRRenderer_Lights_StartPass.


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