proxies containing instances?

[super gnu]

im trying to figure out the most efficient way to render a scene containing millions of little stones scattered with forestpack. at the moment the render itself takes a couple of minutes, but the scene setup (updating instances etc, slowly filling ram) takes another couple of minutes, and, very frustratingly, after the frame has been saved, i have to wait another 2-3 minutes as the ram *unloads*

this is despite the scatter being static, and the camera culling etc linked to a static cam that covers the scene. - i had hoped stuff could be reused between frames.... it seems not, the setup time difference between frame 1 and 2+ is a few seconds.


so i was looking at options.... exporting to instances is one, but there are 160 million individual stones... im not sure max would survive with that many individual objects, or if it will help.

i was wondering if proxy supports instancing internally? that way i could bake out the fp, and if it doesnt crash, export those millions of instances to a single proxy file...


ive no idea if this would have any effect on rendertimes, positive or negative... i guess i need to test, but if instancing is not supported in the proxy file, itll be absolutely enormous.


and please Chaos... find some clever way to fix the super slow "ram unloading" thing at the end of the render when using displacement/fp etc..... its infuriating when the machine sits there doing basically bu**er all for longer than the actual render takes, and you have hundreds of frames to render. ..... iirc neither gpu or IPR have this issue so i find it hard to understand why its unavoidable on production cpu rendering. surely, the render is finished, saved.... just kill the render process already? i know for sure from crashes that ram is capable of emptying itself extremely fast.

[Vizioen]

Yeah, I still have this problem as well. The only thing I can try is to optimize the FP as much as possible with camera culling etc. But even then the unloading is extremely slow at times. I poke Chaos about this every year or so: https://forums.chaos.com/forum/v-ray...on-heavy-scene

But not sure they're still on it. Optimizing the algorithm for rendering is one thing, but if you're losing more time with memory unloading then with setup and rendering combined it's a bit idiotic. I remember Vlado mentioning it's a Windows problem. I wonder actually if you would be rendering this on a Linux server if you would have the same issues.

[yavor.rubenov]

Hello,

In which V-Ray version do you get those slowdowns - we did some improvements in V-Ray 6 especially for proxies

Best regards,
Yavor

[Joelaff]

What happens if you cull with another method other than camera culling? I seem to recall camera culling being slower in FP even with a static camera.

if the camera is static could you cull with a shape or object or something by not distributing in unseen areas to begin with?

[super gnu]

What happens if you cull with another method other than camera culling? I seem to recall camera culling being slower in FP even with a static camera.

if the camera is static could you cull with a shape or object or something by not distributing in unseen areas to begin with?

to be honest camera culling itself isnt really necessary, the scene is already shaped to avoid stuff being scattered out of shot, however im using the camera section for falloff in density and scale. my cam move is a simple crane shot within a small area, so having those falloffs linked to a static camera in the same general position is fine.. however the alternatives (distance tex based i guess) would risk changing the look, which has already been signed off...

having said that, if you have found major differences when using/not using camera based effects (not specifically culling) , it might be worth a try..



ahh and wrt vray version, it is true ive had to downgrade to vray5 to be aligned with my client for this job, so i may be missing some improvement.. having said that, its definitely still an issue with 6/


ive also tried converting the forest to 166 million instances... lets just say, as expected, i got nowhere near 15% on the progress bar before max had had enough.

Probably futile anyway since it would break the forestcolor effects i am using...

[Vizioen]

Can you make your patch(es) that you scatter with bigger so they cover more area? So you have less instances?

[super gnu]

Can you make your patch(es) that you scatter with bigger so they cover more area? So you have less instances?

unfortunately im using forestcolor to match the colours of the pebbles to the underlying texture.. if i use patches, it is my understanding that the "colour from texture" feature doesnt work on sub elements of a mesh. i also need an imperceptible falloff in density and scale, blending into the base texture. so i scattered individual stones.

it actually works great, uses less ram than displacement, renders decently fast, and apart from this issue, which basically doubles my rendertimes uselessly (and an understandably quite long render initialization) ill happily leave it as-is.

[yavor.rubenov]

having said that, its definitely still an issue with 6

Scene with assets sent to our support will definitely help

[super gnu]

Scene with assets sent to our support will definitely help

yes i appreciate that, and when i can ill send a file, you probably experience this quite a lot , but usually, when im asking about issues, im in the middle of an intense job with deadlines approaching, and files with tens of gigabytes of assets which i cant easily share also for reasons of client confidentiality etc. ... finding time to create a file to send over is often tricky..!

anyway ill see if i can package something up today.

ive just reinstalled vray6 and upgraded to latest forestpack (i was still on 6) rendertimes seem more or less unchanged, just waiting for a couple more frames to confirm.

[fixeighted]

Just a thought...could you not use 'planar from world' mapping to colour patches?
That way you can do away with Forest Colour and individual stones.

[super gnu]

Scene with assets sent to our support will definitely help

i am uploading an archine of the scene on a support ticket.

there are actually two issues here, one, the discussed excessive delay after the render before starting the next framne, despite geometry and textures (in theory) being unchanged. (this is marginally better in vray6, but still an issue)

the second issue i was really hoping was resolved by moving back to 6, but ive just seen is not:


i have gradually increasing rendertimes, frame -on frame, whereas, given the camera move, rendertimes should slowly decrease...

in both deadline and max, i get about 15 seconds added each frame.. if i stop the render and restart from the current frame, the rendertimes return to normal, then begin ramping up again. even more wierdly, this isnt accompanies by an increase in ram use, which was my first thought.... ram usage is pretty stable throughout the sequence.


my currednt solution is to set a task size of say, 10 frames in deadline, and restart max between tasks.... however im not sure this actually saves any time given how long the scene takes to reload. its a p.i.t.a..

[super gnu]

Just a thought...could you not use 'planar from world' mapping to colour patches?
That way you can do away with Forest Colour and individual stones.

yeah i probably could but to redo the gravel when client has signed it off, have less cotrrol about blending in distance, on the off-chance that it might render a bit quicker if i dont use the camera tab in forestpack .... hmm, tbh i might just leave it.

[super gnu]

ticket opened : #84641

[Vizioen]

Interested in how this pans out.

[Joelaff]

Did you try deadline’s “Restart Renderer Between Frames” options in the submission? Might be worth a shot, and it is much faster than restarting Max.