Create standalone render materials from structured bitmap collection

Transmutr Feature requests
1

Transmutr feature request:

It would be very valuable to be able to import a selection of systematically prepared bitmaps and have Transmutr automatically output a render-ready material. No geometry, just the render material by itself.

User benefits include

• Enabling creating custom materials in the first place. Many people can make baseline renders and want to use custom materials, but have a hard time learning manual material setup from scratch

• Plenty of time saved compared to having to manually set up materials to ever-so many bitmap slots, determine per-slot colour space settings, sync UV scale factors between slots, and so on

• Unnecessary user errors avoided

A few manual material tweaks may be needed in the target renderer, but it still makes a lot of sense. The user benefits are multiplied when combined with batch creation in Transmutr Studio.

For our workflow, typical input sources include Quixel Megascan surface bitmaps and Poliigon texture bitmaps. Sources like these typically provide consistently structured bitmap file names. This should facilitate automating Transmutr material creation.

For our workflow, the typical output target is a V-ray material (.vrmat).

Controlling map-synced material scale in Transmutr would be valuable. For this, there should be a Transmutr albedo preview that displays a scale from say one centimetre up to at least a hundred metres, with dimensions showing. Preview accuracy on a large scale range enhances usability for archviz and more.

I know that standalone material creation currently is in Transmutr’s public roadmap. I just wanted you to know that it will be a much appreciated feature.

In fact, since the scenes we render mostly show geometry created in-house, Transmutr’s main value for us may be in facilitating material creation. The same may very well hold true for the companies we teach and recommend to use Transmutr.

2

Thank you for your detailed input.
All of this is pretty much what we have planned. Except the scaling/dimensions, I will add that in our task tracker.

3

Thank you, that is great to hear.

Let me explain why Transmutr material scaling is valuable.

You may already agree, but still. Here using V-Ray for Sketchup as the baseline.

First, materials never come out the right scale when you slot in the bitmaps. I guess a correct size should be possible theoretically, provided the source bitmaps use correct dpi. But I suppose many bitmaps do not, or people just do not want to work like that.

In any case, many materials, such as woodwork or brick walls, have features with fairly obvious real-world dimensions, and need to be set accordingly. Anyone using such materials will need to get scaling right. The earlier in the workflow, the better.

Other materials have a more abstract nature. This includes dirt maps, rust, concrete, plaster and so on. These may sometimes be upscaled quite a lot without losing realism. Upscaling can be used to one’s advantage, especially when using high-resolution maps like 8K, in order to cover larger areas without visible pattern repeats. In archviz, this is useful for covering facades, floors, and so on. But you need a fair preview to determine how much you can scale. The earlier in the workflow, the better.

If you export materials through Transmutr, you need to look at them anyway – so scaling could and should be done already in Transmutr. In Transmutr, you would ideally have:

• Linkable numerical and slider U and V scale controls

• A reliable visual indication of real scale displaying numerical dimensions, and preferably a scale figure

What is the alternative? To open each Transmutr-exported non-scaled material in Sketchup or the renderer, and rescale the materials there, and then resave each material, one by one. So getting scaling right already at the first step, Transmutr, will save time, save workload, and mitigate errors.

Note that most tutorials, including Chaos Group’s own, recommend scaling V-Ray materials directly in Sketchup using Sketchup’s Materials Panel > Material > Texture > Height/Width. However, as far as I understand, this may be bad practise. The reason is that it creates a needless dependency to Sketchup. The V-Ray material, by itself, does not know what the Sketchup material’s scale is. The scale becomes correct only by a previous Sketchup-dependent scale transformation. For example, let’s say you rescale the material only using Sketchup, and save the .vrmat. When you reapply the saved .vrmat in another model file, you have to again manually rescale all vrmat bitmap slots in V-Ray, or rescale the material in Sketchup, or re-UV the geometry in Sketchup, otherwise the scale is wrong. You have to do this every single time you reuse the material in a another project. This is such a bore.

So, instead of using Sketchup to scale materials, I recommend scaling the individual map slots directly in V-Ray using Material > Bitmap > Texture Placement > Repeat U/V. This has the advantage of keeping the .vrmats scaling consistent, across any project, whether reused in Sketchup or in any other DCC. The workflow downside here, however, is that in contrast to many other renderers, V-Ray apparently lacks UV scale sync per-material. This means that every time you want to change the true scale of a V-Ray material, you need to open every bitmap slot used, one by one, and manually edit their scale parameters. This is such a bore.

Transmutr can solve this.

4

I don’t think we will export *.vrmat files, but probably *.skm instead. This is the SketchUp material file format, than can be loaded directly from the Materials window.
This will allow us to export a single file with the V-Ray, Thea, and Enscape data directly attached to the SketchUp material.
This will also allow us to set the dimensions of the SketchUp material directly, so that we don’t have to touch the UV scaling.
I think UV scaling can be really confusing because you don’t see the same thing in the SketchUp viewport and the V-Ray render. On top of that, depending on how a SketchUp material is created (via the UI, the Ruby API, or the C API), it doesn’t have the same default dimensions. So we can’t rely on default dimensions to set the correct UV scaling.
Therefor I’d rather avoid it.

5

Okay, thank you.

I agree that the UV scaling business is prone to confusion – especially for Sketchup. As far as I understand, the Sketchup default material, as usually applied, does not even have proper UV:s. In Sketchup, object UV:s ought to be able to exist independently of any material applied.

You may consider *.vrmat as a Transmutr output option. It would be of value to bypass certain Sketchup limitations and make Transmutr’s applicability more general.

From the user perspective, there is an added benefit to using vrmats: the Sketchup model may remain small. Whereas now, a single random Megascans 8K albedo map may easily take 80 MB. If this material is saved from Sketchup (default binding on), the 80 MB are added to the *.skm. If saved from V-Ray, it’s just a pointer and the *.vrmat is 0.1 MB. Perhaps then Transmutr could downsize the albedo texture version that is shown only in Sketchup? Let me know if I am getting this wrong.

In any case, we are looking forward to Transmutr material generation.

6

Not really.
Faces with no material (aka “Default Material”) have no UV coordinates.
But when you apply a material with the Paint Bucket tool, UV coordinates are applied to the face, based on the dimensions of the material. That’s why it’s important to set the correct dimensions of SketchUp materials, it makes them much easier to work with.

We already disable binding for all V-Ray materials that Transmutr creates. So in the *.skm we can have a downsized version of the diffuse/albedo map for the SketchUp material, while having the V-Ray material point to the original high-res map file.