Help to fix proper edge winding with ASE exporter

[LDAsh]

I'd really like to fix the way the ASE exporter (and others) orientates the middle edges of the quads it exports. They are opposite of how they should be, as seen in Radiant. To illustrate, I have this pic below - on the left is the original patches that I exported, and on the right is the ASE model that I imported back into Radiant. You'll see how the inner edges are orientated differently, and in this case gives a different shape, and in other cases may affect the way the textures are warped on these faces.

(I added the extras lines in the orthographic view to demonstrate this, but they are 4 patches, not brushes)

I'm also trying to figure out how to do this in Blender, but I don't think it's possible. Perhaps Meshlab can do it. There is a line in the Python script here:-

            for x in reversed(winding):

                verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])

A tweak to this may be what's needed, but I have no idea how. I might try to play with it in a while.

Exporting as OBJ corrects the orientation of the inner edges of the quads, but using this method loses the material headers, this information is not exported.

 

[LDAsh]

So yeah, MeshLab can certainly do this:-

...but with a couple of important caveats. Here's how anyway:-
_______________________________________
Convert ASE to OBJ, change any "/s" into "!s" (to (try to) preserve full material headers), and import mesh into MeshLab:-

Filters >
Polygonal and Quad Mesh >
Turn into Quad-Dominant mesh -
(Optimize For: Better quad shape)
Filters >
Selection >
Select non Manifold Edges
Filters >
Remeshing, Simplification and Reconstruction >
Planar flipping optimization -
(Planar metric = area/max side)
(Post optimization relax iterations = 0.0)

...then export to OBJ, which is a different version that Blender doesn't seem to like, but there are converters to fix that.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
So the issues are - I can't seem to reliably retain the material headers, and it will also reposition the mesh to the middle of the object on exporting, which may or may not be a big deal depending on the proportions of what is exported. This can probably be circumvented by encasing everything in a giant cube, possibly. MeshLab's OBJ exporter doesn't have a lot of options there, so although it does work, the material header issue is the deal-breaker for keeping it an efficient overall solution. It prefers the filename over the material header, unfortunately. If it were as simple as this 4-quad 1-material test, sure, no biggy, but in practice we'd be shoving around (tens or even hundreds of) thousands of triangles, with dozens of different materials, and it's just not reasonable to spend hours in a text editor, fixing every damn material header, every damn time.

[AluminumHaste]

Nice work.

[LDAsh]

Nice work? No, looks like I'm going to need to make a chunky-ass macro to fix all the material headers automatically...

[LDAsh]

Sorry to bump this over a year later, but coming back to this issue, that Meshlab fix only really works on perfectly flat meshes and my other simple tests. If trying to fix a piece of terrain that has already been thoroughly articulated, only some of the edges can be fixed. Toying with other options usually destroys it in one way or another. Turning some edges is still better than it all being the complete opposite winding, but, for actual use-case it's still a lot of manual tidying up to get the geometry in and out of Radiant in a reasonable way, for such finely detailed terrain. I don't want to be offensive, but, realistically perhaps the reason this issue has been so overlooked for so long is because nobody has actually tried to do this kind of thing before - fully and finely articulating large chunks of vertex-blended terrain, and then optimising it outside of Radiant, and bringing it back in again.

So I've come back to looking into the Python script. I've played with a few things in the script (as mentioned in the first post) but nothing is getting it right, if it works at all. Hopefully this final beg might result in a solution, but whatever the case, Merry Christmas to all.

Edited December 22, 2018 by LDAsh

[Bikerdude]

Might be worth logging a tracker, if you haven't already.

[STiFU]

(I added the extras lines in the orthographic view to demonstrate this, but they are 4 patches, not brushes)

 

I'm also trying to figure out how to do this in Blender, but I don't think it's possible. Perhaps Meshlab can do it. There is a line in the Python script here:-

            for x in reversed(winding):

                verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])

A tweak to this may be what's needed, but I have no idea how. I might try to play with it in a while.

 

Exporting as OBJ corrects the orientation of the inner edges of the quads, but using this method loses the material headers, this information is not exported.

1. You've been looking the wrong location. You said you export a patch. Patches are exported in a separate function called processPatch().

2. What about lwo export? Does that also not work?

3. Could you supply a test map? It's been 5 years sind I have used DR and I have forgotten it all. ^^

[LDAsh]

Actually I realised something interesting - this different winding issue is even in the software itself, as seen in the viewports:-

The way you see it in Q4E is how it would be exported from DR, but not how it's displayed.

 

So in order to get this type of geometry correct (where every triangle is important), it should just be done in "Q4Radiant", as difficult as that program is to use compared with DarkRadiant, at least it's WYSIWYG.

[Bikerdude]

Log a tracker, so Greebo can atleast see if its possible implement.