Isotropix Forums

-log_level question

General Discussion about Isotropix and CG related topics

-log_level question

Unread postby bvz » Fri Apr 02, 2021 6:12 pm

I am trying to debug a scene that gets completely locked up when scattering points (It will progress from 82% to 86% in about 8 hours trying to scatter 300,000 points). During this time I do not get any output other than the progress view moving forward at a glacial pace.

I tried running Clarisse with a higher log_level but nothing appears to be different. Can anyone tell me how it is supposed to work?

I have done the following (Linux CentOS 7):

clarisse -log_level Debug5

but Clarisse behaves exactly as though I have never changed the log level at all. What am I doing wrong?
Posts: 96
Joined: Tue Dec 03, 2013 9:55 am

Re: -log_level question

Unread postby sam » Mon Apr 05, 2021 8:26 am

Hi there,

You did nothing wrong. The debug5 only outputs when using special debug logs macro on a debug build which is exclusively used for debugging modules written in C++ with the SDK.

The symptoms your are describing is odd. Did you check the CPU utilization? Have you checked the texture graph used to generate the points/scatterer?
Sam Assadian
User avatar
Posts: 1649
Joined: Fri Jan 25, 2013 11:33 pm

Re: -log_level question

Unread postby bvz » Mon Apr 05, 2021 7:12 pm

Hi Sam,

Got it (log_level). Thanks.

I did a bunch of debugging and finally figured out how to fix the issue, though I still do not know why it went wrong.

To answer your questions:
The CPU utilization would jump all over the place. It generally pegged one core at 100% and all of my other cores would randomly fluctuate between 0 and 50%.

The texture graph controlling the point clouds was super simple. A point cloud attached to a combiner that contained a number of geometric objects. A single map plugged into the decimation of the point cloud.

I isolated the problem to the use of these decimation maps for the point clouds. When I turned off these decimation maps the issue went away. They were 4K jpg maps. So I converted them to .tx files and that solved the issue. But I have no idea why a jpg being used as a decimation map would cause such an issue (vs. a mip-mapped file). I would assume that when doing decimations that the highest mip-map level would be used regardless? But converting the texture to a .tx file solved the issue.

But it gets a little more complicated: I ALSO found out that opening the same scene under a different user (same machine though) would not exhibit any of these problems (even with non-mip-mapped jpg files). Under this new user the scatter is completed in a few seconds vs. hundreds of hours - regardless of mip-mapping.

So I deleted my preferences (moved them to a new location actually) and suddenly my scene works normally again.

I have not spent any time trying to figure out what specifically in my .isotropix/clarisse/4.0 directory was causing the slowdown. But some setting in there was killing the performance in these specific cases. And whatever setting that was, it would not be triggered as long as I was using a .tx file.

Since I personally always txmake all of my textures, I have never noticed this issue before. It was only when I took over another artist's project that it came up. So I cannot easily identify a change I made in my preferences that would have triggered this behavior (and obviously the other artist never noticed it because their preferences did not trigger the same issue).

If I have the energy, I will try to re-enable the old preferences and start eliminating things till I find the culprit. But of course, that may never happen due to time constraints. :)
Posts: 96
Joined: Tue Dec 03, 2013 9:55 am

Return to General Discussion