Yep. Or else you try depth peeling as is suggested above by LS.

I am reading those articles she gives to me, I think they would be helpful.

if you simplify the scene down to a single organ, do you have a chance to notice whether the problem occurs only if you look through a concavity.

I upload some detail images.

This isn't a problem solely related to yours. It is common in game engines and elsewhere. And hence there is a solution

It is possible to have more than a single order on objects. Notice that it is recommended to have several organizing structures, one for each task to do. It is absolutely fine to have a logical organization of the objects, a spatial organization (if collision or proximity is an issue), a render order, and perhaps more. Don't stuck with the über scene graph approach, or you will be lost sooner or later!

For example, you iterate the scene description and detect all objects that need to be rendered. You insert each object into a list (which is emptied before the scene is iterated). After finishing, you sort the list by some criterion, in your case using the distance from the current camera. Object rendering then is done in the order given by the list. So rendering has no influence on other aspects of object organization, and nevertheless is done in the required way.

This is quite inspiring, I will try it out! thanks!

I am reading those articles she gives to me, I think they would be helpful.

She is actually a he. Just pointing out.

The problem you are seeing stems from the nature of your blend operation. Every surface slightly darkens what lies behind them, which allows the user to percieve an order of the surfaces, but also means that the order of mixing together the colors is important. There are other blend operations, like additive blending (glBlendFunc(GL_ONE, GL_ONE);) where the order doesn't matter. Can you get away with additive blending?

If not, mixing the colors of different surfaces seen on top of each other must be performed in the correct order: Mixing from back to front. As you already know, there are multiple, very different approaches, to achieving this. Some require you to write shaders, some only require you to do s.th. with your meshes, some work in all cases, some only if you can make certain geometric assumptions for your modell or allow for certain artifacts.

For example, consider a single convex object. If you render the back facing triangles first, their color will get blended with the background color. If you now render the front facing triangles, their color will get blended with the result of the previous blending operation and you get the correct result. So for a single convex object, you can get away with the simple trick of rendering the back faces first, and then the front faces which will, for each pixel, always be closer to the camera. Automatic and perfect back to front sorting. Sadly, you have more than one object, and those intestines are far from convex.

So exploiting convexity is out of the question, at least directly. Which leaves you with 2 questions: Do you want "perfect" results? Do you want to use shaders, or do you prefer a geometric solution?

Haegarr is suggesting a geometric solution: Cut your scene into pieces (or your objects into subobjects) and sort them back to front. But what pieces? Is it enough to cut them into convex pieces? The answer is no, just cutting them into convex pieces will not guarentee artifact free pictures. For example, assume that you make one subobject out of each triangle (a single triangle is convex). Then there are certain situations where you can not find an ordering for the triangles, that lead to a back to front rendering. For example, consider these 4 quads (also works with 3 triangles), where each quad has one end in front of the previous but behind the next.

  DD        BB
AAAAAAAAAAAABBAA
AAAAAAAAAAAABBAA
  DD        BB
  DD        BB
  DD        BB
  DD        BB
CCDDCCCCCCCCCCCC
CCDDCCCCCCCCCCCC
  DD        BB

For these, no correct rendering order exists. At least one of the quads has to be split. This is the point, where you have to decide, if you can live with the occasional artifact, or if you want to descend into the ugliness of splitting faces, and inserting them into a BSP-tree or s.th. similar.

If you go the geometric route, I would follow haegarr's advise: Automatically cut the objects into smaller, approximately convex and not elongated pieces, sort those pieces back to front then render each object twice, first by culling away the front faces (only rendering back faces) then by culling away the back faces (only rendering front faces). Then take a look at it and decide, if the remaining artifacts are acceptable, preferably while experimenting with different parameters for your cutting algorithm. However, keep in mind, that the geometric sorting approach can get very ugly, so if you have the compute power to spare, and the time to read further into OpenGL, then Depth-peeling and other "order independent transparency" techniques can be a reasonable choice.

few post earilier you said that you already checked this solution.
You lie and post another images that say nothing.
I cut out of this topic,

I am really really sorry if I said or did something to upset you. If so, I have to say I definitely didn't mean it! there must be some misunderstanding between us.

I deeply appreciate your help here, why would I lie about anything?

try to set up only one light in the back and see if problem occurs for back of the model) (or set ambient to the same color like diffusion color)

I tried, problem does still remain. I already upload the images.

divide whole model to different organs, then try to render every organ where you begin from those that are deep in the body and you end with drawing lungs

I have not tried this yet, as I said before, my objects are all mapping other stuff, I need to figure it out how to do it in a proper way before I do any modification on models.

also glBlendFunc needs to be set properly (and sometimes glColor4f <- alpha value)

I tried a couple in glBlendFunc, and also tried change the alpha value. If I use a lower value, like 0.3, the meshes looks thinner but still exist.

we also dont know if your textures have alpha channel but i guess they don't)

Yes, my textures have no alpha channel, I got bitmap files, I just load the texture by gluBuild2DMipmaps. If there has any alpha channel in texture, I don't know where to modify it.

At first you need to draw parts that are not transparent and then you draw transparent organs in proper order.

This is still about resorting, I have to say again, I will try it, since modifying my model is a little bit complex, I prefer to try other way first. And I have no non-transparent objects in the scene.

this also try to lower z_near value (in glFrustum)

I use gluPerspective, the near value is already 0.01f.

anyway youll have to sort faces or that would be far way faster and easier -organs


this is what ahppens when you sort faces.

I will try it later.

Again, I am really sorry.