Jump to content


Photo

MDLOps

mdlops tool md alpha

  • Please log in to reply
82 replies to this topic

#61 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 10 June 2016 - 10:11 AM

This is very interesting. I would be curious to have a full set of rules on what the model structure should be for each set, PC, NPC, and some of the more complex animation/cutscene only models.

I think it would also be interesting to find out what those rules and structure are for placeables and even module parts.

The more you uncover about these things in the ASCII the better off we can resolve these issues prior to testing new or repaired models.

#62 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 32 posts

Posted 10 June 2016 - 08:09 PM

Yeah, I totally noticed that about PC models also, my pfbam never had any combat camera issue, just the missing shadow. I think there's probably something in the engine making the PC models be handled slightly differently in that regard (but not completely differently, because they still lose their shadows ... weird).

 

perl is an interesting language. it is kind of difficult until you understand its data types really well. on the plus side, it only has three data types (unless you consider refs (which are scalars) a fourth type, which i kind of do). a lot of things that are really painful in other languages are a total breeze to write in perl. the issue is that they are not usually very easy to read after that  :pc: . but yeah, i generally keep people nowadays from having to learn perl, pushing them more towards using javascript in node.js instead, which is why i'm not too aware of good learning resources. still though, a lot of systems administrators still use perl for scripting systems and build tasks.  i am loving how much perl source code exists for kotor tools.  it is really up my alley.  now if only 3d geometry stuff wasn't always so mathy i'd be set!

 

It is definitely interesting how a little thing like the difference between CHARACTER and Character can make such a difference. If you feel like subjecting yourself to a bit of excruciating detail on why this is, read on! I figure if you think you might be interested in perl ... hey why not ...

 

The classification in the ascii model only controls 1 byte in the compiled model. MDLOpsM.pm contains a map connecting names with their byte values, it is a hash, %classification around line 196. The names, or keys, in that hash are all ucfirst (upper case first letter). The important values there are 'Character => 0x04' and 'Other => 0x00'. So, the classification is read from the ascii model (that's actually the part I fixed), and then it gets used while writing out the binary file. In this stage, it is used directly as a key/name into the %classifcation hash. perl does not find $classification{CHARACTER}, so it returns 'undef' aka undefined. My guess though, is that, because that undef value is being used in a 'pack' call (the pack call is basically letting you be very specific about how perl interprets different values) that is claiming it should expect an unsigned char (byte), it interprets undef as being 0 (which was Other, rather than Character, which was 4). So basically the bug just makes the game think your model is classification Other instead of classification Character. Honestly, I'm surprised such an issue wouldn't cause more problems in-game.

 

 

Oh I understand where you're coming from, Ndix UR, by suggesting to others to look at better options in language programming, comparing some of the difficulties with one language versus another, which some are better then others. But, yeah, my only reason for even bothering with learning a little bit about Perl was because some of it reminded me of similar coding structures in LUA and Python, but then again, they all have such similar coding structure to begin with. But I just thought I'd delve into it a little bit, just to see and get a general understanding of it for my own personal use.

 

And with what you just explained in detail as to why that happens with the capitalized letters of the word Character, after running the ASCII file through MDLops, it actually does make a lot of sense to me. Because it actually did occur to me at one point, that the Perl coding was probably returning the classification as undefined (or really, I thought it was returning it as 'unknown') since it probably didn't recognize the word Character placed in all capital letters. So that does make sense, if there is no code for Perl to define the difference between lowercase and uppercase letters in what the file's classification is and carry out the necessary change, it's no wonder it labels it as 'undefined' - probably by default.   

 

BTW, speaking of programming languages and in relation to the above classification problem - the little python novice in me got to thinking about the little issue with the higher case letters of the word Character in the header of the ASCII files, since you mentioned that to me in your previous post. So I thought I'd take a look into the old NeverBlender 1.11 import\export scripts with Python's Idle Editor and see why it was writing the word Character in capital letters in the header in the first place, which I think can be fixed in the Python scripts as well.

 

 Because I've gotten some good results through some hacking of my own in the Neverblender files, but unfortunately, so far, this is only with the old Neverblender 1.11 version, because I've not even touched or begun to look into the Neverblender 1.23 version, which is what most people can only use with latest Blender versions. And I have no idea where to even begin with those later file versions of Python. I mean, I don't even see any python import or export files in the Neverblender 1.23a version (?), which perplexes me at this point. They really must of upgraded a lot of stuff in Python since the later 2.0 versions. But hopefully I'll be able to eventually figure out how the latest python version works since the 2.0 versions. I just need to do some studying on those later python versions. :laughing:  God I'm behind the times!

 

Anyway, if you happen to be curious or anyone else for that matter, here's what I discovered; 

 

I first noticed this coded block under "Helpers" starting on line 76 in the nvb_importmdl.py file, where it appears to me to be purposely coded to recognize any classification string (including the word character) and return those lower case letters into higher case letters. Which is really like the opposite of your coding fix in the MDLOpsM.pm, if you think about it.















def get_mdl_classification():
    '''
    Matches the classification the model with
    the available ones and returns it
    Writes a warning to the logfile if there is a 
    unknown classification an sets it to unknown
    '''
    if (glob_classification.lower() in {'unknown', 'tile', 'character', 'door', 'effect', 'gui', 'item'}):
        return glob_classification.upper()
    else:
        print('WARNING: Invalid Classification')
        return 'UNKNOWN'

Lol. So I've been screwing around with this block of code in trying to get it to return the classification string of 'Character' in lower case letters upon export, but the way I'm doing it, given my novice experience in python, is really more like hacking than proper python coding. But to my surprise, I've been getting some good results with some of the models so far with the old Neverblender exporter finally writing the classification as Character in the ASCII file's header as it should be in lower case letters. But I found out later on, by testing a few other body models, they get a default classification of 'UKNOWN' in the header of the ASCII upon export. So right now I'm trying figure out why those particular models get the 'UNKOWN' classification, while some of the other body models are getting the proper 'Character' classification in lower letters like they should be. 

 

There are also a couple of lines in the "nvb_exportmdl.py" file, which seems to confirm the classification as 'CHARACTER' in capital letters, which really just seems to reaffirm the coded block under "Helpers" in the "nvb_importmdl.py file". For example under in the "Variables" on line 45









glob_mdl_classification   = 'CHARACTER'

 and on line 297









elif (glob_mdl_classification == 'CHARACTER'):

On this I just changed the string 'CHARACTER' to 'Character' in those lines I found, which may or may not have any effect on the Neverblender export process. I don't completely know yet, but I did find out, that if you just edit those strings, only in the python export file,  it does nothing to change the classification in the ASCII header to lower letters. But then again, I suspect those particular lines do depend on what is changed in the coded block under "Helpers" in the "nvb_importmdl.py file". So I'm betting they need to be changed to lower case letters anyway.

 

 

So anyway, it's just a case of more testing and experimenting with these old python files, to get them to write Character as it should be in ASCII file header, with every one of the ASCII files upon export. Which like I mentioned before, I've been able to get it to do it with some of the models upon export from Blender. So some success, but not quite total success yet.   ;)

 

 

 

EDIT TO ADD:  By the way, it looks like Symmetric uploaded a new version of Neverblender (1.25) a couple of days ago.

 

http://neverwinterva...blender-269-27x



#63 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 14 June 2016 - 11:36 AM

Well, I have some "new" information for KotOR modders. The models for NWN1 are already ASCII, which means when they updated the aurora engine for KotOR, they decided to convert the models to binary to make the files smaller.

Now, de-compiling the NWN model may give us some new clues as to the differences between the KotOR ASCII and the NWN ASCII.

I can import all nwn1 models without converting them to ASCII with mdlops, they just import with Neverblender.

Since KotOR models are binary they have to be converted to the old ASCII format with mdlops first, so the mdlops converter is not quite built to convert everything to the old NWN format. Part of this could be due to the skinned models in KotOR. It could be that one or two bytes on a line are mismatched or that the nwn1 format did not allow for the complexity of KotOR models since the NWN models are all just trimesh objects with helpers, kind of like the KotOR droids.

so the issue is not the importer at all, it is reworking mdlops so that the conversion to the ASCII format matches the ASCII data in the old nwn1 models, and that has to be done first before the importer will be successful 100% of the time with all KotOR models.

I have a few of the models for NWN1 in my external drive if anyone wants to use them to compare the data between formats so that mdlops can better approximate the format that Neverblender expects. This actually might also benefit users of NWNmax as well, since the importer relies on the models being as close to the original NWN1 model format as possible.

The models I have include character, item, and even some areas with walkmeshes, so examining those could really benefit people trying to mod KotOR.

Anyone interested in comparing the formats to troubleshoot can PM me for a zip file of the MDL’s.

#64 ndix UR

ndix UR

    Jedi Apprentice

  • Members
  • PipPip
  • 50 posts
  • Locationca, usa

Posted 16 June 2016 - 12:02 AM

@Purifier thanks for the neverblender release announcement! Now I just have to determine whether it's worth upgrading. The reason it is a question is that I have substantially modified my NVB, and if I want to upgrade I'll probably want to produce proper patches ... or do a git merge ... and as a software engineer I am kinda lazy ... I have also been approaching the modeling issues from both sides, NVB/python and MDLOps/perl. My goal has been getting them to produce identical results (so I can see the things that have *actually* changed by comparing MDLOps ascii files against neverblender exported files).

 

It would probably be wise to take the neverblender discussion to a new thread.

 

@DarthParametric - that is interesting that you encountered the combat camera weirdness on a KAurora compiled model. I haven't used KAurora ... I think maybe I tried, but I'm in wine, so it's a bit of a crapshoot as to what windows software will or won't function. It seems really unlikely that KAurora would misclassify a model ... what was the workflow for that? Starting from zero, or starting from some existing model? I am really interested in that because I am strongly considering implementing a new droid model (probably based on HK?, but heavily modified) for Elbee (T1-LB) from the comics series. Elbee the sullen hulk.

 

I just wanted to alert anyone that currently maintains MDLOps that I am working on a suite of improvements, and I am interested in discussing it much more than I'm going to have time to right now  :P .

 

Anyway, here's what I've done so far:

  • Controlled precision: we lose repeatability in the process because MDLOps doesn't really 'handle' precision. This is bad for anything that's a floating point value. Google says that for 4 byte floating point numbers you need to maintain 6 significant figures to repeatably go from number string => floating point value => number string, and 9 sigfigs for fp value => num string => fp value.  MDLOps approach is just 'more is better' combined with 'whatever you want to do, perl', routinely outputting 16 sigfigs. I don't think those are real, they are garbage. So now anywhere floats are used, somewhere between 6 and 9 significant figures of precision are used explicitly. That will probably be refined to 'the right' numbers at some point, but so far it is working well.
  • Reworking the templates used for reading from binary models to fit KAurora's better understanding. So far I've only reworked the common mesh header stuff, but it's already helping.
  • Implemented and fixed some of the unhandled attributes already known: shininess, lightmapped, bitmap2-4, 'sparkle'. I have been trying to take as many names from nwn-tools as possible to maintain maximum compatibility with NWMax ... it seems possible that bitmap2-4 should maybe be 'texture2'-'texture4' instead, but i'm not sure how much it matters. I use neverblender, which I am going to have to extend to retain all the kotor-specific attributes (it already retains some custom data (aka data that blender doesnt understand) at the mesh level, so it should actually be easy!).  These are all implemented for decompile and recompile.
  • Fixed a couple infinite loop and infinite recursion conditions that affected a few of the models that have 'bad things' happening in them. One of the k1 dor_... models animates meshes by name that don't appear in the model itself, mdlops hated that.
  • Placeholder for controller240 - gathers data on values only, decompile only.
  • Performance & reliability - there are still problems I'm working on here, but as a software engineer who's been using perl for 10+ years, there were a lot of little things to fix to make it function better, faster, and more deterministically (overreliance on $_ and nuances of buffered IO are (among) the evils of perl).
  • Improved ability to determine nodetypes when classifying controllers, leading to more complete decompilation of controllers (I have 0 'didn't find controller X in node type Y' messages now)

And here's what I hope to do soon:

  • Compilation support for more controllers
  • Debug mode that will export all the unknown flippable parameters to ascii models and then compile them back in also
  • Improve the nice work you guys did not too long ago on the model seams (implementing the cross-mesh smoothgroup test (also figuring out whether you guys got angle weighting & face weighting in there ... when i was reading quickly it seemed like maybe only face weight?)
  • If I can see what KAurora knows I'll fix all the unpacking templates to current best understanding
  • Figure out wtf is up w/ scale & specular

And here's what I hope to do longer term:

  • Full(er) animation controller compilation (decomp support is surprisingly good already AFAICT, but right now only position & orientation can get back into game models)
  • Remove supermodel requirements (I currently understand this to be a limitation of bone understanding in the MDX ... but these goals are all lofty and not well-understood at this point)

 

I am pretty solely focused on the technical aspects of it, just modifying MDLOps.pm really, not very concerned w/ any kind of GUI or CLI 'features'.

 

Once I solve any of the 'harder' problems it will probably be worth thinking about doing a release of some kind ... so far it's been mostly somewhat 'frilly' stuff to make way for real improvements.

 

MDLOps is an amazing tool already, and I really want to help it get further along in making people's modding experiences easier, better, and more reliable.



#65 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 720 posts
  • LocationOz

Posted 16 June 2016 - 08:26 AM

@DarthParametric - that is interesting that you encountered the combat camera weirdness on a KAurora compiled model. I haven't used KAurora ... I think maybe I tried, but I'm in wine, so it's a bit of a crapshoot as to what windows software will or won't function. It seems really unlikely that KAurora would misclassify a model ... what was the workflow for that? Starting from zero, or starting from some existing model? I am really interested in that because I am strongly considering implementing a new droid model (probably based on HK?, but heavily modified) for Elbee (T1-LB) from the comics series. Elbee the sullen hulk.


It was a completely custom series of meshes, with only the helper objects from the original T3-M4 model remaining. It wasn't the character classification issue, but whatever the root cause was the camera issue sounds like it was the same.

As to other droids, HK will work as a basis for new meshes. Protocol droids are a bust.
 

MDLOps approach is just 'more is better' combined with 'whatever you want to do, perl', routinely outputting 16 sigfigs. I don't think those are real, they are garbage.


I think Max, like most 3D apps, only outputs 4 sig figures anyway, so anything beyond that is probably worthless.
 

And here's what I hope to do longer term


Something else that might be worth stealing from KAurora, if possible, would be its support for emitters.

#66 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 16 June 2016 - 08:40 AM

It was a completely custom series of meshes, with only the helper objects from the original T3-M4 model remaining. It wasn't the character classification issue, but whatever the root cause was the camera issue sounds like it was the same.

As to other droids, HK will work as a basis for new meshes. Protocol droids are a bust.
 

I think Max, like most 3D apps, only outputs 4 sig figures anyway, so anything beyond that is probably worthless.
 

Something else that might be worth stealing from KAurora, if possible, would be its support for emitters.

 

i was curious about the droids. I have a couple of new ones, one is based on the protocol droid mesh but just resculpted, and the other one is based on another source i was experimenting with to see how close NWN aurora was to Kaurora for at least the droid trimesh. What you are talking about is a completely new mesh has to be rigged to the HK helpers? how about animations? it has to do with the experiment.



#67 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 720 posts
  • LocationOz

Posted 16 June 2016 - 09:12 AM

There is no rigging/skinning required, unless you are planning on using a skinned mesh. The droids all typically drive the trimeshes directly. Obviously you'll need to keep the same number of meshes, with the same names, and same pivots.

Regarding animations, you'll typically want to use a custom model name, export without animation, and reference the original model as the super model.

#68 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 16 June 2016 - 09:17 AM

@ DP, i sent a PM because i dont want to clutter the thread any more with unrelated stuff, im kind of going off topic about things that are vaguely related to MDlops, and there are more details in the PM.



#69 Kexikus

Kexikus

    Jedi Master

  • Members
  • PipPipPipPipPip
  • 1,072 posts

Posted 07 November 2016 - 02:47 PM

I've been editing several area models with animations in the last days and usually creating the bindary file from the ascii was never a problem when using mdlops, but today I started editing bigger models (bigger in file size) and mdlops doesn't seem to progress at all.

 

Before I had models that were a few 100kB in filesize and the conversion took a minute at most. The latest model I was editing has a filesize of about 7 MB and I aborted the conversion after about 2 hours. So my question is, whether I just have to wait for it to finish or if there's a file size limit or something like that.

 

The other way, from binary to ascii worked perfectly with that same model by the way.


Signatur_zpsdlwsov7b.jpg


#70 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 720 posts
  • LocationOz

Posted 07 November 2016 - 03:49 PM

You can compile models around that size, but if it takes more than a couple of minutes that's pretty much game over. You could try progressively deleting elements to see if you can isolate what specifically is causing MDLOps to choke.

It would actually be good to revert something more akin to the more verbose output of MDLOps 0.5, but preferably even more verbose, in order to better diagnose compile errors like that.

#71 Kexikus

Kexikus

    Jedi Master

  • Members
  • PipPipPipPipPip
  • 1,072 posts

Posted 07 November 2016 - 05:06 PM

Tried another big model (3.5 MB I think) and while it took about two hours, the compilation was completed at some point. The problem is that for some reason all textures were missing or something like that. I just don't know if that's MDLOps fault or something I screwed up before even compiling the model.

 

Deleting elements wouldn't really help me since I only want to add a few tiny parts to the vanilla model. I could use this method to figure out what's causing the issues but then I'd still need a way to solve these issues and I don't have the knowledge for that. So I might just go with a new model that I add to the module.

 

Edit: It seems that MDLOps is just quite slow when compiling ascii models as even 2MB models take me between 15 and 30 minutes. So, if you come across this problem, just wait. It will finish at some point^^

The missing texture issue I had, wasn't really a missing texture issue but the model just started to the the sun fog overlay which made it appear completely grey, while in vanilla, this model doesn't have the sun fog. I misinterpreted that as missing textures.


Signatur_zpsdlwsov7b.jpg


#72 JCarter426

JCarter426

    Jedi Knight

  • M478_Staff
  • 178 posts

Posted 20 March 2017 - 03:25 AM

I have two more MDLOps issues to report.

 

We talked before about how MDLOps does not currently allow for smoothing between different meshes. Well, I just discovered that this also applies to different elements within a single mesh.

 

Spoiler

 

So, you can see here I have the model PFBAM, which is made up of a few elements. They are all set to use smoothing group 1. The individual elements smooth just fine, as do the arms, however...

Spoiler

 

There's a rather nasty seam around her shorts, and it's not really visible but the same issue occurs in the shoulder region.

 

And here's the same model again with the textures removed, so you can see this is a smoothing issue and not a texture issue:

 

Spoiler

 

I tried welding vertices but that led to more trouble. It was actually a bit serendipitous because it helped confirm the source of another problem I've been having.

 

The second issue is... this is hard to explain, but basically MDLOps does not allow for faces that are connected on a mesh to be unconnected in the UVW map. 3ds has a break function that lets you do this - you can map faces to wherever you want, so even though if they share vertices on the mesh, those vertices don't have to be in the same place on the UVW map. I was using this function to un-mirror Bastila's underwear model, so the left and right sides of her body could be textured differently.

 

Spoiler

 

It looks fine in 3ds, it exports fine, and I can even import the new ASCII file and it still looks fine. Once it's run through MDLOps, however, it looks like this:

 

Spoiler

 

Not what I was going for. MDLOps stretched the UVW map, as you can see below:

 

Spoiler

 

A similar thing happened after I welded vertices on PFBAM. The faces on the map there were already separate because they were originally on separate elements. And then after I welded the vertices, I got the same problem, stretched mapping at the edge of the faces.

 

In both cases, I have faces that are supposed to be separate on the UVW map even though they're adjacent on the mesh, and it seems like MDLOps thinks it has to connect them.

 

So to summarize, if adjacent faces are to be mapped to different parts of the texture, then they must be separate elements or meshes, and in either case MDLOps doesn't allow smoothing. I can have something with smoothing, or I can have it with UVW mapping the way I want - or in some cases, the way the game already is - but not both.



#73 N-DReW25

N-DReW25

    Little Fixer

  • Members
  • PipPipPipPip
  • 368 posts
  • LocationMalachor II

Posted 20 March 2017 - 04:44 AM

I have two more MDLOps issues to report.

 

We talked before about how MDLOps does not currently allow for smoothing between different meshes. Well, I just discovered that this also applies to different elements within a single mesh.

 

Spoiler

 

So, you can see here I have the model PFBAM, which is made up of a few elements. They are all set to use smoothing group 1. The individual elements smooth just fine, as do the arms, however...

Spoiler

 

There's a rather nasty seam around her shorts, and it's not really visible but the same issue occurs in the shoulder region.

 

And here's the same model again with the textures removed, so you can see this is a smoothing issue and not a texture issue:

 

Spoiler

 

I tried welding vertices but that led to more trouble. It was actually a bit serendipitous because it helped confirm the source of another problem I've been having.

 

The second issue is... this is hard to explain, but basically MDLOps does not allow for faces that are connected on a mesh to be unconnected in the UVW map. 3ds has a break function that lets you do this - you can map faces to wherever you want, so even though if they share vertices on the mesh, those vertices don't have to be in the same place on the UVW map. I was using this function to un-mirror Bastila's underwear model, so the left and right sides of her body could be textured differently.

I know for a fact that model of underwear is K1's scoundrel underwear model with a different texture. That weird line thing is supposed to be the underwear where the original scoundrel underwear was supposed to be. I do believe a simple reskin to make the underwear match up to that line should remove the eyesore.



#74 JCarter426

JCarter426

    Jedi Knight

  • M478_Staff
  • 178 posts

Posted 20 March 2017 - 04:51 AM

That may be the case, but that's not what I want to do with the model. I'd like to fix the smoothing to use it as shorts or pants and so on. And as I pointed out, that's not a matter of a simple retexture.



#75 ndix UR

ndix UR

    Jedi Apprentice

  • Members
  • PipPip
  • 50 posts
  • Locationca, usa

Posted 20 March 2017 - 05:12 AM

I have two more MDLOps issues to report.

 

We talked before about how MDLOps does not currently allow for smoothing between different meshes. Well, I just discovered that this also applies to different elements within a single mesh.

 

Spoiler

 

So, you can see here I have the model PFBAM, which is made up of a few elements. They are all set to use smoothing group 1. The individual elements smooth just fine, as do the arms, however...

Spoiler

 

There's a rather nasty seam around her shorts, and it's not really visible but the same issue occurs in the shoulder region.

 

And here's the same model again with the textures removed, so you can see this is a smoothing issue and not a texture issue:

 

Spoiler

 

I tried welding vertices but that led to more trouble. It was actually a bit serendipitous because it helped confirm the source of another problem I've been having.

 

The second issue is... this is hard to explain, but basically MDLOps does not allow for faces that are connected on a mesh to be unconnected in the UVW map. 3ds has a break function that lets you do this - you can map faces to wherever you want, so even though if they share vertices on the mesh, those vertices don't have to be in the same place on the UVW map. I was using this function to un-mirror Bastila's underwear model, so the left and right sides of her body could be textured differently.

 

Spoiler

 

It looks fine in 3ds, it exports fine, and I can even import the new ASCII file and it still looks fine. Once it's run through MDLOps, however, it looks like this:

 

Spoiler

 

Not what I was going for. MDLOps stretched the UVW map, as you can see below:

 

Spoiler

 

A similar thing happened after I welded vertices on PFBAM. The faces on the map there were already separate because they were originally on separate elements. And then after I welded the vertices, I got the same problem, stretched mapping at the edge of the faces.

 

In both cases, I have faces that are supposed to be separate on the UVW map even though they're adjacent on the mesh, and it seems like MDLOps thinks it has to connect them.

 

So to summarize, if adjacent faces are to be mapped to different parts of the texture, then they must be separate elements or meshes, and in either case MDLOps doesn't allow smoothing. I can have something with smoothing, or I can have it with UVW mapping the way I want - or in some cases, the way the game already is - but not both.

 

 

So, your second issue, regarding connected geometry and different UVW vertices along island breaks. That is a limitation of the MDL/MDX format and cannot be worked around (well, unless MDLOps were to automatically split edges that need to be split, which is technically possible). You have to double your vertices along every edge of UVW islands. It is because vertices and UV vertices are stored together in single MDX rows, so you can't have a UV without a geometry vertex, and you can't have multiple UVs for a single geometry vertex. You can tell whether you are going to have this problem by opening your ASCII model in a text editor, going to the node you modified (torso), and seeing if the number of verts matches the number of tverts. If it does not, your model will have some kind of problem, maybe subtle, maybe not.

 

And on the first point, you are quite right. Current versions of MDLOps don't smooth across disconnected geometry, which is required at UV island edges, so it can never smooth across different UV islands. The fundamental issue for current versions of MDLOps is that they only accumulate vertex (& face, if I recall) normals from connected geometry. Also the current versions of MDLOps don't do anything with smooth group numbers.

 

I apologize for any inaccuracies, it's all top of the head.

 

The way I have been working lately is to weld all the vertices, and then towards the end, I go around each UV island edge using 'edge split' to double the vertices as required. That is a blender command though, so you'd need to find/do the 3ds equivalent.



#76 JCarter426

JCarter426

    Jedi Knight

  • M478_Staff
  • 178 posts

Posted 20 March 2017 - 05:22 AM

So, your second issue, regarding connected geometry and different UVW vertices along island breaks. That is a limitation of the MDL/MDX format and cannot be worked around (well, unless MDLOps were to automatically split edges that need to be split, which is technically possible). You have to double your vertices along every edge of UVW islands. It is because vertices and UV vertices are stored together in single MDX rows, so you can't have a UV without a geometry vertex, and you can't have multiple UVs for a single geometry vertex. You can tell whether you are going to have this problem by opening your ASCII model in a text editor, going to the node you modified (torso), and seeing if the number of verts matches the number of tverts. If it does not, your model will have some kind of problem, maybe subtle, maybe not.

 

I see. I suspected that might be the case. So the only way to have separate UVW maps is to have separate meshes or elements. I can live with that. But then that does leave the matter of the smoothing. For that matter I can only hope that one of you enables smoothing group in a future update. :D

 

The way I have been working lately is to weld all the vertices, and then towards the end, I go around each UV island edge using 'edge split' to double the vertices as required. That is a blender command though, so you'd need to find/do the 3ds equivalent.

 

I believe I tried this already, but I could go back and try again. I may have been doing it wrong before.

 

But it sounds like it wouldn't resolve the smoothing issue anyway, since they would still be separate elements. For un-mirroring, in the past I've split it into two different meshes and it had a visible seam in the middle. Seems like the result would be the same for that. And in the case of PFBAM it has all the duplicate vertices already, but still no smoothing.

 

EDIT: Yeah, I tried welding the vertices and then used the detach as element function. Still no smoothing. It basically set the model back to the way it was before.



#77 VarsityPuppet

VarsityPuppet

    Jedi Master

  • Premium Member
  • 1,923 posts

Posted 20 March 2017 - 11:12 AM

Is vertex smoothing not working in mdlops7? That was like the main thing it was supposed to implement

#78 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 720 posts
  • LocationOz

Posted 20 March 2017 - 12:43 PM

There are posts about the issue in 0.7a2 back at the end of January 2016, so news of it isn't new.

#79 VarsityPuppet

VarsityPuppet

    Jedi Master

  • Premium Member
  • 1,923 posts

Posted 20 March 2017 - 02:07 PM

There are posts about the issue in 0.7a2 back at the end of January 2016, so news of it isn't new.


I vaguely remember that... seemed to work fine for things I've been using it for so idk

I also had a program that smoothed all of the normals in the .mdx file bur I trashed it awhile ago... guess I should have held onto it.

#80 JCarter426

JCarter426

    Jedi Knight

  • M478_Staff
  • 178 posts

Posted 20 March 2017 - 07:07 PM

What does work works great. Smoothing on individual mesh elements is fine. No more ugly seams on arms and legs and such. But it won't do smoothing between different meshes or mesh elements - essentially, across seams in the UVW map.

 

It's only a problem depending on what model you're working on. Many of the armors are fine. Where their meshes meet, there isn't supposed to be smoothing, because there's armor or whatever in between the joints. The underwear models are particularly problematic, though, because they're meant to be smooth all over.

 

The issue also crops up on models that have... the nice word would be questionable, questionable UVW mapping. The Jal Shey armor and the Twin Sun models, for example, have faces on the UVW map that are isolated for seemingly no reason, on the pants. The original models get away with it thanks to the smoothing, but MDLOps loses that.







Also tagged with one or more of these keywords: mdlops, tool, md, alpha

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users