Jump to content


Photo

TSL Textures Remastered

TSL textures HD remastered high resolution

  • Please log in to reply
522 replies to this topic

#481 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,458 posts
  • LocationOz

Posted 17 January 2018 - 08:05 AM

The Aspyr version doesn't alter appearance.2da, so it's not that at least.

#482 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 19 January 2018 - 02:13 AM

I figured out the issue with the HK and Mandalorian specular not working, it was an easy fix in that I forgot that the Steam version of the game actually stores workshop mod files in a completely different directory to the game itself. I was updating the appearance file but it was getting overridden by another.

 

So, was playing some more and found another longstanding issue, that to do with the Telos station animated displays. They get used also in the HK factory/base, so, I got around to doing an animated texture for them:

 

 

Spoiler

 

As this display is often found accompanied with other displays using an Ebon Hawk texture, I decided to redo this one again, making them green and devoid of the interlaced striping -- they are glossy / reflective displays now instead:

 

Spoiler

 

I also did the other Ebon Hawk display textures, including a simple animated texture replacer for the galaxy map screen -- really didn't make any sense why this one was in full colour with all the rest effectively monochrome displays:

 

Spoiler

 

I also did a few quick texture jobs for a couple of placeholder objects I spotted:

 

Spoiler

 

Couldn't find the texture or model for this one though -- if anyone knows, please let me know, FYI can be found in the HK base:

 

Spoiler

 

Not sure how well these screens represent the work. How the game is rendered on my laptop compared to my old dev rig, well, there is a marked difference between the two!



#483 VarsityPuppet

VarsityPuppet

    Jedi Master

  • Premium Member
  • 2,091 posts

Posted 19 January 2018 - 03:35 AM

Just marvelous, work! The screens look phenomenal

Be careful how you think; your life is shaped by your thoughts. - Proverbs 4:23


#484 Kexikus

Kexikus

    Jedi Master

  • Members
  • PipPipPipPipPip
  • 1,556 posts

Posted 19 January 2018 - 08:11 AM

Those look amazing. Great work!



#485 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 20 January 2018 - 07:40 AM

Just marvelous, work! The screens look phenomenal

 

 

Those look amazing. Great work!

 

Thanks!

 

Something I started working on today, but need to stop as I have plans for tonight:

 

Spoiler


#486 N-DReW25

N-DReW25

    GenoHaradan Legacy Developer

  • Members
  • PipPipPipPipPip
  • 898 posts
  • LocationSuper Secret GenoHaradan Base

Posted 20 January 2018 - 10:18 AM

Thanks!

 

Something I started working on today, but need to stop as I have plans for tonight:

 

Spoiler

THAT is absolutely stunning.



#487 Vriff

Vriff

    Jedi Knight

  • Members
  • PipPipPipPip
  • 222 posts

Posted 21 January 2018 - 12:48 AM

i LoVe YoUr WoRk



#488 Mephiles550

Mephiles550

    Jedi Knight

  • Members
  • PipPipPipPip
  • 271 posts

Posted 21 January 2018 - 03:13 AM

Amazing, reminds me of the old Star Wars comics before the prequel trilogy. They loved scenery like this. 



#489 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 22 January 2018 - 12:55 AM

Thanks for the kind words about the work.

 

Some screens of the outside of the tomb. FYI at this point I am only doing the Dxun tomb textures and not the rest of Dxun due to time constraints -- though I will likely do something about the rain fx. I started on the tomb as is uses some textures from other planets that I had changed and no longer fit the tomb; plus, the tomb interior was a real eyesore of rushed texturing.

 

Spoiler


#490 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 22 January 2018 - 08:22 AM

So, some new screens of the interior of the tomb with some revised textures...

 

Spoiler

 

I still have some textures to do with the computer terminals in the tomb. Once those are complete -- and maybe the odd texture like the outside rain -- I will be leaving the Dxun tomb where it is. Realistically, due to the original textures being used in all manner of ways -- think that low-resolution brown dirt texture ending up being used on metal walls, not at the correct scale with distorted UV mapping -- it is difficult to get decent results without extensive hex editing. Or by using the new tools to edit meshes. That I just don't have time for at the moment.

 

If people are wondering, I am aiming to have a release up by the end of this week. Whilst I have some time available to me.



#491 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 26 January 2018 - 02:54 AM

So, though I've been sick of late I still worked on the mod, however, I took a break from the Dxun textures as the last animated texture for the tomb was taking a while...

 

Spoiler

 

Originally I was focused on updating and cleaning out the effect plugins my imaging editing app uses until I switched to a long-term issue I had, and that had to do with the Telos station "skybox" and station sprawl. The issue was that the superstructure texture that I created (years ago) was not being rendered properly:

 

Spoiler

 

The issue had to do with mesh settings. Since I was working on a tool and effectively had the converting of a binary model to a readable ASCII version that account for every single byte, I decided to make a quick tool that simplified the formatting to the bare minimum and save it out as a .tmdl file -- text file. Then it was a (relatively) simple matter of writing the part that parsed the file back into binary. With the original and processed .mdl files being exactly the same byte length.

 

I made some changes to the mesh data, and thought I had solved the issue until I saw that what I had suspected would end up being the case, was the case:

 

Spoiler

 

The issue I believe is that C#.Net when reading the bytes for floats will read a number it categorises as NaN -- not a number. Now, I don't know if it actually stores the value that it reads into the float object correctly or not, what I do know is that when it writes it out into a string (ASCII / text) it is NaN and not any number. Though you can safely parse this back into bytes for the binary file, it is clearly not the same value as was originally read.

 

I tried a few things to do with storing it as a double -- floats are "singles" -- which is more precise, and using a custom class I found for writing out doubles precisely as strings. Wasn't a help. As I wanted an effectively tool to make my changes, I decided that I could simply read the float bytes, convert them to Base64 strings that are saved in the .tmdl file, and then parse these back into bytes.

 

It worked:

 

Spoiler

 

It's not the solution I wanted for the NaN float values, but for the time being it works, allowing me to change textures used in models with more ease and flexibility over hex editing, along with making meaningful quick changes to model data without having to import it into a modelling package, make my changes, export it and then compile it into a .mdl file and hope that everything comes out the other end fine.

 

Oh, I also re-did the rain fx -- trust me it looks a lot better when not a static image of a screen:

 

Spoiler


#492 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 26 January 2018 - 01:58 PM

Well, I worked on my tool some more to handle the NaN issue better along with a feature that spits out a list of all the textures used in the model, how many times and by what node types, and then turned back to fixing issues.

 

There was this simple one to fix that came about due to the Dxun Tomb texturing...

 

Spoiler

 

Fixed it...

 

Spoiler

 

Then I looked at how Dxun was being rendered on my laptop, not sure if this is my laptop of the Steam version of the game, but, it is an eyesore to me that turns one of my favourite locations into a bit of a chore to play:

 

Spoiler

 

Had a quick go at addressing the grey fogging issue and had very good results:

 

Spoiler

 

So far I think it was worth the effort making the tool actually usable; at least for me.



#493 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,458 posts
  • LocationOz

Posted 26 January 2018 - 02:07 PM

If you are using the Aspyr version of the game, that's the problem. Amongst many other bugs they introduced, they screwed up the fog. This is what you want:

https://github.com/H.../ShaderOverride

See here for more info - http://deadlystream....-2016-tsl-patch

#494 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 26 January 2018 - 02:17 PM

If you are using the Aspyr version of the game, that's the problem. Amongst many other bugs they introduced, they screwed up the fog. This is what you want:

https://github.com/H.../ShaderOverride

See here for more info - http://deadlystream....-2016-tsl-patch

 

This won't work with Reshade, will it? -- I'm assuming as it is also a "opengl32.dll".

 

How about the issue with the sabers not rendering properly, does it fix that as well? 



#495 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,458 posts
  • LocationOz

Posted 26 January 2018 - 02:23 PM

No, it won't work with Reshade, or any other OpenGL override. The source for both is available though, so merging is always a possibility for those of the code monkey persuasion.

It doesn't address the saber issue, no, but possibly it could if you knew which shader/s to edit (and how to edit them).

#496 ndix UR

ndix UR

    Jedi Padawan

  • Members
  • PipPipPip
  • 99 posts
  • Locationca, usa

Posted 26 January 2018 - 08:03 PM

Just in case you aren't aware, your NaN issue stems from the fact that (most of the) rotations are compressed quaternions which aren't valid floating point formatted numbers (they are 3 floats occupying 4 bytes via a certain math/bitmasking algorithm, which is why treating them as doubles doesn't really help, both float/double have actual internal data structure (separation of value & mantissa, etc)). I decode and use them internally as unsigned ints (just 4 bytes, no funny business) but of course an array/buffer of bytes exported as hex will work fine too. If you were trying to decompress them for any reason, like if you wanted to be able to alter them in a meaningful way, you'd want them as uints so you could do the necessary bitwise logic on them (the required shifts don't line up at byte boundaries).

 

The IEEE754 float32 type specifies a particular value for NaN, so when you read the NaN back in to recompile your model you wind up with a very different, defined, constant value for those rotations.



#497 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 27 January 2018 - 12:47 AM

Just in case you aren't aware, your NaN issue stems from the fact that (most of the) rotations are compressed quaternions which aren't valid floating point formatted numbers (they are 3 floats occupying 4 bytes via a certain math/bitmasking algorithm, which is why treating them as doubles doesn't really help, both float/double have actual internal data structure (separation of value & mantissa, etc)). I decode and use them internally as unsigned ints (just 4 bytes, no funny business) but of course an array/buffer of bytes exported as hex will work fine too. If you were trying to decompress them for any reason, like if you wanted to be able to alter them in a meaningful way, you'd want them as uints so you could do the necessary bitwise logic on them (the required shifts don't line up at byte boundaries).

 

The IEEE754 float32 type specifies a particular value for NaN, so when you read the NaN back in to recompile your model you wind up with a very different, defined, constant value for those rotations.

 

I was aware of *some* of that but not all of it. Recalled something about the rotations (quaternions) being compressed, wasn't aware they were compressing 3 floats (12 bytes) down to just 4 bytes.

 

At the moment I don't need and really can't edit data like that. The .tmdl format is just a line by line account of each data element found in the .mdl file, in sequential order. The "compiler" reads this line by line and writes out the binary file. It doesn't error check byte index pointers and corrects them. Though I guess I could decompress the rotations so that I could then manually edit the data, probably best place to do that is in an actual modelling program. The .tmdl format was never meant for that;  I had originally planned another file format for that which was a store of how the model data would have been stored  in memory -- a more logical structure.

 

That stuffs on hold, especially as this is heading into territory that I find usually takes me 3 to 6 times as long as someone who is interested in it to complete -- I'm not really a coder (software engineer) I'm a game designer who learned how to code (script) in engines that do all the hard stuff under the hood.

 

No, it won't work with Reshade, or any other OpenGL override. The source for both is available though, so merging is always a possibility for those of the code monkey persuasion.

It doesn't address the saber issue, no, but possibly it could if you knew which shader/s to edit (and how to edit them).

 

If it solved the saber issue, I did have no issues dropping ReShade for it. I think instead what I will do is edit all the effected Dxun models so that those that like and use ReShade can keep doing so. Plus, the edited models shouldn't change the corrections made by Shader Override.

 

I thought about writing a custom injector years ago for the game, I've also dabbled in some shader writing, however, what you really need is a graphics programmer. Someone who knows OpenGL quite well and how to analyse / inspect the game in order to find out what it is using so as to know what to override. I might know enough so as to get the two combined -- if they are easily combined and it doesn't mean effectively rewriting Shader Override within the ReShade code (if actually available) -- but not sure about the saber issue. And its really the saber issue that bugs me the most.

 

How Aspyr thinks that what they have released as an update for TSL is acceptable, considering the game is set in Star Wars and is about a Jedi who beyond the use of the force, rely on a lightsabre... well that's just unprofessional in my opinion and makes it clear why they do the kind of work they do as a studio.



#498 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,458 posts
  • LocationOz

Posted 27 January 2018 - 05:44 AM

if actually available

 
https://github.com/crosire/reshade

How Aspyr thinks


They think the same as any other commercial entity. They don't do squat unless they are getting paid to do so. There's no financial incentive for them to bother with additional patches.

#499 sELFiNDUCEDcOMA

sELFiNDUCEDcOMA

    Sith'ari

  • Members
  • PipPipPipPip
  • 350 posts
  • LocationLand of Oz

Posted 27 January 2018 - 06:32 AM

 
https://github.com/crosire/reshade


They think the same as any other commercial entity. They don't do squat unless they are getting paid to do so. There's no financial incentive for them to bother with additional patches.

 

And that's why as a studio -- sorry "publisher" -- they only port other studio's games. An utter disregard for quality due to lack of understanding of what is important and why when it comes to a product meant to entertain people in exchange for money.



#500 VarsityPuppet

VarsityPuppet

    Jedi Master

  • Premium Member
  • 2,091 posts

Posted 27 January 2018 - 07:34 AM

And that's why as a studio -- sorry "publisher" -- they only port other studio's games. An utter disregard for quality due to lack of understanding of what is important and why when it comes to a product meant to entertain people in exchange for money.


I don't think it's necessarily disregard for quality due to a lack of understanding, more likely due a lack of time and resources. Still, I agree lightsabers are the important part of a Star Wars game, and seems like that was a bad thing to overlook

Be careful how you think; your life is shaped by your thoughts. - Proverbs 4:23






Also tagged with one or more of these keywords: TSL, textures, HD, remastered, high resolution

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users