I thought of starting a new thread where several bugs we have been experiencing with Vray for Rhino plugin will be pointed out in a hope that they will be resolved at some point in the future. Please feel free to add to this list.
We are an architecture office that uses Rhino in its everyday workflow more and more and finds the program very useful. Unfortunately, we are disappointed that the rendering, material/texture handling and in particular Vray plugin are still far from what 3ds max version offers. This often forces us into a workflow where the Rhino model has to be exported and then rendered in another software which is both time-consuming and costly. I know similar is true for many other offices. Most issues probably originate with the Vray developers, however I think both software should do a step further in making it work.
interoperability: Vray community has build high-quality collections of materials and models for its most used software 3ds max and Maya. Using those assets in Rhino is not very well addressed, needs a ton of manual setup and adjustments. This makes it difficult to achieve the same level of the final output. We are sometimes exporting 3ds max assets as a vrayscene objects to use them in Rhino. However this requires us to have a vray for 3ds max license, open each file separately and export it out for Rhino to understand it. Once the files is exported it is also impossible to change any of its settings. Sometimes the assets will also not render the same.
Vray assets importing: There seem to be several bugs related to importing of the Vray assets such as materials and lights. when copying a Vray material from one file to another we have experienced everything from files crushing, to materials not importing correctly, to materials becoming Rhino materials, to renaming of imported materials as (imported1, imported2,…) making and endless list of same materials. The way of handling Materials with duplicate names is also not resolved and behaves inconsistently. The same problems persist when working with referenced Rhino files (which is for us a common practice).
texture handling: Rhino has a very confusing way of handling textures and other external files. Ideally, we would like to find a way, where all the textures would be saved in one place on the server. However Rhino keeps creating a folder called filename_embedded_files, despite always choosing not to embedd the files.
Rhino default Materials library: it uses its own files format .tx, which creates a temporary jpeg file when the material is added to the scene. Those temporary files get random generated names and are then periodiacally deleted. This makes maps go missing, difficult to relocate or being located in all kinds of places where they shouldn’t be.
display of maps: Rhino display modes often don’t work well with Vray materials and can’t preview them realistically or at all. This is often problematic as we want to create a mapping of objects, which is of course impossible without a preview. The workaround is to create a Rhino material with the same maps as the Vray version, map the objects and then replace the material with the Vray material - time consuming and unnecessary.
It is difficult for me to say which of those issues come purely from Vray developers and which can be addressed by McNeel, but there is clearly also a need for better communication between both sides that will be neccessary if Rhino desires to become a viable high-end platform for rendering.