10,000 faces max export?

[bnewton81]

Is it true that PyPRP won't export a single mesh with over 10,000 faces?

[dendwaler]

1 object "mesh"may not have more then about 8000, and when 1 remember well, this is only the max for the faces of one object that share the same material within 1 object.
But normally 1 object is ofcoarse much, much smaller.

if you exceed the 8000 faces then pyprp won't export, not because of PyPrp has a limit but because you reached the max of blenders possibility to apply a material to all the faces.

You will succeed if you assign more materials to the same object if the 2 materials are divided over the total of faces.

[bnewton81]

ok, thanks. Just wanted to verify.

[Branan]

1 object "mesh"may not have more then about 8000, and when 1 remember well, this is only the max for the faces of one object that share the same material within 1 object.
But normally 1 object is ofcoarse much, much smaller.

if you exceed the 8000 faces then pyprp won't export, not because of PyPrp has a limit but because you reached the max of blenders possibility to apply a material to all the faces.

You will succeed if you assign more materials to the same object if the 2 materials are divided over the total of faces.

This has nothing to do with blender limitations. A limit of 8K faces per material is useless for anything high-poly for video or visualization applications. Blender very nearly doesn't care how many faces you have per material (I think the limit is 2 or 4 billion). In fact, this can be trivially disproven by exporting such a large object as .obj or collada. It works just fine, materials and all.

As far as I can tell, this limit was simply guessed. There's an absolute limit of 65K vertices, due to the type of number (an unsigned 16-bit integer) used to store vertex IDs. The number of faces is "unlimited", but there are only so many *useful* triangles you can make with 65K vertices. It's possible someone set this limit trying to make sure that buffers didn't grow too big... and I think if that's the case their concern was misplaced.

Let's do some quick math: A buffer of 8192 vertices that have one set of texture coordinates will wind up at 327680 bytes. That's 320KB, which is big..... but not huge. It's slightly larger than a 256x256 texture, which weighs in at 256KB. Modern GPUs can eat that sort of data for breakfast and be hungry again by 10AM. 65K vertices using this format are approximately 2.5MB. The largest vertices that can be generated using blender have 8 texture coordinates. Again with 8192 vertices, we wind up with a buffer that weighs in at 1015808 bytes, or 992KB. This may seem big, but a 512x512 texture weighs in at 1MB. 65K vertices at this size would end up with a roughly 7.75MB dataset. The larger sets will almost certainly be inefficient, but they should render on any hardware from the past 10 years.

tl;dr PyPRP's limit makes absolutely no sense to me as a graphics developer.

[dendwaler]

May be you are completely right Branan, but try to subdivide a cube a few times until you reached a high poly mesh more then 8000.
assign a material and export it.

then you get this error message, then what is wrong there?

[Branan]

It's a hardcoded limit inside PyPRP. I guess I wasn't quite clear about in my first post. That limit is totally unrelated to blender or hardware limits. It's just there. I've never figured out why.

[Trylon]

I'm not sure why the limit is there, and I'm probably the one who wrote much of that export code when revising the graphical export system (At least I wrote the error message itself)
Best I can think of is that it's a leftover from Almlys' original code, and was kept it in just to be sure.

[tachzusamm]

Okay guys.

First, to avoid confusion: There is NO fixed limit to "10000 faces". Neither in Blender, nor in PyPRP, nor in Plasma.
And, there is NO fixed limit to "8000 vertices" as well. In fact, there IS a limit: This is currently set by PyPRP to 32768 vertices (which is written 0x8000 in hexadecimal), and this limits the total number of vertices which can be stored in a "buffer group". But this "buffer group" is not the mesh you created.

What happens in PyPRP: A textured mesh you created in Blender gets - well, lets say: transformed into a list of vertices. Those vertices are not simply the real vertices of the mesh, but are calculated based on how the UV map looks like. Imagine this as some sort of projection, although it's a bit more complex operation.

In fact, the number of vertices in this list of vertices (which is called a "buffer group") can grow *above* three times the number of used faces in the mesh.
This is why it appears sometimes the faces are limited. For example, for a mesh with 10000 faces, the calculated number of vertices in the buffer group can be greater than 3*faces, for example 35000 vertices - then the export will stop with an exception (because 35000 > 32768) and you get the "vertex count too high" message (which is confusing in my opinion, because it's not the vertex count of your mesh).

Now, why IS there a limit?
It's because the size of this list of transformed vertices in the buffer group has to be written into the exported files as well. In fact, the vertex list is just an indexed array, and its size has to be written using functions which are currently limited to unsigned short integer (16 bit) range (which has a maximum of 65535 = 0x0FFFF).
I don't know if this limitation is based on the Plasma files structure or if it's just a limitation of the basic read/write functions used in prp_Stream.py .
Maybe we can't get beyond this 65535 limit (if it's the Plasma structure) - or maybe we can (if it's the stream lib limitation).

The good news is that we CAN increase the limit a bit (to twice, that is). It you have read carefully, the limit is currently set to 32768 - but there's no need for "signed" short integer, we can extend it to unsigned short, which means 65535. (By the way, 32768 (0x8000) is already above the positive short integer limit which would be 32767, so checking for > 0x8000 is simply not exact. It should be >= 0x8000 or > 0x0FFF.)

I've already done this, and was able to export a mesh with more than 17000 faces, which generated a vertex count of about 56000 in the buffer group, without problems in the exported age.

[
Technical: In line 1276 of prp_DrawClasses.py I replaced the 0x8000 with 0x0FFFF. Four Fs with a leading 0.
OLD: "if len(MatGroup["vertices"]) > 0x8000:"
NEW: "if len(MatGroup["vertices"]) > 0x0FFFF:"

And I replaced the next line:
raise RuntimeError, "Vertex count on this material is too high, consider breaking up your object into several materials...."
with this:
raise RuntimeError, "Vertex count (=%i) on this material is above 65535, consider breaking up your object into several materials...." %len(MatGroup["vertices"])
to get an idea of the real calculated vertex count in the buffer group in case of an export error.
]

But don't try to increase the limit above this value - this will surely crash your age with a stack error.

Cheers,
tach


P.S.: I assume the 0x8000 in line 1197:
and bufferGroup.GetUVCount()==UVCount and len(bufferGroup.fVertBuffStorage)+num_vertexs<0x8000:
could/should be adapted as well like this:
and bufferGroup.GetUVCount()==UVCount and len(bufferGroup.fVertBuffStorage)+num_vertexs<0x0FFFF:
but not sure here. I think there's just a new group generated when an already available one is too filled - which should not harm.
Again, not sure here about what will happen under special circumstances.

[Branan]

If the vertex count is *Ever* rising about 3x the number of triangles in a mesh, there's a bug in the code. The worst-case scenario is completely non-contiguous UV maps, meaning each triangle is its own UVW "island". In such a case one unique vertex has to be generated for each corner of each triangle, resulting in a vertex count of 3xtotal_triangles.

If it's generating more vertices than that, then some of them simply aren't being referenced by the mesh - or it's creating duplicate and/or degenerate triangles, both of which will negatively impact rendering performance.

You're correct that indices are limited to 65535. There's no way on most hardware to use more than a 16-bit integer (DX10-class hardware can use a 32-bit integer) to index a vertex. On graphics hardware, vertex indices are *always* unsigned.

[Trylon]

I just remembered - the original PyPRP exporter had buggy code where every triangle would have its own vertices. It made one end up with a lot of superfluous vertices.
Maybe related somehow, maybe not....