Engine patch. Better curves tesselation.

[someone]

Hi there. First, i'd like to thank you all for making such a good game! It became my favourite fps.
Second, i have made a patch that fixes some bugs and improves performance of rendering curved surfaces while the quality stays the same.
Originally, DarkPlaces used too many excess polygons for curves tesselation:

Fixed that.

Moreover, fixed a bug with incorrect degenerate triangle detection (Under certain circumstances holes could appear in curved surfaces). And finally made lower LOD for collision detection purposes work. (Though corresponding cvars "r_subdivision_collision_*" existed, it actually didn't work because of a typo in model_brush.c)

It makes rendering of "mentalspace" map 7% faster on my machine. (If collision detection is taken in account, it is even more). And 11% of "hookrace".

There is actually no "patch", just already patched source files. They are compatible with latest svn version of DP. Just replace and compile. Here: ftp://194.88.211.162/publicprojects/nexpatch.7z
It will be there for a couple of days.

[morfar]

The old "holes-between-patches" bug was fixed in svn some weeks back. I havn't seen a hole since then...

The part about fewer polygons sounds interesting though

[torus]

Very nice work

[someone]

The old "holes-between-patches" bug was fixed in svn some weeks back. I havn't seen a hole since then...

The part about fewer polygons sounds interesting though

There was not only holes-between-patches but also holes-IN-patches bug. It was very rare.

Very nice work

Thanks.

Please test it for bugs. I don't have many "heavily curved" maps and enough time.

[C.Brutail]

Very good job!

As for testing, this might help ya:
http://maps.nexuizninjaz.com/Theta_v1r2.pk3

[divVerent]

Really need this in proper patch form and not single source files that may be based on ANYTHING, and with explanation WHAT you are changing, as it is very likely that this breaks OTHER maps.

The current code in DP SVN (no idea if you even tried that one, or if you worked on the 2.4.2 sources) matches what q3map2 -patchmeta and Quake 3 Arena do, and should perhaps be the best thing to do. It would need LOTS of testing to accept this, as this might tear NEW holes on other maps that look fine in Q3A.

In case you did base it on a svn revision, please state the revision number so we know what to diff against.

[someone]

Really need this in proper patch form and not single source files that may be based on ANYTHING, and with explanation WHAT you are changing, as it is very likely that this breaks OTHER maps.

The current code in DP SVN (no idea if you even tried that one, or if you worked on the 2.4.2 sources) matches what q3map2 -patchmeta and Quake 3 Arena do, and should perhaps be the best thing to do. It would need LOTS of testing to accept this, as this might tear NEW holes on other maps that look fine in Q3A.

In case you did base it on a svn revision, please state the revision number so we know what to diff against.

It is based on DP svn revision 8670 (latest at this time).
I decided to publish it now for testing purposes, because i think it will be very useful for people that have not so powerful machines. Final version (commented and heavily tested) will come in half a month or a bit more because i need to pass some exams first. Some optimizations are not implemented but it is completely usabe by now. The new code is poorly commented at this point though.
It breaks no standard maps (tested on farewell, skyway, reslimed, darkzone, downer, ruiner, bluesky, basement, bloodprison, evilspace, slimepit, soylent, warfare) and some additional (theta, hookrace, mentalspace, racetrack_v2, facing_worlds, streetrace). I'll do more testing later.

Add: it was my mistake to post second screenshot pair where one of them was from 2.4.2. In 2.4svn seam is really fixed.
Add2: i find the patch useful (20% faster on "theta" map) enough to be merged to trunk so more people can test it. Any bugs that will possibly be found will be fixed by me. Anyway, it may be reverted at any time.

[Alien]

This fix might be related to clueless newbie's report of having holes in his map.

[divVerent]

Neither I nor LordHavoc really have any idea what you did to Q3PatchTesselationOnX and Q3PatchTesselateFloat.

But they certainly cause bad (too low) tesselation of mikeeusa's map tundramagi at the default tolerance:

http://emptyset.endoftheinternet.org/~r ... 95efad.jpg

Apparently, it gets tesselation 0 in the "hallway", which is totally wrong, as you see. Looks like the decision for the tesselation 0 needs to be done another way.

And why isn't this patch welded to the trim, like previously?

And really: don't waste time on "optimizing". It's done at map load ONLY. Who cares if that takes a millisecond longer? Better make the code readable, it's currently a horrible mess and hard to decipher.

The wrong usage of the collision cvars, and the triangle degenerate check, is now fixed in svn. Thanks for pointing to it.

[someone]

> Neither I nor LordHavoc really have any idea what you did to Q3PatchTesselationOnX and Q3PatchTesselateFloat.
I'll make a description of what I have done later.

> But they certainly cause bad (too low) tesselation of mikeeusa's map tundramagi at the default tolerance:
New Q3PatchTesselationOnX/Y take care of one curious case when old ones generated completely useless polygons. It computes a bit different squared deviation. A linear factor can be guessed so that the results of old and new ones will nor differ in 99% of cases. Though, it can be easily reverted and patched to take the possibility of 1/2 tesselation in acount. I'll do that.

> Apparently, it gets tesselation 0 in the "hallway", which is totally wrong, as you see. Looks like the decision for the tesselation 0 needs to be done another way.
It's totally right for the "long" dimension, I think. There is no need to split it in two equal parts. And for the other dimension it is > 0.

> And why isn't this patch welded to the trim, like previously?
Because the two not-welded patches do not have common vertices. That is ok, Quake3 does the same:

(It cannot load such huge level so I cut a piece of it and made a small room) As you see, it does not care about welding these two patches, contrary to "vertex-touching" patches.

> And really: don't waste time on "optimizing". It's done at map load ONLY. Who cares if that takes a millisecond longer? Better make the code readable, it's currently a horrible mess and hard to decipher.
Ok, I'll try my best to make it more readable next time.