Vine Arrow

[Springheel]

I had thought we'd make it grow up and outwards, but it might be easier for the player to aim properly if we have it just radiate out from the center.

[SneaksieDave]

If 'pieces' (instead of a single mass) are used, and if they're small enough pieces, I don't think it'll look bad at all if it sticks to odd objects here and there. It won't stick out several feet into the air, if each piece is only a few inches long, and dozens of them are sent out. That, masked/blended with angua's cool particle effect, and it'll appear 3D anyway, so it'll probably look great. Shoot it at a desk full of stuff, and instead of one giant ugly flat blob covering the whole desk, there will be patches of the stuff sticking to everything - very cool!

[OrbWeaver]

The pieces could be spheres (very low-poly, just a smoothed 8-quad diamond shape might even be enough) which are spawned at the detonation site and travel outwards for a while until they hit something, where they remain. The spheres would be textured with an alphatest vine texture, giving the impression of plant growth. Combined with a particle effect this could be very impressive and would not require any special processing (because the spheres would look the same from any direction, so they could land on any surface).

[Springheel]

Wouldn't spheres be difficult to climb though?

 

I guess we'll have to wait until someone implements something that we can try out. It's hard to know how good it will look, theoretically.

 

edit: Just checked out the particle effect--it's excellent! I think if we did something like that (maybe sped up a bit) that left a decal/mesh underneath it when it was done, that would look good. We just have to work out how to handle irregular surfaces.

[Ishtvan]

I had thought we'd make it grow up and outwards, but it might be easier for the player to aim properly if we have it just radiate out from the center.

With the projectile method we were thinking of, it would still be possible to get it to grow upwards rather than outwards if you just set up the angular distribution of the projectiles so that they go from horizontal to vertical and not downward. Btw these would be projectiles set to not be effected by gravity.

 

A problem with that method though is that if you want it to cover a wider radius, you have to either increase the angle distribution or set the "point source" where they start farther back. Increasing the angle spread works up to a point, but if you have say an underhang geometry and the point source is spawned underneath the underhang, it would have to be set farther back if you wanted any vine to stick on the surface above the underhang.

 

Then there's the issue of what if the arrow hits something small close by, and the vine projectiles would spread out way beyond that point to create a useless spread out vine pattern on some far away wall, but I think that can be fixed by setting the projectiles not to travel much farther than the impact point to "point source" distance.

 

Another option would be a "collimated" wall of vine-spawning projectiles, same idea but rather than take a point source diverging in angle, spawn a sheet of vine projectiles all pointing the same way as the arrow was fired, again with the distance set to somewhat behind the impact point, and the projectiles set to detonate without doing anything if they go far beyond that initial point to the impact point.

 

You could of course do a brute force, complicated method that actually spreads out along the surfaces starting at the point hit, testing along the way with traces to detect new angled surfaces, but that would take a long time to code and get right.

[Springheel]

Another issue we'll have to consider is how large an area we want the vines to cover.

[Domarius]

I was thinking the player shouldn't actually climb the vine objects themselves, that might be a bit complicated.

 

One way could be to just distance check between nearby vine objects, and if the player is within a certain tolerance, then the climbing code kicks in as if the nearby geometry is climbable.

[Crispy]

I dunno, I think that's more complicated.

 

Provided the vine patches aren't really bumpy, it shouldn't be too hard to climb them, surely. Anyway, let's try it that way first and then see if it needs to be tweaked.

[Ishtvan]

The new (and old for that matter) climbing code just needs a texture to check for, and should be fine from there. As long as the decal is hit first on a trace toward the wall it's covering, we should be fine. I seem to remember hearing that decals are actually really thin brushes on top of the thing they're on, so that should work.

 

The new climbing code should be able to handle climbing over small gaps in the decals if there are any. As long as the gap is not bigger than the height of the player model in the vertical or width in the horizontal (plus some slop), you'll be able to climb over it.

[SneaksieDave]

Are the blood sprays just decals? I never thought that was a dynamically placed thin brush, but instead just another blend (or whatever, possibly not the right term) on the texture or the brush. Decals can be a thin patch hovering over a brush, but it doesn't seem like it has to be. I just got done playing a short session of RoE, and after smearing a possessed marine all over the wall... and floor... and doorway... and door... with single point blank shot to the chest with the double-barrel, it occurs to me, why don't we just adapt the blood sprays instead of worrying about models or all this other complication? If we could do so with angua's leaves particle, it would look great, and would cover all surfaces that the "spray" hits. Make it permanent, and there you go. Could that be detected just like any other surface?

[Ishtvan]

Could that be detected just like any other surface?

That's what I'm trying to find out. If it is always a thin patch applied then the answer is always yes. If it does some dynamic blend to the texture, the answer is "I don't know." I suspect it might be a patch, because otherwise what would happen if the existing texture and the material you're blending in had conflicting surface flags?

 

I guess the simplest test is to make a blood decal ingame (via a judicious application of violence), and use g_showsurfaceinfo to see if it registers as a different material.

[Ishtvan]

The answer seems to be yes, we can see it with a trace.

 

I slashed a cityguard in the face so that a blood decal appeared there, used r_showsurfaceinfo 1, and where the decal was, I saw textures/decals/hurt1 instead of the cityguard face texture. So yes we should be able to detect decals made in the same way as the "hurt" ones when AI are damaged.

 

I tried it with the current moss arrow, but didn't actually see a difference. I think there might be a problem with this moss arrow decal though, because it seems to be Z-fighting with the texture on the wall. Maybe this only happens with my system, but I see a black z-fighting texture where the moss should be. If the decal is not above the texture in Z, it makes sense that it doesn't get hit by the trace.

[Springheel]

On D3W they said you should put "sort decal" into the shader of the decal to make sure there's no z-fighting, though there seemed to be some disagreement about whether it worked or not.

[Gildoran]

I'm inclined to disagree about "sort decal" affecting z-fighting. I haven't specifically worked with "sort decal", but I believe it has a different effect - it makes sure that the decal is drawn under other translucent surfaces. For example, if you have a blood-stain on a wall, and a window in front of it,

"sort decal" should cause the window to be correctly drawn OVER the blood-stain. Whether or not the bloodstain z-fights should be dependent on whether it has an identical triangle to the surface it covers, or whether polygonOffset is used. Maybe they meant that you should use DECAL_MACRO or polygonOffset.

[Domarius]

Just wanted to say it sounds exciting - simply being able to climb decals...

[Ishtvan]

Hmm, I could be wrong about seeing it with a trace. I assumed r_showsurfaceinfo would do about the same thing as a trace, but this is an internal renderer function so we don't know what it will do. Guess we have to test with a trace, if we can use decals at all (it sounds like we can't in the other thread).