[brodie_geers]

Just a little tip I've picked up. Thought I'd share in case others haven't thought of this yet.

With the new plugin you can take your SU material and associate it with an mxm, let's say a brick material. You then have the option to copy the color to the SU material or the Texture. I pretty much always use Texture so I can see the UV that I'm dealing with. The "problem" is that it will bring that map into SU and I use a lot of HighRes maps which can really bloat a SU file quickly.

With the old plugin, typically you would have created a low resolution copy of your map and used it to apply in SU, then linked it to your high res mxm. But since the new plugin brings in an actual map that you're using in your material you don't just want to replace one of your high res maps for a low res version.

So my little workaround has been to take my low res map and place it into the material in a slot I'm not using (typically Global Bump for me). Now you can choose that low res map in the "Set texture displayed in viewports" menu in the material editor and now SU will bring that map in rather than one of your high res maps and your material doesn't change.

-Brodie

[JDHill]

Yes, if you're linking MXMs, this is a good strategy. One way or another though, and as has been discussed some before, I mean to establish some protocol for accomplishing a similar thing when working with native SU materials and/or customizing them in the plugin material editor.

If you have any thoughts on what sort of system would make sense for you, by all means let me know. As it would be an auto-replace type of scheme, you'd either use folders of predetermined name, or files with some agreed-upon string prefixed to their name.

I tend toward the first, where for example, I'd look for a folder named /thumbs at the location of the specified full-rez image and use what I find there in the SU viewport, if it contains an image with a matching filename. On the other hand though, you may have noticed that the plugin makes a habit of referring to files by name only, and regarding any directory data as transitory; that makes the first scheme a little more difficult, since the difference lies in the directory and not the filename. If we instead use altered filenames to do the job, then it's clearer to the plugin whether or not it is dealing with a thumbnail image that it should attempt to swap at export time.

So let me know what pros/cons you see here, or if you have another idea altogether.

[brodie_geers]

I'm not sure I fully understand your scheme. What would be nice is to have a system that's fully automated, meaning you never have to open the full res version in photoshop and downsize it at all. What would be truly ideal, would be if that could all be done behind the scenes. Perhaps there could be some Preferences setting where you could determine how the maps are rescaled via a maximum pixel dimension and a jpeg compression. Then when you hit the button to apply the texture to your SU material that resizing happens automagically.

Perhaps you could even toggle between the various "maps to be viewed" in viewport within the SU/Maxwell dialog without having to edit the mxm each time. That way you could start with, say, a brick bump map to get all your UV's just right and lined up, then switch over to the color map to see how the colors are looking in context.

-Brodie

[JDHill]

No, I don't think I want to do that -- the plugin is a rendering plugin, not a general-purpose image processing tool. If you are willing to batch-process your files to make thumbnails, say with '_thumb' appended to their name, then I'm willing to code the plugin in such a way that it will try to use them.

I see your second suggestion is being dependent on the status of the thumbnail scheme. If we work that out first, then it becomes more realistic to give you a list of all the textures used by the MXM. Until then though, that's potentially a whole lot of bits to read, assuming I mean to show them using a thumbnail list, which is the only way I would want to do it.

[brodie_geers]

I can certainly understand not wanting to get into the realm of image processing. I was afraid that may be asking a bit much.

I, personally, would shy away from doing a generic batch processing of all my maps for 2 reasons. 1) I have a large library (70 gigs which all of the full size arroway textures) and even saving them at a reduced size would take up a lot of space. 2) Each project always has some unique factors which require me to download or create new materials which, for those materials, would make my batch of thumbs almost irrelevant.

For example, right now I'm reusing a brick texture from my library but I had to open the color map and edit the color in photoshop. I created a new mxm which was identical to the old one except for the new color maps and saved the mxm as blahblahblahbrick (Dark Red).mxm. Each time I did that I'd still need to create a low res version of whatever map I want to be low res and save it as blahblahblahbrick (Dark Red)_thumb.jpg in whichever folder it would need to go to.

I'm not sure what the answer is. I guess with the system I think you're proposing it would at least be a bit faster than it is now. It would save me the step of having to find a file to save my low res image in and then open the mxm and find that map again. I'm sort of coming around to your idea I suppose, particularly if I could find a decent image resizer that I could preset to always save into my thumbs folder and append the _thumb to the file name.

-Brodie

[JDHill]

I've used this one before; it's quick and has very nice batch jpeg compression, editing, watermarking, auto-renaming, etc.

[Half Life]

Sketchup already has a down-rezing function in it for images -- could this not be leveraged for this purpose? It's not the greatest quality I know but it might serve the purpose.

Alternately the default image editor attached to Sketchup (in Preferences) could automatically open the image when you create an mxm...

Neither solutions is particularly elegant, which brings me back to one of the many reasons why I love Maxwell Studio so much... in Studio you can select any size you want to display the images from extremely low rez to high rez... without any image processing.

Best,
Jason.

[brodie_geers]

Sketchup already has a down-rezing function in it for images -- could this not be leveraged for this purpose? It's not the greatest quality I know but it might serve the purpose.

Alternately the default image editor attached to Sketchup (in Preferences) could automatically open the image when you create an mxm...

Neither solutions is particularly elegant, which brings me back to one of the many reasons why I love Maxwell Studio so much... in Studio you can select any size you want to display the images from extremely low rez to high rez... without any image processing.

Best,
Jason.

I would say that really the nice thing about studio, as well as the materials themselves, isn't so much the display size but rather the fact that instead of embedding image files into the material file it just references the files so you end up with 118kb files rather than 20+mb. It makes sense for SU to do this as it makes things more idiot-proof, but it would be nice to be able to change that as a preference in the Pro version.

-Brodie

[Richard]

I already work in the way JD suggests to some degree! Any map saved as reduced for use in SU is suffixed "_SU". this way it works fast when exporting from PS using the save for web function.

Brodie, mate for bricks I use one map for all which is a simple black and white with nice crisp mortar mapping so I can get accurate UV's, to change add materials I copy the SU material and apply a primary colour, this can still be swapped out later if needed with the colour map. This keeps my SU browser very light indeed! And only one reduced map does a tonne of jobs!

JD I'd support the suffix option and if by chance you use the "_SU" suffix - big sloppy kiss for you mate! We'll keep it on the cheek though!

[JDHill]

Sorry, but I think '_thumb' would tend to be a more logical choice here.

[Richard]

Don't be scared mate! I was only joking!

Yeah either way is cool, I don't have that many floating around - though still support the suffix idea! Cheers mate!