Support for VRay Standalone

[Svetlin.Nikolov]

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?

Oh yeah, the data's getting read from the PRT file not at the time of the export, but during the actual render. It's technically possible - it's the same concept for baking the textures, voxels and particles to vrscenes - right now the approach is to have the data out of the vrscenes since it might be quite large (this is a problem with meshes for example).

[Joelaff]

Oh yeah, the data's getting read from the PRT file not at the time of the export, but during the actual render. It's technically possible - it's the same concept for baking the textures, voxels and particles to vrscenes - right now the approach is to have the data out of the vrscenes since it might be quite large (this is a problem with meshes for example).

I see, now that need for a plugin makes perfect sense. How is it working with TyFlow , though?

Oh, it is embedding it, I think (which is good in this case):

GeomParticleSystem node_UID1138tyFlow001 {

[Svetlin.Nikolov]

Alriiight! With the AUR caches, got the crash finally! Let's see now...

[Joelaff]

Good. Glad it’s wasn’t in my imagination!

I am off to bed. May Grace Hopper by with you in your bug quashing quest!

[Svetlin.Nikolov]

Oh, it is embedding it, I think (which is good in this case):

Ahaa, nice! My guess was that perhaps the tyFlow particles were getting meshed, but then they wouldn't render with the particle shader...

[Svetlin.Nikolov]

Dang, found it, but will have to summon a colleague for it, and it will have to wait until after the new year's.

The crash started happening in the Phoenix nightly from 7 November, but if you roll back to it, the AUR caches would not open correctly and will in turn cause a crash.

This happens because we upgraded the AUR format a month ago, so the cache would need to be simulated again with the older Phoenix. Would this be an option for you?

[Joelaff]

Thanks for tracking this down.

The project is delivered. So at this point this is all academic on my end. I am trying to be prepared for standalone use in the future because, when cloud resources are needed it is much cheaper than rendering on Windows, since MS upped their data center per-core tax. Also, this project will be re-rendered again with some tweaks in the next week (a client addition to the non-Phoenix parts of the shot that are not included in the stripped down file).

I am happy to re-simulate if it will help with testing/debugging. Rolling back the entire farm would be cumbersome, but a machine or two as a test might work. (Still need to work out some ideal mass deployment method.)

Thanks again.

[Joelaff]

Here’s another thought… just throwing this out there.

I know changing files specs, like the changes to the AUR format, is a big pain for many reasons, especially with Chaos Cloud compatibility being something to think about as well. I wonder if it would be worth the effort to put the ability to change AUR spec versions of existing caches into the command line tools. That way you might feel more free to make improvements without having to worry about changes to the AUR spec that might break things.

No clue how hard or possible that is, but I know how having to be rigid in one area can place limitations on other areas. Perhaps it would be a freeing experience

Anyway, very cool things coming out of the team, there.

[Svetlin.Nikolov]

Exactly what I've been thinking earlier today! It would be a bit fragile, but it would offer an alternative that currently is not there.

While playing with different setups today I noticed another difference between the 3ds Max and vrscene rendering - Particle Shader with a texture in Object XYZ in Points/Bubbles/Splash/Cellular modes renders differently. I will see what's up with that right now...

[Joelaff]

I just heard today that will we will need to be doing more renders of this project with some tweaks to the non-Phoenix parts (I hope!). We should be able to render in Max for now, but standalone may be the future, since linux is so much cheaper (and I have heard faster, but have not tested yet).

[Joelaff]

Just checking in on this issue. I have a little time where I could test any fix if there is one.

Thanks.

[Svetlin.Nikolov]

Hey, right on time - the fix for the crash went in today's Phoenix nightlies!

I did some fixes to object xyz mapping in 3ds Max with the particle shader, but there is also a difference between object xyz in 3ds Max and the V-Ray Standalone that I am working on at the moment - I hope it will be in the nightlies in the next few days as well, will ping you

[Joelaff]

Thanks. I will check it out. So the build dated 1/5 31827 ?

[Svetlin.Nikolov]

Yess, that's the one!

[Joelaff]

So far so good. NO crashes in standalone! I will keep at it some more, but thus far seems to be working well in both SA and Max.

The modifiers are pretty awesome too! They even work on the particle shaders without having to apply them to some particle source object (the source of the particles rather than the particle shader. That is a real plus.

Quite fast as well, 4mil+ cells are deforming almost realtime (or as fast as the AUR files will load).

The modifiers do not automagically apply to cutter objects, but I wouldn't really expect them to.

Can't wait for FFD

Speaking of AUR files loading. It would be cool if these could be cached in RAM. I could be a simple FIFO, but that could be quite helpful sometimes (esp since this machine has 512GB of RAM).