Jump to content
Sign in to follow this  
ChaoticBeauty

September 24th, 2020 - Development Update

Recommended Posts

Don't understand something.  Why would aircraft (not sure about airport) DEVs keep working on their products for MSFS now, if in near feature DX12 will come along and require them to re-work their products yet again?  At this point, why not just wait until all the current bugs, DX12 is released, and new DX12 bugs are all worked out?


Aaron Ortega

AMD Ryzen 7 5800X3D 3.4 GHz 8-Core Processor, Asus TUF GAMING X570-PLUS (WI-FI) ATX AM4 Motherboard, Samsung 980 Pro 2 TB M.2-2280 PCIe 4.0 X4 NVME Solid State Drive, SAMSUNG 870 QVO SATA III SSD 4TB, Asus TUF GAMING GeForce RTX 3090 24 GB Video Card, ASUS ROG STRIX 850G 850W Gold Power Supply, Windows 10 x64 Home

Share this post


Link to post
Share on other sites
1 hour ago, Dreamflight767 said:

Don't understand something.  Why would aircraft (not sure about airport) DEVs keep working on their products for MSFS now, if in near feature DX12 will come along and require them to re-work their products yet again?  At this point, why not just wait until all the current bugs, DX12 is released, and new DX12 bugs are all worked out?

Why do you think a change in rendering API would require them to 're-work' their projects? The game is already using a PBR pipeline so assets wouldn't need any change. Not that companies like carenado are actually bothering to do it correctly.

Share this post


Link to post
Share on other sites
13 hours ago, omarsmak30 said:

If I am right, we will expect monthly world updates? 

World Updates are going to be 2-3 months.

Edited by Tuskin38

Share this post


Link to post
Share on other sites
12 hours ago, Will Fly For Cheese said:

Yes I would. Everyone should be on the case with the faults. Pretty scenery can wait.

They're gilding the lily while it's being eaten alive by big ugly bugs.

The devs who work on scenery would not bethe same devs who work on the Airplanes or the other systems and you can't just bring a scenery dev onto the aircraft team, that's not their specialization/knowledge base. 

Work on the Japan World Update would not take time or resources away from the aircraft team fixing their bugs, they're separate teams.

 

Edited by Tuskin38
  • Like 5

Share this post


Link to post
Share on other sites
1 hour ago, Dreamflight767 said:

Don't understand something.  Why would aircraft (not sure about airport) DEVs keep working on their products for MSFS now, if in near feature DX12 will come along and require them to re-work their products yet again?  At this point, why not just wait until all the current bugs, DX12 is released, and new DX12 bugs are all worked out?

They probably rushed their products out to earn the front spots in the Marketplace and increase their earnings. Both the Orbx London City Pack and the Carenado CT182T were not in a very good state at release. There is also another aircraft that is said to be terrible and a shameless cash grab.

  • Like 1

Share this post


Link to post
Share on other sites

  Consider the possibility that the ambiguity over the word "update" is intentional.  There is such a huge difference between a "patch" and the promise of a patch that the purpose of using the same word for both is obvious. It is to foment extended discussions like this in order to increase the "buzz" about the product.

   Anyone at MS who was interested in clarity rather than obfuscation would have caught this glaring problem immediately--they're not.

    Anyone who was interested in promptly  fixing the bugs in the aircraft and SDK would have replaced the scenery developers with programmers who worked on those things. 

     That might not create as much of this weekly corporate hype but it would serve to concentrate on the fundamental characteristic of any flight simulator--flight

    For those primarily interested in scenery there is a flight sim module in Google Earth.  It is very simple of course but it is at least honest.

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, TASCHMANN said:

  Consider the possibility that the ambiguity over the word "update" is intentional. 

 

Quote: "Depending on what the meaning of the word "is" is"..

Nice to know that you at least know how to fix this!  There is hope yet.. 🙂

 

Edited by Bert Pieke

Bert

Share this post


Link to post
Share on other sites
1 hour ago, L3m0n said:

Why do you think a change in rendering API would require them to 're-work' their projects? The game is already using a PBR pipeline so assets wouldn't need any change. Not that companies like carenado are actually bothering to do it correctly.

The PBR pipeline is not the same in DX11 and DX12.

When loading a texture, it may be necessary to generate the mipmaps for the texture. A mipmap is a smaller version of the original texture. The first mipmap (at level 0) is the original texture. The mipmap at level 1 is half the size of the mipmap at level 0 and at level 2 is half the size of level 1 and so on. DirectX 12 no longer provides a method to automatically generate the mipmaps for a texture. It is the responsibility of the graphics programmer to generate the mipmaps for a texture. A compute shader is used to generate the mipmaps  in DX11 and is not available in DX12 at this time.

This is one of the biggest reasons for chewing up VRAM if the MipMaps are not generated correctly in DX12

In addition textures need to load via a Library rather than having direct support as in DX11 and of course there will be debate about WHICH lib to use.. will it be DirectXTex or another one?  However, this wasn't fully released until this year (fully still being debated) and is the Microsoft option..  however it is strictly Windows and won't work, or be useable on either Mac or Linux for development houses that use Mac for graphic work.

There are also differences in how Pipeline State Objects work in DX11 and DX12..  certainly this means that the DX12 may be more efficient, but it doesn't mean by any means that you can just take graphics that have been produced for DX11 and assume they will work in DX12.. they may, but then again they may not even if they are still PBR.

Most DX12 applications use a wrapper to convert DX11 functions and procedures to DX12 which is fairly simple to write, but of course all this really does is add CPU cycles with no material benefit from actually using the low level programming capability of DX12..  the oly way to really do DX12 properly is design it from the ground up as DX12 or do a FULL conversion, and that could affect a huge amount of already built stuffs 🙂

Just a few examples of potential issues that may crop up 🙂

Graham

 

Edited by Moria15
  • Like 4
  • Upvote 1

System specs...   CPU AMD5950,  GPU AMD6900XT,  ROG crosshair VIII Hero motherboard, Corsair 64 gig LPX 3600 mem, Air cooling on GPU,   Kraken x pump cooling on CPU.  Samsung G7 curved 27" monitor at 2k resolution ULTRA default settings.

Share this post


Link to post
Share on other sites

Good write-up.

 

Thanks

bs


AMD RYZEN 9 5900X 12 CORE CPU - ZOTAC RTX 3060Ti GPU - NZXT H510i ELITE CASE - EVO M.2 970 500GB DRIVE - 32GB XTREEM 4000 MEM - XPG GOLD 80+ 650 WATT PS - NZXT 280 HYBRID COOLER

Share this post


Link to post
Share on other sites
2 minutes ago, Moria15 said:

The PBR pipeline is not the same in DX11 and DX12.

When loading a texture, it may be necessary to generate the mipmaps for the texture. A mipmap is a smaller version of the original texture. The first mipmap (at level 0) is the original texture. The mipmap at level 1 is half the size of the mipmap at level 0 and at level 2 is half the size of level 1 and so on. DirectX 12 no longer provides a method to automatically generate the mipmaps for a texture. It is the responsibility of the graphics programmer to generate the mipmaps for a texture. A compute shader is used to generate the mipmaps for a texture when the texture is loaded which is not always needed in DX11.

In addition textures need to load via a Library rather than having direct support as in DX11 and of course there will be debate about WHICH lib to use.. will it be DirectXTex or another one?  However, this wasn't fully released until this year (fully still being debated) and is the Microsoft option..  however it is strictly Windows and won't work, or be useable on either Mac or Linux for development houses that use Mac for graphic work.

There are also differences in how Pipeline State Objects work in DX11 and DX12..  certainly this means that the DX12 may be more efficient, but it doesn't mean by any means that you can just take graphics that have been produced for DX11 and assume they will work in DX12.. they may, but then again they may not even if they are still PBR.

Just a few examples of potential issues that may crop up 🙂

Graham

 

Why wouldn't there be mips for everything already? The package tool generates them so unless a developer is exporting all there textures by hand than its a non-issue. And every single tool, from nvidia texture exporter plugin in photoshop to compressonator by default exports textures with mips. If there is a hypothetical developer who, for some reason, is intentionally not creating mips then that is a very corner case scenario.

And I have fabulously not idea what you are getting at with directtex. Most of the games textures are BC7 which, once again, the package tool will convert for you. BC7 is also supported in just about every tool out there regardless of windows/linux/mac. 

As for the last part, there is no way they are going to change there BSRDF just for a port to DX12. What would be the point? Why do something like that?  Oh and you absolutely can port from DX11 to 12 without issues, its not like MS decided to remove/change a bunch of instructions for giggles.

Share this post


Link to post
Share on other sites
20 minutes ago, L3m0n said:

Why wouldn't there be mips for everything already? The package tool generates them so unless a developer is exporting all there textures by hand than its a non-issue. And every single tool, from nvidia texture exporter plugin in photoshop to compressonator by default exports textures with mips. If there is a hypothetical developer who, for some reason, is intentionally not creating mips then that is a very corner case scenario.

Some tools don't automatically generate mipmaps or maybe the dev / designer doesn't want to use them.

Regards

bs

Edited by bean_sprout

AMD RYZEN 9 5900X 12 CORE CPU - ZOTAC RTX 3060Ti GPU - NZXT H510i ELITE CASE - EVO M.2 970 500GB DRIVE - 32GB XTREEM 4000 MEM - XPG GOLD 80+ 650 WATT PS - NZXT 280 HYBRID COOLER

Share this post


Link to post
Share on other sites
9 minutes ago, L3m0n said:

As for the last part, there is no way they are going to change there BSRDF just for a port to DX12. What would be the point? Why do something like that?  Oh and you absolutely can port from DX11 to 12 without issues, its not like MS decided to remove/change a bunch of instructions for giggles.

https://software.intel.com/content/www/us/en/develop/articles/tutorial-migrating-your-apps-to-directx-12-part-3.html

and that's just part of the issues.  Look at ANY application that's been ported from DX11 to DX12 (rather than written in DX12) and see how long it's taken for the DX12 version to become even vaguely stable and efficient.  Assuming DX12 is just a straight port is just that  assuming, and actually MS HAVE removed a whole load of instructions because of moving from a wrapper to a low level interface.

Graham

Edited by Moria15

System specs...   CPU AMD5950,  GPU AMD6900XT,  ROG crosshair VIII Hero motherboard, Corsair 64 gig LPX 3600 mem, Air cooling on GPU,   Kraken x pump cooling on CPU.  Samsung G7 curved 27" monitor at 2k resolution ULTRA default settings.

Share this post


Link to post
Share on other sites
29 minutes ago, Moria15 said:

https://software.intel.com/content/www/us/en/develop/articles/tutorial-migrating-your-apps-to-directx-12-part-3.html

and that's just part of the issues.  Look at ANY application that's been ported from DX11 to DX12 (rather than written in DX12) and see how long it's taken for the DX12 version to become even vaguely stable and efficient.  Assuming DX12 is just a straight port is just that  assuming, and actually MS HAVE removed a whole load of instructions because of moving from a wrapper to a low level interface.

Graham

Shader model 6 supports 100% of shader model 5 instructions which is what actually matters for rendering things. So why would they change the lighting equations in any way? What would be the point?

The game is doing lambert for diffuse and cook-torrence for spec - why would that have to change in DX12? Although hypothetically they could change it to something like oren-nayer without needing any changes to the assets, the same metal, rough and albedo channels could be used without a problem.

I'm just not getting how going to DX12 would cause a ton of issues for third party developers. There isn't going to be a big change, if any, in how all the lighting is being calculated. So what if some (bad) developers who have never heard of mips need to learn how to check a single tick box. This isn't going to be some huge change like what happened with P3D or likely will happen with Xplane.

Most of the issues you are referencing above are related to memory management in DX12. Which is a challenge since now its more like a DIY kind of thing. But I don't see how that will have any impact at all on what a given asset looks like in-game. Or how said assets need to be created.

  • Upvote 1

Share this post


Link to post
Share on other sites
11 minutes ago, L3m0n said:

Shader model 6 supports 100% of shader model 5 instructions which is what actually matters for rendering things. So why would they change the lighting equations in any way? What would be the point?

The game is doing lambert for diffuse and cook-torrence for spec - why would that have to change in DX12? Although hypothetically they could change it to something like oren-nayer without needing any changes to the assets, the same metal, rough and albedo channels could be used without a problem.

I'm just not getting how going to DX12 would cause a ton of issues for third party developers. There isn't going to be a big change, if any, in how all the lighting is being calculated. So what if some (bad) developers who have never heard of mips need to learn how to check a single tick box. This isn't going to be some huge change like what happened with P3D or likely will happen with Xplane.

Most of the issues you are referencing above are related to memory management in DX12. Which is a challenge since now its more like a DIY kind of thing. But I don't see how that will have any impact at all on what a given asset looks like in-game. Or how said assets need to be created.

I hope you are right, but having worked on conversion projects from DX11 to DX12 I see it as a potential nightmare that could take a long time to sort out..  My undying hope is that in the sim there is a button so you can choose which DX you want to use so that we don't all have to put up with months of faffing around as people get used to the new requirements for DX12 if we are happy on DX11.

Graham

Edited by Moria15

System specs...   CPU AMD5950,  GPU AMD6900XT,  ROG crosshair VIII Hero motherboard, Corsair 64 gig LPX 3600 mem, Air cooling on GPU,   Kraken x pump cooling on CPU.  Samsung G7 curved 27" monitor at 2k resolution ULTRA default settings.

Share this post


Link to post
Share on other sites
12 hours ago, kaosfere said:

THIS.   Thank you.   Companies can do multiple things at once, especially when it comes to different areas requiring high skill.  The amount of people who think you can just move workloads around on demand on technical teams always bemuses me.    It's like saying, "This hospital could do more brain surgeries it they took all the heart surgeons and made them do brain surgery."   Sure, you might get some outcome, and probably a better one than if you asked a random dope off the street to do it.  But I wouldn't want to trust my brain to a heart surgeon.  Or my heart to a brain surgeon.

 

6 hours ago, Tuskin38 said:

The devs who work on scenery would not bethe same devs who work on the Airplanes or the other systems and you can't just bring a scenery dev onto the aircraft team, that's not their specialization/knowledge base. 

Work on the Japan World Update would not take time or resources away from the aircraft team fixing their bugs, they're separate teams.

 

Exactly! You can delegate tasks between people in the same team/area but not people from different areas. In fact, cross area delegation would most likely make things worse. 3D modellers and scenery developers wouldn't have the knowledge to work on flight model or avionics coding and vice versa. Or heart surgeons not working on brain surgeon tasks as kaosfere said. It's really not hard to understand.

  • Like 3

Steven

Intel i7 950, Gigabyte GTX 960 2GB G1 Gaming Edition Gigabyte RTX 2060 OC 6GB, 12GB RAM, HDD SSD

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...