research MDLedit x MDLOps Compiled Model

[ebmar 893]

Greetings, fellow Jedi! May the Force be with you.

Along with the compiling-decompiling model attempt I have done recently, some discoveries were found regarding the end-result of using both MDLedit v1.0.3 and MDLOps v1.0.0.

First, this comparison purpose is to give the potential user of both tools a preview of the compiled model using each of the tools mentioned.

This also had no intention to show which tools are best and which are less; it's simply to share the discoveries been found.

Here's a screenshot for details:

 

• Left image is TSL's n_quarren [Quarren's F model] model compiled using MDLedit v1.0.3 with tangentspace enabled by not ticking the bumpmap flag, but instead changing its value inside the ASCII file from 0 to 1 using a text editor.
• Right image is TSL's n_quarren [Quarren's F model] model compiled using MDLOps v1.0.0 with tangentspace enabled by changing its value inside the ASCII file from 0 to 1 using a text editor.

As we can see there is a difference in the head part; which MDLOps version produce a noticeable line whilst MDLedit version isn't. This occurrence already emerging several times on my end; such with compiled TSL's n_commf model.

I hope this discovery kind of helps with any future modding attempt, and gave an insight of what will and what won't regarding the implementation of the aforementioned method.

Edit: Be advised that they had nothing to do with normal maps. It's a smoothing error, as informed by DarthParametric. The normal maps activation is just part of the compiling process.

Edited December 16, 2018 by ebmar
It had nothing to do with normal maps. It's a smoothing error

[DarthParametric 3,782]

That has nothing to do with normal maps. It's a smoothing error.

[ebmar 893]

Just now, DarthParametric said:

That has nothing to do with normal maps. It's a smoothing error.

Thank you for the heads-up! I'll revised the information above accordingly.

Ah- so it called smoothing then. 🤔

[DarthParametric 3,782]

The mesh is split along UV seams. We always traditionally had a problem where ye olde MDLOps was unable to smooth across such seams, but this was fixed in more recent revisions of MDLEdit. I believe it is also fixed in MDLOps, it just hasn't been pushed to the public release.

The reason you get a hard seam is there are two sets of verts at each point along the seam, and each has their own normal. When you unify these into a single averaged normal, you get a smooth transition across the seam (i.e. no visible seam). It should be easy to visualise this in Max/GMax if you decompile that model, load up the ASCII and add an Edit Normals modifier.