Chaos Scatter

[matanov]

Does Chaos Scatter needs it's own license, since installing the latest build I get an error that I need a license, even if vray6 is working just fine?

Yes, you can check if it's in place in the LS - http://localhost:30304/#/

[q976431]

When I scatter a very large number, such as millions of pieces, if I use the IPR of the Vray GPU for rendering, 3dmax will have no response for a long time when I switch the time axis, as if it would calculate the scatter of each frame, but actually no parameters will be changed due to the change of the time axis. Even after I turn off the update automatically of chaos scatter, it is the same. In fact, I use vantage for testing. I have fed back relevant problems to the vantage team. They told me that this is the problem of Vray GPU. At that time, I tested the forest pack. I thought chaos scatter would be optimized. But it seems that this problem still exists

https://forums.chaos.com/forum/chaos...rame-is-output

[q976431]

When I scatter a very large number, such as millions of pieces, if I use the IPR of the Vray GPU for rendering, 3dmax will have no response for a long time when I switch the time axis, as if it would calculate the scatter of each frame, but actually no parameters will be changed due to the change of the time axis. Even after I turn off the update automatically of chaos scatter, it is the same. In fact, I use vantage for testing. I have fed back relevant problems to the vantage team. They told me that this is the problem of Vray GPU. At that time, I tested the forest pack. I thought chaos scatter would be optimized. But it seems that this problem still exists

https://forums.chaos.com/forum/chaos...rame-is-output

But after I close chaos scatter, I can quickly drag the timeline in Vray GPU IPR.
But after spreading hundreds of thousands or millions of numbers, dragging the timeline becomes extremely difficult. If the chaos scatter is not animated, I don't think it should be recalculated every frame. Now it's like switching the timeline and it needs to be regenerated (camera clipping is not turned on)

[^Lele^]

It could be tied to the viewport performance issue seen elsewhere, it seems similar.
Could you check if the CPU and/or GPU are being taxed when moving the timeline?

[q976431]

It could be tied to the viewport performance issue seen elsewhere, it seems similar.
Could you check if the CPU and/or GPU are being taxed when moving the timeline?

The vantage team asked me to test whether the Vray GPU IPR has the same problem when Vantage is not linked in real time. The result is yes. As long as the Vray GPU IPR is running. Forest generates a large number, and dragging the timeline becomes very slow. I'm sure the forest doesn't have any updates in different timelines, but every time you drag the timeline, it's still as slow as it was when it was first loaded

Perhaps there is a separate setting to prevent this from happening? It is also invalid for me to disable automatic update of forest

[q976431]

The number of viewports in my forest has been turned off. Even I hid the forest. When rendering hidden objects only is enabled, dragging the viewport becomes as slow as if it reloads the forest scatter for each frame. The same is true for chaos scatter. This problem can occur in hundreds of thousands of quantities. I sent the scenario with problems to the vantage team, and they got the same results

[^Lele^]

So it's a behaviour fPro too shares.
I seem to recall it was also the case with the scatter plugin of a while back: if you displayed many nodes, you could kiss goodbye to the UI performance.
I have to assume it's not an easy one to fix, if it's three different companies/devs coming up with nigh-identical limitations, while TYFlow under identical circumstances flies.
I theorised it has to do with the caching (not happening in the various scattererers), so the time is spent moving data to and from memory (CPU and GPU seem absolutely flat in the while).
Let's see what the devs will say.

[q976431]

So it's a behaviour fPro too shares.
I seem to recall it was also the case with the scatter plugin of a while back: if you displayed many nodes, you could kiss goodbye to the UI performance.
I have to assume it's not an easy one to fix, if it's three different companies/devs coming up with nigh-identical limitations, while TYFlow under identical circumstances flies.
I theorised it has to do with the caching (not happening in the various scattererers), so the time is spent moving data to and from memory (CPU and GPU seem absolutely flat in the while).
Let's see what the devs will say.

You have a point. There is a big difference between no cache and cache in tyflow. I hope chaos scatter can consider this.
But then again
After all, tyflow is a particle plug-in. It is bound to have many moving objects and need to calculate new data for each frame. However, in most cases, forest and chaos scatter do not need to calculate data for each frame unless the camera is turned on for cutting. You need to get the camera range of each frame. The rest only need to use the cache loaded for the first time.

I use google translate. Maybe my description is not accurate enough. Sorry

[^Lele^]

You're perfectly understandable.

[BBB3]

I'm getting very long geometry compiling times for low numbers of objects. Scattering 10,000 high-res tree on a high-res landscape mesh takes about 30-40 seconds. Is this normal or is there an issue with my setup here?

EDIT: Actually, this seems to have to do mainly with my surface. If I occlude part of it with a spline, simulating a camera cull, compute times are a lot more reasonable.

[jerlat]

I'm missing the possibility to add empty instance.
For example using a UV map grid pattern, I wish some spots to be randomly left vacant.

[matanov]

I'm missing the possibility to add empty instance.
For example using a UV map grid pattern, I wish some spots to be randomly left vacant.

You can do that by making the Visibility of an object = 0

[jerlat]

I would also love to have the possibility in edit instances, to switch the model of a specific instance to another of the base models.