Checkerboard pattern appearing with only 10 million triangles[Remote rendering problem]

[WikkidEdd]

We have a user who has reported seeing the checkerboard pattern when using ARR. He is a new users and didn't know what it meant so asked why it was happening. I explained that it's shown when the rendered models exceeds 20 million triangles. However, looking at his session analytics (which are gathered from the remote rendering stats) he wasn't rendering anymore than 10 million triangles at a time.

Having a look at the stats of the converted model I noticed that the triangle count is 10,818,540, but the vert count is 29,479,679. Could it be the case that the limit which triggers the checkerboard is related to vert count and not triangle count?

I haven't done any further investigation yet, but thought I'd check first before digging much deeper.

[AdamCichocki]

Hi Edd,

Conversion service reports number of unique triangles within given model. In case some part of the mesh is instantiated multiple times within the model, it still contributes only once to the number of triangles reported by conversion service. As a result, number of triangles that actually gets rendered can be significantly higher than what the conversion service reports. So I'd suspect that this might be the cause for crossing the 20M threshold. Also note that only number of triangles is relevant, i.e. number of vertices doesn't play any part here.

You mentioned some session analytics. Is this your internal tool or anything provided by ARR? I'd be interested to know what is the origin of the number of triangles value you're seeing there.

AC

[WikkidEdd]

That is useful to know that the reported triangles don't include instanced triangles. At the moment we share that information without our users and guide them to using premium based on that number. It would be helpful if there was a version of that number reported which was the total number of triangles so we can effectively communicate to our users before they start a remote rendering session. Is that something that could be added?

Our analytics events send the stats which are returned by the ARR service via ServiceStatistics which as I understand it should show the total number of triangles being rendered including instanced triangles. Is that correct? If so, then I think something might not be quite right.

I appreciated that the threshold should be based on tris, I was just taking a shot in the dark that there could be a bug that was using verts instead of tris (perhaps when implementing the point clouds, the measurement logic was changed).

[AdamCichocki]

Yeah it would make sense to add the total number of triangles to conversion output. I'll see what I can do about it soon.

ServiceStatistics should show the number of rendered triangles, just as you're saying.

Is there any chance you could send me a session-id where the issue can be observed?

[WikkidEdd]

SessionId: 9ba3a439-3e89-45f6-8d9a-78928fd51553

Looking further at this user's session analytics they did actually load the model in 3 times. The user had said they were having problems getting the scale correct, so I believe they loaded in the model and deleted the model afterward in an effort to get the size right. One thing to note is that our app hides the model when the user deletes it for faster undo'ing so 3 instances would be in the scene with 2 hidden. Unfortunately, we have a gap in our analytics so I can't confirm whether the user did actually do that.

Either way, the stats we're seeing definitely don't go over 10 million, so something doesn't seem quite right. I'll see if I can repro by following similar steps.

[AdamCichocki]

Looked through our telemetry. The model in question has 10.8M instanced triangles, so this invalidates my original clue about unique/instanced triangles count disparity.

However, there is a moment during a session where total number of rendered triangles is 20.16M, so above the threshold. Unfortunately I cant' tell exactly for how long, but (based on indirectly related telemetry) up to 6 seconds.

It would be very useful if you could investigate this issue further, possibly with the client. Did he report the checkerboard being persistent or just for a short time? On our side I'll add some more telemetry in order to have more clarity for future cases.

[WikkidEdd]

I'll close this, we haven't had the problem again and we weren't able to reproduce it.