Different variations...that aren't.

Alan Fraser

I’m posting this here, rather than on the beta forum, because I thought it would be a useful heads up to some of the wider community. Although, if Andrew or one of the other Googlers doesn’t pick it up, I’ll post it over on the beta too.

As far as I know this is a bug/behaviour that has always existed, but is still present in V7. I came across it when doing trees in various summer/autumn foliages a few years ago. It may well be that there isn’t a solution to this, because it’s intimately connected to how SU handles components and groups.

If you have a model that has been image-mapped in a fairly complicated way….striped material on a sofa….wood grain going every which way on a dresser etc; and if you want to offer that model in a few different configurations of material; then it’s a whole lot easier simply specifying a different image in the Material browser than repainting the entire model…face by face.

When you do this, the entire model is instantly remapped…correctly…in the new material. So far, so good. You’d imagine that doing this…and maybe renaming the new material, to identify it as different from the original, would be enough…far from it.

It might look just fine, all on its ownsome…but try importing it into a new model alongside the original and see what you get.

I’ve attached two simple tables done in this way. Table01 was constructed normally, from scratch. Table02 is another version of Table01, but with a different wood texture specified and the name of the material changed.

Open up either one on its own and it’s just fine….table01 is dark; table 02 is light.
But import them into a new file and both will be mapped in whatever version was imported first.

The only solution I’ve found to this is to (after remapping) open every group and component within the model, then edit it in some way before closing it again. The easiest way of editing is to just select the contents of the group/component and move it, say, 3 inches to the right, then move it back again. Obviously, you only need to do a single instance of a component…but you need to do every group individually. Occasonally, you also need to actually rename groups or components from one version to the next.

It does seem very odd behaviour…especially when both the Component and Material browsers are telling you everything is fine…whilst it’s a very different story in the drawing window. It would be very nice if the program could automatically update/refresh the components without having to do it manually.

PS. While testing this...editing parts of table02 then opening a new file and trying to import both versions to see any improvement...after going back and forth a few times, I occasionally got a bugsplat.

table01.skp

table02.skp

Gaieus

It is indeed interesting, Alan. I have also experienced issues when reloading materials but have never gone after so detailed. I will have a look, thanks.

Maybe it is a good timing anyway as the Googlers themselves admitted that there are indeed a couple of fields SU has to change and improve and one priority is texture mapping in general. Once they touch it, they should also have a look at such inconsistencies.

BTW - I guess it would work correctly with DC's, wouldn1t it?

Alan Fraser

It's not very relevant to DCs, Gai. Having different materials with DCs only works in Group Paint mode; not Face Paint mode. This being the case, it's impossble to have an intricately mapped object in DC form. The few Google examples, like the different wood finishes on a table top work okay, but you couldn't have a detailed DC cupboard, for example...because most of the wood grain would be running in the wrong direction.

tomsdesk

Alan, I've noticed this in the past too...and now this http://twilightrender.com/phpBB3/viewtopic.php?f=11&t=1123 is yet another reason to fix the SU bug...?

TIG

This is related to the problem of doing a save_as on a component, and giving it different names - it will appear under its original name in the second component browser pane [therefore there could be several variants with the same name displayed there] but it'll kick into it's file name if loaded into the main pane !
I at first thought that it was the externally saved model 'component' title and name being different - but if you manually change the external files 'name' to its 'title' it doesn't help.
The instance.definition.path returns the correct file path so it's not muddled there...
Seems that there's something saved in a model's data that confuses the import into thinking its the same definition[s]...
If you edit the table's groups after it's saved externally it'll then import with the right textured top and rails etc BUT the legs won't change as 'leg' already exists from the first table now in the model, so the import still uses that ! Solution ought to be to rename 'leg' as 'leg2' in the second table's skp file, but it's not going to work as SUp still imports the second table's leg as 'leg' even when it's not called that any more in that external skp !!! Super-confused mess...
I think it's also tied into the weirdness where a group definition can have more than one instance - it can't theoretically and the group.make_unique even gives a deprecated method warning BUT it is needed to ensure a copied group that is changed doesn't affect its 'original' sibling...
Of course the way to 'fool it' is to make the table out of groups/components with no materials and then apply the material to the component instance! But then UV mapping is a messy business one at a time...
It is 'against nature' [ ] to have an app that lets you export variants of a component with different materials and later import them back into a new model but somehow muddle up their identities to such an extent that you can't trust which it is...