MDLedit bug reporting thread

[ndix UR 218]

1 hour ago, JCarter426 said:

Ah, so it actually doesn't make a difference if I save the height map on the alpha channel. Or are you saying it generates a solid white channel only if there isn't an alpha channel already?

It generates a solid white channel only if there isn't an alpha channel given in the input image. On the plus side, I've tested stuffing unrelated things into the alpha channel of normal maps and the game doesn't seem to care. I put ambient occlusion in there sometimes... so you should be fine storing your height maps in there.

1 hour ago, JCarter426 said:

Yeah, 1.0.0. That's the most recent version on the site?

So it is...

If I am reading the issue correctly, the wrist issue should be present on the default p_handmaidenba.mdl file when adding tangent space & normal map? Just in terms of being able to easily replicate the issue for debugging.

@bead-v interesting. I haven't done any world translation for the tangent space basis yet (IIRC). I don't actually expect this issue to be quite so directly similar. I'm thinking you need to do something more like rotating the UV map coordinates (per-island?) to match the coordinate system of the world in order for all tangent space bases to be compatible (whereas, right now, they are all mesh/UV island relative, so don't smooth together properly). How that works mathematically isn't something I know off the top of my head, that's just an initial idea.

[JCarter426 1,220]

34 minutes ago, ndix UR said:

It generates a solid white channel only if there isn't an alpha channel given in the input image. On the plus side, I've tested stuffing unrelated things into the alpha channel of normal maps and the game doesn't seem to care. I put ambient occlusion in there sometimes... so you should be fine storing your height maps in there.

Ah, ok. I did some testing and it didn't seem to make a difference whether the height map was there or whether it was all white. It really didn't like having an inverted height map on the alpha channel, however. Did some weird things to it.

36 minutes ago, ndix UR said:

If I am reading the issue correctly, the wrist issue should be present on the default p_handmaidenba.mdl file when adding tangent space & normal map? Just in terms of being able to easily replicate the issue for debugging.

It should be, yes. And only when using a normal map. It's not an issue with the regular smoothing.

[DarthParametric 3,795]

6 hours ago, ndix UR said:

I've tested stuffing unrelated things into the alpha channel of normal maps and the game doesn't seem to care.

So you're saying it doesn't ever make use of an alpha mask for transparency, even though there's at least one vanilla normal map with an alpha mask? Although the map in question appears to be unused in the actual game, at least judging by the TXI semantics of its parent diffuse.

[ndix UR 218]

5 hours ago, JCarter426 said:

Ah, ok. I did some testing and it didn't seem to make a difference whether the height map was there or whether it was all white. It really didn't like having an inverted height map on the alpha channel, however. Did some weird things to it.

Interesting... well... maybe I'm wrong. That's always an option. Often a good one. It's possible that the tests I ran were the wrong ones.

42 minutes ago, DarthParametric said:

So you're saying it doesn't ever make use of an alpha mask for transparency, even though there's at least one vanilla normal map with an alpha mask? Although the map in question appears to be unused in the actual game, at least judging by the TXI semantics of its parent diffuse.

There's at least one vanilla normal map w/ a non-white alpha channel? This is the first I am hearing of such a phenomenon. If the game actually uses the alpha channel on a normal map for ... reasons, that would definitely be interesting news.

[DarthParametric 3,795]

Well it appears to be a greyscale bumpmap - albeit an odd one - rather than a tangent space map, but it converts to RGBA with a transparency mask in the alpha. But neither the diffuse nor bump have any TXI data that I can see. It was pointed out to me by @Salk in this thread. I believe I did mention it to you in a PM at some point.

LKA_leaf01.7z

[JCarter426 1,220]

37 minutes ago, ndix UR said:

Interesting... well... maybe I'm wrong. That's always an option. Often a good one. It's possible that the tests I ran were the wrong ones. 

Here were my results:

Spoiler

And I've attached the most up to date files for anyone who wants to take a look. I believe all the problems (apart from the weird inverted alpha option) have been sorted on this one.

Hand_Normal_Testing_v31.zip

[bead-v 251]

https://github.com/DrMcCoy/NWNTools/blob/master/_NmcLib/NmcMesh.cpp

NmcGenerateBumpmapData()

Took me a second to find it

It seems to be tracking some Mirror boolean, could be what we need? I'll have to make the real dive into it another time though, way too tired right now..

[ndix UR 218]

50 minutes ago, bead-v said:

https://github.com/DrMcCoy/NWNTools/blob/master/_NmcLib/NmcMesh.cpp

NmcGenerateBumpmapData()

Took me a second to find it

It seems to be tracking some Mirror boolean, could be what we need? I'll have to make the real dive into it another time though, way too tired right now..

Spent a fair bit of time looking at that today too I think the mirror boolean is just how it tracks the UV faces whose normal vector Z components go "down" or "into" the texture image. It definitely seems to use a simpler algorithm in general, which may or may not be accurate for our needs. I'm currently trying to make sure that the algorithm we use actually chooses a consistent tangent vector in the first place. Since there are numerous vectors that are tangent to the surface, and it's just a convention to choose one along an axis defined by the UV's.

[xtprojects 13]

Nice work Beadv! I just tried to load the capeless revan model and it still crashes. Were you able to take a look at it yet? Sorry to keep pestering you, just hoping this gets fixed so i can test out more stuff on the xbox side. :)

 

[JCarter426 1,220]

I got more oddities to report, another one that I don't think necessarily needs fixing but I figure this is the best place to bring it to everybody's attention, and one I suspect might be a similar case.

Both these problems show up on the model 204telc for anyone who wants to investigate.

The first issue - the one I know how to fix - is that the windows become invisible. I believe this is related to either KOTORMax's lightmap export script or how MDLEdit deals with them. The gist is that the window meshes are not lightmapped, and any part of an area model compiled without a lightmap or self illumination becomes completely black. Because the TXI uses the additive blending mode, black = transparent, so you get invisible windows. So any area that has transparent meshes might need double-checking.

The second issue is that all objects using the Animate UV setting - the fountains, the sign to the Ithorian compound - are not actually animating. I didn't touch them at all, apart from linking them to my new Odyssey base. And I thought the workings of animated UVs had been known for a long time, so I'm a little perplexed. But as I said, I suspect it might be a similar eccentricity that the tools don't account for out of the box, but could still be fixed. Has anybody worked with them before?

Edit: Never mind on #2. I recalled a vague memory of somebody saying something about some situation with meshes that can't be linked directly to the base. Linking meshes with animated UVs to a dummy that's linked to the base works, and that's probably how it was on the original and I just didn't notice. So I can reconfirm that condition applies here, though I don't understand why.

[DarthParametric 3,795]

There's something weird with the animations for vanilla K1 models for hologram Dodonna and Vandar. MDLEdit will crash on loading the ASCIIs with animations, either vanilla or passed through KOTORMax. It has no problems with an ASCII that has been stripped of the animations.

@ndix UR: MDLOps will successfully compile a vanilla ASCII and it will work in-game. It will also compile an ASCII passed through KMax with no errors, but in-game it will be stuck in the t-pose (i.e. no anims presumably). Interestingly, I can edit the vanilla ASCII and have MDLOps compile a working model, although so far I have only tried editing existing values and adding additional keyframes.

K1_Holo_Vandar_Dodonna.7z

The additional problem I am having - and I am unsure if this is a problem with these particular models, or something more general - is that the game is not respecting my mesh alpha animation values properly. For example, when Vandar first appears, part of the animation fades him in, so all the skins/trimeshes have an alphakey animation going from 0 to 1. Since I wanted to swap from texture blending to mesh alpha for the hologram effect, I changed all the alphakey values so that the upper value was 0.5 instead of 1. However Vandar still fades in to, and stays at, fully opaque (so I assume alpha 1). Any idea what is going on here?

Edit: I managed to get my custom Dodonna model working properly when I use an edited copy of the original (with added dummies for my new meshes to add alphakey animations) as a supermodel. I'm doing exactly the same thing for Vandar, but he doesn't properly use the alphakey values, as stated above.

K1_Custom_Holo_Vandar.7z

 

On 8/14/2018 at 5:00 PM, JCarter426 said:

I recalled a vague memory of somebody saying something about some situation with meshes that can't be linked directly to the base

For area models, yes. It may also apply to placeables, I can't remember. For area models, strictly speaking it is supposed to use the OdysseyBase name with an "a" appended I believe. I know @ndix UR and/or @bead-v provided a breakdown of the specifics somewhere, but possibly it was in a PM. Sure would be good if we had that wiki about now to document this sort of thing.....

 

[JCarter426 1,220]

5 hours ago, DarthParametric said:

I managed to get my custom Dodonna model working properly when I use an edited copy of the original (with added dummies for my new meshes to add alphakey animations) as a supermodel.

This is exactly what I had to do for G0-T0 to get around the mysterious crashes caused by editing his texture of all things. This was years and years before MDLEdit, though I recently looked at it again and noticed MDLEdit crashes on loading his model as well unless animations are stripped - again, exactly as you described.

As I remember it, I had to resort to a supermodel because back in those days MDLOps couldn't properly decompile models with animated meshes (droids, doors, some placeables) and while the new tools definitely can for lots of models, I'm guessing they might still have some hangups on a few.

I'm surprised you need animations on the hologram models at all, though. I had thought they used stunt models for their animations.

[DarthParametric 3,795]

Look at the Misc TOR Ports WIP thread. K1 uses a texture-based approach for the hologram effect. I am swapping that to mesh alpha instead, but that requires animating the alpha value because they fade the models in and out, and they also had to hide eyeballs in certain shots because of the whole bug-eyed thing (plus they cheat with Vandar's eye blink, swapping between two sets of eye meshes with different textures rather than using physically animated eyelids).

[JCarter426 1,220]

That's just what you're adding though, right? Though judging by what you say, I guess maybe there would've been stuff going on with the transparency on the original anyway. It's just such a roundabout way of doing it... why would they do that?

[DarthParametric 3,795]

This Dodonna hologram is driving me mental. It works fine in the DS custcene, but for some reason, even after adding custom keyframes to all fifty freaking animations, in the LS cutscene her torso still momentarily goes to an alpha of 1 before reverting in the next shot to 0.5 as intended. I cannot work out how this is happening.

I think I have identified the specific animation being called during that line of dialogue, but the way it works is weird. The DLG references animation 1251, but the animations on the model are named CUT001W etc. It looks like the LS cutscene animations start at CUT051W (the previous one being CUT025W), but it seems that CUT052W must be the one being used for that line. So it seems like 12XY = CUT0(XY+1)W. Anyway the relevant portion is:

newanim CUT052W S_HoloDodonna
  length 4.0
  transtime 0.0
      node dummy TOR_Chest
      parent S_HoloDodonna
      alphakey
        0.0 0.0
        0.666667 0.5
        4.0 0.5
      endlist
    endnode

All the alphakeys for that animation lacked the additional keyframe at 4 seconds, so I added that just in case, to no effect. Interestingly, when looking at the 60fps video the first frame of her reveal the chest mesh is completely gone (presumably alpha 0) while all the other meshes are visible:

Edit: I just noticed the upper arms are also both missing in that single frame, and turning to a solid alpha 1.0 in that shot. So three meshes are affected, the rest not.

[JCarter426 1,220]

22 minutes ago, DarthParametric said:

I think I have identified the specific animation being called during that line of dialogue, but the way it works is weird. The DLG references animation 1251, but the animations on the model are named CUT001W etc. It looks like the LS cutscene animations start at CUT051W (the previous one being CUT025W), but it seems that CUT052W must be the one being used for that line. So it seems like 12XY = CUT0(XY+1)W.

This is another thing where a wiki would've come in handy. Yeah, all the cutscene animations - those on stunt models, as well as animated cameras - are numbered starting at 1200, while the names begin with CUT001W because at some point in development somebody forgot that in programming you always start with 0.

As for the transparency issue... I only have two flimsy guesses.

The first is that since you said you're using the original model as a supermodel, maybe it's interfering... if that's the case, perhaps removing the offending animations from that might stop it interfering.

The second I think you already know but it wouldn't hurt to double check - make sure that on the frame before and after each animation, there's a key to reset it to the values at frame 0. Also, messing with what the frame 0 value is might help in this case - if it's at 1.0 at the start and end, perhaps changing it to 0.0 or 0.5 might get it to behave.

[DarthParametric 3,795]

The in-game model has no animations of its own. All of them are being pulled from the supermodel (which is a modified version of the original model).

This is all being done via directly editing the ASCII in a text editor, since neither MDLEdit nor MDLOps will compile a version exported from KMax. And because I am using dummies in the supermodel rather than meshes (due to ease of editing), KMax wouldn't be able to handle it anyway (it has no provision for trimesh values like alpha for a dummy).

[JCarter426 1,220]

Oh, ack... roundabout solution to roundabout problem, should've figured. If that's the case, I believe you can still edit the initial alpha value on their individual mesh nodes.

[DarthParametric 3,795]

The torso and arm meshes in the supermodel use completely different names, had their trimesh alpha values set to 0.5, had their render flags set to 0, and had all their alphakey nodes removed. I don't think the cause can be pinned on them. The problem for me is, is this something I am doing/not doing, some sort of bug, or just the game being a dick.

Edit: Maybe it is the game being a dick. I edited the DLG and pointed that line of the LS cutscene to the (different) animation used in the equivalent line of the DS cutscene. Despite there being no problems in the DS cutscene, that animation in the LS cutscene also suffered the same torso and arms going full opaque issue.

Edit 2: And I also tried switching the (off-screen) animation used in the previous line to the DS scene equivalent. Again, still does it. I don't know what the hell is going on.

Edit 3: OK, I solved the LS Dodonna problem, but uncovered some weirdness in the process. The previous animation switch I tried still had a fade in from alpha 0.0 to alpha 0.5 (even though by the time the camera actually switches to Dodonna she is already fully visible). This time I switched to an animation where she was already fully visible and the problem went away. So I tried an experiment with Vandar to see what would happen. I switched his reveal animation from the original with a fade in to one where he was visible the whole time. For some reason, everything except his eyes was completely invisible. And not just for the duration of that animation. His body remained invisible for the rest of the cutscene (which is comprised of a further 8 separate animations). The eyes in this case had animations switching between visible and invisible, because of the aforementioned blinking trick where it swaps visibility between two different sets of eyeball meshes. This is really doing my head in.

Edit 4: Oh FFS. I found the problem, and I should have realised sooner. The DLG references stunt models for the animations. In this case, it's the unique hologram models for both Dodonna and Vandar. But for some reason it seems the game reads animations from both the stunt model and the scene model, and in this case even the scene model's supermodel. So I see now why I could never get Vandar to go transparent. My model was using the same mesh names, so clearly it was pulling the 1.0 alphakeys from the stunt model. The stunt model field for Dodonna is blank in the DS cutscene DLG, which is why she worked without a hitch in that one. I guess this is what happens when you try to get fancy and use custom names. Although to be fair to myself, I only really did that because of the MDLEdit crash issue. So, really, it's all @bead-v's fault.

 

[bead-v 251]

On 8/16/2018 at 2:58 PM, DarthParametric said:

Edit 4: Oh FFS. I found the problem, and I should have realised sooner. The DLG references stunt models for the animations. In this case, it's the unique hologram models for both Dodonna and Vandar. But for some reason it seems the game reads animations from both the stunt model and the scene model, and in this case even the scene model's supermodel. So I see now why I could never get Vandar to go transparent. My model was using the same mesh names, so clearly it was pulling the 1.0 alphakeys from the stunt model. The stunt model field for Dodonna is blank in the DS cutscene DLG, which is why she worked without a hitch in that one.

Wait, so it's gonna play two animations on the same model at the same time? Or did it simply play the stunt model animation instead of the character model's animation?

 

On 8/16/2018 at 2:58 PM, DarthParametric said:

So, really, it's all @bead-v's fault. 

I take the blame!

Also, considering the latest mdledit beta release is crap, do you guys wanna see a new beta or are you fine with 1.0.5 for now?

[JCarter426 1,220]

I was about to report but you beat me to it. 1.0.5 will load c_holododonna, so the crashes must be related to the recent update that broke animations.

On 8/16/2018 at 8:58 AM, DarthParametric said:

But for some reason it seems the game reads animations from both the stunt model and the scene model, and in this case even the scene model's supermodel. So I see now why I could never get Vandar to go transparent. My model was using the same mesh names, so clearly it was pulling the 1.0 alphakeys from the stunt model.

That's why I was scratching my head before about how roundabout it is. It seems the stunt model is used for the character animations as well putting it into position onto the holoprojector as is usual with cutscene animations... but animations are also used on the character models, for things like Vandar fading in. That must be a mess to navigate.

[DarthParametric 3,795]

10 minutes ago, bead-v said:

Wait, so it's gonna play two animations on the same model at the same time? Or did it simply play the stunt model animation instead of the character model's animation?

I really don't know. The appearance.2da value was changed to my custom model, which used a custom supermodel. The DLG pointed to the original model as the stunt model. I would have thought that the stunt model would override  any animations of the same name, but clearly it was reading my custom keyframes on my custom supermodel for new meshes in the Dodonna model that don't exist in the vanilla model. The Vandar model had all the same mesh names, so maybe that was why it wouldn't accept my changes. Although Dodonna did have a couple of residual meshes that retained the same names as the originals, namely the face, hair, and eyeballs.

 

By the way, both hologram Vandar and stunt Revan both have more than 16 bones on a mesh. MDLEdit did manage to compile functional versions as far as that was concerned, so maybe my previous issues were unrelated, or maybe there is something specific about head meshes and "too many" bones.

[bead-v 251]

1 minute ago, DarthParametric said:

I really don't know. The appearance.2da value was changed to my custom model, which used a custom supermodel. The DLG pointed to the original model as the stunt model. I would have thought that the stunt model would override  any animations of the same name, but clearly it was reading my custom keyframes on my custom supermodel for new meshes in the Dodonna model that don't exist in the vanilla model.

So I would be right in saying that it went looking per mesh first into the stunt model and using that if it found any, then into the character model?

 

3 minutes ago, DarthParametric said:

MDLEdit did manage to compile functional versions

I was told (by you) that it doesn't work... so it does sometimes work?

[JCarter426 1,220]

I suspect cutscene animations only override animations on objects that are animated on the cutscene model, while anything else uses the animation on the character model (or the whole supermodel chain) - much as an overlay animation works. Like how the blaster deflection animations only affect the arms but everything else keeps doing whatever else it was doing at the time.

So the if the stunt model only affects the cutscene dummy and bones, then it's still getting animations for the mesh transparency directly from the meshes on your model. It could be the game actually can't get that sort of thing from a cutscene model or supermodel... that would be my guess for why they went to the trouble of setting it up that way, anyway.

[DarthParametric 3,795]

7 minutes ago, bead-v said:

I was told (by you) that it doesn't work... so it does sometimes work?

Like I said, maybe there is something about head models it doesn't like, as it was a head model with 16+ bones that I had issues with previously. Vandar is a full body model and the stunt Revan is just the body. I'll test it further when I get a chance.

5 minutes ago, JCarter426 said:

then it's still getting animations for the mesh transparency directly from the meshes on your model.

Not just animations, but keyframes for the same animations. I wasn't aware it went to that level.