There is a problem with z sorting when using transparent materials. It seems the engine is using center point for sorting transparent objects, So I was thinking is there any mesh.pushback equivalent in Away3D v4 to force the engine for using farthest point to sort objects?

There’s not, but you should be able to achieve the same effect by offsetting the geometry within the mesh, so that even if the mesh’s position is a certain distance away from the camera, the geometry’s center of mass is closer. Try this, e.g. by using Geometry.applyTransformation().

You can also file a feature request for getting back the old Away3D 3.x properties that existed to affect z-sorting (e.g. pushback.)

Wow, Offsetting idea worked great. Thanks a lot Richard.

Hello,

I got a z-sorting problem too but I didn’t understand your “offsetting idea” very well :
I would like to get this : maya render = http://hpics.li/f8c6af8

I tried to translate the head using Geometry.applyTransformation()
http://hpics.li/8b7047c

But I still have the problem : http://hpics.li/004eee1.

What should I do?

Where is the z-sorting problem? Is it Hairs? From what I see you’re using transparent material for hairs. hopefully your character has cartoony sharp hairs and you can create the details in mesh instead of using transparent material. z-sorting issue happens mostly when you use alpha blending in your materials.

Thank for your reply,
Unfortunatly “don’t use transparency” is not the solution I’m looking for. It’s true, I choosed a quite simple example because I wanted to focus on the solution. there are z-sorting problems everywhere ( head, armor, little accessory behind the head…) but if needed I could share a relatively more complex model : There is the same issue. I’m pretty sure that Away3d could render transparent matérial, but I need help to know how. I think it would help other ppl who got the same issue.

The basic principle here is one that is true for all GPU rendering engines, not just Away3D. It revolves around the fact that the GPU is generally able to do per-pixel depth sorting, which works really well for opaque pixels, but when they are transparent that is not enough. It’s not enough because it’s not adequate that the pixel belonging to the object closest to the camera is the one showing, you also have to be able to see the pixel belonging to the next object behind it (and possibly more if you stack transparent objects.)

This means that when using semi-transparent materials, the relevant objects needs to be pre-sorted on the CPU. For this to happen at acceptable speeds, the sort happens per object (and not, for example, per triangle.)

This in turn means that for the objects to render in a particular order, you have to make sure that their positions (i.e. the scene position of their origins) are in that order relative to each other.

There are different ways of doing this, but the most reliable way is to break them apart so that they never “surround” an object which should be rendered behind them. Maybe you can start by doing that?

In some cases breaking them apart is not necessary, but it’s enough to just offset them a little. That’s what one can do with the applyTransformation() trick. By offsetting the geometry one way (using applyTransformation()) and then offsetting the mesh the same distance in the opposite direction, you are effectively moving the mesh’s origin while retaining the visual output. And moving the origin affects the sorting.

I’ll try to find the time to write an article about this, as it’s proving to be an area that a lot of people have troubles with (and rightfully so.)

Thanks a lot!
“the most reliable way is to break them apart” I’ll try that.

Richard, I feel that your explanation is really good, but I did not understand nothing I think you really should write an article about that (when you have time of course).

BTW, do I have the same problem? Screen is attached

Is there a better solution provided in 4.1 Alpha or we still need to do the offsetting hack?

Offsetting is not really a hack. Blended geometry needs to be sorted on the CPU and drawn in the correct order (from furthest to nearest) and the only reliable way to sort is to sort by pivot. It’s a matter of geometry design, not something that the engine can do for you with good performance and reliability.

So no, there is not automagic routine for this in 4.1. You still have to design your scenes with this in mind, either when creating the models, or by offsetting them in code.

I see what you mean Rich, I’ve been offsetting transparent objects relative to the camera direction to overcome the problem and I can’t say it’s a fast approach (calculate new direction, reset sub geometry transform data, transform sub geometry backward then move the mesh forward).

Sorting based on pivot point has it’s own problems when dealing with large objects. In 3.6 we had pushBack which solved the problem (I know it’t not fast) but there isn’t any good solution for this problem after v4.

So I was thinking maybe we can have a zOffset variable for each object that adds up with the calculated zIndex in current sorting algorithm, this way we can force an object to render upfront or in the back. I think it will be much much faster and will solve the problem.

Edit:
Btw, doen the current sorting algorithm use Object3D.pivotPoint to sort objects?
I was thinking maybe I can just offset pivotPoint instead of moving the whole thing back and forward.