New effects

No clue, that's the first time I read that as well.

And then of course there are different possible implementations. Here some examples, roughly sorted by complexity ascending

- global humidity value dependent on the weather setting

- global, altitude-dependent value (based on some lookup table)

- local, altitude-independent humidity value (dynamic weather)

- local, altitude-independent humidity value, with clouds as separation (below, in, and above clouds different values)

- the full program (altitude, temperature, pressure, weather, clouds are all factors, and their exact values are computed every second or faster, their effect on performance is a function determined in the AFM of each plane)

No clue, that's the first time I read that as well.

 

And then of course there are different possible implementations. Here some examples, roughly sorted by complexity ascending

- global humidity value dependent on the weather setting

- global, altitude-dependent value (based on some lookup table)

- local, altitude-independent humidity value (dynamic weather)

- local, altitude-independent humidity value, with clouds as separation (below, in, and above clouds different values)

- the full program (altitude, temperature, pressure, weather, clouds are all factors, and their exact values are computed every second or faster, their effect on performance is a function determined in the AFM of each plane)

Yeah, I guess you could do an "easy" implementation for static weather where humidity is also static, perhaps varying according to altitude, but where it gets interesting is when you couple this dynamic with the existant weather system. One could think of localized ground fog that can develop if conditions allow or other visible weather effects.

So far, temperatures don´t ven change in the dynamic weather system. Last time I checked, if you set up a mission in Nevada @ 4:00 am with 10°C, it will be 10°C at 1:00 pm as well, regardless of the weather.

It´s probably not worth the effort to do all this just for vapor effects. If any "real" humidity component was or is implemented / in development, it would have to be in the changelogs somewhere. I usually read them top to bottom, but can´t recall seeing anything related.

Sobek, could you please clarify. I´m sorry if it´s something too obvious that I´m asking for, but I really missed the whole humidity manifestation within DCS.

By the way, that would also affect contrail altitude for example.

Right now it is static in DCSW I think.

The higher CPU clock frequency will net necessarily improve CPU performance that much.

It is.... complicated. I can't really explain it well, here are two links that try to:

https://www.comsol.com/blogs/havent-cpu-clock-speeds-increased-last-years/

https://www.quora.com/Why-havent-CPU-clock-speeds-increased-in-the-last-5-years

Bottom line (kind of):

They do get faster, but that is not linear with clock speed.

Is there any plan to open up another cpu core? We have 1 for sound and 1 for everything else, is that correct? Would another core be possible/worthwhile?

Not as easy as it sounds. The main challenge is timing and dependency on data generated by calculations.

I had a pretty basic equation a while ago, that explains the general issue with multi-threading/multicore processing.

http://forums.eagle.ru/showpost.php?p=1728877&postcount=36#

In DCS for example how would a unit know, it has been hit, when the bullet trajectory calculation is only available in another thread? How can you check collisions of objects, if they are on different cores? And so on...

Yeah, it sounds so easy. And actually: Graphics cards do that.

We are talking about CPU cores though, aren't we? All the stuff you mentioned is not done in the CPU.

Shagrat's example is very simplified, but it shows that distributing operations over several cores can - quite often - make them take longer instead of gaining speed. Because the organization also takes time.

EDIT:

Even more severe are problems that have parts that rely on part reults to do the rest.

Imagine baking a cake. You won't gain that much speed by letting another pastry chef do the icing/decoration on the baked cake, because he needs to wait for the cake to come out of the oven. He can't do that in a parallel operation.

In complex simulations there are a lot of such problems that you just cannot distribute.

EDIT2:

...also I think we are getting off topic. We are talking about two things:

#1 will rain effect impact performance?

#2 could multi-core use solve that?

The answer for #1 is: probably. But if it mainly runs on the GPU we may be fine.

The answer for #2 is: pretty sure it can't.

Yeah, it sounds so easy. And actually: Graphics cards do that.

 

We are talking about CPU cores though, aren't we? All the stuff you mentioned is not done in the CPU.

 

Shagrat's example is very simplified, but it shows that distributing operations over several cores can - quite often - make them take longer instead of gaining speed. Because the organization also takes time.

Yes, and I know ED did consider it so they have selected what is best for the future I guess.

Yeah, it sounds so easy. And actually: Graphics cards do that.

 

We are talking about CPU cores though, aren't we? All the stuff you mentioned is not done in the CPU.

 

Shagrat's example is very simplified, but it shows that distributing operations over several cores can - quite often - make them take longer instead of gaining speed. Because the organization also takes time.

Partly that even requires CPU for land grid/object collision checks, scene compositing, before the GPU actually renders the scene.

As you said the main issue is the management of data that needs to be sent to the GPU every frame to get a consistent screen output.

In the end all cores need to wait for each other to have the scene data ready before sending it to the GPU to do the rendering, z-fighting, texturing, lighting, Post-FX to produce a frame that can be shown on the screen.:weight_lift_2:

EDIT: That is why ED chose to seperate the sound engine to a second core. It does not require millisecond accurate synchronisation with the world...

ED / DCS Forum is for discussion of ED / DCS Products and Topics, not comparisons to other flight sims.

Maybe the conversation has moved away from this point, but I dont think weather effects should be tied to humidity. It would be an oversimplification.

As for rain, what kind of rain are we talking about? Heavy showers are a lot different than drizzle and mist. When talking about reductions in vision, that would have be heavy rain from a particular weather situation.

Ive said it in a couple places, but in terms of all weather effects, I feel like a simplified frontal system would work best because its location (randomized) could then spawn one of only a couple combinations of cloud/their associated effects. The clouds themselves follow a pattern, rather than being random.

Not as easy as it sounds. The main challenge is timing and dependency on data generated by calculations.

 

I had a pretty basic equation a while ago, that explains the general issue with multi-threading/multicore processing.

 

http://forums.eagle.ru/showpost.php?p=1728877&postcount=36#

 

In DCS for example how would a unit know, it has been hit, when the bullet trajectory calculation is only available in another thread? How can you check collisions of objects, if they are on different cores? And so on...

Events.

Events.

DIFFERENT cores?

Core1 wait and check events from core 2 on each cycle?

not so much for graphics myself, optimisation and easy for a pc to run is much more important

however -rain is something that needs much improvement droplets moving across glass to make visability reduced, this is something that real pilots have to deal with and would be great to introduce into DCS

DIFFERENT cores?

Core1 wait and check events from core 2 on each cycle?

That's a bit exaggerated. There are ways to do that a bit more efficiently. The problem with the management overhead is still there though.

Oh, and just for the record since I just noticed my post got deleted: Links to videos of other games for showing examples for effects are also forbidden it seems, not only if the linked games are flight sims.

I will suggest putting that into the forum rules to avoid confusion.

If anybody wonders what I was talking about: There is a rather new and well-known rally game that has a great rain effect, which I think is a good example because it isn't dynamic, but it _looks_ dynamic.

Some of those techniques can be computed solely on the graphics card, and save the precious CPU performance.

That's a bit exaggerated. There are ways to do that a bit more efficiently. The problem with the management overhead is still there though.

 

 

Oh, and just for the record since I just noticed my post got deleted: Links to videos of other games for showing examples for effects are also forbidden it seems, not only if the linked games are flight sims.

I will suggest putting that into the forum rules to avoid confusion.

 

If anybody wonders what I was talking about: There is a rather new and well-known rally game that has a great rain effect, which I think is a good example because it isn't dynamic, but it _looks_ dynamic.

Some of those techniques can be computed solely on the graphics card, and save the precious CPU performance.

I was refering to the multicore issue, only.

Rain would be another full screen overlay that requires RAM and additional shaders... though, when I remember my last flight to Munich, as soon as the plane accelerated on the runway, the raindrops where basically blown away in milliseconds after they hit the window. I guess in a jetfighter the cockpit screen should be pretty blown clear of any raindrops at the typical speeds.

The streaks and mist that block your vision would remain though.

Any real life jetpilot mind to share his thoughts?

How noticable are raindrops on a bublle canopy at 350 kts?

I also am not quite sure about that. Would love to hear some real pilots' view on that. There are rain/snow removal devices on a lot of planes, even fast ones.

Example: http://www.anft.net/f-14/f14-detail-rain.htm

Also keep in mind DCSW also supports slow planes and helicopters. The need for wind shield wipers on helis clearly shows that rain or snow can be an issue.

But yes, I also expect for jets that the effect would be mostly visible when on the ground and/or at low speeds, at least at forward facing windows or bubble canopies. On the sides the rain/snow will probably be visible at higher speeds as well.

This forum never ceases to amaze me!

DIFFERENT cores?

Core1 wait and check events from core 2 on each cycle?

Developer here.

One thread can raise an event which is read by the main executing thread. These events are subscribed to by executing code (it doesn't matter what thread they are on). When it hears the event being fired it picks up any parameters that are passed over by that event and acts on it.

The event handler is known as a delegate.

EDIT: Also, CPU cores have NOTHING to do with threads. I wish people would stop thinking this.

I think people have in mind that CPUs try to spread threads to different cores if possible. So if DCSW would create more threads it would use more cores (if more cores are available).

EDIT: But I'd like to go back to my question #6 because that one is related to wind/snow removal:

I wonder how ED could do that. I imagine it to be a pain in the behind for a third party to go back to their module and change something to have the rain/snow effect implemented. Perhaps such things are covered by the third party license agreement (pure speculation, since those are not public AFAIK), I guess there are paragraphs that basically say "the 3rd party has to implement some stuff from time to time after release to make sure the module stays compatible to DCSW".

But being a software dev myself I wonder about technical stuff of course. :)

So maybe a modeler will be provided with a different material to use for the windows that are supposed to be subject to the rain effect, instead of the normal glass, and the renderer just applies the rain/snow shader to those. And then there is an API function that can be used to clear the glass with one of a few pre-baked removal animations. So when implementing the wipers or other removal tools the 3rd party developer 'just' has to create the wiper animation and call the removal function for that (part of the) window. Something like that.

Yep, multithreading does not require multicore.

What I meant is, the event does not necessarily help.

In DCS a lot of stuff is dependent on each other. AI, bullet trajectories, could in theory be calculated in a different thread, but the overhead to ensure synchronization may not be worth to completely rewrite the current game engine, they currently introduce?

Currently all objects interact in the same world. They need collision detection, against each other, the ground, projectiles, missiles, trees, buildings etc.

My guess is, ED developers have a very good reason, they only separated the sound engine.

If it would be, that easy, they would have done it in EDGE.

Yep, multithreading does not require multicore.

What I meant is, the event does not necessarily help.

In DCS a lot of stuff is dependent on each other. AI, bullet trajectories, could in theory be calculated in a different thread, but the overhead to ensure synchronization may not be worth to completely rewrite the current game engine, they currently introduce?

Currently all objects interact in the same world. They need collision detection, against each other, the ground, projectiles, missiles, trees, buildings etc.

 

My guess is, ED developers have a very good reason, they only separated the sound engine.

If it would be, that easy, they would have done it in EDGE.

Yes. The only processes that can be threaded are processes that will work asynchronously. That is non-essential tasks that other processes do not rely on (ie block).

I would imagine Air Traffic Control processing could be async and also loading textures async could reduce slow down of the overall sim.

Yeah, there are a few I could think of, but not really many.

In any case the people who expect that suddenly there could be 20 parallel DCSW threads running and they can use the full potential of their i7 CPU are most likely mistaken.

ATC is mostly sound engine, I guess.

Texture loading should already load a dynamic “bubble“ around the Player, since EDGE.

They vastly impoved the performance through relieving the DirectX 9 object bottleneck.

Damage model calculations and effects for example can be done asynchronous, I made a suggestion in that direction, a while ago. They plan on overhauling a lot of stuff, anyway.

It just takes time. :)

Oh man, don't get me started with ATC. I really hope they surprise us with something AWESOME in 2.5

As for the effects (graphics and gameplay): There is SO much potential in this engine, even though some of it takes quite long to develop. I even think DCSW could become the first sim with proper icing (see question #10 in the first post). And that's very exciting!

O with proper icing (see question #10 in the first post). And that's very exciting!

Which one?