Question

I wrote a quick application to get a feel for the limits of RenderScript and discoved that when reaching approximately 65,000 triangles, the system simply does not draw any additional ones. For example, if I create a cylinder with 70,000 triangles, there is a missing wedge from the cylinder corresponding to the triangles that exceed the ~65,000 count. The triangles are textured and for ease of writing the app, I simply used a TriangleMeshBuilder class so there is no real optimization going on such as using trifans or tristrips. The hardware is a Samsung Galaxy Nexus. LogCat reports a heap size of about 15MB with 3% free. I receive no errors or warnings regarding the graphics system or RenderScript.

Can anyone explain the reason for the triangles being dropped? Am I at a hardware limit that RenderScript is handling gracefully?

UPDATE Happens on a Samsung Galaxy Nexus (4.0.3), Samsung Galaxy Tab 7.0+ (3.2) and Motorola Xoom (3.2). All at the same point of approximately 65,000 triangles. Each of these devices have different GPU’s.

UPDATE 2 In response to Steve Blackwell’s insights, I have some additional thoughts.

Lines 710-712 do indeed downcast the int indices to short, thus 65536 goes to 0 as Steve points out. Additionally, the “cast” on line 757 is not so much of a cast as telling the RenderScript the format of the binary data that will eventually be sent to it. RenderScript requires all data to be packed into a RenderScript specific data type called an Allocation to move from Java to the RenderScript runtime, and this needs to be informed as to the data structure. In line with Steve’s opinion that this is a bug, line 757 informs RenderScript to treat the index data as short (unsigned 16bit) but it sends it a 32 bit signed value (which will be accepted due to the lack of a check and treated unsigned, and then only the lower 16 bits used, hence why we get something drawn when below this threshold and triangles connecting back to the first indices when we go over).

Subclassing TriangleMeshBuilder to see if I can make it accept these values all as integers to increase this limit did not work, which leads me to believe that somewhere in the deep code we do not have access to, there is an additional reference to unsigned shorts. Looks like the only work around is to add additional vertex buffers as Steve suggests, which is easily done with the existing Mesh.AllocationBuilder class. I will also bring it up with Google in the Developer Hangouts to determine if this is in fact a bug or intentional.

Answer 1

I know almost nothing about RenderScript, so I don’t know whether this is some inherent limitation, a hardware issue, or something to do with TriangleMeshBuilder, but I would bet you’re running out of triangles at after number 65535.

This is a magic number because it’s the maximum value of an unsigned 16-bit integer. (Wikipedia)

I would suspect that somewhere in the code there’s an unsigned short that holds the number of triangles. It won’t be in the Java code since Java doesn’t have unsigned values. And the limitation is probably not hardware since CPU registers/pathways are >= 32-bit. So I would check TriangleMeshBuilder.

EDIT:

That’s a great find on line 553. The value of every index has to fit into a short. It looks like the downcast is happening at line 710-712.

I assume that you’re calling addTriangle(). That function takes three ints and then does an explicit cast to short. I think that’s a bug right there because the downcast happens silently, and it’s not what you’d expect from the function signature.

On line 768, that bogus data gets passed to Allocation.copy1DRangeFromUnchecked(). I didn’t follow it all the way down, but I imagine that at some point, those signed values get cast to unsigned: the -32768 to -1 gets turned back into 32768 to 65535. So turning the indices into negatives looks bad, but it’s just reinterpreting the same data and it’s not really a problem.

The real problem starts when you send in values like 65536. When 65536 is cast to a short, it turns into 0. That’s a real loss of data. Now you’re referring to different indices, and a cast to unsigned doesn’t fix it.

The real kicker is that copy1DRangeFromUnchecked() is an overloaded function, and one of the overloads takes an int[], so none of this ever needed to be an issue.

For workarounds, I guess you could subclass TriangleMeshBuilder and override the member variable mIndexData[] and method addTriangle(). Or maybe you could use multiple vertex buffers. Or file a bug report someplace? Anyway, interesting problem.