Wind not modelled. Doesn't vary over/behind terrain and Windward/Leeward winds are identical.

[TEMPEST.114]

From every test/calculation and spot test I've made for months, there is zero modelling of wind, other than a gradient vector applied constantly at the same height all over the map. Buildings, mountains and other 'terrain' make zero difference to wind or turbulence. 

It seems even when there is a turbulence i.e. burble - it's a manufactured one and not because of the wind direction, strength or size/shape of the island on the carrier. 

This means that even hiding behind a skyscraper you still get wind 'blowing' you 'through' the skyscraper. 

Is this ever going to be addressed?

[speed-of-heat]

Bear in mind that such a calculation is likely to be computationally expensive...  Like wake turbulence but with many more factors modelled, it becomes quite complex to deliver in anyway real-time, and that's in single player, you would also want to do so in multilayer which would be additionally complex... I suspect that the prerequisite would be the availability of sufficient resources such as say the ability to utilise a large number of the available cores I a modern cpu for such calculations... the initial multi core work, is essentially very basic in this regard.

Edited January 22, 2023 by speed-of-heat

[WipeUout]

Have you tried also going over the top of mountains? There is a bit of wind effect I noticed when flying close to mountain top.

Nevertheless, I must agree with @speed-of-heat, this would require so much resources to simulate and I don't think we are there yet with the present code and even hardware capabilities.

[Durham]

Here is the code to determine the wind direction and heading at two points - one a vehicle on the windward side of the mountain, the other on the leeward.

--functions region
function round( x )
	local f = math.floor( x )
	if (x - f) < 0.5 then --round down
		return f
	else
		return f + 1 --round up
	end
end--function round

function getHeading( windVector )
	local result = 0
	local heading = math.atan2( windVector.z, windVector.x )
	--default_output_file:write("Done heading math!\n")
	if heading < 0 then
		heading = heading + 2 * math.pi --put heading in the range of 0 to 2 pi
	end
	heading = heading * ( 180 / math.pi ) --convert radians to degrees
	result = round( heading )
	--spin the heading by 180 to conform with aviation norms!
	if result > 180 then
		result = result -180
	else
		result = result + 180
	end
	return result
end --getHeading

function getSpeed( windVector )
	local result = 0
	local speed = (windVector.x^2 + windVector.y^2 + windVector.z^2)^0.5 --m/s
	speed = speed * 1.94384 --to knots
	result = round( speed )
	return result
end --getSpeed

--say you're starting
trigger.action.outText('WindTest starting...' , 5 , true)

--get the location of each of the units
--groups
local unitWindward = Unit.getByName('Windward-1')
local unitLeeward = Unit.getByName('Leeward-1')

--positions - vec3
local posWindward = unitWindward:getPosition().p
local posLeeward = unitLeeward:getPosition().p
--log write the positions
log.write('WINDTEST', log.INFO, 'Pos_Windward: x = '..posWindward.x..'; y = '..posWindward.y..'; z = '..posWindward.z..'.')
log.write('WINDTEST', log.INFO, 'Pos_Leeward: x = '..posLeeward.x..'; y = '..posLeeward.y..'; z = '..posLeeward.z..'.')

--increase the altitudes by 10m
posWindward.y = posWindward.y + 10
posLeeward.y = posLeeward.y + 10

--surface heights - number - currently unused
--[[
local heightWindward = --land.getHeight(posWindward.x, posWindward.z)
local heightLeeward = --land.getHeight(posLeeward.x, posLeeward.z)
log.write('WINDTEST', log.INFO, 'height_Windward: = '..heightWindward..'.')
log.write('WINDTEST', log.INFO, 'height_Leeward: = '..heightLeeward..'.')
]]--

--winds - vec3 - for the two units
local windWindward = atmosphere.getWind(posWindward)
local windLeeward = atmosphere.getWind(posLeeward)

--windspeed and heading for the two units
local windspeedWindward = getSpeed( windWindward )
local windspeedLeeward = getSpeed( windLeeward )
local windHeadingWindward = getHeading( windWindward )
local windHeadingLeeward = getHeading( windLeeward )

--log.write the results of the loop
log.write('WINDTEST', log.INFO, 'Wind_Windward: x = '..windWindward.x..'; y = '..windWindward.y..'; z = '..windWindward.z..'.')
log.write('WINDTEST', log.INFO, 'Wind_Leeward: x = '..windLeeward.x..'; y = '..windLeeward.y..'; z = '..windLeeward.z..'.')

--log.write speed and heading
log.write('WINDTEST', log.INFO, 'Wind_Windward: heading (deg) = '..windHeadingWindward..'; speed (kts) = '..windspeedWindward..'.')
log.write('WINDTEST', log.INFO, 'Wind_Leeward: heading (deg) = '..windHeadingLeeward..'; speed (kts)= '..windspeedLeeward..'.')
--write results to user
trigger.action.outText('Wind_Windward: heading (deg) = '..windHeadingWindward..'; speed (kts) = '..windspeedWindward..'.', 5 , false)
trigger.action.outText('Wind_Leeward: heading (deg) = '..windHeadingLeeward..'; speed (kts)= '..windspeedLeeward..'.', 5 , false)
--say you're done
trigger.action.outText('WindTest completed.' , 5 , false)

WindTest.lua
4 KB

Here are the log results:

2023-01-22 02:30:47.957 INFO    WINDTEST (Main): Wind_Windward: x = -20.213688330495; y = 0; z = 32.348655590497.
2023-01-22 02:30:47.957 INFO    WINDTEST (Main): Wind_Leeward: x = -20.66910287424; y = 0; z = 33.077471069346.
2023-01-22 02:30:47.957 INFO    WINDTEST (Main): Wind_Windward: heading (deg) = 302; speed (kts) = 74.
2023-01-22 02:30:47.957 INFO    WINDTEST (Main): Wind_Leeward: heading (deg) = 302; speed (kts)= 76.

So even with a big mountain between the two the windspeed is identical, give or take the 2kts because one unit is higher than the other.

I agree with the previous comments that computing this only the fly is going to be ridiculously expensive, however, as the wind doesn't change over time, other than the altitude slope, then could pre-compute with mission load?

 

 

WindTest_NTTR.miz

[Exorcet]

If you want CFD on terrain and cities, yes real wind is expensive, but that's not the only option. The terrain can be broken up into large grids classified roughly as moutains, plains, city, etc and have different wind effects modeled.

Also, X-Plane and MSFS model this for terrain.

[Durham]

3 minutes ago, Exorcet said:

If you want CFD on terrain and cities, yes real wind is expensive, but that's not the only option. The terrain can be broken up into large grids classified roughly as moutains, plains, city, etc and have different wind effects modeled.

Also, X-Plane and MSFS model this for terrain.

And they likely pre-compute on mission/session load?  So chat with Austin required?

 

[Exorcet]

9 hours ago, Durham said:

And they likely pre-compute on mission/session load?  So chat with Austin required?

 

X Plane can use live weahter (I think MSFS can too) so I don't think the wind interacting with terrain is fixed, but dynamic like the rest of weather. I should also clarify that when I said the other sims model "this", I was referring to wind over terrain, not the grid method I was suggesting. The grid method would make sense to precompute currently since DCS doesn't have varying weather.

[TEMPEST.114]

On 1/22/2023 at 2:26 AM, speed-of-heat said:

Bear in mind that such a calculation is likely to be computationally expensive...  Like wake turbulence but with many more factors modelled, it becomes quite complex to deliver in anyway real-time, and that's in single player, you would also want to do so in multilayer which would be additionally complex... I suspect that the prerequisite would be the availability of sufficient resources such as say the ability to utilise a large number of the available cores I a modern cpu for such calculations... the initial multi core work, is essentially very basic in this regard.

 

Nonsense. XPlane, MSFS and Condor 2 can do a very good job of wind with no hit to performance. Again, binary thinking doesn't get anyone anywhere. 

1 hour ago, Exorcet said:

X Plane can use live weahter (I think MSFS can too) so I don't think the wind interacting with terrain is fixed, but dynamic like the rest of weather. I should also clarify that when I said the other sims model "this", I was referring to wind over terrain, not the grid method I was suggesting. The grid method would make sense to precompute currently since DCS doesn't have varying weather.

It does have varying wx now. The clouds, precipitation etc move over the map. Thus it should change the wind over land / buildings.

[Germane]

Yeah thats a very important topic for me. I hope for a much better simulation in the future!

[WipeUout]

5 hours ago, Elphaba said:

Nonsense. XPlane, MSFS and Condor 2 can do a very good job of wind with no hit to performance. Again, binary thinking doesn't get anyone anywhere. 

I believe that DCS does much more as far as simulation of other stuff such as weapon, enemy AI, troop movement, radars, etc...  Very different sims!

[TEMPEST.114]

1 minute ago, WipeUout said:

I believe that DCS does much more as far as simulation of other stuff such as weapon, enemy AI, troop movement, radars, etc...  Very different sims!

Binary thinking fails again.

Windage AFFECTS dropping bombs, straffing, landing, hovering, canyon flying low level... basically EVERYTHING IN DCS. 

[Ironhand]

Like Elphaba I, too, would like to see better modeling of the medium we “fly” through. Hopefully things can start moving in that direction in the not too distant future.

[WipeUout]

13 hours ago, Elphaba said:

Binary thinking fails again.

Windage AFFECTS dropping bombs, straffing, landing, hovering, canyon flying low level... basically EVERYTHING IN DCS. 

Thinking alone fails again.

What is being simulated in MSFS, X Planer etc.. is much less demanding than a FULL COMBAT SANDBOX  like DCS.  Adding yet another dimension like weather modeling, would for sure be cool and increase realism but at a cost that would result in even less performance.  It already takes a top rig to run DCS in VR, last thing we need is more stuff being simulated.  DCS needs to first solve performance and then look at cranking additional realism or whatever the customer wants next.

 

[oreste]

If you say it is too much to calculate low altitude or mountain crest turbulence then so is wake turbulence.
They gave us wake turbulence and now we wonder if we can also have other types of effects, it was obvious that would happen
I hope so much, especially the currents that form near the crests of the mountains and at very low altitudes.

[draconus]

MT is out, you can use 1 or 2 threads for the winds, clouds and other atmosphere stuff.

[Lace]

36 minutes ago, draconus said:

MT is out, you can use 1 or 2 threads for the winds, clouds and other atmosphere stuff.

This is the ideal solution (and add in water swell, chop and current effects for good measure).

[jstnj]

On 1/21/2023 at 9:26 PM, speed-of-heat said:

Bear in mind that such a calculation is likely to be computationally expensive...  Like wake turbulence but with many more factors modelled, it becomes quite complex to deliver in anyway real-time, and that's in single player, you would also want to do so in multilayer which would be additionally complex... I suspect that the prerequisite would be the availability of sufficient resources such as say the ability to utilise a large number of the available cores I a modern cpu for such calculations... the initial multi core work, is essentially very basic in this regard.

 

multiplayer does not complicate this at all. The local "sandbox" of weather must to be the same, yes... but its fine if one player has a gust decoupled from another. That's perfectly fine compromise. MSFS and even Xplane 11 has been doing this for years on hardware a decade old.

Edited April 28, 2023 by jstnj

[Whirley]

+1