hi all,
i’m wondering what the advantages/disadvantages are w/regard to compiled models vs. non-compiled models. is this an example of the time/space trade-off ? for example, i can suppose that non-compiled models may take up less space on-disk, but that they will also take more time to use/display in the engine when the game is run because [shooting in the dark here] the game may have to compile them or interpret them before it can display them ? or is that a complete miss ?
thanks
-x.
In theory there should be 0 reason to not compile the models when distributing them to others. Various CC creation tools only work on uncompiled models (max/blender scripts, CM3, etc), so your workflow will likely be entirely with uncompiled ones, and then when packaging them up for distribution, you’d compile them.
Uncompiled models are compiled by the game on the fly, which means very visible stutter when such a model comes into view - very noticeable with 1.69 horses which were left uncompiled.
Now, if you’re making models for EE and are using some of the new fancy tools, the external compilers (e.g. nwnmdlcomp) won’t know how to deal with them, and the in-game one might have bugs. So the general advice might not be strictly true right now, but bugs are getting fixed in the development versions.
Be cautious with nwnmdlcomp apparently. It doesn’t know about selfillumcolor and doesn’t compile it. That is the reason why I had to release all my glow in the dark stuff (TR’s Glows, Rainbow Rats V 2.0, etc.) with ASCII format models only. I only discovered this when I tried compiling them.
TR
@clippy What you said is probably true for the minority of builders who’ve mastered the modelling tools, but, for general builders, the finding over the years is that it normally makes no perceptible difference.
Indeed, arguably, uncompiled models are preferable, because unskilled builders can understand and tweak them with a text editor.
Of course, there are exceptions. Very high poly models do lag, and may even cause crashes, unless compiled - but I’ve only seen a handful of such cases.
That bug was fixed. You must have an older version. I have a nwnmdlcomp.exe from 2018 that works.
It does make a huge difference if creatures are compiled or not at least if high poly.
A link to the fixed version would be useful.
TR
I would have given a link, but I’m old and forgot where I found it.
hi zwerkules,
would you mind posting that to the vault? even if it’s just the .exe and nothing else, if it fixes some of these longstanding bugs i think it would be worth having.
thanks !
I have run at least 3 different threads on this subject in about a decade, and will share what we learned at different points. There IS a massive difference. When it comes to creatures, compiled models have an impact on dynamic spawning, which is directly related to the phenomenon known as “microstutter.” This is true of pretty much any videogame, and since NWN is such an old one, the effect is even more obvious. The highest the polygon count of a model (whether it be an entire creature or simply a PC body part), the longer said microstutter takes. Compiling models drastically reduces the freeze-framing whenever NPCs and creatures spawn or come into the player’s view. The downside to this is there are some popular, custom content creature and placeable models that don’t play well with compiling. The animations break. The other aspect that sees a dramatic difference is area loading. When using uncompiled tileset/placeable models, loading times increase. Depending on their hardware, some testers reported even around 10 minutes. My own tests were done with an SSD, and even then, the difference is fairly noticeable. While the experience may vary from player to player, the content used, etc, overall, compiled models significantly benefit performance.
These also tend to be the same creatures that don’t render in NWNExplorer. IIRC, @cervantes was a whiz at getting these things to render correctly - and thus compile.
Thanks for that plug GrumpyOldGoat but what I find as to why models don’t compile are small errors of data in the model which the NWN game doesn’t recognize and most of these fall in the danglymesh, skins, emitters and animations areas. The model fails to compile because it finds these errors when it trys to compile it then fails out.
@cervantes See, I knew you’d know. 
@GrumpyOldGoat some problems with Q models I have been playing with lately are the WIP Purple Worm there where some errors in the animation portion of that model. I have the animations working but they are very incomplete. The dwarf003 Dugear model had skin errors that I also fixed so that it now renders in explorer. These kinds of problems will keep the model from compiling.
Yeah, I’m all done with Q.
regarding the selfillumcolor/setfillumcolor bug in nwnmdlcomp, it seems that this is on line 123 of the file NmcController.cpp, available [for example] here. if this is the only problem, it should be fixable easily enough. i could compile this with the change and upload it to the vault – would that be useful, or is there more to the problem ? also, could there be a more recent version available somewhere ?
IIRC, the self/set bug was in NWMax and MDA fixed it in NWMax/GMax Plus. I don’t know if it was ever fixed in the regular NWMax 0.8c that Bannor uploaded to the Vault. Being that you isolated it to a line in NmcController, I’d wager the version of nwnmdlcomp packaged with Plus is all set.
Virusman also has an alpha EE of nwnmdlcomp available via dropbox - sorry don’t have the link.
hmm… dunno. are you referring to nwgmax_plus_v6_11_30.7z from here ? if so, i can’t speak to whether the nwnmdlcomp included w/it no longer has this bug, but i can verify it as far as this :
$ strings nwnmdlcomp.exe | grep illumcolor
setfillumcolor
unfortunately there’s no revision text in the exe and firing it up just tells me it was made in 2003, but since there’s no ‘selfillumcolor’ and there is a ‘setfillumcolor’, i think i’d rather assume the bug hasn’t been fixed. not being a modeler, i don’t really have a way to prove that though… ;p
is there a model someplace i can compile with this tool that has demonstrated this ‘broken’ behaviour in the past ? what would i look for to show the model is broken – does it sort of grow wings where they shouldn’t be or something, or would the model just not instance in-game ?
It would mean that self illumination which is mostly used for windows at night in some tilesets won’t work. In the older tilesets it will work because they use textures of lit and unlit windows instead of self illumination.
I’m not sure where I got the working version of nwnmdcomp.exe, but it may be I got it from Ossian and I’m not sure if it was experimental and if I am allowed to upload it.
What @Zwerkules said.
I know when MDA started work on NWMax/GMax Plus, he was in touch with OMB and I vaguely remember some conversation about the spelling issue. Nor can I recall an instance where either version changed the spelling as it used to in older versions of the tool. Maybe that block of code you’re greping - is that a word? - is part of a comment?