Material Editor Error

[falcon409]

When attempting to "Minimize Drawcalls" I get this message"



I have attached the full text of the message as well.

 

[falcon409]

Just some additional info: I compiled this same hangar yesterday with no problems. I decided to reduce the size of some of the larger single textures I had to help reduce the number of final texture sheets. I also added an auto-platform command to the textures that make up the hangar floor. Aside from that, everything else stayed the same. This is for FSX.

 

[=rk=]

By same, you mean this is the same build, you compiled it fine yesterday with larger single textures after you'd performed the minimize draw calls procedure and today, in an attempt to reduce the number of texture files, you made the single texture files smaller and you performed the same minimize draw calls procedure on the same original model, upon which you got the unhandled exception, correct?

This is the kind of error I would get, if I tired to minimize draw calls using a texture file to which that procedure had already been applied, or if I tried to include a tiled texture in the minimize procedure.

 

[falcon409]

By same, you mean this is the same build, you compiled it fine yesterday with larger single textures after you'd performed the minimize draw calls procedure and today, in an attempt to reduce the number of texture files, you made the single texture files smaller and you performed the same minimize draw calls procedure on the same original model, upon which you got the unhandled exception, correct?

Ummm, basically yes. I don't build my own texture sheets. . .I let MCX do that as part of the "Minimize Draw Calls" process. I work from the 3D model (dae file) and go through the full process of setting the auto-platform command, applying any night textures I have, setting the object name as part of the file name then on to the minimize function. The textures I'm using are those exported with the collada file from Sketchup.

I have built and compiled literally thousands of custom objects over the years and this is the first time this error has ever displayed.

 

[arno]

Could you send me the object for testing? Then I can try to reproduce the bug.

 

[falcon409]

Yes I can:
https://app.box.com/s/i75zqmnaljyqr9vqop9dxdh8ee5siav6

MCX Version 1.4.0.0 df98e696 DEV 4/13/2019

 

[=rk=]

I don't think it is so much a bug, as a consequence of several tiled textures and in my experience, those aren't supported in larger texture files.

You can see that there are two instances of "Metal_Corrugated_Shiny" and also two instances of "Wood_Cherry_Original," there are known default SU textures and they are intended to be tiled, that means to place repeating copies uniformly across a surface. This is opposed to projected textures, like "Spacemaster," that are fitted in the space of a sign, for example. The fact that two of the textures have an underscore number, is consistent with SU's solution to different mappings for the same texture, it exports numerically sequential versions of each texture, since no models support multiple mappings for the same texture file, how could they.
I am really, really certain that in all my experimentation, one can not tile a smaller portion of a larger texture file, one can only tile an entire texture file. So, not saying it can't be done, but I suspect the attempt to place tiled textures onto a larger texture file, is what caused the hang.

EDIT:
This was a bit of a misprint:

no models support multiple mappings for the same texture file, how could they.

Models will support multiple mappings, in the case of scaling and, "scrunching." What is not supported, in my experience, is multiple "skewings," where an image is adjusted in terms of perspective, or warp and again, adjusted differently. There is a common expression, "don't move the yellow pin" and I think it's more accurate to say, only move it once, if necessary. The operation of adjusting the yellow pin is what causes SU the export sequentially numbered texture files.

 

[falcon409]

Thanks for checking this out Arno. I have a habit of altering the names of the textures prior to doing the minimize drawcalls. That may have contributed to the error. I went back and did a simple compile, no auto-platform and no night textures. It compiled fine. I did another with auto-platform and night textures. . .that caused the same error. Again I ran it, this time with night textures added but no auto-platform. . .again I got the error. The only way I can compile and have it process completely is to eliminate the addition of the night textures . . .doing auto-platform seems to be fine though.

 

[=rk=]

I tested the model, none of the tiled textures are skewed and none of the tiled textures were placed on the generated texture sheets, as far as I can tell. I checked one of the example textures and it appears to have been projected as part of the hoist, not tiled and it was incorporated into the minimized texture.

The sample file uploaded does not include the night textures, nor your assignments for them, which will make it difficult to reproduce the bug.

 

[falcon409]

. . . . .The sample file uploaded does not include the night textures, nor your assignments for them, which will make it difficult to reproduce the bug.

I looked at the zipfile I uploaded to my Share site and all files are included. I then downloaded using the link I posted above and they are in that zipfile. The assignments are self explanatory. . .the windows, hangar floor and one style door are the only textures that have matching textures with the "LM" extension. No need to do anything other than select the texture and assign the night texture with a single click.

 

[falcon409]

I do not see the problem with the night textures, but something about them specifically or the process of attaching them will cause the error when starting the Minimize Draw Calls process.

 

[=rk=]

I am pretty sure ALL textures have to have a corresponding night texture, when running through the draw call optimizer, Arno may be able to confirm this. I prefer to not assume anything, despite how self explanatory it may seem, thanks.

 

[falcon409]

Thanks for taking a look at the problem anyway. I'm moving on without the night textures since it will compile as long as I leave that step out. This was supposed to be a quick turnaround scenery object for folks at SOH to use and it's taken longer than necessary. Thanks again.

 

[arno]

The drawcall minimizer can handle textures with and without night textures mixed.

I'll try to look at the crash tonight. Didn't have time yesterday evening. But I'm sure it's a bug, since MCX should not crash.

 

[=rk=]

I can't get MSX to crash. I've tried, best I can to duplicate the procedure, I've even tried re-applying the minimize algorithm to the same textures, which used to be a sure cause to crash.

As a final test, I took all the textures in the Corel Auto-Preserve folder, overwrote the originally mapped textures, ran the minimizer and the minimized draw call count actually increased, however the procedure completed without a hitch.

 

[falcon409]

Stay with me on this as the explanation is rather lengthy:
I discovered the problem and it had to do with the path for the location of the night textures.

Once I got to the tab in the material editor to "Apply Night Texture", even though the night texture is in the same folder it will not locate it so I have to locate it and add it (don't have any idea why). Once I have added the necessary night textures and move to the "Texture Tab", the night textures show an extremely long path. Up until about 30 minutes ago, as a normal procedure I would simply click "prefix all with model name" then move on to "minimize drawcalls". . .here's the "Ah Ha" moment. . .when I clicked to change the texture names to match it also eliminated the path to the night textures so when I ran the minimizer it would quit since it could not find the night textures.

When I left that alone. . .everything ran fine.

 

[falcon409]

This is just laughable at this point. I decided to just start from scratch, so I deleted everything associated with the hangar in question and went back to Sketchup. I exported the hangar and it's textures again so I was working with new textures and "dae" file. I loaded the window, door and hangar floor textures into Paint Shop Pro and produced the night textures. . .added the _LM extension and saved them back to the folder. Load MCX, load the hangar, attach the night textures for the door and window only (no searching necessary, it found them as it would normally). . .made the "prefix change to the texture names and ran the minimizer. . .error message appears.

closed the program then restarted, same scenario except that now I only loaded the night texture for the door. . .same process, run minimizer. . .perfect. . .no error. I can run it with no night textures and it's fine, all night textures except the window and it's fine, but it does not like that one night texture.

 

[arno]

Hi,

I had a look at the file you uploaded before, but I'm afraid I can't reproduce the crash with that.

Can you provide a detailed explanation what you did or upload a small sample that always has the issue?

I added night textures and then minimized the drawcalls, but that all works fine.

 

[falcon409]

After a long day of trying and retrying, even going back to Sketchup and changing windows textures, it looks like it came down to the program not finding a night texture because of something I did and not some bug in the program.

It seems that, in the case of the night textures, if I forget to add one and load the collada file without it, you can't go back while in MCX. . .add the missing night texture in the file folder and then have MCX automatically find it by clicking the "Add Night Texture" option. If it wasn't loaded with the 3D file, when you tell it to load that night texture you get a checkerboard in it's place as a texture and you have to browse to it and load it that way. . . .even though it's there, it has the correct "LM" extension, if it wasn't part of the initial loading the program won't pick it up.

When you load it by browsing it adds the entire path for that file rather than the truncated path I see for the diffuse texture. When I proceeded to the "Texture Tab" to ensure all textures had the object name as a prefix that process removed the full path and so when I ran the minimizer it would start but then give the error. . .I assume because that night texture was no longer available.

I hope you can understand the explanation. . .what it basically came down to was a series of miscues by me and not understanding what I was doing wrong. . .even though I have performed that process literally thousands of times since I started using your program.

 

[arno]

I'll see if I can reproduce it that way.

If you updated a texture on disk, there is an option to reload all textures in the toolbar. That should also work if you added a night texture that was a checkerboard before.