Question about the method
Cathy
A short question, just to be sure:
As far as translucent triangles must be sorted to be drawn from back to
front, you can not use vertex arrays or VBO to draw them, because the
order for them to be drawn often change.
So you must use the old "glBegin()... glEnd()" to display translucent
surfaces in a scene.
Or am I wrong? In this last case, could you explain the method?
Thanks
Cathy L.
Stuart Golodetz
You might be after indexed vertex arrays.
Cheers,
Stu
Cathy
>
> Cheers,
> Stu
Hum... yes I know about IBO, I use them, but anyway as you have to sort
the surfaces, you have to rewrite the whole buffer object everytime and
so to synchronize both RAM and VRAM which is not, if I am not mistaken,
really efficient.
For vertex arrays, it could be better as you don't have to access VRAM.
But I mainly use VBO/IBO, is it anyway better to sort the IBO than to
use glBegin()...glEnd()?
Thanks
Cathy L.
jbwest
"Cathy" <n...@now.fr> wrote in message
news:4b0fe3b8$0$30631$426a...@news.free.fr...
See "depth peeling" technique. Sorting is not necessary with this multi-pass
method.
A cheaper "cheat" is to draw all opaque objects 1st,
Then backfacing transparent
Then frontfacing transparent.
This is basically a sort of the most rudimentary type.
Finally for Indexed VBO, you just need to recompute the index array, us the
same vertices.
(but only if 1 VBO holds *everything* in the scene).
jbw
Cathy
> Then backfacing transparent
> Then frontfacing transparent.
That's quite the way I thought it was:
- draw the "opaque scene" with zbuffer writing enabled
- disable zbuffer writing and face culling
- sort the translucent faces so that they'll be drawn from farthest to
nearest
- draw the "translucent scene"
Is the interest of drawing backface first then frontface to avoid
sorting faces?
Thanks
Cathy
aku ankka
Problem is that you have to change material all the time if you sort
whole scene.. it's not very efficient no matter what you do.
fungus
>
> Hum... yes I know about IBO, I use them, but anyway as you have to sort
> the surfaces, you have to rewrite the whole buffer object everytime and
> so to synchronize both RAM and VRAM which is not, if I am not mistaken,
> really efficient.
It will more efficient then using glBegin()/glEnd()
for every triangle.
> For vertex arrays, it could be better as you don't have to access VRAM.
> But I mainly use VBO/IBO, is it anyway better to sort the IBO than to
> use glBegin()...glEnd()?
>
Probably.
If your tirangles never intersect each other then
you can subdivide everything into convex shapes and
sort those instead of sorting individual triangles.
PS: Sorting triangles isn't easy either - you
probably need to use a BSP tree to do it properly.
--
<\___/>
/ O O \
\_____/ FTB.
Cathy
> whole scene.. it's not very efficient no matter what you do.
So texture atlas would be the solution?
Thanks to have point this issue, I missed it.
jbwest
Right, you can use the above method without sorting or breaking up your
Vertex Arrays. It's a cheap cheat, but works reasonably well -and is quick-
as long as you don't have large intersecting transparent thingies.
-or-
you could just raycast the whole scene...
jbw
Cathy
> you can subdivide everything into convex shapes and
> sort those instead of sorting individual triangles.
My triangles never intersect, but for example these 2 fences (=texture
with alpha layer, so we see through and they must be considered as
transparent surfaces that must be processed after opaque ones) seen from
the top:
---- A
/ ----- C
| \
\ | 1st fence going from A to B and 2nd from C to D
---- B /
----- D
^
|
if you have the camera there, you must draw the plane A, then C,B
and D in this order for the view to be correct, even if both fences are
convex, no?
As always, thanks for your answer
Cathy
Cathy
> Vertex Arrays. It's a cheap cheat, but works reasonably well -and is quick-
> as long as you don't have large intersecting transparent thingies.
Ok perhaps I was not accurate enough in the initial question, I just
talked about translucent triangles, so you certainly understood (as you
should, it is a mistake from my side) "whole triangle translucent" but I
was thinking about texture with alpha layer too (fences, tree leeves,
etc...) and obviously, the interest of sorting triangles is mainly for
these last triangles. In this case, sorting is mandatory, even if
triangle don't intersect no?
> you could just raycast the whole scene...
My scene will never display more than, say 400 translucent/alpha channel
triangles (and in 90% of the time, certainly less than 50), so sorting
wouldn't be such a pain (if I pre-compute the "center of the triangle"
and just calculate the square of the distance from the viewer), is it
necessary to use a more advanced procedure (as, once again, my triangles
will never intersect)?
Thanks
Cathy
Wolfgang Draxinger
> ---- A
> / ----- C
> | \
> \ | 1st fence going from A to B and 2nd from C to D
> ---- B /
> ----- D
>
> ^
> |
> if you have the camera there, you must draw the plane A, then C,B
> and D in this order for the view to be correct, even if both fences are
> convex, no?
Do i that way:
glCullFace(GL_FRONT);
draw_object(AB);
draw_object(CD);
glCullFace(GL_BACK);
draw_object(AB);
draw_object(CD);
You should also Google for "order independent transparency" and "depth
peling techniques".
Wolfgang
aku ankka
If you use alpha compare to reject fragments on/off basis, it will
look like crap but that's what many games do to overcome the sorting
requirement. I witness somekind of dithering on Direct3D games with
alphatest but don't recall seeing any extensions for GL that do the
same thing.
The DX11 demos from AMD have something they call "Order Independent
Translucency" or something like that. I don't know if it's tiled
rendering technique, or just some sorting done in the driver or what
it is.. I Just observed the demos on Radeon 5870.. even if they bring
something like that to OpenGL it will still work only on some hardware
so you might not be interested in that technique.
Just some things that pop randomly into mind.. the alphatest is
practical on any 3D card. It might degrade the fillrate little bit,
but that's a small price to pay compared to full sorting? Try and see
how it works for you. =)
jbwest
Well, sorting is mandatory for "correct" translucency (each triangle being
all or partly translucent),
but the backface/frontface method works pretty well and dead simple to try
out. Use the alphafunction to
not write the zbuffer for fragments that are translucent.
The "proper" sort is a good question. You can sort centers, but that might
generate errors. Sorting on the "nearest" corner might prevent some
artifacts.
jbw
Ruud van Gaal
> On 30 marras, 08:53, Cathy <n...@now.fr> wrote:
>>> Right, you can use the above method without sorting or breaking up your
>>> Vertex Arrays. It's a cheap cheat, but works reasonably well -and is quick-
> If you use alpha compare to reject fragments on/off basis, it will
> look like crap but that's what many games do to overcome the sorting
> requirement. I witness somekind of dithering on Direct3D games with
> alphatest but don't recall seeing any extensions for GL that do the
> same thing.
that's Alpha to Coverage, also available in OpenGL. You need some kind
of anti-aliasing though, since it dithers based on the alpha value when
downsampling to the anti-aliased buffer. More AA = better dithering.
It does enable you to just turn on Z-writes and forget about sorting.
Ruud