Then upon further opening you might have got all “Placeholder” materials duplicated as “Custom” materials automatically. The model was opened without V-Ray being loaded, and then saved again. The types of the materials have deliberately been changed to non “Placeholder” while V-Ray was not loaded, and further modified them If I enable V-Ray and open the file I get this message: This was once a V-Ray material, and if it stayed like that we would generate that low-res. In any case it would be interesting to debug both Btw Rhino is using the same approach to display its procedurals in the viewport. tx files but also the procedural textures visible in the viewport. tx converter in favour of the core texture sampler soon. I guess either there is a bug somewhere convering the files, or the Windows codec is playing tricks ( not the first time this happens), or it is some edge case related to the moved model files.Īnyway we are going to ditch the. We use the standard Windows codecs for that. jpg files, which Rhino OpenGL pipeline can handle. So we convert those files to low-quality temporary.

tx image format V-Ray library materials use.

The white textures are due to the fact that Rhino does not understand the. They are missing essential metadata, that is fetched from the database, and then the entire asset becomes renderable. Having the cosmos model files on the disk is not a guarantee that it would render. Most probably the database is missing the exact asset revision. The red tick in AE and the lack of geometry in the render. There are two indications that the Cosmos Assets links are broken.

I believe both problems comes to moving the model file between different machines.

V ray library