Why am I getting __Auto Textures in Sketchup?

[falcon409]

The project I'm working on contains approx. 25 to 30 Custom Buildings and related textures. I have combined the various areas of the Airport into single bgl's, so one area might contain 6 buildings all as a single bgl and so on.

Most of the textures I load into Sketchup are given a name like "Material_01" or something similar however with one area (The FBO and a small utility building) the textures were loaded with a double underscore then "Auto" so I would have "__Auto_18_0" as the texture name. That didn't seem to be a problem until I loaded the final work into MCX to add the night textures and complete the compile to a bgl.

No matter what I do, MCX will not accept "__Auto_18_0_lm" as a night texture. I've tried renaming the main textures by removing the double underscore but they simply reappear. Does anyone know why this is happening?

I've complete 2 other groups of buildings and neither one had any textures named "__Auto" and all night textures loaded fine in MCX.

 

[=rk=]

The texture assignment slots are not dependant on any other name or even the customary "_LM" suffix convention. For example, you could name your day texture "blackest_night_LM" and you night texture "glaring sunlight" (without - or with - an underscore) and MCX will load them and save the assignments as expected. The extra underscore probably relates to a missing or untranslatable character, but it is not clear why you need to have the name of your night texture be an adaptation of the day texture name.

 

[GaryGB]

Hi Ed:

Are you importing any buildings into a intended multi-building project file via a Collada *.DAE or *OBJ file format ?

If so, do they have 'distorted' textures mapped from texture Materials already mapped onto other Faces / 3D objects in the same 3D model within the source project ...from which such buildings were exported ?

Or, are any of the building Faces with the mapped <__Auto> texture Material names 'distorted' textures mapped from texture Materials already mapped onto other Faces / 3D objects within the same 3D model in the intended (destination) multi-building project file?

GaryGB

 

[falcon409]

. . . . .but it is not clear why you need to have the name of your night texture be an adaptation of the day texture name.

It's a naming convention I have used since I started doing scenery. It's simply the way I keep track of textures.

 

[falcon409]

Hi Ed:

Are you importing any buildings into a intended multi-building project file via a Collada *.DAE or *OBJ file format ?
If so, do they have 'distorted' textures mapped from texture Materials already mapped onto other Faces / 3D objects in the same 3D model within the source project ...from which such buildings were exported ?
Or, are any of the building Faces with the mapped <__Auto> texture Material names 'distorted' textures mapped from texture Materials already mapped onto other Faces / 3D objects within the same 3D model in the intended (destination) multi-building project file?
GaryGB

The short answer to your long question is yes and I will delete the offending 3D model and work forward to hopefully eliminate the problem.

 

[GaryGB]

Hi Ed:

You may wish to review the discussion on that type of scenario in this post by "TIG":

http://sketchucation.com/forums/vie...dbc36315f8faf7a285f4f1e84651&start=30#p447334


...in this thread:


http://sketchucation.com/forums/viewtopic.php?t=40397



You may be able to avoid rebuilding- / re-mapping texture Materials for- existing 3D models, by using either / both of Aerilius' other plugin Ruby scripts for Faces having any distorted texture Material mappings ...prior to Sketchup Export / Import:

Make Unique Texture ++

http://sketchucation.com/forums/viewtopic.php?p=367210#p367210


Texture Resizer (1.5.6) — updated 15.05.2013

http://sketchucation.com/forums/viewtopic.php?t=40720


Perhaps as well, this type of scenario may be minimized by Exporting to *.KMZ, or using TIG's *.OBJ Exporter plugin Ruby script ?

OBJexporter v3.0 20130131

http://sketchucation.com/forums/viewtopic.php?p=294844#p294844


Hope this helps !

GaryGB

 

[=rk=]

It's a naming convention I have used since I started doing scenery. It's simply the way I keep track of textures.

Ok, your procedure generates texture names that MCX will not digest. It may be the way you keep track of textures but the word simple does not belong in the sentence.

 

[arno]

Hi,

What do you mean with MCX rejects the textures? MCX should be able to process any texture name, there is no magic logic for the names. What kind of error or problem you encounter?

 

[=rk=]

I had similar errors, I'd assumed it was forbidden characters. I changed my procedure to prevent the extra textures being generated and the problem went away. I don't think the problem arises in MCX, I think the SDK tools are the issue.

 

[arno]

Might be, xtomdl is quite tricky with certain characters.

 

[falcon409]

Well, interestingly this seems to only started a few days ago. Below is an area of the Airport that I added some night textures to in order to see how they displayed (hangar floor and door). The naming style used was the same that I've always used and never had a problem with (adding _lm to the end of the texture name). The In-Sim night version is shown below;

I went back to that area a while ago and attempted to add additional night maps and now I get an error message saying MCX could not load the textures.

Nothing has changed with the exception of two updates to MCX. . .currently I have: Version 1.4.0.0 8d1f8c53 DEV 11/13/2017
So I'm wondering why it worked 3 days ago and now it doesn't. Rick, not sure why you have such a problem with the way I name textures. . .as Arno mentions, MCX should be able to process any texture name and I'm certainly not using any odd characters that should throw MCX into a tizzy. My naming style has worked for years and unless you can show me a legitimate reason why I should suddenly stop, I'll continue as I always have.

 

[arno]

This warning just means MCX can't find them. I see they are still in jpg format as well. Are you sure you put them in the right folder? Sketchup models often use relative paths, which you won't have if you enter the name manually.

 

[arno]

I also see that the loaded textures have no prefix with the model name, while in the editor I see this prefix. So it might be that you are in progress with some editing. In that case sometimes the textures only exist in memory. Saving the textures first might help in that case.

 

[falcon409]

This warning just means MCX can't find them. I see they are still in jpg format as well. Are you sure you put them in the right folder? Sketchup models often use relative paths, which you won't have if you enter the name manually.

I use the browsing button on the Night Texture line to locate the correct texture. So if I locate the correct texture that way, why would MCX say it can't find it. I never enter names manually.

 

[=rk=]

To be clear, there is no problem with the suffix "_LM" and likely not even a problem with the double underscore, as far as MCX is concerned. The issue, about naming, not file paths, is that either one of two things is happening; either MCX calls the double underscore texture file and xtomdl rejects them, or, the double underscore represents a forbidden character that isn't displayed or accepted.

By your description, it sounds like a case where you have downloaded a model from the Trimble Warehouse that was created in another language, the characters of which aren't recognized. Since it can't be called "質地.jpg," Sketchup allows the texture to be "unnamed." When you perform the operation that causes Sketchup to generate textures, probably by moving the yellow pin, the suffix "_auto1" gets added. When you export the model, Sketchup titles the texture "_" and if this texture becomes copy/edited by Sketchup in subsequent skewing operations, the texture name becomes "__auto1."

Your solution, if this were the case in these instances, is to examine all textures within the Sketchup model and edit their names to something recognizable, before beginning any texture repositioning. Alternatively, you could use fixed texture mappings and avoid this situation altogether.

I use the browsing button on the Night Texture line to locate the correct texture. So if I locate the correct texture that way, why would MCX say it can't find it. I never enter names manually.

That locate function works when compiling models, you must first compile a model with those assignments to see the textures loaded in MCX.
You do not need to enter names manually. Simply insure that all relevant textures are in the same folder as the model, or in an adjacent folder named "textures." MCX will automatically locate and load them.

 

[falcon409]

Ok, I don't. . .or did not load anything from the Warehouse. . .all models are my own. I did, as Gary questioned, load an already built (my own from a previous scenery) ".dae" model back into the scenery to "save time". That was what generated the "__Auto" texture names. I deleted that model, removed all "__Auto" textures from Sketchup and built my own model as I should have to begin with. So the __Auto problem is in the past and no longer relevant.

The base textures I use have names like "window", "door", "sign" or "hangar_floor". When I load them into Sketchup to position them on the model, they become "material_1", "material_2" and so on. That is not my naming manually, that is what sketchup changes them to on it's own. As Arno has already stated MCX should load any texture regardless of the name. . .a texture is a texture and "material_01" is as simple and straight forward as "window_01" and shouldn't be a problem.

I can't restate enough that this has never been a problem until a few days ago. I know you are all trying to help but the problems that everyone seems to be picking on were never a problem for the last 5 years. . .now all of a sudden what has always worked. . .no longer does.

 

[=rk=]

can you say the format of these textures?

 

[arno]

Let's stop discussing underscores and focus on the errors that are shown and how we can solve them. The error in the screenshot has nothing to do with xtomdl or underscores.

Also let's stop to argue that one's workflow is better than another's. Everybody should use their own workflow they feel good with. Especially if it always worked.

 

[=rk=]

Ok. I'd say, based on the available information and OP statements, it looks like either texture "material_5LM.jpg" got renamed to "17N_FBO_material_5_LM.jpg," or, something in the last few days removed 17N_FBO_material_5_LM.jpg from the 17N_FBO directory.
Was really just trying to figure out the cause to the above results.

 

[falcon409]

I have taken shots of the way the workflow is done and maybe there is something that helps this way:
First Pic is the main folder for the scenery for "Cross Keys Airport". It contains all the current textures available to me for the various models I've built for the airport. Notice I also have individual folders for various compiled files that I might use once in MCX.

Next Pic shows the opened "3D Folder". You can see the other ".dae" files I have to work on and the two currently textured areas "17N_East" and "17N_FBO".

Final Pic shows the texture files saved when I exported the work on the FBO area (17N_FBO). These are all the textures connected to the job I am currently trying to add night textures to. You can see that the daytime textures have corresponding night textures available in that folder. . .yet it will load the scene into MCX with all textures, but doesn't find the night textures. . .why?