Wind doesn't really change direction on the time scales most games deal in. It tends to gust and die down with the same general directional pattern.

Exactly.

The weather engine already has wind speed and direction down pat.

As you say - its all about the localized sporadic gusts and calms - and how they move across a field of grass over time - coming and going, then springing up again elsewhere - like little dust devils.

What is is is that we're trying to fake the results of a roiling atmosphere above a field of grass, and how the air occasionally buffets it from above as it flow and tumbles by - as well as makes it bend to due general ground wind force.

So Vwind should really be a 3d vector, not just a vector in the x-z plane, and meshes should truly bend. I think i saw a UE4 video that did mesh deformation of grass based on wind. true progressive deformation (IK or lerp, perhaps), not just moving the top verts.

Some posts about weather in my engine for an abandoned game. Might be useful:

https://mtnphil.wordpress.com/category/weather/

I modeled weather on a larger scale, and had some support for gusting like you describe - but I don't think I'd figured out the right model to make "micro-gusting" convincing.

I modeled weather on a larger scale, and had some support for gusting like you describe

At the moment, i'm modeling wind, cloud cover, and precipitation on a global basis (which is really a bit too big for a world 2500 miles across). Temperatures are modified based on latitude. The system is highly dynamic, with climate change effects. I had to run the weather simulation every game hour for 800 game years to make sure it oscillated back and forth over time without going into a death spiral of ever increasing or ever decreasing temperatures.

What about a perlin noise generated texture, where you change the phase of the period over time, so you get noise patterns that move across the texture over time, like an animated texture? Then use the texture to calc local Vwind.

Well, i just tried Vwind on a per instance basis. No go.

The instance data is a worldmat, and dx and dz values (float2).

each frame, i lock the VB, update dx and dz, then draw.

Frame rate dropped from 62 to 22-23 fps. i7-6700 @ 4Ghz, GTX1080 at 10-20% overclock. Still drawing 1 million instances with no culling.

D3DUSAGE_WRITEONLY and D3DUSAGE_DYNAMIC have no noticeable effect.

I would assume that locking a texture and putting the data in there and then setting the texture each frame before i draw would be just as slow.

maybe a set of hard coded textures you cycle through? like an animated alpha map... alpha modulates a global Vwind sent as a shader parameter. then you just set one static texture each draw call, instead of having to update a dynamic texture each call.

Might be useful:

Already found, read, downloaded, and checked out the code. <g>. Your's was one of only two or three samples worth serious investigation. Congrads! <g>

That was one of the places i found example code for two sided lighting. As i recall, there was randomness within the motion of a plant, but no real area effects i could discern.

I may just have to go for randomized motion based on time, trig functions, gobal Vwind, perlin noise, etc. IE constants and uniform variables, and forget about the area effects.

canned animated static textures would work, but you'd need a number of textures in each direction.... unless you had a single big static seamless texture 2 or 4 times the size of the area, and moved your sampling area across it over time with wraparound based on global Vwind.

Guess i'll start by trying to get a good animation based on time and global Vwind and some randomness going first. then i can worry about area effects.

I would assume that locking a texture and putting the data in there and then setting the texture each frame before i draw would be just as slow.

You can just draw into the texture. No need to lock anything to send data from the CPU. My weather simulation (which included a wind vector on a 4m x 4m scale) was all done on the GPU by drawing a bunch of moving blobs for "weather systems".

A bunch of others have suggested simpler solutions with noise functions and such. That might be the way to go.

each frame, i lock the VB, update dx and dz, then draw.

Double or triple-buffer your vertex buffers.

It's generally a terrible idea to try and use a resource on the GPU in the same frame you uploaded it.

You can just draw into the texture. No need to lock anything to send data from the CPU.

No, i'm talking about calculating local Vwind values and stuffing them into a texture,then setting the texture then drawing, then repeat. Either way you send a bunch of dx and dz values. either through a texture,or with the instance data. but you have to lock a texture or buffer every time dx and dz values change.

If i had a set pf pre-generated animated textures, i could just cycle through them. No locking required.

But as i said, that could require a number of textures for various wind directions. although odds are different forms of texture addressing could handle a lot of it.

A bunch of others have suggested simpler solutions with noise functions and such. That might be the way to go.

Yeah, ive decided to start with that, and then see.

Double or triple-buffer your vertex buffers. It's generally a terrible idea to try and use a resource on the GPU in the same frame you uploaded it.

so use 2 or more VBs in round robin fashion... yes, i seem to recall playing around with that back when i was working on terrain chunks. there, i was able to generate and cache static meshes, which turned out to be faster than using dynamic buffers. Even with round robin as i recall.

But yes, pipeline stalls while it waits for the buffer to be available is a distinct possibility. I'll have to give that a shot first. Thanks!

Instance data per chunk is 7.2 meg. cache size is currently 90 chunks. so each extra set of buffers is another 648 meg of data in POOL_DEFAULT memory.

All this seems to be getting kind of big... wait and see what happens, i guess.

No, i'm talking about calculating local Vwind values and stuffing them into a texture,then setting the texture then drawing, then repeat. Either way you send a bunch of dx and dz values. either through a texture,or with the instance data. but you have to lock a texture or buffer every time dx and dz values change.

Ah, I see. I was implying the wind simulation would run on the GPU (that's what I do - just draw a bunch of moving blobby sprites to a texture).