Updates and more efficient handling of scattering

[steve3duk]

Hi there,

I've been working on a project heavily featuring Forest Pro for a large landscape with a vehicle driving along a road. It is a very painful experience.

Maybe I'm just not that efficient at using it but I find that it crashes Max a lot when using Vray IPR. Any small change will just instantly crash Max, mostly related to the forestcolor shader.

For animations it is very hard to know if the entire animation will feature an error as the view changes...will the forest max limits be reached? Surely some kind of checker for an animation should be included to make sure this doesn't happen otherwise you have to manually check frames. It is hard to know which frame might pass the threshold.

Another annoying issue is, why am I getting dialogue telling me to change X & Y density rather than allowing me to up the items. I have 256gb on my pc and I'm not really understanding why there would be such fixed limits on the amount of items displayed at render time.

Finally, the way that forestpro always seems to have worked is it will even take into consideration an item in the black part of the mask. Surely after all this time the code could be made more efficient and improved upon. It seems like ForestPro hasn't really evolved much at all over a number of years.

I am of course only listing these frusrations because I would like to see improvements but it really has been a series of crashes and waiting times with this plugin....including the interface which can take over 15 seconds to appear sometimes...

With such high subscription prices and the amount of customers you have I'm somewhat dissapointed with how Forestpro works these days.

[iToo]

Hi,

I've been working on a project heavily featuring Forest Pro for a large landscape with a vehicle driving along a road. It is a very painful experience.

I'm sorry you had a bad experience using Forest Pro. We'll will try to attend each one of these issues:

Maybe I'm just not that efficient at using it but I find that it crashes Max a lot when using Vray IPR. Any small change will just instantly crash Max, mostly related to the forestcolor shader.

Please, send us the minidump when it crashes. This is the only way we have to identify the problem.
Using minidumps we could solve recently a couple of issues related with IPR. One of them was fixed by Chaos (fix should be included in their latest builds), and other in our side (it will be included on next FP update).

Interactive Render modes are very tricky, because 3DS Max (and plugins) have not a standard mechanism to support them.
So each render engine implements their own methods, and it's a continuous work of trial and error adding workarounds (both in Forest and the render engine).

For animations it is very hard to know if the entire animation will feature an error as the view changes...will the forest max limits be reached? Surely some kind of checker for an animation should be included to make sure this doesn't happen otherwise you have to manually check frames. It is hard to know which frame might pass the threshold.

Sorry, i don't understand this. What limit do you mean exactly ? Does Forest show any message about that ?

Another annoying issue is, why am I getting dialogue telling me to change X & Y density rather than allowing me to up the items. I have 256gb on my pc and I'm not really understanding why there would be such fixed limits on the amount of items displayed at render time.

You can find a detailed explanation about what Density Limit means here.
This limit was introduced to avoid to create huge distributions. Anyway, you can disable it setting Distribution->Image->Max.Density to 0. Same from Display->Render->Max Items.

Finally, the way that forestpro always seems to have worked is it will even take into consideration an item in the black part of the mask. Surely after all this time the code could be made more efficient and improved upon. It seems like ForestPro hasn't really evolved much at all over a number of years.

Initially Forest was designed to use this distribution mode (using images), because it's more efficient to scatter large areas:

a) We can create separated scattering threads, each one rasterizing a row of the image.
b) When applying Camera limit, it let us to remove large areas of the image (outside of the camera frustrum), without rasterizing them.

Other scattering plugins use a different method, with a fixed number of scattered items. But doing this, each item must be checked with the bitmap, the camera and the spline, and then decide to use or discard it.
We evaluated to include this method as an alternative mode in 'Distribution'. But it would be confuse for users, because it's very similar to the current procedure, and Forest has many options in the interface already.

in the other hand, we cannot remove or replace the original 'image' mode, because we must keep compatibility with existing scenes.

I am of course only listing these frusrations because I would like to see improvements but it really has been a series of crashes and waiting times with this plugin....including the interface which can take over 15 seconds to appear sometimes...

That is not normal. Does it happen each time you open the interface, or only the first time ?
Depending of that, it would a problem with the own interface, or the license loading (which is done only one time).

We know there was a problem of slow interface related to Threadrippers and dual CPUs (as described here). But it should not happen with current CPUs.

With such high subscription prices and the amount of customers you have I'm somewhat dissapointed with how Forestpro works these days.

I'm sorry to hear that.
We continue working on the plugin and improving it, but unfortunately we also are limited by some factors (as compatibility with the existing work, or issues related with render engines).

[steve3duk]

Thanks for the response. I think I was ranting as I was very frustrated when I wrote the message.

Please, send us the minidump when it crashes.

I'll do this the next time it does this.

Sorry, i don't understand this. What limit do you mean exactly ? Does Forest show any message about that ?

So, it's the standard message about either reducing the X/Y distribution or increasing display items as an error can pop up saying something like, "some forest objects did not render ...etc". This threshold about what can be rendered is dependant on camera view afaik so at the beginning of the animation the forest object would render and maybe half way through it wouldn't because it passed the threshold. I was just wondering if there was a checker for an entire animation to make sure the forest object was always rendered...

Anyway, you can disable it setting Distribution->Image->Max.Density to 0. Same from Display->Render->Max Items.

I didn't know you could do this. That's very useful to know. I actually ended up altering the camera max distance and it resolved the issue when low to the ground.

in the other hand, we cannot remove or replace the original 'image' mode, because we must keep compatibility with existing scenes.

Does this mean Forest pro is limited to being backward compatible and can never use other methods? This seems like a bit of a trap in terms of forest pro's future development.

We know there was a problem of slow interface related to Threadrippers and dual CPUs (as described here). But it should not happen with current CPUs.

I am still using a threadripper 2990WX (32 core) so I will try those things mentioned...problem is, I cannot disable multithreading as Vray takes advantage of it as do a number of other apps I use. It just wouldn't be viable to do this.

Do the new threadrippers cause this issue? Do you have a list of CPUs that have been tested?

[iToo]

Thanks for the response. I think I was ranting as I was very frustrated when I wrote the message.

No problem. That's understable when you find these issues on a deadline.

So, it's the standard message about either reducing the X/Y distribution or increasing display items as an error can pop up saying something like, "some forest objects did not render ...etc". This threshold about what can be rendered is dependant on camera view afaik so at the beginning of the animation the forest object would render and maybe half way through it wouldn't because it passed the threshold. I was just wondering if there was a checker for an entire animation to make sure the forest object was always rendered...

I see. As far as i remember, "Density Limit" and "Max.Items" are the only parameters which may affect this. Just set both to zero, to remove all limits.

But be care that uncapping it, you would get huge distributions.
There is not physical limit about the number of items that Forest can generate. Just processing time, memory and possible limitations of Max and the render engine.

Does this mean Forest pro is limited to being backward compatible and can never use other methods? This seems like a bit of a trap in terms of forest pro's future development.

We can add new distribution methods, but not remove or modify drastically existing features. But this is a problem with all the software.
If not, think what would happen if we release Forest 9, and now all your scenes doesn't work or generate a different result. Backward compatibility is very important for our customers.

I am still using a threadripper 2990WX (32 core) so I will try those things mentioned...problem is, I cannot disable multithreading as Vray takes advantage of it as do a number of other apps I use. It just wouldn't be viable to do this.
Do the new threadrippers cause this issue? Do you have a list of CPUs that have been tested?

No, sorry. We have little infomation about this issue. In fact, we never could reproduce it.
It was reported by customers using old Threadrippers, and some motheboards with dual CPUs. That matches with the information provided by Autodesk.

According to their notes, Max interface redraws much more slower that it should. That affects specially to Forest, because our plugin has many rollouts and parameters.
If that helps, you can hide unused Forest rollouts from General->Global configuration.

[RealViz]

I agree that modifying distribution methods is not appropriate. Moreover, the "image based" method is very good and allows a lot of tricks when using custom bitmaps. I understand that for some people it is a bit more complicated to understand, because you need to recalculate the pixels of the bitmap itself to real size in a max environment. Also the resolution of the bitmap itself comes into it. The "Draw Gizmo borders" helps a lot in this when getting started with FP. In my experience, most beginners employee enter completely nonsensical values into FP and try to make up for it with collisions for example. This of course results in completely overwhelming the scene with nonsensical calculations and can just lead to error messages about the max limit. However, you need to understand how FP itself works. Then it is a very robust plugin and I encounter errors quite rarely. Usually they are secondary what is related to a new feature etc.

[steve3duk]

Please, send us the minidump when it crashes.

Which is the best email to send the crash file to?

[iToo]

Which is the best email to send the crash file to?

You can send it to helpdesk@itoosoft.com.
For large files (scenes and so), please use a web sharing service as WeTransfer.