Instancing problem...?

[tomsdesk]

So I had the bright idea to do some trees with full 3d trunks/branches, anchoring face-me leaf bunch png components where needed on the branches...allowing the tree to be rotated in place for different views of the same tree (getting real :`) while taking advantage of the byte savings of the leaf-bunch png trick. Worked great in SU...not so much in Twilight: It appears copies of the original tree component (or group) are rendered with the png orientation of the original, so when the tree is rotated, while looking great in SU, renders out on edge...? Exploding down to loose face-me leaf components (and also regrouping each tree individually) solves the problem. (Last image is how they should and do look in SU.)

Any fix besides exploding the trees and loosing the benefits of multiple components?

[Chris]

Hm... that is a problem. In Twilight, an "instance" is a literal copy, down to the last vertex. Obviously SU doesn't treat instances that way; it evaluates each one separately for 'face me' behavior. When Twilight prepares a scene for rendering, it only makes a single copy of components; this save A lot of processing time, and a lot of render time too.

There is one existing solution.
In the 'Advanced' tab, under Grouping Method, if you select "Per Material" instead of "Definitions / Instances", it should render each component independently. But I don't know for certain how SU will respond; Face-Me's are always a little touch and go.

Some possible future options:
A render option to treat all components with Face-Me's in them as groups instead of components.
A context-menu option for each instance (or component definition) to treat that specific instance or definition as a group. If it's stored "per definition" you could pre-configure the trees so that anyone using them would have them render correctly 'out-of-the-box'.

[tomsdesk]

Hey Chris, thanks for your quick response...man, you guys are good!

First, I tried the "per material" suggestion...but it didn't make any difference.

Next, tried exploding the component, then grouped the trunk/branches component with the loose face-me png components, before copying...but, same results as with full tree components.

About then I noticed it wasn't the original, but the last copy, that set the render orientation of the face-me png components...very interesting?

Guess I'll have to warn folks about exploding if rotated until/unless you find some other trick, but thought give you this info to put in your pipe to smoke in the meantime :`)

[Gaieus]

Hi Tom,

Do I remember correctly that you are a SU Beta tester?
The case is that when SU 7.1 Beta came out, it had serious issues with face-me components either exported (say in Kerkythea) or rendering with any built in apps (Podium, Twilight, IDX etc...). Fortunately it was soon fixed but this seriously resembles that issue (just your components are more complex)

[tomsdesk]

Gai, thanks for the headsup...and I sure wish it had worked: I was using SU7.1 dated 9.27.09 and updated to 12.22.09 this AM, to no avail :-(

[Frederik]

...and I sure wish it had worked: I was using SU7.1 dated 9.27.09 and updated to 12.22.09 this AM, to no avail

Please remember what Chris wrote...

Some possible future options:
A render option to treat all components with Face-Me's in them as groups instead of components.
A context-menu option for each instance (or component definition) to treat that specific instance or definition as a group. If it's stored "per definition" you could pre-configure the trees so that anyone using them would have them render correctly 'out-of-the-box'.

Without promising anything (I can't since I'm not the person coding TWR), I'm certain that Chris will nail this, so that it works in TWR...

[tomsdesk]

Thanks Frederik...this is not a problem, just an inconvenience: of which, there have been few with this wonderful software. I will restate, so Chris' investigation goes as simply as possible, there seems to be the same problem with groups as with components...?

[Chris]

I will restate, so Chris' investigation goes as simply as possible, there seems to be the same problem with groups as with components...?

Actually that is an interesting point. Groups are definitely not supposed to act that way... So when you only have groups, no components at all, it still doesn't render correctly? That is definitely a problem. I'll have to do some testing and see what, if anything, can be done about it.

[tomsdesk]

In case I'm not on the same page: the tree here tested consists of a regular component (the trunk/branches) and several face-me components (the leaves) which have been grouped together as a tree, then copied. If I don't group the tree components (trunk and leaves) together before copying: they all render fine (I can also group each individual tree together separately after copying). This tree-group seems to be working the same as if I made the tree parts into a tree-component.

[Chris]

Ah, I understand now. I was misunderstanding.

The one thing that comes to mind, something I think I saw on SketchUcation, that there is a 'bug' in SU where groups that are identical, ie. cut-and-paste, are actually treated as if they were instances of the same component. When a group is edited in some way, SU, internally, breaks that group from the others, making it unique. It seems quite possible that this is a problem with the data SU is delivering to Twilight, exact copies of the same geometry, instead of separate unique groups. If that is the problem, I'll have to give some thought about how Twilight can work around this problem (It would only be an issue with groups containing Face-Me components).