With the current zbuffer is impossible to achieve nice HW assisted order independent trasparency ( sorry, i dont like depth peeling, polygon sort, ps2 tables, etc etc )… I propose a susbtitute for the current zbuffer. I think it is called a-buffer … basically is a pointer-linked zbuffer with color and alpha information:
To compute the final color, you sort from back to front by [depth] value.
This buffer also support some kind of ray test btw.
We really need a new method to make OIT, because actually all the other methods simply sucks. PS2 tables aren’t precise… depth peeling is too complicated and expensive, polygon sorting is slow, BSPs for transparency are ugly…
We need a HW-assisted transparency/depth buffer for ya! is incredible that, in the year 2004, this problem IS STILL NOT SOLVED.
[This message has been edited by santyhammer (edited 01-04-2004).]
The problem isn’t solved because any method, outside of tile-based rendering, is very slow, compared to using a regular z-buffer. Indeed, if you sort objects yourself, you will find that it will be faster than a non-tile-based hardware solution, to the extent that polygon-level sorting is not required.
Is there some particular reason the a-buffer couldn’t be effectively implemented in hardware? It should beat sorting geometry at least in difficult cases. If you, for example, have lots of transparent polygons with different textures, sorting by depth will cause you a huge amount of texture changes.
No, but neither do I see a clear reason why it couldn’t be done as long as a maximum memory limit can be used. It’s not a complete implementation of a linked list, just insert and clear. But yeah, I don’t know much about hardware, so it may just be my lack of understanding. That’s why I asked in the first place.
Look the “Hardware Translucency Sorting (Dreamcast, Naomi)”… I work with a PMX chip and it sorted the transparent polys nice
But well… Perhaps it can be done NOT by a linked list… imagine you use a tile system… and each tile can be a pseudo-3d-texture. I will be happy with only, for example, 65536 lvls of transparency With the current “depth peeling” system you use 4 and ppl say it looks good, so…
Tile-based rendering (TBR) is a good technique. Unfortunately, it has a number of fundamental problems associated with it that makes a scalable hardware implemenation difficult.
First, I’m not even sure you can write a conformant GL implementation using a TBR system. Mainly because the GL spec specifically says that things are drawn in the order they are given, not the order the implementation chooses. Obviously for order-independent transparency (OIT), this is not an issue, but it is an issue for being able to call it a full OpenGL implementation.
Second, and more importantly, TBR’s are differered rendering systems. This means that all glVertex-equivalent commands simply store vertex attributes into video memory buffers. These buffers contain state data for drawing that primative. After you send all your vertex data (T&L can happen as you send it), you do a SwapBuffers, and the TBR will render these polygons in front-to-back order sorted per-pixel.
The problem is scalability of this. The more triangles you send, the more memory it takes. If I have a single building on a regular renderer, I can render it any number of times and take up no extra memory. However, in a TBR, each render of the building takes up room. Also, this working buffer needs to be double-buffered, so that while the TBR is rendering from one buffer, the client can be sending vertex data to a new one. This takes up loads of video memory, especially for modern 3D models.
TBR is a great idea. Unfortunately, it just doesn’t scale well enough to fit modern graphics.
i don’t know if it van be done effectively enough, but i think there is a way to fix some of the problem’s associated with the z buffer allthough it involves shifting, comparing and blending pixels together.
Basicly what you have is a couple of color/z buffers(8 will do) stacked ontop of eachother.
then when you draw a pixel it places it in the backmost buffer if nothing is previously written to it.
If the pixel is transparent and infront a layer(with an alpha more than 0) then put it in the layer infront of it.
if the transparent pixel exist’s between two layer’s, then shift all layer’s in front of it one step forward.
IF an opaque pixel is placed in front oftransparent layer’s, that pixel is then written in the back layer and the layers in the front is shifted back acordingly.
Now, if for some reason all layer’s would be full and you would like to write another pixel there the two layers closest to eachother would be merged and the layer’s shifted acordingly.
I don’t know if it’s even possible to do(allthough i think it is) or even if you would ever want to do it.
Allthough it’s simmilar to the a buffer this method has no liked list or variable size and this would be easier to create in harware.
(note: this is just a rambling from my slightly deranged mind.)
Well I dont know what is the perfect solution to this, but that I know is that NON-ADDITIVE TRANSPARENCY, in the year 2004, is STILL a problem… go go NVIDIA/ATI/etc engineers… give us a SOLUTION to this because BSP/depth peeling/triangle sort is not the perfect PER-PIXEL SOLUTION… perhaps is time to think in the realtime-pseudo ray tracing?
[This message has been edited by santyhammer (edited 01-26-2004).]
Yea it need’s to be resolved pretty soon.
So here is my wishlist of thing’s they should add/fix on the next generation of hardware.
Non addative transparacy(volumetric rendering anyone?).
Zfighting fix, booth larger z buffers and a uniform way of calcylating z displacement on planes and polygon’s(ask me about this if you dare).
3.Curved surfaces, on an per pixel level and not the slightly crappy subdivided ones(line’s are only straight curve’s).
surface shader’s, that can do heightfields and displacment mapping.
hardware voxel’s.
on the nonaddative transparacy problem there might be a somewhat interesting solution i just thought of.
Basicly when you render the scene, a special buffer filter’s out all transparent polygons, then when you’r done, it automaticly sort’s and split’s every polygon.
Finaly it renders them in apropriate ordering.
(this is still just a mad rambling from my slightly deranged mind).
[This message has been edited by lc_overlord (edited 01-27-2004).]
Look that only 2k polys can be sorted ( completely NOT enough for me… imagine a terrain with grass like SWG, FutureMark 2k3 )… and look like a slow method ( too much vs/ps/texture changes … )
Look that only 2k polys can be sorted ( completely NOT enough for me… imagine a terrain with grass like SWG, FutureMark 2k3 )… and look like a slow method ( too much vs/ps/texture changes … )[/b]
It’s slow because the problem is complex and doesn’t map well to the hardware. There’s no way to do this with the performance you seem to expect, on the hardware that’s currently in wide use.
Case in point, even the Kyro starts to dramatically lose efficiency once you go above a certain number of overlapping surfaces. All dedicated hardware is limited in one way or another.
The problem is worse than you think, it is impossible to generate a proper rendering order for some combinations of triangles. It is possible for any number triangles to cyclically overlap. To illustrate take 3 (or more) long pencils and stack the pointy end of each one on the eraser end of the next, in a kind of triangle(n-sided polygon). Thus, the correct rendering order should probably be generated at the fragment level (as your so called a-buffer, Quake sorted spans(opaque geometry)). Or the geometry should be sliced into finer pieces until no cycles exist (which is how a BSP would do it).
If you’re so desperate for order independent transparency I suggest you use multisampling and ALPHA_TO_COVERAGE or whatever it’s called.
You only get as many levels of transparency as the number of samples, so it won’t look stellar by any means, but you should be able to do better than alpha testing. The bandwidth required for large transparent areas would be huge though.
Mmmm I am pretty sure NVIDIA used that in the Dawn demo to render the hair using lines … not sure if can be applyed to “triangles”… can you give me any dx/ogl example pls?
[This message has been edited by santyhammer (edited 03-03-2004).]
And pls DONT say to me that is a BSP … I tryed to perform my grass using a 1polygon-based bst with terrible results… also 1bit alpha traspanecy and alpha test( looks bad, like “colorkeyed”, dented, unsmooth ) … Any idea how they do the grass system??
[This message has been edited by santyhammer (edited 03-03-2004).]
They use alpha testing(take at a look at the leggs of the guy on the first pic, that’s a dead giveaway), however, if you have high enough resolution(but still fairly small) and avoid dark edges it does look better.
If you ontop of that add FSAA it looks pretty decent.
Basically i wanna render TONS of vegetation at good FPS like:…And pls DONT say to me that is a BSP
It’s probably a tile-grid. They are very fast and easy to render from. You can use 3D sprites. (An old technique where you take “n” different views spaced around an object and change between them based on the angle to the view screen. Wing Commander 2 used something similar for the enemy ships.) And place them on the edges of the grid.
As for natural looking vegetation motion, there is a wonderful article about the physics of Jello. If you can find it, you have all you need to do the physics of a wheat-field.
Another help, is not to use the same 3D sprite for every piece of vegetation. Have maybe 7 different graphic sets, and orient pieces different directions. The billboarding caused by using 3D sprites will enhance the apparent thickness of the vegetation.
(Read carefully.)But this is a signifigantly easier topic, since you don’t have sort transparent objects at all(with depth buffer). No blending occurs with transparent objects. You only need to sort translucent ones. One could render that vegetation in any order with a Z-buffer(depth). And from what I remember of the grass in FutureMark it too was only transparent, so any render order would have worked with depth buffer. I believe it had anisotropic lighting which required the newer pixel shaders.
Aye… Stalker appears to use alpha test in the floor’s grass… The problem is that i want to perform vegetation like FarCry does(alpha fading the vegetation over camera’s distance), so I cant use traditional 1-bit alpha test to perform IOT 8(
No alpha test possible here, I can see nice gradients(but well… not easy to see due to the JPG and FSAA…)I have no idea what is but cant be alpha test! Impoooosible Mr.Anderson! XD They know something we dont!
ps: Aye, i am a mmorpg fanatic!
[This message has been edited by santyhammer (edited 03-08-2004).]
