ndix UR

Members
  • Content count

    162
  • Joined

  • Last visited

  • Days Won

    8

ndix UR last won the day on May 6

ndix UR had the most liked content!

Community Reputation

94 Jedi Grand Master

2 Followers

About ndix UR

  • Rank
    Jedi Knight

Profile Information

  • Gender
    Not Telling
  • Location
    ca, usa
  • Interests
    I like to code. Also animation, manga, puppetry, digital visual arts.

Recent Profile Visitors

4,319 profile views
  1. ndix UR

    MDLedit bug reporting thread

    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.
  2. ndix UR

    MDLedit bug reporting thread

    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. 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.
  3. ndix UR

    MDLedit bug reporting thread

    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. 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.
  4. ndix UR

    Module Transitions

    Can be found several places, here's one: https://github.com/kucik/nwn-docs Just have to remember that they are for Aurora (NWN), and Odyssey (KotOR) is slightly different. I am unaware of a source for updated documentation.
  5. ndix UR

    MDLedit bug reporting thread

    This was essentially the first thing implemented, because when we first started, I had to rule out all the various indexed color modes as necessary or helpful in order to show that 32-bit RGBA is the one true way I don't think it does normalization though, possibly just R/B inversion. Some old implementation detail memories there... Why the game would require a useless alpha channel on normal maps is a question for BW actually. I would love to know the answer though. As for the RGB/RGBA DXT1/5 thing ... I think I went the other direction. If you request DXT5 on an image with an all-white alpha channel, or missing alpha channel, you get DXT1 instead. I believe this was the choice based on people not really understanding the differences and probably erring towards "oh, DXT5, higher number, better". Actually, unless I'm missing something in the code, it looks like I talked myself down from helping people in that way. So yeah, if you DXT5 an RGB image, you just get a flat white alpha channel. I'd assume that frankencompile was mdlops 1.0.0? That one had some serious issues w/ orientations. Usual dot-zero release stuff... Yeah, the tangent space calculations are due for a closer look, certainly. We can finally do the comparison with the nwntools compiler's code (which I found after painstakingly figuring out the algorithm), to see if it had anything else figured out... I'd be interested in seeing whether the wrist highlight problem is affected by changing the hands and fingers to 'down' in the parlance of the infographic. I'm wondering if the issue has to do with something absolute or relative ... is it actual 'upness' that matters, or is it just that issues arise at the places where 'up' meet 'down' (this might indicate it's essentially the same problem we had w/ normal vectors, and we just need to reorient the tangent space basis according to 'world coordinates' before accumulating them).
  6. ndix UR

    Module Transitions

    The documentation for Aurora says that LinkedToFlags controls area transition, so is what you need possibly. 0 = links to nothing, 1 = links to another door, 2 = links to a Waypoint. LinkedTo is the Door or Waypoint in question (probably). For triggers, I think the area transition behavior is controlled by the 'Type' in the UTT file, and should be set to 1 for area transitions.
  7. Yeah, I mean, I do think it's the same poly, having now looked at the model in game for a bit. Changing the weight on vert 307 from 0.6 0.4 to 0.0 1.0 was successful in fixing the issue... I'm surprised that it's not easier to find that triangle, visually, distorted somewhere, as it should be connected at 308 & 309 still.
  8. @DarthParametric Looks like the usual weight mismatch to me. Torso vert lcollar_g 1.0 meeting larm vert lcollar_g 0.4 lbicep_g 0.6. Bigger mismatch than "usual".
  9. ndix UR

    MDLedit bug reporting thread

    Definitely a good thing to fix. I recently fixed that in kotorblender for the same reason. Although in Blender, it's easier to just import model 1, save it as a blend file, start new document, import model 2, and use the 'append' function to pull in specific nodes directly from the other blend file. That bypasses the text editor part. Before that I was using a text-based approach, similar to you, then a script that did it (but that was for merging specific nodes into a vanilla ascii model file before the compilers had skills).
  10. ndix UR

    [Question] NPCs vs Placeables

    NPCs won't have a PWK file. The PWK file lets you specifically locate where the 'use' points are. Like, if you have a chest that opens from the 'front', the two 'use' points will be in the front. If you have something without a direction, like a barrel, the use points are usually in 'front' and 'back'. There might be a way to combine an NPC 'placeable' with triggers to get a behavior that tracks closer to a normal placeable. I'm interested in this topic, but I haven't done any experiments yet.
  11. ndix UR

    Freedon Nadd's Tomb Statue WIP

    fx_ritual01.tpc is my enemy now. here you go: fx_ritual01.tga
  12. ndix UR

    MDLedit bug reporting thread

    @bead-v I believe your problem with the vanilla model is that you're not applying an orientation transform to the normals. The torso skin mesh has a super cool 180 degree Z orientation (quat(0, 0, 1, 1.27e6)), so, actually all those torso vertex normals you drew pointing away from the cape vertex normals, all "3" of those normals go in the same outward direction (and two of them match). If not complete slop/oversight it was probably done to workaround a bug in the vanilla toolset's smoothing. I suspect when you fix that (apply orientation translation to normal vectors), the patch-based normal construction is going to work out better. I don't fully comprehend why this would be necessary, other than, interestingly, apparently we need to be doing world coordinate vector comparisons in our smoothgroup computations where we've been doing something more like object space comparisons. When I opened the binary model straight into blender, it looked ... well ... like it does in-game. For the record, I wouldn't consider the smoothing on the vanilla pfbim model something worth emulating/holding up as an example. It's reaaaaal sloppy and horrible. The weights along the torso-robeback interface don't even match, such that you can see gapping in-game when you look from the right angle. Here's a screenshot of the vanilla model hilighting the garbage smoothing between torso and robeback (basically it's OK on the 5 rear seams, but kind of sucks on the side seams) @JCarter426 if you're tweaking this model, I'd definitely recommend applying the rotation on the torso skin mesh if that's not one of the for-some-reason-sensitive-for-skin-weights-in-3DS operations. If the model you posted in thread already has this done, sorry and nevermind! (I only looked at vanilla while debugging)
  13. ndix UR

    TOOL:KotORBlender

    OK, I've got these issues sorted. All kotorblender issues. Will be fixed in 1.0.2. One complete typo was making the particle effect on the sphere wrong (Motion instead of Motion_Blur in two places). The issue w/ the lines & symbols being visible came down to my setting of minimum values for alphaMid and lifeExp that didn't include the full range of possible values. I had them set to 0.0, but apparently -1.0 is the actual minimum value. Because there are 50+ emitter controllers, I think I probably relied on logic, rather than exhaustive cataloging, to establish some of the min/max values. And anyone who tries to apply logic to the functioning of the game engine gets bitten eventually... Here's the code patch:
  14. ndix UR

    TOOL:KotORBlender

    Cool, if you're interested in getting support, you need to be way, way more specific about what animations are changed and/or what particle effects on what meshes.
  15. ndix UR

    TOOL:KotORBlender

    Well, that would be after export. Also, in Blender, if you just parent plc_starmap_wg under the plc_starmap_pwk node, you should get the right result without having to make text edits after exporting from Blender. I think. Maybe.