uuderzo

So... Limiting the "scope" and setting visibility to 0% has the same effect, as you said. Can we consider the scope as a shortcut to avoid setting opacity or does it have more features? I suppose that since the scope is a single range that cannot be "broken", once the picture goes out of scope then it can be unloaded from the grahics card memory. Are all pictures loaded before the slide starts showing or are them loaded following the "scope" timing? Can I use the scope to fit in the graphics card memory (at different times in the same slide) more graphics than the card can accept? Thanks... Umberto

Wow. I just discovered that each object in the object animator displays a blue range on the time line when selected. Is this range used to optimize memory consumption? I noticed that it can be adjusted and when the time cursor goes out of the blue range the object itself disappears. I didn't notice it before. Maybe I'm so lazy I didn't notice it for months... Greetings! Umberto

What about a more global change? I suggest a single "parameters column" with each parameters section stacked one each other, with the ability to click on their title to expand/collapse them. If the user drags a section out of the column, this become a floating window. If the user closes the floating window, the section reappears in the column at its original position. Greetings! Umberto

I suppose that Igor's team choosed this way for backward compatibility. Moreover, by mirroring the "rotate" parameter with a new "Rotate Z" parameter may create user confusion. I agree with you that the current configuration is not the best one, but I think it's the best considering that most users won't deal with 3D parameters. Greetings! Umberto

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

From a more technical point of view, I think it's better not, even considering the introduction of new 3D complications. Greetings... Umberto

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

Sorry Igor, I did not understand your statement. Did you mean that it will not be fixed in future? Thanks, Umberto

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

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

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.

I'm really excited with this new beta! I finally managed to obtain the 3D effect with no effort! See that Igor opted not to introduce 2 Z parameters as suggested previously (one for real Z pos and one for apparent Z pos to correct perspective effects). I agree with the choice, because a double Z parameter could confuse many users. The same "apparent distance" correction effect can be obtained with the zoom parameter, also if the zoom level is difficult to compute exactly to balance the perspective zoom given by the Z position. But that's no problem at all. Just need a little trying and let's go. This is a sample of what can be obtained: Cave test I agree with TheDom about the new icon. Amazing! 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. Now just need to wait for multi track audio and finally... PTE will rule the world!

One more thought... If "Z position" will be introduced into PTE, a problem arises: The paint order of pictures that share the same Z position. I suggest to use this algorithm: 1. If Z position differs, the paint order is computed considering the Z position 2. If Z position equals, then the paint order is computed considering the position into the slide structure, as usual This will permit to build several "groups", each one with a specific Z position that paints as expected. I think that this algorithm is enough obvious, but wished to point it out. Greetings! Umberto

TheDom, you brought really good examples, thank you! I did a test some time ago: Layers test but, while it's easy to do with zooming and panning, it's not so easy with rotations. To compensate the absence of "Z buffer" it's necessary to rotate and pan layers one each other and, to be geometrically correct, a straight pan it's not enough. So, as you said, with "Z buffer" it would be easier and easier. Greetings! Umberto

You are right. Hope that a written example would suffice sice I've not the right material here to bring a running slideshow. Keeping it simple, suppose to have a shot of a room with far chair, a table in the middle and a near chair. I would like to obtain a 3D movement effect. I already seen some demos in the forum that work the way I'll describe, but I wish to push it a bit further. So, take Photoshop and start cutting out the picture into layers: The nearer chair, the middle table, the far chair and, finally, the remaining of the room. I need to fill the holes caused by cutting out nearer elements by manually reconstructing the layers with cloning or something else. Finally, I get 4 layers: The room without chairs and table, the far chair, the table, the near chair. I obtain 1 jpeg for the room and 3 png (because of transparency) for other elements. Now I bring everything into PTE. New slide with the room jpeg (the root element) and 3 children elements with pngs. So, I obtain the initial shoot. Now it's time to move. I wish to obtain a panning effect. Without disturbing real 3D, I can achieve that by simply panning each element with different offsets. But, I want to push it a bit further, as I said: I don't want a simple panning, I wish also a slight rotation on Y axis. This would give terrific 3D effect. Here the problem comes: If I simply rotate the root element on Y axis, I obtain an odd effect, because the final effect would be a plain image that rotates on Y axis, so the 3D effect is completely lost. Well, if a "Real Z position" parameter exists, I could place the far chair at -20, the middle table at -40, the near chair at -60. By rotating the root element (the room) on Y axis, now a real 3D effect is visible. BUT! By moving children elements on Z axis toward the user eye, I will see them bigger as they should because of the perspective effect. Since the initial picture is already in perspective, this is an unwanted result. Hence I can act on the "Apparent Z distance" parameters, setting it to 20 for the far chair, 40 for the table, 60 for the near chair. This ways compensates the size of each element bringing them to their "apparent" initial size and recomposing the initial picture. But this time each element is really on a different plane, letting me obtain the desired 3D effect by rotating the room on Y axis. Obviously, consider that the Y rotation should be of minimal amount, or the 3D effect will be lost because the user will see the layers. Hope now the proposal is more clear. Greetings! Umberto

Night brought another proposal... What about "Apparent Z distance" and "Real Z position"? Greetings... Umberto

Just another thought... The presence of both parameters is a really nice solution. I explain: If I want to build a picture based on several layers to obtain a perspective effect, I cut each layer from the starting image, then I insert them in a single structured picture inside PTE. At this point, I change the "Z position" of each layer. Doing so I obtain a misalignment of each layer because the narrow layer is zoomed respect to the far one. So, I can correct the unwanted zoom by acting on the "Simulated Z distance". Once correctly fixed the parameter, I obtain the starting image like it was not cutted. Then, by rotating or moving it on the z axis, I obtain my perspective effect. Yes, I think that both behaviors can interact one each other to get nice results. Greetings... Umberto EDIT: I suppose that if I keep the image parallel to the screen plane, then set, say, "Z position" = 40 and "Simulated Z distance" = -40, the image should appear the same, until I start panning/rotating it.

Igor, now I understand why you can't use Z buffering. I think that what you are suggesting is nice. A "pseudo Z-buffer" based on Z distance is a wise solution, waiting for newest DirectX drivers. Obviously some artifacts may appear, mostly if pictures are not parallel, but I can live with it. Anyway, even if I really don't need to perform 360 degrees rotations, the "pseudo Z-buffer" should be smart enough to consider the 180 degrees rotation of an entire group of images (then, invert the order). And, I suppose, the Z order will be computed considering the picture point of rotation. Since you already introduced a behavior with the "Z distance", I think that you should introduce something else for this new behavior... uhm... trying to be as self explanatory as possible, what about something like "Simulated Z distance" as you said, for the existing behavior and "Z position" for the new one? I wish to accent on the "Simulated" word, so users will understand why there is such odd behavior (zooming without really moving) Greetings... Umberto

Hello Xaver, I already had a look at this nice demo. I only say that the "Z axis distance" illusion is kept only while you don't start rotating objects on X/Y axis. Suppose you design a picture with this structure: root image: x = 0, y = 0, z = 0 | +-- child image: x = 0, y = 0, z = -20 (a bit narrowed to user eyes) Then, if you start animating the root image by rotating it along, say, the X axis, you see that both images lays on the same plane and that the z distance only affects the child image size, not its real z position. Since it is a little odd result to me, I would not call the parameter "Z position", sice the Z position is phisically unaffected. Greetings... Umberto

Igor, wouldn't it be better to call this function something like "Z axis zoom"? In fact, first time I seen the function I completely misunderstood it and expected to being able to "separate" images on several planes so in a hierarchical structured set of images i would see real depth when rotating the parent node. I suspect that many good transition effects should be easier to obtain with a real 3D system... nowadays people needs to simulate the Z coordinate when moving/rotating objects. I know that enabling Z buffering for occlusion tests will slow down the performance, but I think it's not necessary to do so. With a wise picture design, you can leverange the real 3D even without occlusion tests... Anyway, Z buffer could be an option flag, why not? I know... I already asked for this function and it seems it is too "difficult?" to understand by final users... I don't think so, but if this is team's choice, please rename this parameter. Greetings! Umberto

Uh, oh... I didn't noticed that! Moreover, without remembering the exact image size, I just need to go on the "Original" tab and put 100% in the size parameters! Now I'm again an happy guy! Goin' back cutting pictures! Thank you Peter! Umberto

I tought that cutting the image into layers would be the toughest part... I must face the reality Thank you for your answer. Umberto

Hello, In my tests to obtain cool perspective effects by moving layered images, I got a problem: - I start with my initial non layered image - Then rework it by cutting into pieces based on depth (distance from observer) - So I obtain a "puzzle" - Rework each single layer to fill the gaps that will appear when I'll move the layers - Export each image layer as a single image (PNG with transparency) Since each layer may slow down the animation due to its size, i trim each image to keep only the real content, and cutting away big transparent frames. This should optimize the use of GPU resources, mainly if the layer contains only small element. Then I come to the problem. When I load each layer in PTE to recompose the initial image, due the fact that each layer has different size in pixel I get a final result where each layer has a different "zoom" level respect each other. This does not happen if all layers are the same resolution (obviously). I suspect this is due to the "resolution independence" of PTE and that's ok but... anyone can suggest a way to load all layers so I don't need to zoom each one in a "try and test" cycle until i get everything matching in my puzzled image? I'd like to get all layers already correctly scaled, so I only need to shift them to recompose my puzzle. Thank you... Umberto

Wow. Simple and effective. You're great Lin! Umberto.

You may try a virtual DVD burner. Nero or Alcohol 120% should have one. Then you can burn the DVD image on the virtual burner and transfer it on the other PC and then, finally, burn the iso image on the physical disk on the other pc. Greetings! Umberto