Support for VRay Standalone

[Joelaff]

Hey,

What exactly of Phoenix is and is not supported in VRay Standalone?

I am guessing I need to use Volume Grid instead of a Phoenix node to load grids? Should this work for both smoke/fire and liquids?

I am having trouble getting the Particle Shader to work. Sure would be nice if that would.

I don't get any warning about these things not working when I use the Analyze feature of the .vrscene exporter, and many are not listed on this page, which is the best list I have found of comparability issues with Standalone.

Thanks.

[Svetlin.Nikolov]

Hey, no need to use a volume grid, Phoenix simulators are the same thing.

I don't know of any issues concerning vrscenes and particle shaders at the moment, and overall very few things are not working in vrscenes. Are you using a simulator + a particle shader, or did you have problems when you used a volume grid? If so, try the simulator. Or perhaps you are using a more exotic setup, like prt reader? Or are you rendering with V-Ray GPU? Does any of the toolbar presets that involve particle shaders work, like the cigarette smoke, or the waterfall?

If you are having issues on the Cloud, first try exporting and rendering the vrscene from 3ds Max locally - if it works locally, then the problem is Cloud specific. Otherwise, if it doesn't work locally, it's a V-Ray standalone issue.

Cheers!

[Joelaff]

I was testing locally. I have a scene that uses a Krakatoa PRT Loader to load PRT files created from Phoenix. Those are then shaded with the Phoenix Particle Shader. They were not rendering. When I use the same Krak PRT Loader and render using TyFlow (using it's Mesh operator set to render instances) is was working.

I am going to do some more testing with a simpler setup.

[Joelaff]

OK. A few issues...

If I load the PRT files with the PHX PRTLoader they do render with the PHX Particle Shader, however, in Standalone the color is coming from one of the channels (maybe from Age), even though I have Color From Particle Channel turned OFF. In other words the Constant Color is being ignored in Standalone. It works correctly rendering in Max. Color from Tex seems to work correctly; so putting a VRayColor map into that slot is a workaround.

If I turn on Color from Particle Channel and render in Standalone I always get the same result, no matter which channel I choose. I think it is the RGB color form the particles.

Speaking of RGB from the particles I don't seem to have ANY way to render that color in Max. It's not an option in the popup menu for the channel selection. The particles are rendering the color of the Constant Color setting.

If I use the Krakatoa PRT Loader to load the particles they render fine with e Particle Shader in Max, but in Standalone they do not render at all with the Particle Shader. The Krakatoa PRT Loader particles work fine with TyFlow-- and render in Standlone that way. So it seems like there is something that is choking in the interface with the Particle Shader.

Note I am Max 2021. PHX build 2022120131770 and VRay build 31790 - Standalone is the release version of the Hotfix 3. (Are there stable builds of Standalone, I could not find them? Does someone need to enable that on my account?)

The Liquid seems to be rendering fine in Standalone (from a Phoenix node).

[Joelaff]

Another note. I think I found a workaround (though it would be great if it would "just work"). It seems that I can use a TyFlow to Birth PRT from the Krakatoa PRT Loader, and PRT Update so that it mimics my Krakatoa PRT Loader (which I need to use for some of the loader features, and to use Magma Modifiers to modify the particles as well). I have to Enable the Particle Interface in TyFlow to be able to select it as the particle source for the Particle Shader.

So rather than Selecting the Krakatoa PRT Loader as the source of particles for the Particle Shader I instead pass it through TyFlow and then it seems to render in Standalone. I need to do an animated test, but with a still it is working!

Of course it would be ideal if you could get it work without having to do this.

[Joelaff]

Hmmm... So the TyFlow thing seems to be working, though of course it has to calculate out to export the vrscenes (even though it is just updating). But what is not working is the Constant Color in the Particle Shader seems to be ignored as I said above, and when I use a VRayColor (or even a checker) as a map to change the color then Standalone VRay crashes.

I am actually using the same Standalone version as my 3ds Max VRay versions, as I didn't realize it was being mapped to use that version of VRay Standalone that is installed with the Max version (VRay build 31790 in my case).

So I can't quite get my scene to render correctly with standalone. I tried just Save Particles from Krakatoa renderer to export all my modified PRTs to a single PRT, however it seems that the original PRT export from Phoenix puts the "size" channel data into a single value, rather than a X,Y,Z array, and Krakatoa complains that the arity does not match, and I can't figure out how to force it to save the size to either format (one dimensional or three dimensional values). It just refuses, and if I copy it to Radius channel then the PRTLoader with Phoenix (or the particle shader) ignores it. I get you are using a single dimensional value to save file space, but isn't that what radius is for? Size should be XYZ, no?

[Joelaff]

So when I started simplifying the scene to try to send it your way I got the Color by Tex with a VRay color to work without the crashing. So I will see if I can figure out what solved the crash. Likely light exclusions if I had to guess, but I will try to figure out.

[Joelaff]

Here is a stripped down scene that exhibits the crash:

• Load the scene.
• Go to The Asset Tracker - Right-click Set Path to the PRT file -- It doesn't want to load from the scene dir without this.
• Go to the VRay Menu and Choose vrscene exporter
• Click Export and Render
• Hangs and crashes out on Building Light Cache

There are many things that can make it not crash. Changing the lights around. Turning some on or off. Even deleting some of the unused objects sometimes makes it work. But in this state I sent it it will repeatedly fail.

Also unchecking Color from Tex in the Particle shader ( PhoenixFDLiquid001 FoamShaderGreenCubesA ) Always fixes it, but then the particles render much darker, and they ignore the Constant Color setting in that particle shader.

Max 2021 PHX build 2022120131770 and VRay build 31790

Thanks.

[Svetlin.Nikolov]

Ah, thank you! Checking it right now...

[Svetlin.Nikolov]

Seems to be holding up here without a crash, using Max 2023 and the V-Ray and Phoenix builds you mentioned, which frame do you render?

I am sorry about the Color from Particle Channel option - right now it is indeed hardcoded only to the RGB channel. I was removing it from the official builds until I have time to finish it properly, but it's visible in the nightlies The workaround is to plug a Phoenix Particle Texture in the Color Map slot and read the channel you like, although this could be much slower than reading it directly, which the new option would allow eventually...

As for the Krakatoa PRT loader - since it's a 3rd party plugin, this makes it different than everything that is Phoenix or V-Ray. I was thinking only about the Phoenix and V-Ray functionality in vrscenes when you asked. So overall, in order for something to render via vrscenes, there needs to be a vray plugin in c++ that handles it, or it needs to be baked at export time to something generic, for example - a mesh. So 3rd parties, like Krakatoa, could either write their own V-Ray standalone plugin that would work in V-Ray, or alternatively we need to mirror all their functionality, which is impractical. There is no V-Ray standalone plugin for the PRT Loader right now, so unless it gets meshed at export time, it would not render via vrscenes, and thus - on the Cloud.

However, I DID manage to reproduce the particle shader color issue with vrscenes, looking into it now...

[Joelaff]

Try frame 1036. If you still can't get it to crash I can try to make the .vrscene file here if that helps.

OK. I see what you mean about the plugins... kind of. Is there no way to just export the particle data to the vrscene? For instance for your built-in PRTReader how does the particle data get saved such that the Particle Shader will work in Standalone? Or is the data literally being read from disk, just like in Max?

[Joelaff]

Here is the vrscene that is crashing mine. I am on the nightly of vray from Dec 30

https://esi.sourceopen.com/crasher.zip


Also running Phoenix nightly from Dec 30.

[Joelaff]

Note you do need to select the prt files as described above. You have to Set Path in the Asset tracker to the appropriate file location.

Oh, you do have Krakatoa installed, right? Because that scene uses the Krak PRT Loader going into TyFlow, which somehow acts as the glue that works with vrscene and Standalone. Does TyFlow have a plugin for Standalone, or is it just somehow writing the particle data to the vrscene file?

[Svetlin.Nikolov]

Yup, was on a fresh Windows and did not have Krakatoa at first, but then I installed it.

Will check it right now.

Meanwhile, the particle shader vrscene difference for the constant color was due to a change that didn't go into the V-Ray stable nightlies - I picked it there and it will be fixed tomorrow

[Joelaff]

Awesome on the fix for the color difference, thanks. I was able to overcome that lack of PRTLoader by using TyFlow as you see in the scene. It does have to processes each frame before vrscene export (not sure why it can't just do one frame, I may be missing some setting for that), but it does work. I got it to render with Deadline (both locally and on AWS) using that.

You might need the .aur files which I noticed are referenced in the .vrscene file (I had mistakenly though that the AUR and particle data were embedded in the vrscene file.

Here are the two aur file for frames 1035-1038, which I think will properly cover frame 1036 (which is time-remapped a little).

https://esi.sourceopen.com/PHX.zip