Tweet
I am importing some ABC particles into VRayProxy, which does a nice job of rendering them as spheres in a seemingly efficient manner (vs. instancing spheres or other shapes with VRayInstancer).
I would like to have some more control over the particles, like the ability to randomize their scale, etc. In a perfect world I could apple Magma Modifier from Krakatoa to the VRayProxy and modify the particles that way. Now, to use MagmaModifier I seem to have to export to PRT (with TyFlow) and then load them in with PRTReader (or PRTLoader). Of course if I am using TyFlow for a processing pass then I might as well export another ABC from TyFlow to get the fast sphere rendering. This is what I have been doing... ABC->TyFlow->ABC. This works, and may be the best solution given the limitations of standalone.
We are rendering in Standlone linux because cloud rendering is SOO much cheaper that way vs. Windows. So this means that using something like Frost is not efficient because that requires creating vrscenes with all the geometry in them as opposed to just the point data. This is slow and makes giant vrscene files. Even though this can be done frame at a time, and done on deadline. It is still not very efficient. Hence why we are trying to just use ABCs loaded into VRayProxy for rendering... Standalone can reference the ABC file and create the spheres to render from that, without storing large geo in the vrscene.
Any other thoughts on this process?
It would be nice if there was a least a randomize scale option in the particle renderer in VRayProxy. While I doubt it would meet the size distribution requirements as well as using TyFlow, it could solve a number of issues.
It would also be nice if VRayProxy had a Render % control to control what percentage of ABC particles get rendered so that this can be controlled easily.
Thanks.
I would like to have some more control over the particles, like the ability to randomize their scale, etc. In a perfect world I could apple Magma Modifier from Krakatoa to the VRayProxy and modify the particles that way. Now, to use MagmaModifier I seem to have to export to PRT (with TyFlow) and then load them in with PRTReader (or PRTLoader). Of course if I am using TyFlow for a processing pass then I might as well export another ABC from TyFlow to get the fast sphere rendering. This is what I have been doing... ABC->TyFlow->ABC. This works, and may be the best solution given the limitations of standalone.
We are rendering in Standlone linux because cloud rendering is SOO much cheaper that way vs. Windows. So this means that using something like Frost is not efficient because that requires creating vrscenes with all the geometry in them as opposed to just the point data. This is slow and makes giant vrscene files. Even though this can be done frame at a time, and done on deadline. It is still not very efficient. Hence why we are trying to just use ABCs loaded into VRayProxy for rendering... Standalone can reference the ABC file and create the spheres to render from that, without storing large geo in the vrscene.
Any other thoughts on this process?
It would be nice if there was a least a randomize scale option in the particle renderer in VRayProxy. While I doubt it would meet the size distribution requirements as well as using TyFlow, it could solve a number of issues.
It would also be nice if VRayProxy had a Render % control to control what percentage of ABC particles get rendered so that this can be controlled easily.
Thanks.
