Inconsistency Between Patches In Doomed And Darkradiant

[greebo]

As reported by SneaksieDave here: http://bugs.angua.at/view.php?id=77

 

Obviously the tesselation algorithm in DoomEdit and DarkRadiant is not the same, resulting in different patch subdivisions for the very same patch control vertices. I don't know if there exist "rules" about this, but if you ever need to solve such a problem (which may not only occur when switching editors), be sure to keep this option in mind:

 

 

By opening the Patch Inspector (Shift-S by default), choose Fixed Tesselation for your adjacent patches, this forces DarkRadiant to take a fixed number of subdivisions, so all the virtual corners are aligned properly.

 

(This will convert the patch from a patchdef2 into a patchdef3 for those who want to know how these are saved in the .map file).

[OrbWeaver]

Would this be fixed by making "Fixed tesselation" the default, or even the only, option for patches when they are loaded?

[greebo]

I'd prefer no fixed tesselation by default, because I would have to increase it manually when making the patch larger or drag its vertices around. It's far less flexible and won't look good in larger patches.

 

The only cases where this is important is when aligning patches to each other (like in this archway) - and there it's always possible to turn it on when needed.

 

I wouldn't call it a serious defect as long as we don't know how the Doom3 engine tesselates the patches. If sparklies appear in-game, you can always turn on the fixed tesselation.

[OrbWeaver]

OK, I think I understand now. The "Fixed tesselation" is similar to the "Subdivide patch" option in DoomEdit, and requires the number of subdivisions to manually entered. The problem is that when this is not selected, both DoomEdit and DarkRadiant subdivide the patch automatically, but they do it in a slightly different way meaning that a patch created with one editor won't automatically line up with a patch created in another -- correct?

 

By the way, we should make that Patch Inspector more visible, I had no idea it even existed.

[greebo]

The problem is that when this is not selected, both DoomEdit and DarkRadiant subdivide the patch automatically, but they do it in a slightly different way meaning that a patch created with one editor won't automatically line up with a patch created in another -- correct?

Basically, yes. There is no guarantee for the patches to align correctly in both editors. Still, it may be that Doom3 tesselates in yet another way, this had to be tested.

 

If the DoomEdit source is ever being released, we could have a look at the tesselation code and "correct" the one in DarkRadiant (although I don't think that DarkRadiant is doing anything seriously wrong here).

 

By the way, we should make that Patch Inspector more visible, I had no idea it even existed.

You're serious?

[Mr Mike]

So this is only ever a problem if one patch is created in DR, aligned next to another created in DE? If so I would think a simple "fix" would be that fixed tesselation is always forced in DR. This should stop the problem no? And has the added advantage that editors would actually think more about optimization: i.e. the lovely arched butress they've just created could be equally nice with a 8x1 patch, rather than the 8x3 that seems to be commonplace. Instant save on 3x the poly's.

 

Along similar lines is one thing that really bugged me in both DR and DE. When you go to create a new patch it defaults to 3x3 and won't let you select any lower than this, only higher. I'm often using patches of Yx1 and it would be good to choose that from the drop down list at patch creation, rather than doing it from the patch inspector. Yeah I'm a lazy bitch...

[greebo]

You can't create a patch lower than 3x3. It refers to the dimension of the control vertices array and as far as I know (I just tested it in DR), you cannot decimate a 3x3 patch any more by deleting it's rows or columns.

 

I guess you're referring to the visible tesselation lines? That are indeed created automatic, and maybe you can gain a bit of performance by saving a few triangles. However, I would not want to have a fixed tesselation on every single patch that I create, because the optimal tesselation can only be defined after the patch geometry is done (bending, scaling, vertex stretching).

[Mr Mike]

You're completely right of course, and I can't believe I never understood that before

 

I don't agree entirely with not forcing a fixed sub division though. If you're going for anything so ornate that it needs consideration towards the end then you'll be forcing sub divide from the get-go, imo.

 

Anything that brings to the mappers attention certain possible optimisation options I would think is a good thing, especially as I've seen quite complex lookin screenshots (on doom3world, not here) where it transpired that the editor didn't even know about these options!

[greebo]

Well, it may be possible to introduce a preference regarding that option ("Use fixed tesselation for newly created patches" or something like that).

 

If you feel that this is an important feature, please add it to the Bugtracker.

[SneaksieDave]

My entry's been closed already without even a chance to followup?

 

My point with the defect is mainly that going from DoomEd -> DR invites/exposes this problem. Sure, we're "not supposed to need to do that" someday, but 1., that's really not realistic to think it won't happen anyway, and 2., today isn't that day - there's a lot DR can't do right now that DoomEd is still needed for. Finally, it's one thing to open up DR and need to fix one arch. What happens when you open DR and have to fix 240 arches? It's undeniably a problem.

 

Is there not a value in the map that covers the tesselation level? There must be, otherwise, how would DoomEd remember that I wanted something subdivided 12, instead of 8, times? And I'm putting forward that apparently DR isn't reading or at least using that number. Am I incorrect?

[OrbWeaver]

So is the problem that correct and completed geometry from DoomEdit suddenly breaks and requires fixing up, when opened in DarkRadiant? That does sound more serious. My previous understand was that if you created geometry in DoomEdit and then tried to match new geometry to it in DarkRadiant, you would have to fix up the original patch first (which is acceptable IMO).

[SneaksieDave]

There's the number:

 patchDef3
{
 "textures/base_floor/a_bluetex1a_02"
 ( 3 3 17 1 0 0 0 )
...

I planted the 17 to locate it.

 

So is the problem that correct and completed geometry from DoomEdit suddenly breaks and requires fixing up, when opened in DarkRadiant?

Yep, that's what I'm submitting. If I save and compile in DE, and then open, save in DR, and then recompile, I'll get different tesselation levels in the end product. They're separated, as shown in the image (due to the difference), and even strangely different, as also shown in the original entry image - it doesn't have 2, or 4, or 8, or 16 subdivisions, but 7 . That may be a separate problem in itself. Anyway, fixing one patch once is fine - having to adapt an entire map just because you switched editors is extremely troubling.

[greebo]

My entry's been closed already without even a chance to followup? <_>

Okay, maybe I was too quick on the draw on this, I will reopen it for you. I seriously doubt that it can be fixed without knowing exactly on which basis DoomEdit and more importantly Doom3 tesselates its patches.

 

Finally, it's one thing to open up DR and need to fix one arch. What happens when you open DR and have to fix 240 arches? It'd undeniably a problem.

Now which map are we exactly speaking about?

 

Is there not a value in the map that covers the tesselation level? There must be, otherwise, how would DoomEd remember that I wanted something subdivided 12, instead of 8, times? And I'm putting forward that apparently DR isn't reading or at least using that number. Am I incorrect?

This is the patch definition from the arch you uploaded:

patchDef2
{
 "textures/darkmod/stone/floor/tiled_001"
 ( 3 3 0 0 0 )
 (
  (  ( -132.0000152588 -734.8048095703 72.6638641357 0 0 ) ( -144.0000152588 -734.8048095703 72.6638641357 0 0.046875 ) ( -156 -734.8048095703 72.6638641357 0 0.09375 ) )
  (  ( -131.9999847412 -709.3229980469 157.5072631836 0.25 0 ) ( -144 -709.3229980469 157.5072784424 0.25 0.046875 ) ( -156 -709.3229980469 157.5072784424 0.25 0.09375 ) )
  (  ( -131.9999847412 -608 160 0.75 0 ) ( -143.9999847412 -608 160 0.75 0.046875 ) ( -155.9999847412 -608 160 0.75 0.09375 ) )
 )
}

 

The important part of this patchDef2 is the ( 3 3 0 0 0 ) after the texture name, which contains the matrix dimensions (3x3 in this case and three numbers that are (ignored) flags and are zero anyway. There is no indication on how the patch should be tesselated, that is obviously subject to the code implementation. DoomEdit obviously handles it differently than DarkRadiant does.

 

The question is: is it possible to find out how Doom handles patches (how many subdivisions, etc.)? I will fire up Doom 3 and see what I might find.

[greebo]

There's the number:

 patchDef3
{
 "textures/base_floor/a_bluetex1a_02"
 ( 3 3 17 1 0 0 0 )
...

I planted the 17 to locate it.

SneaksieDave, this is not the patch from the map you submitted to FTP. In this example there is a patchDef3, which has fixed tesselation. This patch should be tesselated in the same way in both editors.

 

Can you send me this map as well so that I can check it?

[SneaksieDave]

I seriously doubt that it can be fixed without knowing exactly on which basis DoomEdit and more importantly tesselates its patches.

Doesn't that "17" in the example code above indicate the tesselation levels? Next to it is the "1" I chose for the other dimension, so I'd guess all needed info about that is there.

 

Now which map are we exactly speaking about?

What, for the "240" fixes I mention? That's a hypothetical map with X number of patches. And it needn't be all arches, it could be floors or walls or whatever else. A designer would have to fix every one of those?

 

 

The important part of this patchDef2 is the ( 3 3 0 0 0 ) after the texture name, which contains the matrix dimensions (3x3 in this case and three numbers that are (ignored) flags and are zero anyway.

Ah, crap. That does not sound good. So then, at current status, an author has the choice to explicitly define every patch on export from DE, or to explicitly define them on import to DR.

 

This is really not good.

[OrbWeaver]

It looks like there are several options.

 

(1) Figure out what logic DoomEdit uses to divide patches when they are not explicitly given a tesselation value, and mimic this in DarkRadiant. It may be, for instance, that the algorithm is identical but DoomEdit uses n subdivisions and DR uses n - 1 by default.

(2) Advise mappers that if they want patches to line up with each other, they should be explicitly subdivided before saving (to be honest I would always do this anyway, because the default subdivision results in too many polygons).

(3) Ignore the issue entirely. Presumably this only affects the way DR displays the curved patch, rather than saving it to the map file (because the file only contains the vertex coordinates which do not change), or am I mistaken here?

[greebo]

I just checked how Doom3 handles patches,

 

 

and it seems to be the same way as DoomEdit does.

 

I still don't think this is a major problem. Don't get me wrong, it would be nice if the tesselation was the same, but I doubt that this can be easily fixed. Tesselation is not quite trivial and I wouldn't want to reverse-engineer that one.

 

I don't want to sound destructive though, if everyone else agrees that this is some serious problem I can look into it.

 

Presumably this only affects the way DR displays the curved patch, rather than saving it to the map file (because the file only contains the vertex coordinates which do not change), or am I mistaken here?

No, you're right, only the vertices get saved for patchDef2.

[SneaksieDave]

Interesting, if that's a fact, then it would mostly be a display issue for DR? So, an untouched patch which doesn't "agree" with DR would look wrong, but when saved, it won't include tesselation info, meaning DE and Doom3 compilers would still see it the same? Then, if a patch was really really bothering someone in DR, or they had to do further operations on it, they could, and then the tesselation info would be explicitly saved?

 

Am I there? If so, then I agree, that is a problem yes, but it's one that doesn't stop workflow.

[greebo]

Yes, that pretty much sums it up.

 

I already looked at the tesselation code, and it definitely sounds not fun. There are a few hundred lines, completely undocumented, of course with recursions. If I was to investigate this, I'm sure it will take me a month to disassemble it.

I'm not afraid of the math (I've seen a lot of it in my life, believe me), but this is probably only maintainable for the one that wrote it.

[SneaksieDave]

What should we do with the defect entry? We could simply close/forget it, but it is a legit thing, ultimately. Is there a "possible for future (not really, wink wink)" status or bin we can chuck this kind of issue into?

[greebo]

There is the "suspended" status, maybe this fits. I'll set it to something meaningful.

[greebo]

I've got news on this. The preference "Patch Subdivide Threshold" does influence how the patches are tesselated in DarkRadiant. Lowering this value (and restarting DarkRadiant) makes the patches subdivide smoother.

 

A value of 2 yields the same result as DoomEdit, I believe:

 

 

However, I don't know if this is the remedy for all inconsistencies, but at least it's a start. If everybody agrees I will make 2 the default threshold value. Performance issues in game are unlikely because this affects only the tesselation in DarkRadiant itself, not in the Doom 3 engine (unless you choose fixed tesselation, a patchDef3).

[SneaksieDave]

Cool. Are we able to change that in preferences too, if the desire arises?

 

Edit: yep found it, nevermind.

[stgatilov]

I wonder what's the state of patches, i.e. DR vs Doom 3.

I have stumbled upon this but trying to make a trivial quad patch. I.e. just make a plan quad with linear texcoords s = 0-1 and t = 0-1. For some reason, dmap always produces weird meshes instead of two triangles. These weird meshes are overlapping themselves, which leads to texcoords also overlapping and this is a big no-no for me.

I have converted my quad patches to patchDef3, hoping that I would have more control over it, but it does not help. Is there any way to ensure that a quadratic patch gets converted to a simple quad? Is there a way to just draw a trivial quad?

[stgatilov]

Ok, it seems that with brushDef3 engine treats incoming points matrix as control points of quadratic B-spline. Points [0-2] x [0-2] define a quadratic Bezier surface, points [2-4] x [0-2] define another quadratic Bezier surface, points [4-6] x [0-2] define third Bezier surface, in the second row points [0-2] x [2-4] also define a Bezier surface, etc. So if you need B-spline knots, they always look like: "0 0 0 1 1 2 2 3 3 4 4 4" (both by U and V). If number of points in row/col is even, then the last row/col is ignored.

When patchDef3 is loaded, the code evaluates a uniform grid of points on this spline. If subdivision levels are set to P and Q, then every Bezier patch gets replaced with (P+1) x (Q+1) grid of points. Of course, adjacent patch grids share one row/col of evaluated points. In fact, all points with UV-parameters u = i/P and v = j/Q are evaluated.

So it turns out that if I create a quad as patchDef3 with 3 x 3 points and 2 x 2 subdivision levels, then this "subdivision" does not change it. The weird things that I see are due to dmap, I suppose