Rt ram usage vray 3.01.10

[auke]

Playing around some more with the scene I noticed the ram problem emerges with translating displacement. Once it reaches this point the ram fills up in a constant steady pace until it's full, from that point on the system crawls until it decides it is finished after some hours (even when the goals set in the render settings are not reached.) The proxies in the scene did not influence the problem noticably. I'm suprised the ram usage is so high during translation despite it fitting on the Vram with ease. Is this a potential issue or simply a technical limitation at this time?

[super gnu]

i believe its due to the how displacement is handled in RT.. when you render displacement on gpu, it is first created as a complete mesh on the cpu, before being uploaded onto the gpu for rendering. with really heavy displaced scened this can take much more ram that the final outputted mesh does.. or something like that.

one thing ive found tht helps is to subdivide your base mesh as finely as possible before rendering. this seems to give less work for the "precalculation" of the displacement on the cpu.

[vlado]

You can also increase the "edge length" for the displacement, especially if you render large resolutions.

Best regards,
Vlado

[super gnu]

just to revive the original theme of this thread.. same test scene i used then, basic landscape with a modest forest of proxies generated by forestpack..

with 3.02.03 i still have the issue whre the scene renders on cpu with 6gb ram, but on gpu it maxes out my ram on the compiling geometry stage, and seems it will never start rendering.

i thought id try converting the forest to plain instanced proxies..

this at least works better than forestpack, but a) it still uses 17gb of ram compiling geometry ( as opposed to maximum 6gb when using cpu) and also, after getting to the actual render, within a few seconds i get a "cuda error code 719: exception occurred on the device while executing a kernel", and it stops rendering. ram usage on gpu at time of crash was 4.6gb.


not looking too hot for my masterplan stuff on gpu at the moment

i can send an updated scene if it would help.

[super gnu]

ok ive managed to get it to render by reducing the number of trees from 40,000 to 30,000.. odd id have assumed it would not be limited unless the ram was full. could it have been some coplanar faces amongs the intersecting trees? id not imagine that would throw an error either.

anyway next problem:

i got a decent render out in about 10 minutes, so i thought id try a few frames overnight to see how the gpu behaves, and check the shimmering in the foliage.

i set 200 frames going, first frame completed ok, using about 4gb on gpu and vray.exe using about 7gb
it saved the frame, moved onto frame 2 and...stopped. before the gpu even got involved.

ram usage rose again on vray rt up to about 12gb, then stopped rising... i waited 15 minutes then cancelled.

max is half crashed (i cant close render dialog, which wont cancel, but i can save the file and spin the viewport.)

any ideas? so far everythng im trying on rt beyond the benchmark scene seems to have issues

-ive wetransferred latest scene to vlado.

-update:

with 95% tree reduction, the scene renders as expected.. 50% reduction it still locks after first frame.

-2nd update:

with 85% reduction in trees i can see perhaps the "crash" may just be an extremely long pause.. with 85% reduction, i wait about a minute for the next frame to start, but it does start.

HOWEVER, i can see even after the 3rd frame, that the ram is not being cleared after each frame. each frame adds a gb to the ram usage on the host pc. not good! at that rate id only be able to render about 28 frames before my ram maxes out.

considering with 20k trees, it added 6gb before starting the second frame, id only be able to render a handful of frames before game over. assuming i could be bothered to actually wait for the 15+minutes to see if it actually starts the next frame at all.

3rd update:

opencl has same issue as cuda. i let it do 9 frames and my ram usage climbed from 7gb to 12.3 over the course of those frames.

4th update:

even with only *ONE* proxy tree in the scene, i -still- get the ram climbing after each frame. obviously only by a smaller amount, but after 50 frames, its gone up a few GB.


5th update: at least on the ram increase between frames, it seems to be related to the tree material. if i put a flat grey vraymtl on the trees, the ram usage stays constant. i tried just removing the 2sided from the leaves, but still had the issue.. i also found a "forest colour" map in the leaf diffuse, but removing that didnt help either.

[tashko.zashev]

5th update: at least on the ram increase between frames, it seems to be related to the tree material. if i put a flat grey vraymtl on the trees, the ram usage stays constant. i tried just removing the 2sided from the leaves, but still had the issue.. i also found a "forest colour" map in the leaf diffuse, but removing that didnt help either.

Please send us your file to test it here. You can send it directly to our support mail or post it here.

[super gnu]

ive sent an archive of the scene to support@chaosgroup.


there are a few issues as i see it:

1) forest support seems completely broken ( this scene has had the forest object converted to instances, so it will at least attempt to render)

2) RT seems to fail on a large number of instances even if they are well within the ram limits of the card

3) even when the number of instances is reduced significantly so the scene will render, the ram usage of vray.exe is enormous compared to a standard vray render, or an rt cpu render.

4) there is something about the materials on the tree that are causing the ram usage to increase with each frame rendered. ive not had time to test further, but 1, 2 and 3 might be related to 4 in some way.

[vlado]

Thanks, we will fix those.

Best regards,
Vlado

[super gnu]

any thoughts on this? is it something i can work around, or is something major broken?

i can work around problems with forestpack by converting to instances, but if even that doesnt work, im a bit stuffed!