Wenn du etwas neues erstellen willst (eine neue Mod) dann solltest du vermutlich das SDK verwenden (dafür ist es da). Wenn du die HD Edition verwendest (also eine bestehende Mod) dann solltest du erst einmal um Erlaubnis fragen ob du diese Mod überhaupt für deine Zwecke verwenden darfst. Ganz speziell wenn du deine eigene Mod veröffentlichen willst, wäre es ratsam die Erlaubnis zu haben, wenn du Werke von anderen Moddern verwendest (immerhin haben diese Zeit und Arbeit in diese Mods gesteckt).

Normalerweise würde ich jetzt empfehlen FLdev1.1 zu verwenden, aber finde gerade keinen Download link.
Dort kannst du relativ einfach IDs finden und editieren.
Aber wie gesagt, ich habe leider keinen link gefunden. Das ist wohl beim Umbau der Webseite verschüttet gegangen und ich hab keine Ahnung ob ich einen re-upload auf meiner Seite machen darf.

Die letzten deutschen FL-Modding-Communitys wurden ca. 2005/2006 geschlossen, daher ist es etwas schwierig, aktuelle Tutorials auf Deutsch zu finden.
Die alten Tutorials sind alle noch gültig, wenn auch ein bissl komplizierter als aktuell notwendig. Alle (fast alle) Tools sollten nach wie vor noch in den größeren Modding-Communitys vorhanden sein.
Bei Verständnisproblemen würde ich einfach empfehlen zu fragen. Hier gibt es genug Leute die solche Dinge erklären können.

\Freelancer\FLARDATA\Textures
should be the folder structure

inside you have the PBR texture folders e.g. NormalMaps
Creating normal maps would be the starting point, Metalness and Roughness maps later on if you need them. HeightMaps would be a special case that you wont need that often actually.
Create the DDS files and put them into the folders using the original texture names that you can find via UTF. If you work based on original tga textures don’t forget to flip the texture before storing them as dds.
Normalmaps need to be stored as ATI2 and all others as ATI1 dds. Overwrite textures can be dxt1-5.
You dont need to manually edit the material file (but you can). You can use the ingame dev menu to set roughness and metalness values. These values get stored inside the material config file.
I personally edit the material config manually once I know the settings. This way I can group textures which have similar settings and keep everything lightweight that way.

Im not at home this week so I cant take any screenshots atm.
But I have a few vids from a few weeks ago.

It’s not the latest version but probably good enough.
https://www.youtube.com/watch?v=1GggMG3fehw
https://www.youtube.com/watch?v=1YPTdY2E9aY
https://www.youtube.com/watch?v=VUCgl7SUvPw
https://www.youtube.com/watch?v=hPz-_TDcJwM
https://www.youtube.com/watch?v=v4WKOhzVN_s

I personally stayed aways from using lz4 after doing a test with it.
In one very specific case a texture caused crashes when starting the game when compressed to lz4. Overall I noticed random instabilities using lz4.

The settings not saving could be related to what I meantioned with autoupdates and version indexes. I could be wrong as I dont know the exact conditions under which you try to run it.

It’s been some time but as far I remember the Cockpit models store fov for x+y and a z near and z far offset.
That should be enough to achieve this stuff.

Here is the vid:
https://www.youtube.com/watch?v=cj3j3bZDjpA

Maybe an issue with the light settings (the system actually is meant to be relative dark). Dunno.

I still have not had much time testing the new version and therefore can not tell if certain stuff/issues from the old version still are valid or not. I wanted to collect and discuss them with you all at once but then RL came between.
I just went through my notes and well, the latest update covered a significant amount of topics I wanted to discuss.
However, a few issues I noticed in the last version were:

• Dxt1 1bit alpha textures were not rendering correctly (the alpha channel was interpreted as black)
• Material type “BtDetailMapMaterial” and its variations were not rendering correctly (mostly observed on station interiors); the tilemaps were missing completely

I don’t know if these issues were known already or are still in the current version of the renderer. Like I mention, I am very short on time lately and could not test it yet.

I have a few additional questions and suggestions in my notes.

• the ingame slider for metalness, roughness etc. … I was wondering if there is a way to make a texture completely matte with these sliders (I struggled to find working settings); if not, it’s still ok and probably better using dds textures instead; I was just wondering.
• In the original description you mentioned to use ATI2 for the normalmaps and certainly everyone working with textures could eventually figure this out by testing, but maybe you can include the info about the channel layout into that description post. There is ATI2 and swizzeled ATI2 where red and green channels are swapped. Depending on what tools and exporters are used this info can be helpful.
• Is it planned to apply the full feature set of the renderer also to static asteroids? Dynamic asteroids already make use of it but static ones so far do not make use of normalmaps etc.
  I believe that this specifically would highly improve how the game looks since asteroid fields and debris fill large parts of the game. Converting the static ones into dynamic ones might be a solution but has disadvantages in other areas.
• Do you have any information if fog settings in cutscenes or bases are rendered differently now? I noticed that specifically where fog is used in the scripts the lighting looks very different. I at this point would assume that in DX the direction lighting that often is used in the scripts had a very different impact on this setting. The fog now seems to be stronger.
• I used to have a question about “tone mapping” but since thats the only keyword I wrote down to this topic months ago… dunno… I’ll ask again when I remember the question I had.
• Last but not least something that might be a bit specific (maybe not). Many mods these days get updated by some kind of autoupdate feature that is either hash based and/or have a version based way to identify if files need to be updated.
  If the renderer files are distributed via such an autoupdate the config.cfg file is at risk to be overwritten on the client each time the autoupdate runs (for some mods this means with every launch of the game). That in return means that players can not save any settings because next time the game launches the config file get overwritten.
  In my mod I have some features which allow players to store their personal settings in files but also allow me to update such files if really required by using a version index.
  e.g.:

[VersionHistory]
Version=1.1beta1

[Settings]
MSAAMode=0
AnisotropicFilteringMode=0
ToneMappingType=0
ShadowNumSplits=4
ShadowmapSize=4096
ShadowCastingLights=2
EnableNewLighting=1
EnableShadows=1
EnableEnvMaps=1
EnablePostProcessing=1
EnableLightScattering=1
EnableParallaxMaps=1
EnableHQDiffuse=1
EnableShadowPCF=1
EnableAsteroidShadows=1
LightScatteringSunLimit=8
EnableClusteredShading=1
MaxNumberOfLightsIndex=1
ReplaceFakeLights=1
EnablePointLights=0
EnableAutomaticExposure=1
AlwaysUseAccurateSRGBConversion=1

So players can store their settings without the config.cfg being overwritten as long as the version of the file on the update server and on the client are identical. If version 1.1beta2 is available then an updated config file (with the addiontal settings) could be downloaded.
This would allow online distribution of updates of the renderer via mods without blocking players from accessing the renderer menu and storing their settings.
I don’t know exactly how other modders distribute their updates when they have an autoupdate. I can only guess there.
The example above is how I can imagine a working solution (since I have multiple similar config files players already can store data to but also can be updated once a new version is available). Important would be that when storing the settings in game the [VersionHistory] remains untouched while only the [Settings] part gets updated.
Does that make sense? Yes, no, maybe?

A final note: I kept the renderer running with the Here is the vid:
https://www.youtube.com/watch?v=cj3j3bZDjpA

Maybe an issue with the light settings (the system actually is meant to be relative dark). Dunno.

I still have not had much time testing the new version and therefore can not tell if certain stuff/issues from the old version still are valid or not. I wanted to collect and discuss them with you all at once but then RL came between.
I just went through my notes and well, the latest update covered a significant amount of topics I wanted to discuss.
However, a few issues I noticed in the last version were:

• Dxt1 1bit alpha textures were not rendering correctly (the alpha channel was interpreted as black)
• Material type “BtDetailMapMaterial” and its variations were not rendering correctly (mostly observed on station interiors); the tilemaps were missing completely

I don’t know if these issues were known already or are still in the current version of the renderer. Like I mentioned, I am very short on time lately and could not test it yet.

I have a few additional questions and suggestions in my notes.

• the ingame slider for metalness, roughness etc. … I was wondering if there is a way to make a texture completely matte with these sliders (I struggled to find working settings); if not, it’s still ok and probably better using dds textures instead; I was just wondering.
• In the original description you mentioned to use ATI2 for the normalmaps and certainly everyone working with textures could eventually figure this out by testing, but maybe you can include the info about the channel layout into that description post. There is ATI2 and swizzeled ATI2 where red and green channels are swapped. Depending on what tools and exporters are used this info can be helpful.
• Is it planned to apply the full feature set of the renderer also to static asteroids? Dynamic asteroids already make use of it but static ones so far do not make use of normalmaps etc.
  I believe that this specifically would highly improve how the game looks since asteroid fields and debris fill large parts of the game. Converting the static ones into dynamic ones might be a solution but has disadvantages in other areas.
• Do you have any information if fog settings in cutscenes or bases are rendered differently now? I noticed that specifically where fog is used in the scripts the lighting looks very different. I at this point would assume that in DX the direction lighting that often is used in the scripts had a very different impact on this setting. The fog now seems to be stronger.
• I used to have a question about “tone mapping” but since thats the only keyword I wrote down to this topic months ago… dunno… I’ll ask again when I remember the question I had.
• Last but not least something that might be a bit specific (maybe not). Many mods these days get updated by some kind of autoupdate feature that is either hash based and/or have a version based way to identify if files need to be updated.
  If the renderer files are distributed via such an autoupdate the config.cfg file is at risk to be overwritten on the client each time the autoupdate runs (for some mods this means with every launch of the game). That in return means that players can not save any settings because next time the game launches the config file get overwritten.
  In my mod I have some features which allow players to store their personal settings in files but also allow me to update such files if really required by using a version index.
  e.g.:

[VersionHistory]
Version=1.1beta1

[Settings]
MSAAMode=0
AnisotropicFilteringMode=0
ToneMappingType=0
ShadowNumSplits=4
ShadowmapSize=4096
ShadowCastingLights=2
EnableNewLighting=1
EnableShadows=1
EnableEnvMaps=1
EnablePostProcessing=1
EnableLightScattering=1
EnableParallaxMaps=1
EnableHQDiffuse=1
EnableShadowPCF=1
EnableAsteroidShadows=1
LightScatteringSunLimit=8
EnableClusteredShading=1
MaxNumberOfLightsIndex=1
ReplaceFakeLights=1
EnablePointLights=0
EnableAutomaticExposure=1
AlwaysUseAccurateSRGBConversion=1

So players can store their settings without the config.cfg being overwritten as long as the version of the file on the update server and on the client are identical. If version 1.1beta2 is available then an updated config file (with the addiontal settings) could be downloaded.
This would allow online distribution of updates of the renderer via mods without blocking players from accessing the renderer menu and storing their settings.
I don’t know exactly how other modders distribute their updates when they have an autoupdate. I can only guess there.
The example above is how I can imagine a working solution (since I have multiple similar config files players already can store data to but also can be updated once a new version is available). Important would be that when storing the settings in game the [VersionHistory] remains untouched while only the [Settings] part gets updated.
Does that make sense? Yes, no, maybe?

On a final note: I kept the renderer running with the large address aware flag, that we discussed earlier and have not had a single crash in the past months nor have I received any reports of any issues from other players. That one crash issue, I reported earlier certainly was related to that. The issue can be considered resolved and maybe it might be worth adding info to the initial instruction post how to apply LLA. It might prevent some headaches if somebody else runs into such an issue.

I did a short test and it is indeed a big improvement over the last version.
The replace fake lights is really nice and adds much more detail to the game. There seem to be a few minor issues that I notices (such as dock lights being way too big and some other lights on the contrary even disappearing) but I guess that is a matter of what settings the lights use. I am a bit short on time lately but will take a close look at later.´
The clustered shading itself is extremely good compared to the previous version. Lights and reflections fit much better now. Just the fake light replacement in some cases feels a bit strange… but like I said… probably just a matter of creating correct settings for it.

The SRGB color Conversation looks perfect the way it is. Much more realistic.

The automatic camera exposure indeed helps with the darker scenes, especially on some decks and bars. In some cases it maybe felt a bit too bright already but maybe I just simply got used to the darker look.
A problem maybe is the exposure in space when it switches from bright to dark environment. e.g. when looking at a bright planet surface/atmosphere and then tilting the ship away to a dark starsphere.
The exposure transition is too abrupt and feels a bit disturbing (almost buggy). Maybe a longer fade time would help here.

Also during my test I stumbled over a some very weird lighting issues in an asteroid field. I am not sure if this is new in 1.1 beta 1 or if this existed before. I’ll make a video next week so you can see what I mean. Maybe something that needs to be fixed, maybe just simple something that needs to be changed on my end.

Sure, you can do that.
I am curious. Based on what would an automatic tool decide how reflective a surface is… if reflective at all. How does it decide if a surface is metal, plastic, skin, cloth or a rock?
In many cases it is not even required to create a full set of PBR textures since the new renderer has settings for that if the texture does not require to have different levels of reflectivity. But again… the question is what texture needs which treatment?
If you apply the same settings for everything the results might look nice in one area and terribly wrong in others.
However, maybe you figure out something that fits everywhere or requires just some tweaking later on. You can give it a try. The textures easily can be extracted using the UTF editor Schmackbolzen linked. Same tool is required to make the 3d models compatible with the new renderer.
Maybe one thing worth to mention… not all objects in FL fully use all of the new render features. e.g. static asteroids don’t, most stuff on bases also don’t, detailmaps/tilemaps IIRC also don’t.

There are no textures, so you have to create them on your own.
How to create them highly depends on what you want to achieve. Quick and dirty guides on PBR texture creation can be easily found on google search. Quality of course won’t be perfect using anything that just does mass convert textures, especially since the source material often needs some upscaling first (not always). There also are going to be some texture name conflicts that need to be resolved first. Schmackbolzen shared info about the required texture types in the first post.

I’ve so far created ~3000 PBR textures for my mod (so far) and the best approach in my eyes was to create the textures one at a time and tweak settings until the 3d models (all of them tested) looked good in a standard lighting environment.

Probably by creating fitting specular maps (MetalnessMaps)

The keymapping plugin was a custom one, not created by adoxa. I don’t have the source code but I contacted the creator of the dll. It might take a few days to get a reply.

The 1.1 patch indeed did the trick with vanilla FL.
I also narrowed down the issue with the mod incompatiblity to two custom plugins. One plugin that altered some keymapping stuff (apparently conflicts with your keymapping code) -> in the end not a big deal. The other plugin is a custom anticheat version. This needs some further investigation.
In the end probably nothing that would cause troubles for other mods/players.

Thx for the quick reply.
I did not use the 1.1 patch. I’ll try that later tonight.
Maybe it would be worth to include the 1.1 patch right into the renderer download to simplify it for the players? Again, just an idea.
If I get it working with the 1.1 patch I probably can try to figure out why the modded game crashes as soon the mouse cursor moves. I’ll share the results as soon available. Maybe that might help others if they run into similar issues.

First off, thanks for all the effort developing this new renderer. I think this has much potential to keep FL relevant and interesting for the players.

I’ve read through that other thread and also tried to get the beta 2 running.
In both cases I have questions.

1. Credit is of course given where credit is due. But the way how stuff is credited also might matter (or maybe not). What I mean is, would it be sufficient to write “Advanced Renderer by Schmackbolzen” or would you prefer maybe a more detailed reference… maybe with link to a project website or a link to this thread so people can actually find the original source and also know how to easily get in contact with you if required. Maybe a text snippet to use for the credit. Just a thought.
2. Like I mentioned I just downloaded the beta 2 and wanted to give it a quick try. Everything done so far more or less was based on assumptions… so I copied the content right over test version of my mod and launched it. The game loaded, main menu appeared flawlessly and lighting changes instantly were visible. So far so good. However, moving the mouse just one pixel did lead to an instant crash. I tried this 5-6 times always with the same result.
   Since there could be some unknown incompatibility with my mod and the new renderer I tried it with vanilla FL (fresh install + no-cd exe). Vanilla FL loads fine, there are visible changes on the main menu, mouse movement does not cause a crash. However, clicking on new game instantly crashes the game.
   While potential issues with heavily modified FL mods are not that surprising the vanilla FL crash is. Even more since the crash while launching a new SP game always happens in server.dll (at offset 0x0001b300).
   Maybe I am doing something wrong (clearly can not be excluded at this point).
   Are there further ways to debug stuff with the new renderer?

Funny things are good. They keep it interesting.

You are using a mod, right?
What you describe sounds pretty much like an active OpenSP. Try to check if there is an OpenSP option activated somewhere.
If so, deactivate it and load the mission generated savegame prior to that point.

happy NY

not bad so far