Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content

Stefan Hoffmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Stefan Hoffmann

  1. The RealLight issue (steppy floodlights on mainpanel) is solved and already pushed into the update pipeline. You can await it ready for download very soon. The reflection/shadowing issue results with legacy (non PBR) shaders in Prepar3D V5. As the airbus series features legacy shaders still, there is nothing we can do about that currently.
  2. Hi Amarant Fox! I checked on the RealLight issue in Prepar3D V5 and the plugin provider changed some interior parameters which we have to address now internally too. The update is worked on next week and soon there should be an update available for that too.
  3. Hi Amarant Fox! I checked the "reflection" issue you described. Actually that is nothing really new. But its not the reflections, its a not correctly working shadowing algorithm which plagues Prepar3D material which got normal maps since generations. Under certain lighting angles the sim doesn´t seems clearly to know if the surface shall cast shadows or not. As this is decided uniquely for each polygon, you get those hard edges shows. This is obvious for ALL aircraft that use normal/bump maps and cannot be avoided as the error stems out of the sim itself. The only way would be to remove all normals maps, but then it falls back to "FS2004" looks, so also no way. However on PBR material this not happens. I also doubt that LM will invest a lot of time on legacy shaders anymore as PBR is the standard nowadays. When the A320 exterior models are getting a full PBR update, this issue you described will be gone. But the rework is no trivial thing and will cost quite some time. Check the A321 under different lighting conditions. If you get a very flat angle of lighting to a certain polygon, you will get the flawed shadows... There is sadly nothing we can do about that now. The A330 however behaves correctly, as the PBR shaders seems to use a different calculations process to process shadows on the polygons. The helicopter is a default aircraft of Prepar3D V5 and also got the shadowing flaw. The floodlight issue for the A320 series is also processed. I will let you know of the results there later...
  4. Hi Luca_Donadi! The A330 is a much younger product than the A320series and uses PBR shaders, the newest standard. Those aquire their environment reflection data in realtime from the actual existing surroundings. On the A320 however we still got legacy shaders which is fed by a static cubic reflection map. With the new skylighting system in Prepar3D V5 also basicly more yellow hue is added and is aimed supporting PBR shaders for best results. The change from legacy to PBR shaders is not trivial and will consume many workhours to be created. So this will have to wait a bit.
  5. Hi wrs511! The easiest idea is the right one here: All cockpit textures were changed for the Prepar3D V5 release to fit the new tonemapping requirements. (If "tonemapping" is a new term for you: that is some kind of lookup-table/function which alters a pixels color information to another value. This was first introduced in cinematic productions to achieve higher control about displayed colors and to stylize productions. If you have seen a "making of" from an actual movie while a scene was just filmed and then later that same scene in the movie, you will witness a strongly changed look of color and contrast. So for the sake of better storytelling the visual aesthetics is stronly manipluated). To raise the quality bar for visual output in Prepar3D V4, LM introduced a new autoexposure / tonemapping. These processes, outputting frames differently to the time before, alters the finally rendered content a split second before it is send by the graphics card to the monitor. Changes can be made in saturation, brightness, contrast, levels and so on, which can change the look of the input textures in a strong manner. Those processes were not perfectly implemented in V4 and forced us to bring the overall texture values to a darker range to keep the correct output. This also led to further complications with other "reshade" addons some user applied addintionally ontop, who remapped the values again . So LM invested quite some time and updated that output engine stuff intensivly again to work correct with its new sky simulation engine also introduced for V5. The result was, that the small busses non-PBR textures now appeared too dark in the default sim. So to guarantee a good costumer experience with the A318-A321 pro series, the values were changed again to bring the correct values to the display, so in a level you would await comparing with real world imagery. So the pity now is only that the mainpanel texture of the existing repaints appears too dark in direct comparision with the freshly redesigned rest of the cockpit. While the default liveries of course were corrected for the release alltogether, we cannot change all the repaints done by exterior repainters. For that case we provide a replacement template for the mainpanel texture, hwere the registration has to be updated to fit the registration for the respective livery. And yes, in future registrations will be added as dynamicly changing part of the cockpit.
  6. Hi SK10! Your find is confirmed. We will create an update of the models to remove this issue. Thank you for your input!
  7. It depends now what you mean with registration placards. I guess you mean the cockpit internal placard: This is set ready to type! So you directly click on it using the Photoshop TYPE tool and you can change it like in a text processing software. Then save it as DXT3 into your livery folder and there you go. On the external however it is harder. For the default paints i looked for very high resoluted images from the registration area and rebuild just that as vector components as the fonts are often not known or especially made for that purpose and not publicly available.
  8. Hi Yoda1976! As I told you before: Some of your "cosmetic" addons REX, ENVTEX you told about causes this. And you did tell too, that you installed the sim, the aircraft and those addons anew. This of course then restores the old faulty state again too. Some of those addons change stuff, they should keep the fingers away from: default content installed by the sim´s installer which is used widely by other addons too. The same folder for the A320 package I have to make first. The FX files generating the final effect on display consist of a texture base for the visual stuff (f.ex. fx_2.bmp) and a *.fx configuration-file that contains parameters on how to use this map and how it should act as active light. Both have to be changed and that for several effects. But its now on the to do list here, parallely to the planned update for the A330.
  9. The A330 product folder contains an own EFFECTS folder. If you want to try out the solution fast and not want to wait until the official update, then overwrite the files in this addon EFFECTS folder (not Prepar3D main, but addon A330 folder!) with those in the attached 7zip file. It contains an updated version for all light effects issued by the "blueish defect" and a subfolder "texture" which contains the renamed fx_2.bmp effect (now named fx_2_AS.bmp), so naturally no one should overwrite that again. Of course make a backup of the addon EFFECTS folder before, i case you want to revert later. I already tested the new layout and all files are loaded correctly here. Effects.7z
  10. The landing/taxi/turn off lights only show blue when the fx_2.bmp file has been altered again by some of your scenery addons. I cannot say which one it was in detail, but you told already that you installed REX, Envtex, etc... One of them changes the default effect on your machine to the bueish version. As we cannot control those developers I currently try to create a workaround with a costum BMP for the issued lights. If this works parallely to the default files the product will soon get an update that should solve the issue in any case.
  11. Back here! I just tested all CRJ VCs and not noticed the landing lights issue in any case. In fact, as the landing lights not cast any shadows, the cone size and orientation had to be carefully selected to avoid any interaction with the cockpit. So technically it should not be possible that something like this occurs. But we are still investigation the issue further and will post the results here... The files need to check would be: fx_ASCRJ_LANDING.fx I attached a copy of the version I used for my current testing. It belongs into the main addon folders - Effects - section. Also make sure a similar file doesnt exist in the Prepar3D main folders EFFECTS section from a former CRJ installation to be sure, the right version is accessed. Normally with the new folder structure the data should be only accessed via the separate addon folder, but one should exclude all other possibilities too... fx_ASCRJ_LANDING.fx
  12. Exactly. As the system has to carry already a lot, the wings are optimized for the VC view, removing all unecessary stuff. For wing views you got the camera from the exterior views.
  13. I think this (double posted) question was answered already in the other thread...
  14. Yes it is. It simulates the bend of the rubber tire coming with heavy aircraft. Compare it to realworld images or other addons. On such aircraft the tires have to deform to a certain amount as they also play a role in shock damping. The best way so is to let them "sink" in a bit to mimmick this behaviour. Not that with addon scenery you often get costum runways which float above the natural scenery a bit. This then can over-exaggerates the effect a bit. But it is no unusual issue how it is now.
  15. Hi! The black objects occur when the texture for them could not be loaded. This can happen if the texture was simply not found in the livery folder or the needed file is damaged in some way and cannot be accessed properly so.
  16. Sometimes even accidents have a good side! Check the image on this accident report, where the FOs front windshield was completely destroyed and you can see directly out without any glass in the way. Now check the pilots intact windshield glass and note the difference between CPT and FO sky! And yes: Its tinted. A simple photoshoot of the glass from inside the plane just reveals nothing. You need the direct comparision the get the absolute difference....
  17. Hi Kmax59! Its not about your product especially. We not told our costumers to de-use your product especially. We carefully analyzed what causes us issues reported by our customers and gave a report of the facts faced. The thing is that not really all PBR-branded "new" cockpits are really native PBR material cockpits! Maybe this situation is also responsible for the "calibration" differences from one bird to the other. Some are merely swift ports, which majorly used already existing textures that were made for FSX before. Those had to be by nature brighter than the native PBR stuff, as FSX showed them much too dark over the midday times and devs were forced to overexaggerate brightness there. Many of those will exhibit a better behaviour in NON-HDR environments (which some of the people still stick to) combined with the existing shading presets (as FSX is a NON-HDR environment), as they existed long before and the FSX product and the 3rd party shader software had years to adapt and grow nearer to each other. But doing two versions so NATIVE NON-HDR and NATIVE PBR HDR isn´t economically possible. Its not simply playing with some rulers and getting out the other version. Maybe this fact explains why some shading addons work better with those, worse with other aircraft. For the CRJ and the A330 we went they hard way and not overtook existing material. They were made totally new for the NATIVE PBR environment. Usually it works this way: 1. The simulator platform itself defines how the materials will look by their internal and also for us fixed algorithms. That is the basis which all the industry works on. You fit the product to the base platform you work with, be it Unreal Engine, Unity, Unigine, CryEngine and so on. 2. A new scenery or aircraft product has to obey those rules trying to achieve the most realistic look possible with the given tools and rules. 3. And finally there come the shader mods into action (and not before), there can be done polishing to the result of position 2. Polishing should do an addition, an advance to the product, it should not subtract anything from the experience. Can you imagine how many posts I had to answer before to make that clear? That was valuable, expensive production time which we lost here caused by all the fans of Tomatoes and PTAs and so on not understanding how all those stuff works under the hood and why they got the result they not really loved. Of course the most convinient method to release anger with this half knowledge was to blame the new aircraft products for. The task is now to find a solution together with the 3rd party shading software creators to create presets that do work pleasantly also in the new HDR PBR world. If there should be a global preset that works, which is hard to do seeing how dynamic the visual content became with HDR, that would be cool thing for all. Customers are pleased, we can simply develop and are please instead having constantly to moderate a forum with angry people and you can sell your mods in peace! We want no different thing!
  18. Any "shading plugin" is more or less like photoshop contrast effect which alters the final rendered image. Those were initially thought to beef up FSX content but not do well in the more complex HDR setup coming with Prepar3D. FSX had a fixed dynamic range, so more or less the overall brightness of a pixel in a texture remained all the time the same. Those had to be designed in base much brighter than what HDR in combination with PBR demands to deliver correct results. It would be up to the plugin makers now to update their algorithms to fit the new conditions. We had already a lot of discussion about that. But at first comes sim and provides a base on what we work as developers with. Secondly we design our material to get a possible realistic result using what the platform delivers us by default. And then come the 3rd party plugin makers who do their business on their own. They are not in contact with Lookheed, not in contact with the product designers, but if they want to spice up the material they have to change the workings of their product to the new condititions. Thats why you can go with some aircraft (mostly old FSX aircraft, many ports to Prepar3D use simply old FSX content) and more modern variants get complications (they dont make it i want to underline here). We work with new technology that changed the input for those 3rd party shaders too! Now as the base brightness was higher with FSX, they brought the resulting image more down. And no, adapting our brightness values is not a trivial task and will not happen and you cannot make a texture setup for any shading plugin out there. I count at least four of them now, able to differentiate the settings even more locally. Can you imagine how many "not fitting" variants you can generate with that? That many people not understood yet. They should push TomatoShade, PTA and "what the names are"-producers to go into drive-mode and update their software....
  19. PTA and the NON-HDR settings is a pretty deadly combination and should be avoided. The PTA "shader" set, it more like turning up the contrast on your TV set with a remote control. So values are pulled in the depths and heights and the mid values die. Maybe you should give HDR a try again and strongly reduce the BLOOM value. I have a guess that this causes the shimmering effect, as it adds a glossy seam around any pixel that reaches a certain brightness. So when this pixel value then falls below the threeshold value for the bloom algorithm, i suddenly disappears. Having now a scenario where those values pop above and below that threeshold value, you could get this shimmering effect. So when you activate HDR in your options panels, directly below three sliders become active called BRIGHTNESS, BLOOM and SATURATION. The middle one BLOOM, i would set to 0.0 to 0.3 and try again. PTA and the other 3rd party "shader" stuff have a hard time catching up with the new HDR situation. They were initially designed for FSX to mimmick what HDR does now by default and so the effect is doubled and the contrast balance ruined. We do not recommend the usage of those shaders with our products as we cannot control the million combinations which are possible in the end. The same other aircraft devs have stated similarly.
  20. Hi swap777! Would you say to a classic painter who paints a landscape with clouds that he did wrong? You would maybe say: "He, i´ve seen images of the same landscape without clouds! The painter cannot be a good one, because he ruined my expectations of having an empty blue sky above the landscape !". The same thing you try to prove here currently. You show our product in a single state and then you try an awkward comparsion with not even the same aircraft (speed?, mass?, AOA?, turbulence?, G-Forces?, A330 Tanker with hanging boom instead of a PAX A330). This is a phenomenom i just see too often today by too many people. But there isn´t any logic behind your comparision and you should know better if you had investigated better before doing that post. Our A330 does correct and he does even better than you may anticipate, because the wingflex is even influenced by the deflection forces of pointing up and down ailerons and it oscilates shortly when forces hit it suddenly. To finish the circle here, i tried to force our A330 to slap the wings like the A330 tanker and he is even able to do that....imagine that! PS:If you check the A330 tanker image further you will notice the subtle distortion on large areas of the wings, which is caused by the heat exhaust of aircraft the photo is taken from!
  21. Diffuse textures are called AlbedoMaps in the PBR-age . They are a bit different to the diffuse maps we used in past. For example AmbientOcclusion layers to mimmick diffuse shadowcasting of indirect lighting is completely removed from the "color" maps and now resides as a green channel layer in the MetalMap. The reason for this is, that AmbientOcclusion is now dynamicly faded away when the surface receives direct lighting from the sun or moon. Changes in the UV layout are not planned yet and of course would be fatal for the re-use of older paintkits.
  22. A bit early to ask, as we dont know how the materials are structured in MFS yet(FS2020 i guess you meant). But of course when porting to this new platform it is strongly considered to make the work for repainters as easy as possible.
  • Create New...