13 minutes ago, akita said:

Too dense forests will kill the CPU when I experimented with it, I wonder what can be pushed with the new engine.

seems it can be pushed pretty far because the CPU shouldn't be much involved with it anymore. All GPU generated on the fly!

3 hours ago, Mike_CFII_MEL said:

started making these tiles at ZL18/19

quick word of warning in that.

18/19 tiles dont just use huge amounts of disk, loadtimes are insane (from seconds to several minutes)

1 hour ago, RXP said:

seems it can be pushed pretty far because the CPU shouldn't be much involved with it anymore. All GPU generated on the fly!

I'm thinking grass, bushes, yield, all dense, mixed with some perlin noise to create harvesting patterns, all reacts to weather and seasons. 

But for it ro be perfrctly scalable it's better to have an associated vegetation shader for terrain (and not just a .for polygon which is perfect for data-driven forests), I wonder what is going on that department, they made it clear that the forests video meant to show only forests (with the new lighting) and not terrain changes.

Edited September 13, 20214 yr by akita

2 hours ago, RXP said:

seems it can be pushed pretty far because the CPU shouldn't be much involved with it anymore. All GPU generated on the fly!

I am a bit skeptical. I am sure you can move a lot of the load on the GPU but you will still need to do draw calls. There is going to be a load on the CPU.

11 minutes ago, fogboundturtle said:

I am a bit skeptical.

I could be as well, unless I read the developers telling it directly:

https://developer.x-plane.com/2021/08/next-generation-trees-and-opengl/

Quote

I can say that the system is definitely built to be able to cope with a lot of trees. This is possible because the new vegetation engine is designed to use very little CPU processing, and instead moves the majority of the work to the GPU. A lot of the heavy processing for trees also happens very early in the frame, at a time when the GPU was mostly idle waiting for actual drawing commands from the CPU. For anyone curious about the technical aspect of this, we make heavy use of compute to cull the list of trees down to just the ones that are actually visible by the camera. We then use that information to prepare one or more indirect draw calls. This way the CPU can send forests that span multiple kilometers for processing and the GPU will generate the rest of the data all by itself.

But what do I know...

Edited September 13, 20214 yr by RXP

This is good information but like everything. I'll wait until I can experience it. I like any process that reduce CPU bottleneck.

8 hours ago, mSparks said:

probably better sticking with linux and mac tbh,

......and see 80% of their PC market disappear in one fell swoop? In favour of the bug infested kernel inside Linux which requires you to have a degree in computer programming in order to get it to work?  It's got to be one of your most ludicrous statements my friend.😂Not going to happen.

49 minutes ago, RXP said:

But what do I know...

Quite a lot it would seem!😀 3D forests and trees will be great but the real deal is whether or not they are in the right place and are not just slapped willy nilly over a fictitious landscape.

Edited September 13, 20214 yr by jarmstro

8 hours ago, RXP said:

I beg to differ: FS2020 has been implemented using an existing rendering engine, and existing FSX code base, and an existing Bing/Azure facility.

Most of the FSX code is still running the show underneath (at least you can see some idiosyncrasies - let alone digging deeper in the entrails - which are leaving no doubts to me), even if on the surface it looks like brand new.

I'm not saying this is not an achievement in itself, bringing all the pieces together and trying to make them work, but there is nothing "from scratch" in FS2020, far from it actually.

I've been even wondering once whether FS2020 couldn't be better if they'd use SimGear/FlightGear core instead of FSX core, while keeping Bing and Forzatech (or whatever it is) rendering engine. At least it would have been more open...

At this point it's better to stop typing and log off. Enough said 

2 hours ago, mSparks said:

quick word of warning in that.

18/19 tiles dont just use huge amounts of disk, loadtimes are insane (from seconds to several minutes)

Hi,

Just finished Mississippi in 18/19 and I'm beginning to see exactly what you mention. 

19 minutes ago, Greazer said:

At this point it's better to stop typing and log off. Enough said

I'm not sure how to read your post. Would you care elaborating further what is it you're thinking?!

The only thing that i think XP has over MSFS are the light orbs. Not talking about the overall lighting but referring to the individual light bulb, orbs or whatever you wish to call it. The actual Lights in XP are connected to an object whereas in MSFS they’re just floating. This is one area that I feel that MSFS is lacking in. If Asobo can fine tune the individual light sources and make them connect to an object then it will definitely make the overall lighting look much more impressive.

1 hour ago, RXP said:

I'm not sure how to read your post. Would you care elaborating further what is it you're thinking?!

The part about "FS2020 has been implemented using an existing rendering engine" - it is common knowledge, and very obvious, that Asobo while they had access to the original FSX code, decided (wisely) to ditch all that dog's brekkie mess and start with a new engine!

@Greazer

I believe I understand what you wanted to say now. Thank you for the explanation!

Now just to make it clear, I also believe in selectively quoting me you're missing maybe the most important part for understanding what I said. Given you didn't seem to understand, it might well be I didn't express myself properly so I'll try again.

@Gulfstream stated that:

Quote

MSFS was afforded the opportunity to literally create modern engine code from scratch, which is a huge leg-up in this game.

Which is what you're also saying with:

Quote

    "to ditch all that dog's brekkie mess and start with a new engine!"

What I'm saying is that nothing from created from scratch at all:

 - Infrastructure was already made by MSFT (Bing/Azure)

 - core game/sim code was already FSX (simvars, sdk, simconnect, events, and more)

 - rendering engine was already made by Asobo (ForzaTec or Asobo own in-house engine already developed for Fuel).

On top of that they've integrated:

 - User Interface middle ware, which they didn't develop either, which is only meant for UI, and that they also use it has the backbone of the JS/HTML "SDK" and at the root of every drawing in the panel (CoherentGT).

 - A number of other components from a lot of other vendors thrown in the mix.

Speaking of FSX code legacy specifically, I can assure you there is a sizeable amount of FSX code running nearly as-is inside the FS2020 code base. It shows not only because of the same idiosyncrasies between FS2020 and FSX, but also when looking deeper inside. However for the latter you'll need to look inside the binaries at the opcode level and if you didn't, it might be a very plausible reason you don't see what I see and therefore can't draw the same conclusions.

What they did code from scratch is the binding between all these pieces and this is an outstanding work on its own for sure, let alone all the new code for FS2020 added atop the legacy FSX code for the most part, and instead of the FSX code for other parts.

Edited September 13, 20214 yr by RXP

 

26 minutes ago, RXP said:

 - rendering engine was already made by Asobo (ForzaTec or Asobo own in-house engine already developed for Fuel).

That is true but from your original statement it seemed like you were saying the rendering engine was built upon FSX rendering engine.  

I think there is nothing from FSX in the "core". They have provided simconnect for backwards compatibility however it is just an API, a way of talking to it.   I have not seen anything to suggest FSX code is running behind simconnect.  That code is all new.