We need to be able to control the UV mapping of the default material in order to:
Have components that can have no material but then, when painted with a material, textures fall into place;
Import complex models with no materials but with predefined UVs;
Being able to have render engines and game engines use UVs from our components in a controlled way.
This Default material UV mapping should be exposed in API or Ruby or whatever for developers to use.
PS: I’m aware that what the user perceives as a default material is, for the developer, a nomaterial, hence it has no UV mapping. So I’m aware this is a complex task but it’s needed nonetheless…
As you say, the default material is a color and not a texture which behaves differently. A workaround might be to bring in a standard style UV grid then using “Material Replacer” plugin, select the default material and then use the UV template texture to replace the default material across the whole model (there may be other ways to do this but this is my usual go to.) So now all default faces with previously unassigned textures will become apparent. Each texture would still need assigning/baking other wise it “floats” like a color would - see attached (but with colors this would not be noticeable). This could be done with SketchUV mapping tools, or just kept as-is by selecting the surface and selecting “make texture unique” While it may not fix the issue, it would at least identify where potential problems might be ahead of an export? Otherwise any texturing would have to be done prior to export.
However, all that being said, it still means that to get the correct UV mapping on a specific object, the mapping work still has to be done somewhere by us, either in sketchup or subsequently in another engine? as I don’t think think the software could do it just the way you might like it, but it would sure be useful if it made basic assumptions for mapping based on the object being known as a sphere, tube or a box?
Thanks for your input but honestly, I don’t need workarounds.
As an example, there’s no workaround for making a correctly UV mapped and textured component instanced and have different materials. To get corrwct UVs and different materials you have to make each component unique.
There is a hack, that envolves texturing and erasing the material used for texturing from the model, but that hack is invisible to plugin developers: the UV mapping is correctly shown in sketchup, but render engines can’t read it and render with default UVs instead.
This is already supported under the hood. If a material is positioned on a face and then deleted from the model (through the material browser) the UV mapping is in fact kept. The only thing needed here is to expose it in the UI.
Well, eneroth, what I know is that UV that is visually kept in Sketchup isn’t acessible from a plugin developer side, so it can’t be used on a render engine.
But you’re a developer, so could you enlighten me on that?
True, the API doesn’t expose it unless there is a textured material on the face. It exists internally but I should really have said the only things needed are exposing it in the UI and the API.
Ok, thanks for the clarification. So, the only thing needed is exposing it in the API as I can currently circumvent the lack of UI, with the workflow above.
The thing is that it seems a simple thing, yet it’s a long standing request. And though it’s not used by most users, it opens up so any possibilities for randomizing textures, photorealism and creating assets for game engines or renders, that I can’t underatand it isn’t raising in priority for devs.
Exposing in the API is in theory enough but while at making this an official feature I think it should be exposed in the UI too. I suspect the most work for the developers/product managers lies in reviewing if this affects something else, testing and documenting as the required code changes should be really small.
Sorry, I’d like it to be in the UI too, but personally, if the UI side of things is the one hindering the process, then keep it as it is and simply expose it. One day, when the UI is solved release the feature fully. Right now, it’s not working as it could.
