10,000 faces max export?

[Paradox]

Awesome! Thanks Tachzusamm.

I've committed that change to PyPRP trunk. Is it worth a minor version release?

[dendwaler]

This great!
I just made an export of turtleisle with the changed code.
The TurtleIsle_District_mainRoom.prp decreased from 190.625 Kb to 113.590Kb
export time went down from nearly 50minutes to 12 minutes!

I hope this will give a performance boost to!

[Aloys]

Haha, nice. That thread took an interesting unexpected turn.
Isn't it funny that Cyan finally released their own files and yet we are updating ours? :p

[ZURI]

Sorry to be the first idiot to chime in, lol. How do I implement this? I didn't see a link to an updated trunk. Does the current PyPRP download point to the updated version?

My ages, by design, are very low poly. IIRC, the highest-poly one shows about 60k verts and 64k faces in Blender. Should I even be concerned?


Edited for accuracy...

[D'Lanor]

You need to grab the nightly build.

[tachzusamm]

Is it worth a minor version release?

Well, why not? I think version numbers are not limited, are they?

Programmers like us may recognize there's an improvement now which can be found in the nightly build, but others may miss that their ages could benefit - most of them would still rely on the "latest stable" version (1.60) just to feel safe. The nightly build (or trunk) is stable as well.
With minor release you mean a 1.61?

But I would suggest to insert 2 things as well:

a) Adapt the limits of the vertex count of a mesh export to those reflecting the reality.
In line 1276 of prp_DrawClasses.py replace:

Code: Select all

            if len(MatGroup["vertices"]) > 0x8000:
                raise RuntimeError, "Vertex count on this material is too high, consider breaking up your object into several materials...."


with:

Code: Select all

            if len(MatGroup["vertices"]) > 0x0FFFF:
                raise RuntimeError, "Vertex count (=%i) on this material is above 65535, consider breaking up your object into several materials...." %len(MatGroup["vertices"])


and in line 1197 replace:

Code: Select all

            if bufferGroup.GetSkinIndices()==bool(HasSkinIdx) and bufferGroup.GetNumSkinWeights()==NumSkinWeights \
                and bufferGroup.GetUVCount()==UVCount and len(bufferGroup.fVertBuffStorage)+num_vertexs<0x8000:
                return idx


with:

Code: Select all

            if bufferGroup.GetSkinIndices()==bool(HasSkinIdx) and bufferGroup.GetNumSkinWeights()==NumSkinWeights \
                and bufferGroup.GetUVCount()==UVCount and len(bufferGroup.fVertBuffStorage)+num_vertexs<0x0FFFF:
                return idx


I understood Aloys' arguments against it, but if a user splits a large object (e.g. a ground plane) simply into multiple objects, nothing is won.
In my opinion patronizing isn't a good way, so why should we keep simulated/faked limits just because we are in fear of mis-usage.
The better solution leading to performance is still telling the age creators to use low poly whereever possible - as we always did.


And b):
Merge D'Lanor's waveset geostate fixes
viewtopic.php?f=59&t=4516&p=45441&hilit=geostate#p45292


Any other fixes I forgot?


P.S. I would contribute to the SVN too but don't know how

[Branan]

That PRP size thing is a fairly important bug for me as an "artist". As is the vertex limitation per-object. I think encouraging large batches is a good thing, so letting the artists create large meshes when they need to is a good thing. Splitting for the sake of splitting will actually degrade performance (and in Plasma, it might degrade performance a lot if there's an object with a different material drawn between the split objects)

[Aloys]

I understood Aloys' arguments against it, but if a user splits a large object (e.g. a ground plane) simply into multiple objects, nothing is won.

That's correct. I just re-read my post and my reasonning was indeed kind of silly.
There's a 'performance optimization' article on the wiki that hasn't been touched in a while. It might be a good idea that I (or anyone who feels interested) take a look at it and update it where/if needed.

[Branan]

I understood Aloys' arguments against it, but if a user splits a large object (e.g. a ground plane) simply into multiple objects, nothing is won.

That's correct. I just re-read my post and my reasonning was indeed kind of silly.
There's a 'performance optimization' article on the wiki that hasn't been touched in a while. It might be a good idea that I (or anyone who feels interested) take a look at it and update it where/if needed.

Hoikas and I are working on some wiki stuff. You might want to wait until Monday to get started on that.

[Trylon]

About that maximum vertex count.

AFAIK it could be made infinite in theory.
It would require that another Buffergroup be made for any "superflouous" vertices
(As a buffergroup can only hold 64ki vertices)

Considering the already vast amound of possible vertices, I don't see the need however.

EDIT:
Ofcourse, this idea is off the top of my head. I might have overlooked some imporant details.