OpenGL & Transparency
Posted 24 March 2012 - 06:34 PM
Posted 24 March 2012 - 09:48 PM
Posted 24 March 2012 - 09:55 PM
Thanks for helping
Posted 25 March 2012 - 03:26 AM
Posted 25 March 2012 - 09:37 AM
Basically you draw the entire scene without any transparent polygons.
Then depth sort the transparent polygons
Then draw them, farthest away from the camera first.
Posted 25 March 2012 - 11:06 AM
Transparent triangles needs to be drawn back-to-front. That can be more complicated than is sounds like. You need to sort by distance to the camera, but what distance? The center point? Still, that can give you wrong results In some cases.
Also, there can be circular overlap, where a triangle must be split in order to sort them. Have a look at BSP trees for more details. It is a technique that is mostly obsolete by now, but it explains the problems very well.
I think the most popular approach is to make the sorting work in most cases and restrict the art to not cause any of the known problems.
Posted 25 March 2012 - 11:25 AM
In the above screenshot, the rendered image was done in two passes. The first pass you render only opaque geometry, ideally from front to back to maximize fillrate efficiency. In this case, the sphere is rendered first, then the blue rectangle, and finally the ground. In the second pass, you render transparent objects from back to front. This is also known as the painters algorithm because that's how a painter draws. In this case, the red rectangle draws first, then the green rectangle, and finally the yellow rectangle.
Try to avoid scenarios like this. If you must have cross sections, divide the mesh up into smaller pieces. Instead of having 3 rectangles, split them up into 6 and perform the same algorithm as I listed above.
Posted 25 March 2012 - 12:57 PM
But it seems that I have to re-sort every time I move the camera, is that correct? Because I use glNewList(TriList, GL_COMPILE); only once and then glCallList(TriList); on every frame. So do I have to give up the glNewList and re-sort on each frame if the camera has moved? Wouldn't this be real slow?
Posted 25 March 2012 - 09:39 PM
You should avoid programming with display lists as that API is deprecated. GL 2.X and newer states you should be using vertex buffer objects. If you must stick with the 1.X standard, then at least use vertex arrays as they're more robust than display lists. Then you can selectively decide which geometry you want to render and which you do not, as well as adjust the order in which your geometry is rendered.
Posted 26 March 2012 - 12:06 AM
I didn't know about the display lists! thanks for letting me know.
I wonder why OpenGL is not capable if doing transparency itself. Do you know why? It would seems so simple for a microchip doing all kinds of complex stuff!!! Why give us the burden to make complex algo that can't be perfect, and waste time on sorting when we could be computing something else that's more important for the game or whatever it is!
Posted 26 March 2012 - 08:31 AM
Posted 26 March 2012 - 09:51 AM
To answer your question on a higher level:
Hardware manufacturers went down that path once before, with the fixed function pipeline. You had a fixed set of features the hardware could handle, and that was it. If you wanted anything more innovative, you had to do it in software.
It was soon very clear that this was not going to work. Instead pixel/vertex shaders became the norm. Then multiple rendeer targets, instantiation and hardware tessellation, etc. Graphics hardware is now moving in the direction of becoming a completely generic CPU, optimized for extremely parallell tasks, such as graphics, but also physics, password cracking and all kinds of number crunching.
This means we are not limited to what the hardware manufacturer had in mind, but can invent new techniques. The only drawback is, you have to do more yourself...
Posted 26 March 2012 - 10:20 AM
ES1.0 functioned much the same as opengl, you had the same matrix stack etc. The only real difference was that you couldn't do glBegin(...)/glEnd(), you had to use buffers
ES 2.0 all that went out the window and you now just have shaders. You have to do all your own matrices etc, but you do have hardware shaders.
Pain in the proverbial for the first project, after that really nice.
Posted 26 March 2012 - 12:56 PM
But really, they couldn't do something as simple as transparency???
If we can do it in software by simply sorting our object by z-dist, why can't the GPU do it instead? and even better than by object, do it by pixel, so it's flawless all the time!
They can make microchip, send rovers to Mars, but yet, they can't do transparency
Posted 26 March 2012 - 01:13 PM
Also, for the GPU's to be able to sort polies, they first needs to know all the polygons. Which is completely contrary to how they work - they simply execute all draw commands in the order you give them. Another thing is that the GPU doesn't think about translucency as you do. The GPU just blends the pixels with those already in the backbuffer, given some factors for both values. You think of translucencies in terms of src_alpha and one_minus_src_alpha, but that's just one of the available permutations. You could also do simple additive blending, which is order independent. Or perhaps you simply want to blend in a rectangle, regardless of its z-value.
Currently working on: the 3D engine for Tomb Raider.
Posted 26 March 2012 - 02:46 PM
I think that the GPU is still very primitve. They add things to it, but in the end, it makes the programmer's life more difficult. Why can't we simply send all our poly to the GPU, textures, normals, UVs and all, and simply rotate our cam, have a callback for collision, things like that, even some GPU RayIntersection stuff. Everyone could write some peofesional games without spending a lifetime trying to understand how to make a rotating cube. It's now so complex that it makes no more sense. By the time I understand all of OpenGL and able to write somethng worth while, it'll be in a few years when they'll have more for me to learn, so I spend my time learning what it does and never do anything with what I learn, because it's already deprecated! Or maybe I'm just too dumb.
Posted 26 March 2012 - 02:50 PM
Also, it needs to work together with the rest of your rendering. This is easily getting VERY complex.
- Oh! You wanted your cascading shadowmapping to cast filtered semi-shadows? And you have refraction on that water surface? Well, at least you don't use deferred rendering... Oh you do?
Just because it is simple in YOUR case, it isn't simple in general. So why would they waste development time and silicon on features everyone will have to reimplement themselves anyway?
Posted 26 March 2012 - 03:13 PM
We should have a video chip to only do renders, games, and playback videos. That's it. CPU for running our OS and GUI, and another card, with 32768 RISC cores (of very limited instructions) to let us do the number crunching stuff. That would be a real super computer and not hard on the programmers. The more features, the more complicated, the more questions, the more bugs, the more problems, the more time wasted. Lets see, Windows 3.1 use to run as fast on a 286/66mhz as it does today with Windows7 on a 3GHZ. They should re-design the standard rather than trying to modify it. OpenGL is very old, and is now very big, too big.
Posted 26 March 2012 - 03:36 PM
I also wouldn't say life is made more difficult because of the state of things. Rather, I would say that there is simply more things to do. Although I think you're starting a debate about rasterization vs ray tracing. Ray tracing is a more straight forward rendering technique, but it has some disadvantages. The most noticeable being that the two most popular rendering APIs (GL & DX) are using rasterization. Take a look at this article.
Posted 26 March 2012 - 03:57 PM
I'm still trying to make an OpenGL context on a window to use anti-aliasing 4x 2x !?, and I'm still reading all that stuff, it's been 2 weeks I'm on it, and I still get a black window
Sure I can copy codes from free stuff, but that doesn't mean I'll understand what it does. Maybe I need to go to an OpenGL school? if there is such thing!
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users