ebmar

MDLedit x MDLOps Compiled Model

4 posts in this topic

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

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:

MDL_Comp.jpg.e5fd6576a84eed0a8ad92b7307dce676.jpg

 

  • 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. :cheers:

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 by ebmar
It had nothing to do with normal maps. It's a smoothing error

Share this post


Link to post
Share on other sites
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. 🤔

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now