Premium Member
  • Content count

  • Joined

  • Last visited

  • Days Won


bead-v last won the day on June 23

bead-v had the most liked content!

Community Reputation

168 Jedi Grand Master


About bead-v

  • Rank
    Evil Malachor Overlord

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. bead-v


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


    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.
  3. bead-v

    MDLedit bug reporting thread 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..
  4. bead-v

    MDLedit bug reporting thread

    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
  5. bead-v

    MDLedit bug reporting thread

    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?
  6. bead-v

    Module Transitions

    Oh right, doors... check that
  7. bead-v

    Module Transitions

    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.
  8. bead-v

    MDLedit bug reporting thread

    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.
  9. 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.
  10. bead-v

    Fight G0T0

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

    MDLedit bug reporting thread

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

    MDLedit bug reporting thread

  13. bead-v

    MDLedit bug reporting thread

    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.
  14. bead-v

    MDLedit bug reporting thread

    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.
  15. bead-v

    MDLedit bug reporting thread

    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.