ndix UR

Members
  • Content Count

    174
  • Joined

  • Last visited

  • Days Won

    11

ndix UR last won the day on January 31

ndix UR had the most liked content!

Community Reputation

146 Jedi Grand Master

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

6,385 profile views
  1. I've sent you a Personal Message. 

    1. DarthParametric

      DarthParametric

      An attempt at provoking a reply by public shaming?

    2. Sam Fisher

      Sam Fisher

      I  sent him a message at the beginning of march/near enough and it's unread, so I wondered if perhaps he hit "Mark all as read" and simply didn't see my message. Truth is I don't know, so I'm just reminding him/her. But it's really no rush. 

  2. ndix UR

    tpcview

    I've changed the installer to include destination selection (and make 'run after install' optional, because that was awful too). The installer exists to manage the file association thing (default viewer of TPC files), so it will be the right choice for most users. I've added a separate loose install 7z now, for the more particular users.
  3. View File tpcview View and export Odyssey Engine proprietary texture formats. A lightweight, somewhat quick viewer for textures in TPC format, or the proprietary header DDS format used in Aurora and its descendants. Also provides a capability to export to TGA, which is useful when you find images that won't convert via any other tool. The viewer aspect is a bit of an afterthought, as for the longest time this was just where I tested my TPC=>TGA conversion code. However, over time, I found myself wanting a simple viewer that could preview a lot of images at once, so this happened. The application is cross-platform, available for macOS and Windows. The app is written in javascript, built on Electron using three.js. ============================================================ How do I set it up? Windows: Download the '-installer' file, unzip the 7z package, run tgaview Setup <version>.exe Mac: unzip the package, move tpcview.app to /Applications, run it * This is not a signed application, so you have to do whatever is required to run non-MAS applications on your MacOS version. The application provides file associations for TPC & DDS files. Hopefully the DDS association will not override any you may already have for non-proprietary DDS files. ============================================================ How do I use it? Viewing Drag files in. They should show up. The files you drag in fill the window in a list that generally resembles the file input order. They all show at once, so there's a moderate memory requirement around loading many files at once. For example, loading the 5210 TPC files from TSL takes 2.25G memory on my machine, your mileage will vary. Mouse over images to get info about them in the window's title bar. Click images to toggle scaling the image to fit the window and viewing the information about them in the info panel at the bottom of the window. Double click the background of the window to clear all loaded images. Exporting Use modifier keys while dragging in order to get Export as TGA functionality. A description of the export activity you are requesting shows up in the info panel at the bottom while you are dragging. Export will occur while the file is being loaded. You cannot export already open images without dragging them in again. Files are exported into same directory as original TPC files being dragged, THEY WILL OVERWRITE EXISTING TGA FILES WITHOUT WARNING. When a TPC file is exported to TGA, a TXI file will also be generated if the original TPC file contained such information. When adding alpha blending value to TXI output, only non-1.0 values will be added (as 1.0 is considered default). ============================================================ Features View TPC format 32bpp, 24bpp, and 8bpp compressed and uncompressed images View Aurora proprietary DDS format 32bpp and 24bpp compressed images Export to TGA Export TXI files containing the texture extension information from TPC files Export all detail levels (mipmaps) present in original image file (can help debugging image compressors) Add an alpha blending value from the TPC header into exported TXI file outputs, i.e. '# alphablending 0.67' File association for TPC and DDS formats with provided file type icons Submitter ndix UR Submitted 01/30/2020 Category Modding Tools  
  4. ndix UR

    tpcview

    Version 1.0.0

    131 downloads

    View and export Odyssey Engine proprietary texture formats. A lightweight, somewhat quick viewer for textures in TPC format, or the proprietary header DDS format used in Aurora and its descendants. Also provides a capability to export to TGA, which is useful when you find images that won't convert via any other tool. The viewer aspect is a bit of an afterthought, as for the longest time this was just where I tested my TPC=>TGA conversion code. However, over time, I found myself wanting a simple viewer that could preview a lot of images at once, so this happened. The application is cross-platform, available for macOS and Windows. The app is written in javascript, built on Electron using three.js. ============================================================ How do I set it up? Windows: Download the '-installer' file, unzip the 7z package, run tgaview Setup <version>.exe Mac: unzip the package, move tpcview.app to /Applications, run it * This is not a signed application, so you have to do whatever is required to run non-MAS applications on your MacOS version. The application provides file associations for TPC & DDS files. Hopefully the DDS association will not override any you may already have for non-proprietary DDS files. ============================================================ How do I use it? Viewing Drag files in. They should show up. The files you drag in fill the window in a list that generally resembles the file input order. They all show at once, so there's a moderate memory requirement around loading many files at once. For example, loading the 5210 TPC files from TSL takes 2.25G memory on my machine, your mileage will vary. Mouse over images to get info about them in the window's title bar. Click images to toggle scaling the image to fit the window and viewing the information about them in the info panel at the bottom of the window. Double click the background of the window to clear all loaded images. Exporting Use modifier keys while dragging in order to get Export as TGA functionality. A description of the export activity you are requesting shows up in the info panel at the bottom while you are dragging. Export will occur while the file is being loaded. You cannot export already open images without dragging them in again. Files are exported into same directory as original TPC files being dragged, THEY WILL OVERWRITE EXISTING TGA FILES WITHOUT WARNING. When a TPC file is exported to TGA, a TXI file will also be generated if the original TPC file contained such information. When adding alpha blending value to TXI output, only non-1.0 values will be added (as 1.0 is considered default). ============================================================ Features View TPC format 32bpp, 24bpp, and 8bpp compressed and uncompressed images View Aurora proprietary DDS format 32bpp and 24bpp compressed images Export to TGA Export TXI files containing the texture extension information from TPC files Export all detail levels (mipmaps) present in original image file (can help debugging image compressors) Add an alpha blending value from the TPC header into exported TXI file outputs, i.e. '# alphablending 0.67' File association for TPC and DDS formats with provided file type icons
  5. View File HD BoS:SR Portraits HD Brotherhood of Shadow: Solomon's Revenge (BoS:SR) Portraits for Knights of the Old Republic v1.0 - 20200119 by ndix UR (DeadlyStream user) This modification adds high resolution (1K) portrait images for the characters in the Brotherhood of Shadow: Solomon's Revenge modification. The portraits are rendered to match the poses, colors, and lighting of the original images as closely as possible given the following constraints: Only vanilla textures (and my own additional maps based on same) are used Because the playable characters can constitute a spoiler for the BoS:SR mod, I've put the list of characters and a combined preview image in the following Spoiler: Thanks to Silveredge9 for the blanket approval to use assets from his mods, without which I could not have released this package. If you are not using Silveredge9's Brotherhood of Shadow: Solomon's Revenge modification, this modification will not change your game in any way. You should though, because it's really rather good. INSTALL / UNINSTALL To install, copy the TPC files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. LEGAL THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no expressed or implied warranty; you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required. Submitter ndix UR Submitted 01/19/2020 Category Skins K1R Compatible Yes
  6. Version 1.0

    151 downloads

    HD Brotherhood of Shadow: Solomon's Revenge (BoS:SR) Portraits for Knights of the Old Republic v1.0 - 20200119 by ndix UR (DeadlyStream user) This modification adds high resolution (1K) portrait images for the characters in the Brotherhood of Shadow: Solomon's Revenge modification. The portraits are rendered to match the poses, colors, and lighting of the original images as closely as possible given the following constraints: Only vanilla textures (and my own additional maps based on same) are used Because the playable characters can constitute a spoiler for the BoS:SR mod, I've put the list of characters and a combined preview image in the following Spoiler: Thanks to Silveredge9 for the blanket approval to use assets from his mods, without which I could not have released this package. If you are not using Silveredge9's Brotherhood of Shadow: Solomon's Revenge modification, this modification will not change your game in any way. You should though, because it's really rather good. INSTALL / UNINSTALL To install, copy the TPC files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. LEGAL THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no expressed or implied warranty; you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required.
  7. ndix UR

    HD PC Portraits

    That's what I thought when I started, however, when I got in there, what I found is that that doesn't seem to be a thing in the K1 portraits. It's basically just lighting and skin changes. The transition 'facial expression' changes, such as they are, are actually from the Dark-side version of the textures having different contouring and eyebrows painted on (especially in the female portraits). It's incredibly awkward in some cases, because the vanilla skins between extreme Light and extreme Dark were just layered on top of each other and blended at 25%, 50%, 75%. It caused some bad results for some of the faces, including my favorite one, PFHB02, where they got the eye position wrong in the extreme DS version of the texture, so during the transition the iris kind of drifts off, and in the 50% blended version, the person has two iris/corneas next to each other. That was something I had to fix. PFHC01 had the same deal. That said, early on, a few portraits looked like they had different facial expressions that weren't painted on, and for those I did 3 different pose levels across the 5 portraits. At this point, I don't believe they actually did have any expression changes, but at the time I did. I mean, look at PMHB2--they left him smiling (not even creepily) in his extreme DS portrait, if they were going to change any expressions, that would have been a good candidate... I felt pretty weird leaving it that way, but... vanilla is what it is. I did lighting changes on many but not all of the transitions, probably not as many as would have warranted them. 150 different renders already took a pretty huge amount of work so I did have to phone it in on some level. The TSL PC portraits seem to have clear and obvious facial expression changes with little/no lighting changes. I haven't started that project though so I can't say for sure if that applies to all of them... I could, and the body textures would improve the clothing a bit, however, in the couple tests I just did, the faces don't seem to be positively changed by using the upscaled textures. The AI doesn't seem particularly good at skin and hair. They don't get a lot worse either though ... it seems to be, do you want your eyebrows to look pixelated, or do you want them to look like watercolor paint? Definitely not an improvement on a level that would get me to rerender everything.
  8. ndix UR

    HD PC Portraits

    Thanks for finding that. I've uploaded a fixed version.
  9. View File HD PC Portraits HD PC Portraits for Knights of the Old Republic v1.0 - 20190909 by ndix UR (DeadlyStream user) This modification adds high resolution (1K) portrait images for player characters (PCs). All 30 male and female vanilla player characters are provided, with all 5 light-dark variants, for a total of 150 new portraits. The 1K portraits have 256x the resolution of the 64x64 originals. The portraits are rendered to match the poses, colors, facial expressions, and lighting of the original images as closely as possible given the following constraints: Only vanilla textures (and my own additional maps based on same) are used A couple face textures had the eye in the wrong place and had to be fixed I reduced the number of background gradients to a set of 4 standards. The originals are all over the place in terms of the gradients and I didn't have time to replicate every one. An effort was made to match each individual set of portraits to its appropriate set of background gradients. While the textures are mostly crap, most of the work was in material setup using a modern rendering engine, so even the vanilla textures still wind up looking much better than they have any right to. This is because of real lights, shading, and materials, of which the original diffuse textures are only a part. I didn't really redo geometry, beyond appropriate use of subdivision surface modifiers. See the included images in preview/ for an idea of how the portraits look. INSTALL / UNINSTALL To install, copy the files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. LEGAL THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no implied warranty, you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required. Submitter ndix UR Submitted 01/15/2020 Category Skins K1R Compatible Yes  
  10. ndix UR

    HD PC Portraits

    Version 1.0

    710 downloads

    HD PC Portraits for Knights of the Old Republic v1.0 - 20190909 by ndix UR (DeadlyStream user) This modification adds high resolution (1K) portrait images for player characters (PCs). All 30 male and female vanilla player characters are provided, with all 5 light-dark variants, for a total of 150 new portraits. The 1K portraits have 256x the resolution of the 64x64 originals. The portraits are rendered to match the poses, colors, facial expressions, and lighting of the original images as closely as possible given the following constraints: Only vanilla textures (and my own additional maps based on same) are used A couple face textures had the eye in the wrong place and had to be fixed I reduced the number of background gradients to a set of 4 standards. The originals are all over the place in terms of the gradients and I didn't have time to replicate every one. An effort was made to match each individual set of portraits to its appropriate set of background gradients. While the textures are mostly crap, most of the work was in material setup using a modern rendering engine, so even the vanilla textures still wind up looking much better than they have any right to. This is because of real lights, shading, and materials, of which the original diffuse textures are only a part. I didn't really redo geometry, beyond appropriate use of subdivision surface modifiers. See the included images in preview/ for an idea of how the portraits look. INSTALL / UNINSTALL To install, copy the files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. LEGAL THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no implied warranty, you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required.
  11. I would definitely recommend using a standard object serialization format for your textual representation. Either JSON or YAML. YAML is messier as a standard (far more complex parser and encoder), but more human-readable and can have comments. JSON is simple, but hand editing in a text editor is a little trickier because its parser is more rigid (also making it much easier to implement). With either format, you wind up using a more complicated structure if you're modeling the actual GFF data. The format VP showed is nice for export/viewers/other contexts where reconstruction isn't necessary. Here's one way to do the typed version: [ { type: "struct", value: { "DelayEntry": { value:0, type:"dword" }, "DelayReply": { value:0, type:"dword" }, "NumWords": { value:0, type:"dword" } } } ] An approach for retaining type while using the simplified/export version of the JSON might be to have a tool that reads a full GFF file and exports another json object with pathed type info. Like /DelayEntry: "dword", /EntryList/Text: "cexolocstring", etc. Then have the 'compiler' combine that info. Could even just run it on sample files for all types and put it into a structured type dictionary with path lists per type. Personally I've been using GFF->JSON for awhile and it would certainly be my preference, but once you're creating the structured objects, yaml or json is a one line code change. Avoiding writing your own parser is a good thing. I'll just leave this here: cexolocstring Text -1 0 "This is a cexolocstring English male variant. I "hate" my life now." 1 "This is a cexolocstring English female variant. Why did someone put a descriptive paragraph 1 \"in here\". " 2 "This is a cexolocstring French male variant. \tIt is also a long string that contains an internal multiline string \"Write your own parser, they said. It'll be fun, they said.\"" Parsing that isn't my idea of fun. I guess the question and limiting factor here is whether 3DS gives you a native JSON/YAML(or any standard format) parser? Also whether it gives you base64 encoding/decoding (there's a "void" type in GFF which is just raw binary data)...being a proprietary language, your ability to extend and rely on existing libraries and language features is probably not so good?
  12. IIRC, the WOK files have a specific byte or uint32 set (or unset, or something like that) when their mesh data is empty. Maybe K1 used that info to ignore whether a model has AABB, while K2 just ignores it and requires the AABB... I guess it's unlikely because the whole division between WOK & AABB node is a remnant of the 'client-server' architecture, with the WOK being used (largely) to establish & enforce positioning on the 'server' side and the AABB node used for the 'client' side. Cool, sounds like you're definitely aware of this. I wasn't really expecting it to be a factor here, mostly putting it out there as a general debugging tip. Using GLIntercept is another nice thing to add to that apparently.
  13. It seems like there's some Kotormax-relative terminology here. I use the older terminology where 'walkmesh'es are WOK files, and the walkmesh in-model are AABB nodes; bead-v folded them into one thing in the interface so that people couldn't get them out of sync w/ each other. In these terms, m14aa's skybox does have a walkmesh, it does not have an AABB node. When you're discussing issues around this stuff, it is very helpful to differentiate. bead-v chose to collapse the walkmesh functionality around the AABB nodes, ignoring the WOK files as much as possible (except for the information that uniquely resides within them), so, for these models where the area doesn't have an AABB node, it seems highly likely that there would be some kind of breakage, and I would expect MDLEdit not to be able to produce a WOK file (during ASCII=>Binary compilation phase). Probably the fix for bead-v will be to auto-add an AABB node from the WOK file (during Binary=>ASCII decompile) if the model is lacking an AABB but a WOK is present (assuming he hasn't already had to add such a feature). Unfortunately, in several places within the tools (particularly the editor components), the presence of the AABB node is used to classify area models. Meaning, within the model-processing toolchain, there's a decent chance that the WOK file wouldn't even be loaded in cases where there's no AABB node, because we don't even know that the model in question is an area. It's pretty annoying that there's no classification for area models... I'm sure kotorblender would also experience issues with area models lacking AABB nodes, based on the shared use of that AABB-node == area model classification method. There's a chance that mdlops would work where MDLEdit doesn't though because it uses an ASCII WOK file during compilation, while MDLEdit never looks at such a file. In these cases, you have to (often with difficulty) determine whether something "didn't render" or whether it's location was just messed up. They often seem similar. The most common thing that gets messed up is that instead of using the LYT/WOK position, an area model gets placed at 0,0,0 (the second most common is that its location gets 'double' applied, so instead of being at 30,30,45, the model's origin will be at 60,60,90). So sometimes I will load up the LYT in Blender, and move the misbehaving model to 0,0,0 and figure out in there where I might be able to see the model in-game if that were the situation. Anyway, that's just a debugging tip. I've heard before something related to area models without WOK files or AABB nodes (I can't remember which) not rendering in-game, which I assume is what you're experiencing. bead-v was involved in debugging that and only relayed it to me secondhand, so he'll probably have something to say about it when his time permits. I think the idea that K2 requires an AABB node is probably right (or currently prevailing understanding), and that K1 not requiring an AABB node might be something we were unaware of. There might be more to it though, which would be nice to know. Seems like an easy enough thing to test w/ a hexedit... I'll give it a go when I get a bit of time.
  14. 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.
  15. 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.