UVW Randomization not retained in .vrmesh?

[seltzdesign]

I have a large number of instances in Rhino, all using the same geometry. In this first test case they are just differently transformed cubes that overlap each other slightly.

Now while they are instances I can add a UVW Placement Texture and randomize the UV of every instance (I had to select by Render ID in the material for it to work). Here is the result before with a test texture:

and the result after randomization:

As you can see its much better.

Now my problem. I want to export everything as a .vrmesh for easier handling. Rhino is terrible at dealing with large quantities of instances, so exporting everything as a .vrmesh makes sense. That way I can use it elsewhere and still change the material of it.

But how can I retain the randomization of each cube? I have tried all the Randomization methods (by instance, by object ID, etc), but once exported as a .vrmesh it no longer randomizes.

Is this even possible? If so, how? Is there some way to “bake” the randomization first?

[natalia.gruzdova]

Hello @seltzdesign ,
Thank you for your question.

When you export the whole geometry as a .vrmesh single Render ID is being applied to this Proxy Mesh. You can add the Render ID render element to see the difference before and after exporting.
Randomization is a render time effect that Proxy Mesh does not store as an information.

That being said you have two options:

• Export your whole geometry as a .vrscene. In this case you can set UVW Randomization to By Render ID, By Node Handle or By Node Name. Information about materials will be stored in .vrscene and you will get the same result.
• Another option is to export one object as .vrmesh (box in your case) with By Render ID option and instance the Proxy Mesh itself the way you need.

​

I am attaching an archive with a simple test scene from my screenshots (Rhino 7 / V-Ray 6.00.03).
​
UVW_Random_mesh.zip (996 KB)

[seltzdesign]

Hi @natalia.gruzdova ,

Thanks for taking the time to answer again in such detail.

A single .vrmesh would be the best, since you can still change the material, which you don’t have in a .vrscene. Since you can’t really edit a .vrscene per se, using a .vrscene is not an option. Right? You can’t open a .vrscene somewhere, change the material, save and close it again? If you could that would be an option. A bit like using BlockEdit!? What would be the alternative? Open a new Rhino, import the .vrscene, make the changes, export as .vrscene again?

Using the instances of a proxy is a good idea and one we will probably do anyways.

The big advantage of exporting all instances as a .vrmesh is that the viewport performance is so much better in Rhino. Rhino is terrible at dealing with large numbers of instances (say, above 10k) and the viewport becomes super slow, even in wireframe mode. If you save and replace it as a .vrmesh the viewport is super fast.

I think it would be a nice feature to be able to have a .vrmesh, where I can set the material of the contents, but also the UVW Placement of the contents. I was just thinking: are the Cosmos assets .vrmesh or .vrscene files? It would make sense that they are .vrmesh, but if you have some model that uses lots of copies of an object, say like a picket fence, wouldn’t you want to use instances and UVW Placement for those?

A .vrscene file saves all the V-Ray settings though? So what happens if I import multiple .vrscene files into a scene?

Our usecase is the following: We have a large building we are designing, that is like a gallery for all our outputs. Each output is potentially made up of a lot of instances. So it makes sense to have a master file with the building and so on and then for each artwork there is a separate file for it, so you can still change the material at least and so that the master file is not so heavy.

We could use .3dm files and nest them as blocks, but that doesn’t take the V-Ray settings with it.

This is quite a difficult problem, because Rhino Blocks are already complex and then you have .vrscene and .vrmesh files that also have their complexities.

[natalia.gruzdova]

Hello @seltzdesign ,

Please see my answers below.

A single .vrmesh would be the best, since you can still change the material, which you don’t have in a .vrscene.

In this case you can try another option with .vrscene - importing .vrscene files directly as Rhino models. The tool imports geometries, material assignments, and texture placement. Please check our documentation for more information.

A .vrscene file saves all the V-Ray settings though? So what happens if I import multiple .vrscene files into a scene?

V-Ray render settings are saved in .vrscene for purposes of further rendering with V-Ray Standalone or with Chaos Cloud for example. But when you import .vrscene in your current scene, the rendering settings of the .vrscene are not imported.

Are the Cosmos assets .vrmesh or .vrscene files? It would make sense that they are .vrmesh, but if you have some model that uses lots of copies of an object, say like a picket fence, wouldn’t you want to use instances and UVW Placement for those?

Yes, Cosmos Assets are created as .vrmesh. When you merge any Cosmos Asset you can see that it is Proxy Mesh with standard settings. Initial model is created in a different host platform, that contrary to Rhino allows to set Face IDs or to randomize UVW placement for the objects themselves before exporting. Or none of the listed is necessary because textures are unwrapped for the whole geometry.

Please check our documentation about Proxy Mesh file format, especially take a look at The .vrmesh File Format description and Notes about instancing proxies, perhaps it will be useful to you.

​Also, in Rhino there is another interesting option to save proxies as .vrmat files. Please check this tutorial. ​

[nikolay.bakalov]

Hi, you said above:

@seltzdesign

I think it would be a nice feature to be able to have a .vrmesh, where I can set the material of the contents, but also the UVW Placement of the contents.

The UV coordinates is baked in the .vrmesh file. You can have multiple UV channels on the geometry, and you can take advantage of that to activate different UV placement.
However all mapping is controlled by the material. That is both - UV randomization and multi-channel mapping. So I don’t really understand the formulation of your query.
You already have multiple UV coordinates options on the same faces in the .vrmesh file, and then you set the material that adds the mapping (incl. mapping randomization).

[seltzdesign]

@natalia.gruzdova

When you export the whole geometry as a .vrmesh single Render ID is being applied to this Proxy Mesh. You can add the Render ID render element to see the difference before and after exporting.
Randomization is a render time effect that Proxy Mesh does not store as an information.​

@nikolay.bakalov I am referring to this. It would be nice if a .vrmesh that is made up of many elements, like instances of a geometry would retain the render IDs of the parts so I can randomize across them.

If I understand it correctly now a .vrmesh will not retain any instancing information and just create a single mesh out of everything? So if I have 1000 cubes instanced and turn them all into a .vrmesh, they will be one big mesh!? But in a .vrscene they remain 1000 instances of cubes with their own Render IDs and I can randomize the UV for each cube!?

But when I use a .vrscene instead of a .vrmesh, I lose the ability to change materials, correct?

It seems to me there is currently no way to consolidate 1000 cubes for example and place them in a scene as some Vray asset, where I can actually change the material of the cubes and have them remain instances? That is what I want to achieve and I don’t see how at the moment.

[nikolay.bakalov]

Currently what we export to a.vrmesh is baked into a single mesh, hence since node and single RenderID.
.vrmesh itself does support objects and particle instancing, so in theory, what you need is possible. However I’m not sure whether that is exposed in the API at all

You can instead use alembic files, which all have these features natively, and are also supported by our vrmesh reader. However you will need some third-party .abc exporter in Rhino
and also you will not get the instancing part in the viewport preview when you import an .abc file as V-Ray proxy.

On the other hand, a .vrscene is just a read-only cut of the model. It is not supposed to be modifiable.

As far as I can see, you need something like certain parts of three worlds - vrmesh, vrscenes and rhino block instancing.
That sounds more like a smart programable object that is what Grasshopper is typically used for.

[seltzdesign]

Thanks for your insights. Correct, what we would need would be some kind of mix of vrmesh, vrscene and the rhino instancing. We’ll find a way. I am now playing with using vrmeshes in block instances, which are then instanced. It’s not ideal, but it will do.

Grasshopper is great and we have done many very advanced things with it. 3 things it is not very good at is handling blocks (have to rely on plugins with varying success), changing any kind of render parameters like materials (although V-Ray has some cool things, but still exposes way too little to Grasshopper) and dealing with large numbers of items. Once you go past 10k items in a list that is not just numbers, it gets really slow real quick.

[nikolay.bakalov]

hi,
fortunately GH is getting all missing stuff natively - blocks, materials, lights, textures .. it was presented on the STF last month

with the next release V-Ray will have a lot of new stuff to GH as well. we’re on the path of putting all major stuff you can find in the Asset Editor in GH. this will happen gradually with the time.

I’ll appreciate any input from you and anyone else about what the community need. This will greatly help me in my battle with the project manager on this topic.

[seltzdesign]

@nikolay.bakalov

hi,
fortunately GH is getting all missing stuff natively - blocks, materials, lights, textures .. it was presented on the STF last month

with the next release V-Ray will have a lot of new stuff to GH as well. we’re on the path of putting all major stuff you can find in the Asset Editor in GH. this will happen gradually with the time.

I’ll appreciate any input from you and anyone else about what the community need. This will greatly help me in my battle with the project manager on this topic.

Thanks for the information. I assume you are referring to GH2. Last I heard it is still going to take quite while before it is a proper replacement for GH1, because all plugins need to be rewritten. Or is McNeel adding blocks and so on to GH1?

Does that mean V-Ray will have a plugin for GH2?

But great to hear improvements are coming!
​

[nikolay.bakalov]

The new plugins are for GH1. And they will not arrive exactly tomorrow. V-Ray will have a GH2 plugin, as soon as it has sort-of-a-final a public API