Max Power

Member

89

392 Neutral

• Rank
Member

• Interests
Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

1. MorphTarget: Delta Normal / TangentZ ??

Oh wait... I think I get it now. I'm probably just supposed to subtract one from the other, just like with positions. ... right??
2. MorphTarget: Delta Normal / TangentZ ??

Hi. I am looking to procedurally create morph targets for Unreal Engine 4 meshes from variations of a common base mesh. There's a simple-enough struct that contains the per-vertex morphing info: http://api.unrealengine.com/INT/API/Runtime/Engine/Animation/FMorphTargetDelta/index.html The problem is I don't know how to define a delta for a normal vector. I have both the unmorphed and the morphed normal, but what to do with them?
3. solving x*V1 + y*V2 = V3

Np, I appreciate it! Looks almost good now Well, thanks for the advice. First I'm gonna see how it looks, then I may look into that.
4. solving x*V1 + y*V2 = V3

If I have the same 3 triangle vertex positions and a vector I want to save the barymetric coordinates for, shouldn't I get the original vector back like this: BC = ToBarycentricCoords3D(p1, p2, p3, Vec); Vec = FromBarycentricCoords(p1, p2, p3, BC); ??? Because I'm getting different values every time. Am I missing something here? I checked the vertex positions and it's not an index problem - they match.
5. solving x*V1 + y*V2 = V3

Yes, it's called size in UE4 for whatever reason. I forgot to mention that, apparently, locations differ even when the body hasn't been morphed at all and is identical to the initial reference body. Well, if there's nothing wrong with the code I posted, I'm gonna have some debugging to do ...
6. solving x*V1 + y*V2 = V3

Anyone know what I'm doing wrong here?... This is for preparing the "VertMorphInfo" after finding the best (basically closest atm...) triangle for it: VertMorphInfo[v].Vert1 = BodyIndices[t * 3]; VertMorphInfo[v].Vert2 = BodyIndices[t * 3 + 1]; VertMorphInfo[v].Vert3 = BodyIndices[t * 3 + 2]; FVector Normal = FVector::CrossProduct(p1 - p2, p3 - p1).GetSafeNormal(); FVector Pos = FVector::VectorPlaneProject(Pos, Normal);// <-- also tried without projecting FVector BaryCoord = ToBarycentricCoords3D(p1, p2, p3, Pos); VertMorphInfo[v].Weight1 = BaryCoord.X; VertMorphInfo[v].Weight2 = BaryCoord.Y; VertMorphInfo[v].Height = (Pos - p1).ProjectOnTo(Normal).Size(); And this is to update the vertex position after the body shape was changed: FVector Normal = FVector::CrossProduct(p1 - p2, p3 - p1).GetSafeNormal(); FVector BaryCoord(VertMorphInfo[v].Weight1, VertMorphInfo[v].Weight2, 0.f); FVector V = FromBarycentricCoords(p1, p2, p3, BaryCoord) + Normal * VertMorphInfo[v].Height; InstModel.StaticVertexBuffers.PositionVertexBuffer.VertexPosition(Offset + v) = V; It doesn't look just wonky, it's completely off in some regions, slightly off in others. The only other approach I have tried yet was just a placeholder and the simplest thing you can do. I just mapped every clothing mesh vertex to the closest body mesh vertex and kept the offset vector. But even that looks much smoother than what I've got now. There must be something I'm doing wrong.
7. solving x*V1 + y*V2 = V3

Thanks a lot. My mesh is still pretty twisted, but that's probably my own errors... One thing though: does "p" have to be on the triangle plane or can it be anywhere?
8. solving x*V1 + y*V2 = V3

I think that's overkill for what I'm trying to do. Besides, I need to be able to get coordinates outside the triangle as well. So I was thinking, in order to keep the relative location of a single vertex to a given "reference" triangle that can dynamically have all its vertices moved, it should be easiest to just use 1 triangle vertex as the origin and describe the relative location by 2 scalars that are multiplied with the vectors that connect the other 2 vertices with the origin vertex, and then their sum should define the correct position for the "single vertex" at any time. The scalars can be greater 1 or smaller 0 without problems, if the vertex is not on the triangle. So I just need to compute the scalars from the original/initial relative vertex position towards the triangle. That's what I'm trying to do.
9. solving x*V1 + y*V2 = V3

Thanks for replies. I did it like that. Should I project V3 to the triangle plane first, though? And when I use Vector1.ProjectOnTo(Vector2) (it's Unreal Engine), I get another vector. So I suppose I should take its size/length then? And most importantly: what about the scalars? Since the vectors are not orthogonal, I think the resulting point will be off, if I just add them together with their vectors.
10. solving x*V1 + y*V2 = V3

I know this is basically a 5th grade math problem, but I'm very rusty and I was hoping there is a way to solve this thing directly. Background: I am working on a system that morphs clothing meshes based on the (dynamic) morphing/deformation of their underlying reference body mesh. The best I could come up with is to map every clothing vertex to a body triangle in advance and use this data to later shift the vertices with their triangles. My guess is that results will be smoothest, if I keep the relative position of the vertex on the triangle plane, which can be outside the triangle area, if there was no better match to be found. For this, I want to determine x and y, so I can later "restore" them. With triangle positions being t1, t2 and t3, V1 = t2 - t1, V2 = t3 - t1 and V3 = ClothingVertPos - t1 (projected onto the triangle plane). Speed is not an issue, because this gets prepared ahead of time.
11. Need help with interception of accelerated target

By the way, I think I'm having some trouble with the polynomial-root-finder algorithm that you posted a long time ago. I never really noticed before, but right now I am very focused on aiming, shooting, obstacle-checks and things like that, and so I am having a closer look at it. It works very reliable at medium or short distance. But when a character is close to the maximum distance that he can hit a target at (due to gravitation), the root-finder goes crazy and produces very incosistent results.   This is the code: class Polynomial { TArray<float> *coef; public: Polynomial(TArray<float> *C) { coef = C; } int degree() const { return int(coef->Num()) - 1; } double value(double x) const { double result = 0.0; for (uint8 i = 0; i != coef->Num(); ++i) result = result * x + (*coef)[i]; return result; } double derivative(double x) const { double result = 0.0; for (uint8 i = 0; i < (coef->Num() - 1); ++i) result = result * x + (*coef)[i] * (degree() - i); return result; } bool find_a_root(double *output_root) const { double root = 100.0*(-.5 + double(rand()) / RAND_MAX); double old_value = 0.f; for (int i = 0; i<1000; ++i) { double new_value = value(root); if (i>10 && fabs(old_value) <= fabs(new_value)) break; root -= new_value / derivative(root); old_value = new_value; } *output_root = root; return value(root) < 1e-5; } bool find_a_root_with_retries(double *output_root) const { for (int i = 0; i<4; ++i) { if (find_a_root(output_root)) return true; } return false; } void remove_root(double root) { double a = 0.0; for (uint8 i = 0; i != coef->Num(); ++i) { (*coef)[i] += a; a = (*coef)[i] * root; } coef->RemoveAt(coef->Num() - 1); } }; TArray<float> find_all_real_roots(Polynomial p) { TArray<float> result; while (p.degree() > 0) { double root; if (!p.find_a_root_with_retries(&root)) break; result.Add(root); p.remove_root(root); } return result; } I think I have made one or two small changes, but nothing that should have any actual effect. I can post a video later. I just need to find some capture software first.   Basically, when characters get in range of the target, they start twitching like mad, changing their aiming-pitch every frame, even though distance and other parameters stay the same (stationary target). So I looked into it and noticed that the algorithm either produces no positive roots at all, 1 or 2 (like I would expect), or even more than 2, which doesn't make any sense at all to me. The larger root is more (but not completely) consistent than the smaller. The smaller goes up and down like crazy.   This twitching goes on for some distance towards the target and then stops when close enough. From then on the roots seem to be perfectly consistent. Is this bound to happen? Do I need more retries maybe?
12. Need help with interception of accelerated target

Well, it's a top-down kind of game where you control your units like in an RTS. Environments are procedurally generated and stretch over multiple stories. There will be narrow indoor and expansive outdoor areas. So I can't really say there's going to be a typical scale. Combat can take place at close or long range. Weapons should feature as much variety as possible, so there will be relatively slow grenade-like projectiles and very fast beam-like projectiles with anything in between. Some are affected by gravity, others aren't, and some will probably accelerate or decelerate in target/forward-direction. My characters/units are mostly average humanoids with varying size and speed. I made a pretty powerful morphing system with instanced skeletal meshes and I plan on getting the most out of it :p . So, mutants that engage you in melee and run very fast are going to be a thing, as well as slow and big androids.   So, the more accurate, the better, I guess.
13. Need help with interception of accelerated target

Actually, I'm not (currently...) worried so much about turning, because I simply update the aim-direction every few frames and have the character turn towards it until they match before letting him shoot. I know it's not perfect, but so far it has been good enough. I'm more concerned about this offset...
14. Need help with interception of accelerated target

First of all: yay, you are still around :D   Sure, I could make a diagram, but I want to try to better explain the situation first.     I am using the "intercept"-algorithm (3D space, my 2D trip was a short one...) mostly for humanoid characters holding guns in their hands now, so they can predict target and projectile movement and fire in the right direction.   As the origin (the position that the target position is relative to and the point around which the character can rotate when trying to aim) I use a point on the character's up-axis, because it doesn't change when he turns left/right or looks up/down.   My first problem was that it makes little sense and looks terrible when projectiles spawn at this point (inside the character) without an initial distance that matches the distance from origin to muzzle more or less precisely. But as I noticed myself (see previous post), this problem was rather trivial.   The next problem is that a gun's muzzle isn't always located on a line between origin and target. It can be held at hips' height, for example, and the muzzle can be shifted to the right. This is the "vectorial offset" I was talking about. If I neglect this and fire projectiles from origin + initial distance, it still looks terrible, like the character is shooting out of his stomach or something...   If I could, I would spawn every projectile directly from the muzzle, but I need a solution that works with my interception-function, so I think the best I can do is to get this "offset to the side" into it somehow. I mean, if I procedurally tweak my animations a little, especially the blend/aim-spaces that are used for looking up and down, I may even be able to force the offset onto them, so it always looks exactly right. But even without that it should look good enough most of the time.   And, by the way, I intend to make projectiles always fly in the direction of the target-location, even if that means their velocity doesn't match the barrel-orientation 100%, because that's the best I could come up with. This would probably all be much cleaner, if I could use the gun's muzzle as origin. But what good is a computed aim-rotation for a gun that can't rotate freely by itself?...   So, the way I see it, this offset is completely independent of the final computed aim-direction (it's always the same...), but its impact on the computed time of interception varies with distance. And that's pretty much all I've got so far :/
15. Need help with interception of accelerated target

Actually, an initial distance should be very easy to include by adding "p" to the equotion   | (P + V*t + A/2 * t^2) | - (v*t + 1/2 * a * t^2) = 0   making it   | (P + V*t + A/2 * t^2) | - (p + v*t + 1/2 * a * t^2) = 0     I have a feeling that a vectorial offset from the rotation-center will be harder to achieve. But its effect on "t" doesn't necessarily depend on the direction after all, if I can somehow find a "scalar expression" for it...