FPP, Corona animated proxies and scene parsing/prep time

[Abstract Canvas]

Hey All,

I was hoping someone may be able to help with this issue or have come across it before in their travels.

I've a fairly straight forward garden scene. I have some fairly high poly animated tree proxies that I have scattered using latest Forest pack v7.1.1 and suffering with large parsing times. Use Max 2021, Corona 6.0 (use an AMD3990x and had issues with hotfix 0.1 and 0.2 halfling render times, I've been snowed under so not had time to chase this issue), 128gb ram.

I've narrowed the issue down to the FPP scatters of the animated proxies. If I use any other mode other than disabled or follow, Parsing and preparing geometry times go from 2 minutes - 10 minutes. Which is a lot of time to suck up per frame.

This could easily be my fault in something I've done but thought I'd put it out there and see if anyone has come across it. I'm rendering a test animation, not the final so will stick with "Follow" for these and see how it looks. May be fine, but worth finding out a weakness if its there and being able to fix it for the future as randomisation would be nice.

Some of the steps I've taken to reduce these times:
- Corona proxies set to Mesh so that they stay in RAM (parsing issue happened regardless of this, i know this almost negates the proxy benefit but they are the most full proof method ive found for reliably using GrowFX animated geometry)
- Windows Page File increased to 40GB (old tip on Corona Forum, didn't have any effect)
- Optimised visible distances on all FPP objects.
- Turned off FPP Camera clipping (this is an odd one as it decreased parsing times for the ground cover, not by much though and this scatter isn't animated anyway, again just trying to limit FPP calc times)

It took me quiet a bit of time to narrow it down to the animation settings in Forest Pack. It was one of those "one by one" tasks until i found the culprit. I wasted a good amount of hours faffing with PheonixFD as at first i was convinced it was that as it was the latest install. 

If anyone needs more info, happy to provide. Thanks in advance for any help.

[iToo]

Hi, this is a known issue with Corona proxies.

In order to use animated samples, Forest needs to request to the proxy its mesh at different animation times. This is done using a specific Max function (GetRenderMesh), which is very slow with Corona proxies.
Although the mesh is not needed for the render itself (because proxies are rendered directly by the engine), it's necessary for other processes (i.e. to build the Forest point-cloud).

For example, with V-Ray proxies 'GetRenderMesh' is very fast, because it returns the simplified mesh used for viewport.
Instead, Corona computes and returns the full mesh stored in the proxy, and this process takes a lot of time.

We contacted with the Corona team some time ago, to request an alternative way to get a quick mesh from the proxy. They took note of our suggestion, but i think never was implemented.

Please let us some time to return to this topic. We'll make some tests and will ask to Corona guys again.

[Abstract Canvas]

Hi Carlos,

Thanks for getting back to me so quickly. I'm just glad to hear it wasn't me being dense and doing something obviously stupid. 
I will keep an eye on this for updates. It works ok as long as I don't go to complex with the proxies, too high poly or too many different proxies is a no no with random samples at the moment so will stick to follow. Its working well enough for now but would certainly good for the future that you weren't penalised too harshly for using a feature. I hope the team at Corona Renderer come through.

Thanks again.

Curtis

[3DFLOW]

Any clues as to wether this has been improved? We could benefit from this... We do Arch Viz and the vegitation of Forest Pack Pro is starting to become a bottleneck. Is the Corona dev. team rather leaning towards the C-scatter for usage, or can we keep investing our time in FPP. This plugin has become more annoying to work with, in conjunction with the Corona renderer.

Is there any at all improvements in sight.. If so... From who, where...

Should we request the Corona dev.-team, the Forest Pack Pro dev.-team, the Adesk dev.-team...

https://forum.corona-renderer.com/index.php?topic=33580.0

[iToo]

We are in contact with the Corona team to improve this issue.
Although it may take some time, because requires changes both in Forest and Corona Renderer.

[3DFLOW]

Thanks for awnsering

Ok so but to understand correctly, you said:

"V-Ray proxies 'GetRenderMesh' is very fast, because it returns the simplified mesh used for viewport.
Instead, Corona computes and returns the full mesh stored in the proxy, and this process takes a lot of time."

So also when not rendering animations, just stills, we got parsing time issues, (alot of them, 6-7 mins of parsing for a still image with alot of forest pack pro elments).

Is it safe to assume we are experiencing these times mainly due to the problem you described of Corona proxies lacking a "simplified-geometry" version?

[iToo]

So also when not rendering animations, just stills, we got parsing time issues, (alot of them, 6-7 mins of parsing for a still image with alot of forest pack pro elments).

Is it safe to assume we are experiencing these times mainly due to the problem you described of Corona proxies lacking a "simplified-geometry" version?

That's correct. In V-Ray, Forest uses a simplified geometry, and delegates the render process to V-Ray. But with Corona, proxies are handled as a "mesh container", which is less efficient.
Our goal is to minimize (or remove completely) these mesh calls, and hand over the proxy handling to the Corona engine.

Are you using some Animation mode for these Forest objects (other than 'Disabled' or 'Follow Geometry') ?
In this case parse time may be high, even rendering just a still. Because Forest must prepare the Animation samples (getting the proxy mesh at different animation times).

In summary: actually parsing time is proportional to: number of Forest objects * mesh complexity * number of animation samples.

[3DFLOW]

Well.. both.

We're ajusting and animating Grow-FX trees, sending them out to animated Corona proxies, to then use with Forest Pack Pro. Seemed like a legit pipeline and we could create a lib out of that. Animated vegitation is basicly a must these days. It's 2021... come on.

But even without animation proxies: Single-proxy heavy geometry trees, grasses, bushes, potplants, ...  are ending up costing us 2+ minutes at least for parsing times added. These are also due to the same problem then, correct?

We're constantly looking at which area modes we should use where, which should have edge and which can do with "point" handling, but in truth, we're not seeing the "WOW" factor in decimating the parsing times. In fact, we are stuck at this point.

We would for example "love" to distribute office furniture, cars, lighting in-scene with forest pack pro as well, as you describe so nicely in the trailer, but we can't get past the vegitation obstacle. Leave alone distibuting 20x different 500K+ cars in a parking lot added to the vegitation...

Just thinking out loud here

[iToo]

But even without animation proxies: Single-proxy heavy geometry trees, grasses, bushes, potplants, ...  are ending up costing us 2+ minutes at least for parsing times added. These are also due to the same problem then, correct?

Well, it's difficult to know without checking the scene. Even optimizing to the limit, everything sums up and requires processing time (prepare samples, scattering, send to render engine, etc.).

At this point, there is not an easy way to check what is taking more resources. I would suggest to create a separate scene with vegetation, render Forest objects one by one (hiding the others), and check times. A tedious task... i know.
But even doing this, there are some processes which are shared between all Forest objects. Unfortunately there is not a simple trick, because each scene and render process is different.

[lingrenddd]

I found that some people in the Corona Forum have suggest recommendations to them, but they don't pay attention. If you are choosing, then I will abandon Corona, back to vray, because Forest is irreplaceable, but Corona can be replaced by vray. I thought Corona7 will improve, but I found that there is no change in the opening speed. I hope that the ITOO team can communicate again with the Corona team.

[3DFLOW]

I'm actually agreeing with you, we are having more and more issues with FPP due to the parsing scene times and mostly: size. Our workstations are equipped with 64Gb RAM, but every project is ending up around 60Gb of usage, and this last one now, we are STUCK. The scene became +64Gb and crashes when rendering. I'm sweating bricks because I need to create a god damn animation now from the project, and I'm still having to add on City traffic and Anima animation.

GREAT FUN cause now I need to decimate about 50 Forest Pack Pro objects.

One by one...

Would I be correct to assume the same scene would carry less time in parsing times + LESS RAM COMSUMPTION in VRAY?

[iToo]

Would I be correct to assume the same scene would carry less time in parsing times + LESS RAM COMSUMPTION in VRAY?

It's hard to know, without identifying what is the problem exactly.
Do you use animated Corona proxies, as the first case of this thread ? If so, i'm afraid there is not solution, because the limitations i described above.

And no, unfortunately we had not any advance with the Corona team, regarding this issue.
If you use Corona proxies, i would suggest to use standard objects instead. If you want to save space, store them in separated scene using XRefs. That's much more efficient for Forest.