It’s quite nice feature new mental has with those animated proxies.
Is there any chance for vray to have this kind of thing?
Finally we could have a lot a lot of trees moving on the wind 
If I understood correctly they will be included in SP2. Will definitely be nice to have alright! 
So, only two more days of waiting until we can enjoy the new features (the VRayIES Lights will be a more than welcome addition as well). Keeping my fingers crossed and hoping the SP will be there April 20th
Animated V-Ray proxy object are supported for SP2.
Best regards,
Vlado
when animated proxies are instanced though we could use some sort of way to randomise the beginning frame of the animation loop or something to give a bit more randomness
Yes, randomization of the start frame of the “local” animation of one proxy instance would be useful indeed. Then again I could also create several proxies of the same object in which the animation is already random before I convert to proxy. However, with very large proxies (filesize) that wouldn’t be practical and maybe even defeat the purpose of a proxy.
So a built-in “start from keyframe x” would indeed be a very welcome addition. And of course it would also be nice if you could set that property for selections of proxies as well (not just on the individual level). Wouldn’t want to manually set the start frame for 10000 trees / characters
from the image Vlado posted a while ago with this i think there must be some sort of time offset as you could see they weren’t all moving identically - arms and legs in different positions…
You can specify a staring frame, as well as playback speed for each proxy.
Best regards,
Vlado
Great!! Thank you for clearing that up, Vlado! Can’t wait to start implementing this in some of my upcoming projects!
the problem though is if a proxy is instanced then all of the instances will change when you change the start frame of one
Yes, and this is why we need some VRayProxy Mass Controll. This is a simple test
Character is a 26.000 Polygon Count
The .vrmesh file is a 127 MB.
Import the VRayProxy
The character and VRayProxy
100 Charatcers. 5 of them are the “non istance”. Other are instance. I manually change the offset for 5 VRayProxy.
Rendere with QMC+QMC, AA DMC and low priority.
VIDEO
Bye
cecofuli
yeah - have you seen that VrayScatter pluggin that someone wrote?
That looks great…would be great if we could all get at it!
yeah. it would have to be non-instanced to vary the start time and vrayproxy is great when instanced
Yes, exactly Da_elf. I had kind of hoped there would be some sort of independant (VRay specific) control to vary start time while still allowing you to instance the proxy geometry.
As for mass changing start frame, that could easily be done through MaxScript using the anim_offset property of the Proxy object (make your selection and set the $.anim_offset value). Just create a tiny custom interface for that. But that’s not going to work now (verified) because it’s a true Max instance. So like you said, changing one changes all. Unless you don’t use instances… which you don’t really want. Hmm…
There is little point in instances for this one; since you will be using different offsets for each proxy, the geometry will end up being different anyways and will have to be loaded separately.
Best regards,
Vlado
I was updating my planting interface, and can confirm that in case of a COPY of the PROXY objects, vray will have to load each copy’s actual frame once per proxy, even if the file the proxy references to is just one, leading to huge rendertimes due to disks speed (i’m on a 4 disks raid, and it’s still very much on the slow side).
PFlow now does accept proxies as shape objects, though, even though the feasibility of that method compared to hand copy I still have to prove: in any event when the proxy is animation-offset PFlow will try and load ALL the proxies as individual meshes before render start (no proxying whatsoever, massive memory usage).
EDIT: this is in the case one has the wrong PFlow render settings:flow as single mesh 
It can be partially alleviated with rendering one mesh per particle, but in case of a GI the load and memory occupation remains massive.
It’s a tricky one for sure…