GrassVertOut GrassVS( GrassVertIn IN, float4 posv : POSITION0 ) {
GrassVertOut OUT;

OUT.texcoords = IN.texcoords;

//Animate grass
float proxydist = distance(posv.xy, EyePos.xy);
if (proxydist < 30)
{
//Insert fun Trigonometry! (Push verts away from camera)
}


float4 worldpos = mul(IN.pos, world);

float height = clamp(IN.pos.z, 0, 100) / 100;

float2 wind = WindVec * 2.5 + 0.25;

float2 pos_ticks1 = worldpos.xy / 1000 + ticks;
float2 pos_ticks2 = worldpos.xy / 750 + ticks * 2;
float2 pos_ticks3 = worldpos.xy / 500 + ticks * 3;
float2 pos_ticks4 = worldpos.xy / 200 + ticks * 4;

worldpos.xy += ( sin(pos_ticks1) + cos(pos_ticks2) + sin(pos_ticks3) + cos(pos_ticks4) ) * height * wind * 10;

//Define % to Fog
float dist = length(worldpos.xyz - EyePos.xyz);
OUT.fog = saturate( (FogRange - dist) / (FogRange-FogStart) );

//Define % to Blend
OUT.blend = saturate( (BlendEnd - dist) / (BlendEnd-BlendStart) );

//Projection
OUT.pos = mul(worldpos, view);
OUT.pos = mul(OUT.pos, proj);

//Texture Projection
OUT.screenpos = mul( worldpos, TexProj );

//Lighting
OUT.color = (SunCol * 0.25) + SunAmb;

return OUT;
}

Hi Peter,

I think the main problem with what you're trying to do is that the EyePos constant contains the position of the camera, not the player. So while this might kinda work in first person view, it would look really weird in 3rd person view because the invisible camera would be rustling the grass somewhere where there isn't anything. You might want to try to ask the people working on MGE and MSE whether there's some way that they can get you the actual position of the player's feet.

As far as the math, I think you'd just need to create a vector that goes from the center of the player's feet to the worldpos of the current vertex using subtraction, and then push the vertex in that direction by an amount that varies with distance. I can't remember what posv is, but the local position of the vertex is stored in IN.pos. It's not in world coordinates until it's multiplied by world in the next line to create the worldpos vector. To make it vary with distance, you would then calculate the length of that vector before normalizing it. Then you'd use a mathematical function that starts at one when the input is zero and goes down to zero when the input is 30. A linear function would probably be fine. At this point, multiplying the normalized vetor with this scaling factor so that the vertices that are close would cause them to get pushed one unit away from the player's feet while the ones that are far wouldn't get moved at all. You could then multiply that result by some constant scaling factor like 20 so that the vertices close to the player move by 20 units instead of one unit, which would have a more visible result.

Good luck,
--LizTail

Man, I wish I could help you. I know exactly what you're saying but I'm not familiar with that script language.

That's a great idea! oo:

Would this work on NPCs traveling in Grass, too? Is there any way to find where a mesh collides with the landscape (i.e., the feet)?

Couldn't you use MWSE to check the cell references for NPCs and then use ref-GetPos? You could use GetAngle to determine facing, too.

I know it's possible to do--probably not that hard. I was working on a soultrap mod for a little while that scanned all the creatures in a cell to check if they had been soultrapped. Unfortunately, getspelleffect->soultrap is bugged :/

Thanks a lot =)

In other words, you would then pass on the result of ref1x, ref1y, ref1z and up into the Ingame.fx file and then I would need to convert it to some kind of world coordinates that the shader understands.

Isn't GetPos slow tho? I guess it would essentially run every frame for every NPC in the cell... sounds like a load.

That is the problem :/

I know I'm going into the uninviting world of ordinary Morrowind scripting now, but could http://www.uesp.net/wiki/Tes3Mod:GetCollidingActor be helpful at all?
Maybe you could combine it with GetAngle, I mean you only need to know when they collide with the grass and the angle, not necassarily the position, don't you? :shrug:

edit: Thought tbh I'm not sure if an fps drop would be caused by having it on so many objects.

So you can't attach Morrowind scripts with MGE rendered things, but you can attach MWSE scripts, why's this? :huh:

Though I said it might cause an fps impact, I'm not sure it'd be as great as using GetPos.
Lava detects collision, and yet they don't cause any fps drop at all. x50 and they probably will, but you'll get that with your position method anyway.
It would be less flexible, but very accurate (larger things will activate more than one grass automatically for example), and detecting collision is more fps friendly than GetPos in most cases.
I thought this was how most games do this anyway, through collision?

About Morrowind using a variable to get actor position, isn't that what GetPos uses?
Attaching a script that tracks wherever something goes every frame is gonna cause an fps lag, maybe the function could be optimized or something though. :shrug:

GrassVertOut GrassVS( GrassVertIn IN, float4 posv : POSITION0 ) {
GrassVertOut OUT;

OUT.texcoords = IN.texcoords;

//Animate grass
float proxydist = distance(posv.xy, EyePos.xy);
if (proxydist < 30)
{
float3 worldpos = mul(IN.pos, world);
float3 shift = worldpos - EyePos;
shift /= 10;
worldpos += shift;
}
else
{

float4 worldpos = mul(IN.pos, world);

float height = clamp(IN.pos.z, 0, 100) / 100;

float2 wind = WindVec * 2.5 + 0.25;

float2 pos_ticks1 = worldpos.xy / 1000 + ticks;
float2 pos_ticks2 = worldpos.xy / 750 + ticks * 2;
float2 pos_ticks3 = worldpos.xy / 500 + ticks * 3;
float2 pos_ticks4 = worldpos.xy / 200 + ticks * 4;

worldpos.xy += ( sin(pos_ticks1) + cos(pos_ticks2) + sin(pos_ticks3) + cos(pos_ticks4) ) * height * wind * 10;

//Define % to Fog
float dist = length(worldpos.xyz - EyePos.xyz);
OUT.fog = saturate( (FogRange - dist) / (FogRange-FogStart) );

//Define % to Blend
OUT.blend = saturate( (BlendEnd - dist) / (BlendEnd-BlendStart) );

//Projection
OUT.pos = mul(worldpos, view);
OUT.pos = mul(OUT.pos, proj);

//Texture Projection
OUT.screenpos = mul( worldpos, TexProj );

//Lighting
OUT.color = (SunCol * 0.25) + SunAmb;
}

return OUT;
}
GrassVertOut GrassInstVS( StatInstVertIn IN, float4 posv : POSITION0 ) {
GrassVertOut OUT;

//Pack instance transform
float4x4 worldmat = float4x4(IN.m1, IN.m2, IN.m3, IN.m4);

OUT.texcoords = IN.texcoords;

//Define % to Fog
float4 worldpos = mul(IN.pos, worldmat);
float dist = length(worldpos.xyz - EyePos.xyz);
OUT.fog = saturate( (FogRange - dist ) / (FogRange-FogStart) );
OUT.blend = 1 - (saturate( (GrassDist-dist) / (GrassDist/5) ));
OUT.blend += 0.4;
OUT.screenpos = 0;

//Animate grass
float proxydist = distance(posv.xy, EyePos.xy);
if (proxydist < 30)
{
float3 worldpos = mul(IN.pos, world);
float3 shift = worldpos - EyePos;
shift /= 10;
worldpos += shift;
}
else
{

float height = clamp(IN.pos.z, 0, 100) / 100;

float2 wind = WindVec / 6;

float2 pos_ticks1 = worldpos.xy / 1000 + ticks;
float2 pos_ticks2 = worldpos.xy / 750 + ticks * 2;
float2 pos_ticks3 = worldpos.xy / 500 + ticks * 3;
float2 pos_ticks4 = worldpos.xy / 250 + ticks * 4;

worldpos.xy += ( sin(pos_ticks1) + cos(pos_ticks2) + sin(pos_ticks3) + cos(pos_ticks4) ) * height * wind * 10;

//Projection
OUT.pos = mul(worldpos, view);
OUT.pos = mul(OUT.pos, proj);

//Lighting
OUT.color = (SunCol * 0.25) + SunAmb;

}
return OUT;
}

I'm not sure, lava has no collision yet it can detect when the player is on it through HurtStandingActor, I think GetColliding functions work the same way.
I'm sure lava detects collision, because you can go above or below lava and not be hurt. It knows when you're touching the lava, so it's collision, isn't it?
Plus Bounding Boxes are the things which collide.

Lava simply has a box under it that does have collision, you're standing on it so "GetStandingActor" and "HurtStandingActor" work for it :shrug:


http://www.uesp.net/wiki/Tes3Mod%3a%50CGet3rdPerson anyone?

Bump for the early crowd. I'm right now trying to figure out why my edits do not yield any results so far, I'm right now trying to debug it by adding some extreme behaviours and maybe even some temporary color changes when you get close to a mesh so it "activates" for it to be modified.

Very cool, I hope it all works out, because seriously, the first game I remember having this effect was Knights of the Old Republic, and I remember thinking how incredible it was, to be honest, its still one of the coolest effects in a game, I'd love to see it in morrowind!

I am very excited about it too.

@C_Mireneye
I want to help but I never look that side of the codes. Are you editing ingame.fx only or MGE's c codes too?