MDLOps

[LiliArch 115]

LiliArch, have you tried both versions? - and if you have - In your opinion, is there much difference between the Blender 2.69 and 2.7 version?

Well, I've run both versions, but I don't exactly know how to use them, so. By the time I found out I need to use a wheel mouse instead of touchpad to be able to do anything reasonable, I had already sort of hurt my mouse-arm and as such, I was unable to try to learn how to use the program. They have a different picture in the splash screen, that's all I know. I'm still only trying to learn how to do 3D.

 

It seems like every version of blender is different

That's usually the point in releasing a new version, isn't it? If it would be exactly the same, they wouldn't raise the version number...

...sorry, I feel snarky. Bad day.

[xander2077 80]

That's usually the point in releasing a new version, isn't it? If it would be exactly the same, they wouldn't raise the version number...

...sorry, I feel snarky. Bad day.

 

that aint snarky, i get your point, but what i mean is that some things that were nice features or really useful and worked, got canned for no reason while they still ignore user suggested improvements and call it an upgrade to the program. and they could not make up their minds what key combinations to keep for a while, confuses the user.

 

once it levelled off the program became eaier to use, and it finally started looking like an improvement with each version, but then some stuff that could have been ported to the new version were inexplicably removed for no good reason, and blender still has its bugs and weirdness in a few places. like the texture paint mode. why is it that i need something extra to download for it to work but there is nothing to download to make it work? should they not have included some default brushes and things in that part of the program just like in sculpt mode? why did they change the faked ambient occlusion to only work with a texture now? it used to work fine without a texture before since it was based on the native blender lighting rendering the shadows on the model. now i cant use it unless i have already baked an ambient occlusion layer, so it kind of seems counterintuitive. so some of the version 'upgrades' come with a bunch of unsecessary downgrades as well. i guess they seem to think that they have to punish users for making blender so much better each version by removing really nice features, or making some things impossible to use when they worked fine before. or making things more convoluted in some cases. sure there are some nice new features but some of the nice old ones got taken away when they could have just as easily been ported to the new python. it is easier to port old to new than new to old.

[Purifier 22]

We'll thanks for both your inputs on the subject, guys. I'm going to try my hand with the 2.69 Blender and the import\export scripts. See if I can produce anything worthwhile. Lol. Then again, probably not, knowing my luck with 3D editors. 

 

But thanks again!

[Purifier 22]

I just spent waaaaaaay too long debugging MDLOps and I have a fix for you!

 

Setup: working on character models with blender using neverblender import/export

 

Symptom: recompiled characters don't have shadows in game. if they are playable NPCs (handmaiden say) and you enter combat with them active, the camera freaks out, doing a combination of moving inside the model's head and orbiting them really closely as if some kind of collision were happening.

 

Cause: neverblender exports models with classifications in ALL CAPS. It took me *so* long to figure this out. I tried just about everything else (returning weights, tverts, faces, orientations, all things neverblender changes on a simple import/export).

 

Solution: in MDLOps.pm change line around 1795:

    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = $1;

to

    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = ucfirst lc $1;

This is similar to how keys are used in the nodelookup hash.

 

Anyway, I hope this will save some blender character modders some grief somewhere down the line. Thanks for maintaining this essential software!

 

Apparently this new added MDLOps.pm line of code you changed doesn't seem to work for some models exported with Neverblender. I changed the line of code, word for word on line 1795, in MDLOps.pm with Notepad++ and ran the p_juhanibb.mdl through MDLops 07A2, then imported and exported it with NeverBlender, then back through MDLops 07A2 again. Put the new model in the K1 override folder and started up the game. Unfortunately I still get the same problem of no body shadow and the camera flipping out during combat mode, like you did.

 

I may have messed up somewhere, but I tested this several times, but I'm also wondering if this line of code change was for MDLops 07A2 or a older version?

[ndix UR 218]

This change is definitely against MDLOps 07A2 ... Sorry to hear that it hasn't resolved your issue. I haven't seen this issue again since I made the change.

 

Some debug questions:

 

After you changed MDLOps.pm, are you running MDLOps by running the command "perl mdlops.pl" (or by double clicking mdlops.pl I guess) or by running mdlops.exe?  If you are running mdlops.exe, it is extremely unlikely that your change to MDLOps.pm had any effect.

 

My understanding, and people will correct me if this is inaccurate, is that mdlops.exe is a compiled executable that includes perl, Tk, MDLOps.pm, etc. -- all the dependencies. It is completely standalone from the mdlops.pl and MDLOps.pm files.  This is, for example, why you can use mdlops.exe without installing perl (I think! I don't actually have a windows box to test with!).

 

That is my first/best guess as to the problem.  If you're definitely already using mdlops.pl and the modified MDLOps.pm... can you post the 'classification' line from the ascii version of your p_juhanibb.mdl file?

 

Also: speaking to the earlier version questions you had ... I use blender 2.77 and neverblender 1.23a which was released earlier this year i believe. i found it on nwnvault.

[Purifier 22]

This change is definitely against MDLOps 07A2 ... Sorry to hear that it hasn't resolved your issue. I haven't seen this issue again since I made the change.

 

Some debug questions:

 

After you changed MDLOps.pm, are you running MDLOps by running the command "perl mdlops.pl" (or by double clicking mdlops.pl I guess) or by running mdlops.exe?  If you are running mdlops.exe, it is extremely unlikely that your change to MDLOps.pm had any effect.

 

My understanding, and people will correct me if this is inaccurate, is that mdlops.exe is a compiled executable that includes perl, Tk, MDLOps.pm, etc. -- all the dependencies. It is completely standalone from the mdlops.pl and MDLOps.pm files.  This is, for example, why you can use mdlops.exe without installing perl (I think! I don't actually have a windows box to test with!).

 

That is my first/best guess as to the problem.  If you're definitely already using mdlops.pl and the modified MDLOps.pm... can you post the 'classification' line from the ascii version of your p_juhanibb.mdl file?

 

Also: speaking to the earlier version questions you had ... I use blender 2.77 and neverblender 1.23a which was released earlier this year i believe. i found it on nwnvault.

 

Okay, that was exactly what I was doing - clicking or using the mdlops.exe. So that's probably why it wasn't working for me. And I never thought about the Blender and Neverblender version I'm currently using, but yeah, I'm using an earlier version of Blender (2.69) and Neverblender (1.11). So that might also be part of the problem as well, but I've had good results of getting most of my custom edited MDL models into either Kotor games, except for the no body shadow and weird camera effects during combat of course, so I'm not sure if that is part of the problem until I try running the command "perl mdlops.pl" first.

 

So I take it I need to download Perl first and set all that up, in order to use the "mdlops.pl" file with a command? Or can I just simply run that file with a .bat file or something? I did try directly clicking on the file in my windows explorer, under the mdlops folder directory I put all those files in, but all it did was open up the file and show me all the code that was written in plain English. Also, you mentioned that the mdlops.exe is a standalone file? I first thought that as well and tried that, but in my case, if you don't have those .pl and .pm files inside a folder along with the mdlops.exe file, it will just crash when you click on it without having those files along with it in the same folder. So I thought the mdlops.exe was dependent on those other files being there along with it, in order for the whole thing to work? 

[ndix UR 218]

That is interesting that the mdlops.pl and MDLOps.pm files seem to be necessary in the same directory as mdlops.exe. I am not sure how to explain that   ... I have not really experimented with that exe file. The only mdlops.exe I have used is the mdlops.exe that ships in the KotorTool package. It's an older version, maybe a 0.6 or 0.5. It definitely runs without any perl code available.

 

I just re-read all the docs that come w/ MDLOps and yeah, the document you are looking for is 'installing perl.txt'. It tells you how to install a windows-compatible version of perl (in this case, ActiveState's ActivePerl, which I used to use a long time ago also ...), and the dependencies that mdlops will need to run. Basically it covers what you need to do to get to the point where 'double-clicking mdlops.pl' will be a thing that actually works (runs the program, not just opens the code in a text editor).

 

I know that the mdlops.pl code uses Tk (also known as Tcl/Tk) for its interface, but this is not covered by the perl install documentation. There is a thing called ActiveTcl, also by ActiveState, which you might also need to install to get it working. It's been even longer since I have used Tcl/Tk and ActiveTcl, but I will provide any assistance I can...

 

As far as the blender and neverblender version stuff goes ... I can't really speak to that as I am basically a brand new blender user who's never used any other version.

 

OH. I just thought of something you might want to do before you go down this road of installing perl and whatnot. It is actually really easy to determine whether the fix will solve your problem or not. Here's what you can do to test a single model:  open in a text editor your ascii model file that you are about to compile; find the line that says "classification CHARACTER" (usually like 5 lines in or so) and change it to "classification Character". You can then compile it using mdlops.exe and it should be fixed when you try it in game. If you still have the shadow/camera issue, then there's no point in installing perl and all that other stuff anyway.

[Purifier 22]

Thanks for mentioning that last part, Ndix UR. I opened up the exported ASCII p_juhanibb.mdl in Notepad++ and changed "classification CHARACTER" to "classification Character" on the fifth or sixth line. Sure enough, that did the trick. The model had it's body shadow this time in the game and no more weird camera effects during combat interactions. I also did the same with my custom remade player models, pfbas through pfbal and tested them in the game, sure enough again, the body shadow show up for those as well. But there is a funny thing about those particular models, they never did display any weird camera effects during combat interactions before all this; just the missing body shadow. It may have something to do with how those particular models are written before running them through MDLops and how MDLops and NeverBlender processes them afterwards. Strange how just a simple correction of a word's letters to lower case makes that much difference between two different .mdl model types and one type of model doesn't even have the weird camera effects problem during combat interactions, yet that simple correction will fix the same one problem with both differently written .mdl model types and also fix the camera problem with the one differently written .mdl model type. Very interesting.

 

And yeah, I had already went ahead and downloaded both the ActivePerl-5.22.1.2201-MSWin32 and ActiveTcl8.6.4.1.299124-win32 last night, before I saw your re-edited post again. But I have not installed them yet, but will eventually, not only for the reasons concerning MDLops, but just to see what programming in Perl is like anyway. I've been trying my hand at programming as a novice for years with C++ and Python, so I figured Why not Perl too?. BTW, you wouldn't happen to know any good tutorials on starting out with Perl for a novice like me, would you? There are probably a bunch of tutorials on YouTube, but I just thought I might ask anyway.

 

I appreciate your replies to my posts on this issue, Ndix UR. You were very helpful. Thanks again for helping me find a way to get around the problem. 

[ndix UR 218]

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   . 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.

[DarthParametric 3,777]

Interesting. That camera issue sounds pretty much exactly like the problem I encountered (one of several anyway) with a custom astromech model. When combat was initiated, the camera would zoom into the middle of the mesh. Curiously, that model was compiled with KAurora, and was set as a character model (plus on Windows, so presumably no case issues).

[xander2077 80]

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.

[Purifier 22]

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   . 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.   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://neverwintervault.net/project/nwn1/other/tool/neverblender-blender-269-27x

[xander2077 80]

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.

[ndix UR 218]

@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  .

 

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.

[DarthParametric 3,777]

@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.

[xander2077 80]

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.

[DarthParametric 3,777]

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.

[xander2077 80]

@ 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.

[Kexikus 994]

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.

[DarthParametric 3,777]

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.

[Kexikus 994]

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.

[JCarter426 1,214]

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.

 

 

 

 

 

 

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...

 

 

 

 

 

 

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:

 

 

 

 

 

 

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.

 

 

 

 

 

 

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:

 

 

 

 

 

 

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

 

 

 

 

 

 

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.

[N-DReW25 1,320]

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.

 

 

 

 

 

 

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...

 

 

 

 

 

 

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:

 

 

 

 

 

 

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.

[JCarter426 1,214]

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.

[ndix UR 218]

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.

 

 

 

 

 

 

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...

 

 

 

 

 

 

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:

 

 

 

 

 

 

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.

 

 

 

 

 

 

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:

 

 

 

 

 

 

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

 

 

 

 

 

 

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.