bead-v

That's the LipSynchEditor, yeah. But where are you gonna get the .phn file from? Of course, you could enter the data manually, but that's not what the folks above are talking about.

So .... ... it's not happening.

I'm interested in this as well... so this is not the CSLU thing?

Any mesh may use bitmap2 as a lightmap, but I don't know what happens if you try to do it on a placeable or door or the like... But anyway, from the point of view of the format, being an area model is not a prerequisite for being lightmappable. Hell, there's isn't even a proper Classification number for area models.

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? I was told (by you) that it doesn't work... so it does sometimes work?

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

So, after selecting a .2da to open, I get this and nothing happens anymore (at least not after 10mins): Running on Win10 64bit.

VP was kind enough to make the new forum for us, thanks again @VarsityPuppet! Though it would be nice if we got some news as to where the other site updates are at.

So, it seems it still works. Up to @DarthVarkor to determine if it's easy enough to use, though

Finish finish, no, but it was in a state where you could get something done with it. I wanted to fix it up because I could make the GUI more smooth now and I could also directly export the animated camera model without having to go through anicam, but I was left under the impression it wasn't worth it, because you can also do it with kotormax nowadays. So if you think you could do it in kotormax, I'd suggest that. Otherwise, I can send you a copy.

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

I'm already doing that in the latest beta version of mdledit. I do it in paralel with the vertex normals, so I basically take the world coordinates for the verts instead of the object coordinates and do the whole calculation and then at the end rotate the vector to where it needs to be in object space. I checked a few models and it seemed to get them right, but it could be that I only checked models that don't have any weird stuff going on... so maybe that's not the right way to do it. So yeah, need to find the time to look at the algorithm and compare with the one in NWNTools... You never wait for us to fix the tools

Thanks So, it's likely that this is connected to the tangent space calculation. That calculation also uses smoothing groups to determine which faces to include in the calculation of a particular tangent space. Also, regular smoothing (normal vectors) doesn't care about UVs. They are however used in the tangent space calculation. So again, very likely that that is the cause. It also explains why the issue went away when you removed the bump map. Have you tried compiling with MDLOps? Unless ndix UR has done some changes to the algorithm, it should produce the same result, because the tangent space calculation was a copy paste of ndix UR's algorithm after he figured it out in the bumpmapping research thread (we should still check though). Because it was just a copy paste, I never went very deep into why it is the way it is. I can try to get into it when I find the time, and maybe I can find some way to account for this situation. I can't know for sure, but it feels like this issue should be solvable with an updated algorithm. @ndix UR, what do you think?

Oh right, doors... check that

In the .git file look at the triggers, some will have a different structure with some extra parameters, it will be obvious they're transitions. They're usually linked to waypoints in the other module via the tag IIRC, so make sure you set that up as well.

Aaaaaah, mdledit needs a warning in this case. It simply takes the model as it is with its supernode numbers, compiles it for the other game instead and completely disregards that the supernode numbers might be different. Thanks for reporting this, @Red Hessian, I'll add a warning to the next version of mdledit.

You need either MDLedit or MDLOps. With either, decompile the relevant models to ascii, then edit the ascii. Find all the nodes that make use of the texture you want to add bumpmapping for and add "tangentspace 1" anywhere in the node's parameters. Alternatively, you can tick the checkbox for the texture directly in mdledit, like DP said. One thing to note here is that if you're using the released version, you have to convert to ascii, then load that ascii and only then tick. Ticking the box when loading a binary model only works in the latest beta.

It definitely was part of MVI, but I don't think there was any separate mod. (RIP)

Is that a bug report or just user error that amused you? (fingers crossed) No biggie, I'm just glad it works!

Hallelujah!

This is intended to be the last beta, if everything checks out I'm uploading it as mdledit v1.1.0. This version has a completely redone vertex normal and tangent space vector calculation algorithm, which also affects smoothing group calculations. Generally, mdledit will calculate the intra-mesh normals correctly, it will calculate those inter-mesh normals where only two vertices overlap correctly, but where more vertices overlap, it's more likely to fail. I can't spend more time on figuring out how to calculate those right now, but there will probably be improvements in the future, just like this was an improvement now. When compiling models there should be no issues however, inter-mesh smoothing really does work now. Some crash issues are also fixed, one that I found myself and one that DP encountered with the K1 endgame area models. mdledit_v1.0.9b.zip mdledit_v1.0.9b_xp.zip

It shouldn't be case sensitive, but apparently I never implemented that globally for kmax. It's on the to-do list. This was also the cause of the issue with the .lyt import DP reported.

Yeah, it's planned for mdledit after we finish the new vertex normal implementation. There are actually quite a few new features at this point. As for kmax, that'll take a little longer, there are some new functionalities I (may) want to implement, but that'll be after I'm done with mdledit.

Sorry bout that! kotormax_fix_20180718.zip

Kotormax exports all verts and UVs, regardless of whether they're "stray". Mdledit cleans this up and ignores the stray ones. It's just that this time the index in the ascii was so high, the numbers turned negative in mdledit so it couldn't fetch the right UV from the array. It tried to fetch the -2888sth-th element in the array, which crashed the program. If your code is written better, this won't happen, which is why it worked in mdlops. Nothing to do with the game, really. But it was a simple fix.