[3D Transformation] Need explanations about "Z position"

[JPD]

Now PTE is more homogen, not more powerfull but easiest to use for beginners. It's a good idea to have change this Zposition

Nota you'll have to change the value of Zposition of the template made before (twice the value) and sometimes to modify the template because rotation and zoom of parents work on Zposition, not before.

[Igor]

According suggestion of Jean-Pierre we've renamed "Z Position" to "Pan Z" in future Beta 22.

[uuderzo]

According suggestion of Jean-Pierre we've renamed "Z Position" to "Pan Z" in future Beta 22.

Are you considering to introduce some kind of "Z zoom" correction parameter?

This would make easy to compose correctly matching layered images by compensating

the "Z pan" parameter with a negated (but equal in absolute value) "Z zoom",

avoiding to try-and-correct with the zoom parameter to compensate the "Z Pan" zoom effect

of an already perspective zoomed image part.

I know this is complex to digest to most users, so if you decide not to introduce

something like this, i think it would not kill me

Greetings! Umberto

P.S. And, if possible, try to fix the 180 degree rotation glitch! Maybe a flag.

[JPD]

Are you considering to introduce some kind of "Z zoom" correction parameter?

This would make easy to compose correctly matching layered images by compensating

the "Z pan" parameter with a negated (but equal in absolute value) "Z zoom",

avoiding to try-and-correct with the zoom parameter to compensate the "Z Pan" zoom effect

of an already perspective zoomed image part.

I know this is complex to digest to most users, so if you decide not to introduce

something like this, i think it would not kill me

Greetings! Umberto

P.S. And, if possible, try to fix the 180 degree rotation glitch! Maybe a flag.

No need neither Zoom neither center function on Z axis because thick of 2D objects is 0. Now PTE is absolutely coherent.

[uuderzo]

No need neither Zoom neither center function on Z axis because thick of 2D objects is 0. Now PTE is absolutely coherent.

Jean Pierre, zoom is needed because if you cut a picture in pieces to separate near objects from far objects, then near objects are already "big" because the original camera lenses recorded them as "big". Then, by placing this layer on a nearer plane with Z Panning makes it more big and the original image is not preserved. So, we need to "zoom out" a bit to balance the increased size of the layer because of the narrowing to user eye. After this balancing, we obtain original image but with different Z position layers, and we can move/rotate the whole block to obtain our 3D effect.

The issue is that the zoom amount is not easy to compute starting from the Z panning value. I only suggested a way to compensate the narrowing effect by simply using the negated Z panning value. Since the original "Z position" did the trick, I suggested to keep it for this purpose. But I understand that the parameter may be confusing.

Greetings! Umberto

[Igor]

Umberto,

I also noticed that a 180 degree rotation is still not handled correctly, but I trust that

in near future also this little glitch will be solved.

Even if for my immediate needs this is a non problem, I think this should be solved

to keep consistency of the user experience.

P.S. And, if possible, try to fix the 180 degree rotation glitch! Maybe a flag.

Please could you tell me more about this issue? If possible with a demo project.

If it refers to non-linear speed of an object, this should be resolved in Beta 22.

[uuderzo]

Umberto,

Please could you tell me more about this issue? If possible with a demo project.

If it refers to non-linear speed of an object, this should be resolved in Beta 22.

Igor, I'm referring to the fact that the Z order is not correctly handled in a 180 degrees rotation.

As you should see with the attached project (made with beta 22), the two rectangles lie on different

z panning. Initially, the red rectangle is on top and the blue one in on bottom, but after rotating

it 180 degrees, they should switch because of different Z panning. (If they had the same Z panning

value, then they should be drawn as usual).

If the Z panning value differs, then you should project the center of image (or better, the rotation

center of image) and resort images on a projected Z coordinate basis. This will keep consistency

of the 3D environment.

As said before, this is not necessary for my purposes, but I asked it only to ensure consistency.

And more over, as I previously said, to keep backward compatibility, same Z panned images should

be drawn with "old" algorithm. I don't want to dig down to cases like that:

root = z pan 100

+-child1 = z pan -200

+--- child 2 = z pan 600

What should be drawn first? I don't know, but normally it would not bother me.

Greetings! Umberto

180 dregrees rotation test.zip

[Igor]

Umberto,

Thanks for the demo.

This problem related with Z sorting which is not available regrettably.

[uuderzo]

This problem related with Z sorting which is not available regrettably.

Sorry Igor, I did not understand your statement.

Did you mean that it will not be fixed in future?

Thanks, Umberto

[Igor]

DirectX and video card doesn't support Z sorting for images with alpha channel (Text, Buttons, Masks, Images with edge-antialiasing option).

So we can't do anything in this version.

In the next version(s) we have to choose:

1) Pseudo Z sorting of objects in 3D space.

3) Or try to write own implementation of Z Buffer for sorting. Probably it will work, probably not due to low performance of this algorithm.

[uuderzo]

DirectX and video card doesn't support Z sorting for images with alpha channel (Text, Buttons, Masks, Images with edge-antialiasing option).

So we can't do anything in this version.

In the next version(s) we have to choose:

1) Pseudo Z sorting of objects in 3D space.

3) Or try to write own implementation of Z Buffer for sorting. Probably it will work, probably not due to low performance of this algorithm.

Yes Igor, you already explained why you cannot use hardware z buffer due to technical issues with current video cards.

But, I did not mention that way to solve the problem. As you said, "manually" sorting each picture by merely considering the center of rotation of each one should do the trick. I think that a simple vector-matrix multiplication and subsequent sorting of the resulting z coordinate should not have performance issues.

And, moreover, just deactivate this algorithm for images that lay on the same plane.

In my opinion, if you are considering to introduce this algorithm it's nice not to wait a future release, or you will face backward compatibility issues and you would be forced to introduce some kind of option to activate the correct z sorting.

The issue is to design a clever algorithm to correctly handle the z sorting for each (reasonable) case.

Say that I have two groups of images. The first lays on Z -100, the second lays on Z 100. Then, each group should be rendered as usual, using the "old" rendering mechanism. This will ensure backward compatibility with all PTE projects until now (and future if we don't want to handle 3D). After that, each group should be rendered by considering the group's Z panning. If you wish, we can think more about a decent recoursive algorithm to solve most of cases, but I suppose we should do privately, not to bother other forum users with such technical issues.

Greetings! Umberto

[Igor]

Umberto,

Regrettably there are pitfalls in this algorithm. I wouldn't add such serious change hastily, because for the next version probably we will find much better solution. We think it would be some kind of an option so it will not cause an issue with backward compatibility. We're trying add changes step-by-step, for example alpha version of 3D objects was implemented already in v5.6 in the hidden mode.

[uuderzo]

Regrettably there are pitfalls in this algorithm. I wouldn't add such serious change hastily, because for the next version probably we will find much better solution. We think it would be some kind of an option so it will not cause an issue with backward compatibility. We're trying add changes step-by-step, for example alpha version of 3D objects was implemented already in v5.6 in the hidden mode.

That's right Igor.

I understand that such new algorithm may introduce a lot of compatibility issues. As said, I don't need it

at the moment, so I don't want to urge you in implementing it. My main concern is that PTE should give

a coherent behaviour also using generic 3D, but I trust you and your team will find an optimal solution

in future releases.

As final comment, I would like to point out that (perhaps) using hardware z-buffering may introduce a lot

of graphics glitches due to different implementations of the feature by different drivers, and to different

Z-buffer depths. If possible, and if you want to introduce it, please consider a drop down box somewhere

in the slide options with following items (example):

1. no z buffer

2. software z buffer (the one that sorts picture by their center point z coordinate)

3. hardware z buffer

So, if some "special" effects are needed, user can choose the preferred way to draw images.

Greetings! Umberto