Vray Proxy/Alembic Particle Question

[Dentzz]

I was playing around with Vray Proxy by loading alembic files and wasn't really sure do alembic particles have age also the same question if I created a vray proxy mesh with particles would they retain their age information. They seem to understand velocity or are at least giving me what looks like some kind of motion blur.

[vladimir.nedev]

I think the V-Ray Proxy can read all kinds of vector and scalar information for particles from an Alembic file (including age), but currently there is no way to use it for shading in V-Ray for MODO.
The "Create V-Ray Proxy" command only supports meshes, it doesn't support hair/particles.
You can use the ply2vrmesh tool to convert an Alembic file to a .vrmesh file, and I think all information should be retained, but I am not sure.

And yes, motion blur should be working with triangles/hair/particles from an Alembic file.

Greetings,
Vladimir Nedev

[Dentzz]

I think the V-Ray Proxy can read all kinds of vector and scalar information for particles from an Alembic file (including age), but currently there is no way to use it for shading in V-Ray for MODO.

That is too bad on the particles thing. Is this a limitation on modo/foundry end or something still being worked on vray's end?

The "Create V-Ray Proxy" command only supports meshes, it doesn't support hair/particles.
You can use the ply2vrmesh tool to convert an Alembic file to a .vrmesh file, and I think all information should be retained, but I am not sure.

And yes, motion blur should be working with triangles/hair/particles from an Alembic file.

Greetings,
Vladimir Nedev

Is ply2vrmesh not able to convert an alembic particle to vrmesh as well or is this just a current limitation on using create vray proxy in modo?

[vladimir.nedev]

That is too bad on the particles thing. Is this a limitation on modo/foundry end or something still being worked on vray's end?

That's on our end, I need to figure out how to specify this in the interface. It might be a new texture type.

Is ply2vrmesh not able to convert an alembic particle to vrmesh as well or is this just a current limitation on using create vray proxy in modo?

As far as I know, ply2vrmesh can convert all kinds of Alembic files to vrmesh (mesh, hair and particles).
Not being able to create vrmesh files from particles in MODO is a limitation of the create proxy command in V-Ray for MODO.
I think the same limitation is present V-Ray for Maya as well.

I am not sure when I will have time to look at these two issues though.

Greetings,
Vladimir Nedev

[Dentzz]

Okay cool, was really happy when I applied an item mask to a vray proxy and was able to shade the particle at all, but at that point I wasn't 100% on what info is collected/stored that even could be used later.

Does converting from alembic to vrmesh improve rendering for vray? Also as a side note meshes but not particles show up when rendering proxies on the GPU what am I running into that is not allowing GPU rendering to show up?

[vladimir.nedev]

Okay cool, was really happy when I applied an item mask to a vray proxy and was able to shade the particle at all, but at that point I wasn't 100% on what info is collected/stored that even could be used later.

By the way, how did you create the Alembic file ? The V-Ray proxy reads all kinds of information from it, and at some point I will add a texture to access it, but the information needs to be there in the first place, so it matters how it was created.

Does converting from alembic to vrmesh improve rendering for vray?

The conversion creates a special "preview" voxel in the vrmesh file, which can be shown in MODO's OpenGL viewport.
When using Alembic directly, the "preview" voxel needs to be generated each time V-Ray for MODO reloads the Alembic file(for example when opening the MODO scene), and this might take some time.
As for rendering speed, I am not sure if it matters if you are using Alembic or vrmesh.

Also as a side note meshes but not particles show up when rendering proxies on the GPU what am I running into that is not allowing GPU rendering to show up?

The support for particles in RT GPU was added very recently by our GPU guys and I haven't even tested it yet.
V-Ray for MODO uses an older version of the V-Ray core/standalone (the version is from 2015.08.27), because we are preparing for release, and I don't want to risk somebody introducing a serious bug just before release.


By the way, you can use the V-Ray proxy as a "Point source" in a Replicator, although I don't think the particles will have orientation.
So you are not restricted to rendering them only as spheres/disks.
The replicator instances should render in RT GPU as well, although it will probably be much less memory efficient compared to rendering as spheres.

Greetings,
Vladimir Nedev

[Dentzz]

By the way, how did you create the Alembic file ? The V-Ray proxy reads all kinds of information from it, and at some point I will add a texture to access it, but the information needs to be there in the first place, so it matters how it was created.

Normally I am creating the particles in Modo and exporting out but these were particles that were created in Houdini as an alembic file for caching and wanted to see how they rendered in Vray.

The conversion creates a special "preview" voxel in the vrmesh file, which can be shown in MODO's OpenGL viewport.
When using Alembic directly, the "preview" voxel needs to be generated each time V-Ray for MODO reloads the Alembic file(for example when opening the MODO scene), and this might take some time.
As for rendering speed, I am not sure if it matters if you are using Alembic or vrmesh.

I wasn't sure if it was somehow more memory efficient or faster to have the files be in what I assume is a more vray friendly file format. I tried using the command line but while I could get a mesh to be converted to vrmesh I was only getting a 1kb file that didn't have anything on the particle vrmesh converted file?

The support for particles in RT GPU was added very recently by our GPU guys and I haven't even tested it yet.
V-Ray for MODO uses an older version of the V-Ray core/standalone (the version is from 2015.08.27), because we are preparing for release, and I don't want to risk somebody introducing a serious bug just before release.


By the way, you can use the V-Ray proxy as a "Point source" in a Replicator, although I don't think the particles will have orientation.
So you are not restricted to rendering them only as spheres/disks.
The replicator instances should render in RT GPU as well, although it will probably be much less memory efficient compared to rendering as spheres.

Makes sense to not have the newest version but is the version with particles from 8/27 or the modo version, isn't 2015.8.27 still in the future or am I confused? Will try using the replicators as mostly just playing around but would orientation be needed to have motion blur or would that just be needed for objects created to face in a controlled direction?

[vladimir.nedev]

I wasn't sure if it was somehow more memory efficient or faster to have the files be in what I assume is a more vray friendly file format. I tried using the command line but while I could get a mesh to be converted to vrmesh I was only getting a 1kb file that didn't have anything on the particle vrmesh converted file?

Can you send us (vladimir.nedev [at] chaosgroup [dot] com) the Alembic file so we can see if maybe there is a bug in ply2vrmesh.

Makes sense to not have the newest version but is the version with particles from 8/27 or the modo version, isn't 2015.8.27 still in the future or am I confused? Will try using the replicators as mostly just playing around but would orientation be needed to have motion blur or would that just be needed for objects created to face in a controlled direction?

Sorry, I made a mistake there, I meant 2015.07.27. V-Ray for MODO uses the V-Ray core from this date. The particles in RT GPU were added after that.

Greetings,
Vladimir Nedev

[Dentzz]

Sure but I might send it over the weekend/monday so that I can 1. make sure I didn't do anything dumb and it works fine 2. create a smaller scene/file particle count as the alembic file I was using was like 20gb and had no reason to be that big besides just seeing how vray proxy handled alembic caches.

[Dentzz]

Was able to load the latest nightly and tried using ply2vrmesh and also played around with different particle amounts. ply2vrmesh was able to convert the smaller alembic particle files but didn't work or crashed on the larger ones(larger being ones that were like 18gb).

The .vrmesh files that I converted using ply2vrmesh are able to load in v-ray proxy and in the viewport look okay but they seem to ignore the particle width multiplier. The size can work by doing what you said and using a replicator with a prototype.

However if I try and use the replicator on the V-Ray Proxy as a point source it seems to render based on the preview number, I have no idea if that is how it is supposed to work or not, it makes sense that it functions that way but I could see wanting to preview in the viewport a lot less compared to how many get rendered?

Not sure if you there is any reason to you would need me to still send the alembic file but if you do what is the max size to send?

[vladimir.nedev]

Was able to load the latest nightly and tried using ply2vrmesh and also played around with different particle amounts. ply2vrmesh was able to convert the smaller alembic particle files but didn't work or crashed on the larger ones(larger being ones that were like 18gb).

Can you send us the smallest Alembic file that still crashes ply2vrmesh ?

The .vrmesh files that I converted using ply2vrmesh are able to load in v-ray proxy and in the viewport look okay but they seem to ignore the particle width multiplier. The size can work by doing what you said and using a replicator with a prototype.

Can you send me the file that ignores the particle width as well ? When was the width ignored - when rendering or for the OpenGL preview, because the preview has a limitation on the maximum particle size I think, because it renders them as points. Can be fixed probably, but will make the preview slower.

However if I try and use the replicator on the V-Ray Proxy as a point source it seems to render based on the preview number, I have no idea if that is how it is supposed to work or not, it makes sense that it functions that way but I could see wanting to preview in the viewport a lot less compared to how many get rendered?

Yes, when the V-Ray proxy is used as a particle source, it will give MODO the preview particles (you can select "Render geometry" for Preview and it will give MODO all particles).
I don't think I can distinguish between OpenGL preview/render when the V-Ray proxy particles are used in a Replicator.
I just give the particles to MODO, the Replicator does something to them and gives me (transformation, instanced object) pairs for each particle at render time.
When I give MODO the particles I don't know whether they will be used for the OpenGL preview of the Replicator or for rendering.

What I can do, is show the preview number of particles in the OpenGL viewport (as points), but always give MODO the final number of particles for the Replicator.
So if you enable the OpenGL preview of Replicators, it will always show the rendered number of instances.

Not sure if you there is any reason to you would need me to still send the alembic file but if you do what is the max size to send?

As long as you can upload it somewhere, I don't think it matters how big the file is. A smaller file will be easier to debug though.

Greetings,
Vladimir Nedev

[Dentzz]

Sent the smaller vrmesh file. Might need a bit more time to figure out how to send the larger file, or if I can get a crash with a smaller sized file.

[vladimir.nedev]

Sent the smaller vrmesh file. Might need a bit more time to figure out how to send the larger file, or if I can get a crash with a smaller sized file.

I took a look at the file, and now I remember that the "particle width" multiplier affects only Alembic files.
That's why it doesn't affect the render/OpenGL preview in MODO in this case.
The ply2vrmesh tool has an option "-particleWidthMultiplier" which you can specify to bake the particles in the vrmesh file with a specific size multiplier.

The reason for this is that the particle size affects the bounding box of each particle, which is something the ply2vrmesh tool needs, in order to split the particles efficiently into voxels for rendering.
When you use an Alembic file, the splitting into voxels is done on the fly, which probably means that the whole Alembic file is loaded at once (I am not completely sure about this part though).

The ply2vrmesh crash with the larger file might be caused by the particle size as well. These big particles have a lot of overlap between them, which might present a problem for the voxel splitting algorithm.
Try the big file with a suitable "-particleWidthMultiplier".

Greetings,
Vladimir Nedev

[Dentzz]

Cool, got the particle width set into the vrmesh at creation time.

Is this something that can be changed after it is a .vrmesh, such as rerunning ply2vrmesh, it either seems to have no impact or crashes.

Also (I understand currently modo vray can't use particle attr on the proxy) is it possible to set particle width by particle attributes such as age or is this something that because of how it is created is locked into the vrmesh file format and can't be changed at rendertime or just that it needs some attribute that has to be defaulted for display in the viewport purposes?


The 18gb file still crashes ply2vrmesh even setting the particle width. Since you looked at the vrmesh file if it didn't seem like I had some crazy channel from houdini that was being sent into the format you think that increasing the size of the scene might help or do you think there is just an upper limit for either the ply2vrmesh program or my computer running ply2vrmesh?

Signed up for free One Drive account so hopefully if it ever uploads sometime in the next few hours will be able to email the slightly smaller file that is still able to crash ply2vrmesh.

[vladimir.nedev]

Is this something that can be changed after it is a .vrmesh, such as rerunning ply2vrmesh, it either seems to have no impact or crashes.

I don't think you can use a .vrmesh file as input to ply2vrmesh, but you can rerun it on the original Alembic file with a new particle width, of course.

Also (I understand currently modo vray can't use particle attr on the proxy) is it possible to set particle width by particle attributes such as age or is this something that because of how it is created is locked into the vrmesh file format and can't be changed at rendertime or just that it needs some attribute that has to be defaulted for display in the viewport purposes?

I don't think the particle width/size can be changed once the .vrmesh file is created. It is locked in the file.
The direct Alembic rendering, as well as the ply2vrmesh tool will try to read radius/width data from the Alembic file, if it has it.
I am not sure but it might be possible to export the particles with their correct radius/width directly from Houdini, so you don't have to set a fix width with the "particle width mutliplier".

The 18gb file still crashes ply2vrmesh even setting the particle width. Since you looked at the vrmesh file if it didn't seem like I had some crazy channel from houdini that was being sent into the format you think that increasing the size of the scene might help or do you think there is just an upper limit for either the ply2vrmesh program or my computer running ply2vrmesh?

I am not sure how ply2vrmesh file works in this case, it might be loading the whole Alembic file into memory.
Can you check how much RAM it takes while running (if it's not crashing immediately of course).
How much RAM do you have ?

Greetings,
Vladimir Nedev