Making opacity an inheritable attribute

[fh1805]

In the current versions of PTE, opacity is the one keyframe-controllable property that cannot be inherited via the parent-child relationship. And part of the reason is that the frame is not really a frame, it's a zero opacity rectangle. This can readily be demonstrated: in the O&A window add a rectangle and note its icon in the Objects list, then change its opacity to zero and now note its icon. Do the same with a Frame, changing its opacity to 100%.

When the v5.0 animation came out I campaigned unsuccessfully for opacity to be inheritable in a selectable manner. I do not want to change the default behaviour of PTE; I realise the immense benefits of being able to fade in/out the individual objects. But for those who sometimes build complex animations, there is often no easy way to fade out a complex structure whilst retaining all the animation of all the other objects.

Using version 5, I produced an animated sequence called "Kaleidoscope" which involved over 700 objects on the slide at any one time. Ideally, I would have loved to fade out the various structures one after another. But that would have meant programming 1400+ keyframes to control the opacity of each of the individual objects.

Whilst v6.5 was in beta, I produced my "Rubik's Cube" sequence: it had 54 facet images. To programme the fade out of these on the last slide required 108 keyframes. But that cube sat under a master controller frame. Now imagine a version of PTE that allows the user to say: "for this parent (a PNG image of nothing), I want you to impose inheritance of opacity on all its children and children's children - to the bottom of the stack". I could have faded out the entire cube with just one pair of keyframes on the master frame.

I have no idea what the programming complexity of this feature would be for the team, but I think it would add immensely to the ease of coding complex animations.

regards,

Peter

[ContaxMan]

That would be great!

[Jean-Cyprien]

Hi Peter,

Not a bad idea for the future, certainly, but I think that for the present time, you could easily put your "master controller frame" under a mask, and use the opacity of the container (or of the mask) to control the opacity of all the objects under this frame.

Amicalement

Jean-Cyprien

[stonemason]

It gets my vote

Geoff

Update just tried Jean-Cyprien's workaround and it works very well so many thanks Jean-Cyprien.

[Lin Evans]

Hi Jean-Cyprien,

That's the way I've always done it and it works fine. I guess it could be helpful from a resource perspective to inherit opacity, but the mask works very well for me.

Best regards,

Lin

[fh1805]

Whilst I can accept that the mask offers a way of achieving the desired result, it is most certainly not the most intuitive way. It is, however, an excellent example of what is wrong with PTE. The capability exists within the product but requires the use of a complex and totally unrelated function. Consider the novice user for a moment. He or she has learned to change pan, zoom, rotate and 3D transform on a single object using a pair of keyframes. They also have learned about the parent-child relationship and discovered that these attributes can be inherited by a child object. They also learned that opacity of a single object could be changed between a pair of key frames - but this could not be inherited. To them, that is totally illogical. I feel it is wrong of us "experts" to accept the workarounds and not push for the more obvious and more logical solution. On any object, the user should be allowed to nominate that its opacity setting is to be passed down to all its children. One little tick box on the Properties tab: "Opacity is inherited by all child objects" - totally intuitive, totally flexible in its deployment.

regards,

Peter

[davegee]

Peter's suggestion is a good one and obviates the need for any "workaround".

Experienced users find it much easier to find "workarounds" and we sometimes think that modifications are not necessary because these "workarounds" exist.

The fewer "workarounds" in the process, the easier it is for new the user to understand it quicker.

DG

[ppenen]

I agree with Peter suggestion. It's easier for new users to work with this solution.

Pierre

[Jean-Cyprien]

I would not say that Peter was not right when he wrote it would be easier if the opacity was an inheritable attribute of a parent'frame.

Generally I don't like using the masks, which are often big ressources consumers (but they are of great interest), but here we have a solution, not particulary difficult to use.

My message was CERTAINLY NOT intended to denigrate the proposal of Peter, but to provide a simple (in my opinion) solution already feasible today.

Regards,

Jean-Cyprien

[fh1805]

Jean-Cyprien,

Rest assured, I have not taken offence at what you said, nor at the way you said it. If my choice of words in post #6 has given you that impression, I apologise most sincerely.

Like you, I use masks only when I must because of the significant additional processing resource that they impose. I had not thought of using one for that purpose, so thank you very much for that suggestion.

regards,

Peter

[davegee]

I too, was confused by Jean-Cyprien's post.

I see nothing above which refered to anything that he said or which suggested that he was denigrating Peter's proposal.

Was something lost in translation????

DG

[Jean-Cyprien]

Dave, dear Peter,

It's always difficult to understand each other, and specially by writting, and more, when it's not in one's mother language.

Also, it was not the first time Peter wrote a proposal to improve PTE, and that I answered « It's already possible ! ». So actually, I was afraid of having offended Peter (upset, at least), thus my post.

I'm very happy that it's not the case. It was just my apprehension (nothing in your #6 post, Peter ! Rest reassured too, my friend) . Thank you for your understanding. And forgive me my sins mistakes.

Best regards,

Jean-Cyprien

[fh1805]

Jean-Cyprien,

No harm done! I know only too well from my occasional participation on the diapositif.net forum that communicating in a foreign language (written or spoken) is very difficult. And when someone points out to me that a particular feature already is possible, it means I am adding to my knowledge. That can never be a bad thing for any of us.

Dave,

The possible translation problems are the reason why I tend to write in full: no abbreviations, no mnemonics, no idiomatic English - except when I am replying directly to an individual whom I know uses English as their first language.

regards,

Peter

[Lin Evans]

Hi Peter,

I suspect that your assumption about "programming complexity" is indeed correct and why this wasn't an original feature along with the other inherited features of the parent/child relationship. It would be a nice addition if it were possible to implement without too much effort, but I suppose that creating features more commonly used might have higher priority. I think perhaps getting those who have been asking for multi-track visuals on sound, etc., might be at the forefront of the next wave of improvements. Another area in which many would like to see implemented is text effects. Once video is ironed out, video sound controls are improved and expanded and sound features in general are improved, I suspect the development team might start working on more esoteric features such as you suggest along with some improvements in implementing "smooth" animation controls. I've often wondered why it wouldn't make more sense that when one chooses "smooth" motion that the individual keyframe groupings (separate here and glue here) were not defaulted rather than having to do it by individual mouse clicks. Then the "option" could be to change them individually, when needed.

At least we do have an alternative means of achieving group opacity available, even if it isn't necessarily intuitive. There are also some types of masking which the competition has available that PTE doesn't yet support which might be nice to have.

Best regards,

Lin

snip

I have no idea what the programming complexity of this feature would be for the team, but I think it would add immensely to the ease of coding complex animations.

regards,

Peter

[xahu34]

... One little tick box on the Properties tab: "Opacity is inherited by all child objects" - totally intuitive, totally flexible in its deployment ...

Peter,

I would like to learn how inherited opacity should be defined, in more detail! Consider an object A with opacity a%, a child B with opacity b%, and a grandchild C with opacity c%. What is about to happen to B and C if you now tick your box?

Regards,

Xaver

[davegee]

Lin,

I find your description of what Peter is suggesting as "esoteric" to be a little strange.

Surely, it is a fundamental of 3D animation that the child in a Parent/Child relationship should inherit ALL properties of the parent?

I would agree with Peter that this fundamental principle could/should be ironed out before proceeding.

If, however, Igor says that the hurdles are too high then so be it.

DG

[fh1805]

Xaver,

In my vision of the future product, if Object A was visible at a fixed opacity, its children could have independent opacity values (varying between keyframes if desired). But as soon as Object A's opacity began to vary between a pair of keyframes, that rate of change and "direction of change" (fade up/fade down) would be applied to all the children.

regards,

Peter

[stonemason]

In my opinion the the help files, and documentation for this whole area of PTE needs a radical update. I can well imagine a new user trying to get their head around all this, coming to this forum and thinking we were speaking a different language. For any product to be successful it needs to capture it's customers within a short time of the opening the box. I fear that the most creative area's of PTE may fail to do that purely through a lack of information available to new users from within the software.

Geoff

[Lin Evans]

Hi Dave,

I don't think you can make the case that "all" properties of the parent should necessarily be inherited. I have experienced a number of times when I would not want all properties to be inherited. I think property inheritance should be an "option" but not a mandatory feature. Without the ability to mask, having "all properties" inherited could be a recipe for failure in some animations.

I consider it "esoteric" because the type of animations where it is useful are those which only a few users will ever even try to experiment with. I believe that the vast majority of users will not build cubes, pyramids, fancy masked screens or few other things which you, I, Peter, theDom, or any of the fine French animation experts and some others here on the forum find enjoyable. Most will do simple transitions, add some videos, text, synchronize sound and do things which "most" users of presentation slideshow software do. There are hundreds and thousands of presentation slideshow users who don't even have parent/child options with their software - so in that sense, even having this ability qualifies as somewhat esoteric in my view.

Best regards,

Lin

Lin,

I find your description of what Peter is suggesting as "esoteric" to be a little strange.

Surely, it is a fundamental of 3D animation that the child in a Parent/Child relationship should inherit ALL properties of the parent?

I would agree with Peter that this fundamental principle could/should be ironed out before proceeding.

If, however, Igor says that the hurdles are too high then so be it.

DG

[davegee]

Lin,

I believe that Peter covered your point by asking that the ability be switchable, presumably defaulting to OFF.

The new user might not even know it is there but the advanced user could take advantage of it as and when required.

DG

[xahu34]

... In my vision of the future product, if Object A was visible at a fixed opacity, its children could have independent opacity values (varying between keyframes if desired). But as soon as Object A's opacity began to vary between a pair of keyframes, that rate of change and "direction of change" (fade up/fade down) would be applied to all the children ...

Peter,

Good luck for your proposal. It is a requirement which introduces quite new time (or context) dependent aspects, which may become complicated in cases where we have big graphs of objects with the inheritance option for opacity in various generations.

Presently, the parent/child mechanism is restricted to the geometrical states of the objects, and at each single point of time the size and position of a child can be derived from the size and position of its parent (at the same point of time), and the child's own (independent) geometrical parameters which are not global ones but which are to be interpreted relative to the geometrical state of its parent object. In the language of 3D applications: The object model of a PTE slide is a kind of scene graph (with the screen as common root), and it is very likely that this model is nicely supported by D3D (DirectX).

Regards,

Xaver