Josh Posted April 17, 2021 Share Posted April 17, 2021 Oh ok, I see it is map 6... Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 14 minutes ago, Josh said: I ran the project and it look like it is running a terrain generation program? If I run in release I mode I get this error: index field 'targetPoint' (a nil value) In spiderleg.lua, line 50, when running the "start" map. You need to reset the targetPoint to sphere_Far and Sphere 1 as in the screenshots. It was in the map data but probably lost when you opened it somehow. Quote Link to comment Share on other sites More sharing options...
Josh Posted April 17, 2021 Share Posted April 17, 2021 The reason this problem is difficult is because there are two layers of unknowns. Is the rotation being calculated correctly? Is the rotation being set correctly? So I am trying to eliminate one of those so I can see the other... Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Josh Posted April 17, 2021 Share Posted April 17, 2021 There's a lot of places this could go wrong. There are extra bones in the animated model hierarchy One of the limbs up the hierarchy is scaled to 100,100,100 One of the limbs up the hierarchy has a 90 degree pitch Any of those things could be acting in an unpredictable manner if the rotation calculation code isn't 100% perfect. If it is possible I would be looking to simply that model leg and try to get it as close as possible to the working leg. If you look at this map you can see the calculation is definitely consistent, which is good. test.map 1 Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 1 minute ago, Josh said: There's a lot of places this could go wrong. There are extra bones in the animated model hierarchy One of the limbs up the hierarchy is scaled to 100,100,100 One of the limbs up the hierarchy has a 90 degree pitch Any of those things could be acting in an unpredictable manner if the rotation calculation code isn't 100% perfect. If it is possible I would be looking to simply that model leg and try to get it as close as possible to the working leg. The rotation is set like this - during runtime the entity of the script makes a new pivot on itself and set itself as child of the new pivot - this new pivot points at the target point so it eliminates two axis of rotation - to set the x rotation of the leg the two bones are determined and a triangle with base from leg origin to target is made. - then from the length of the origin of the leg to the knee, and from the length knee to the target, the other two sides are determined. - with that there is enough information to calculate two angles, one of the upper leg and lower child leg and set. (something with arccos) For the latter, I am confident they are calculated correctly because one of the leg works when inverted. For the leg with bone, I already tried to store offset rotation at start and add it to the calculated rotation with weird outcome. When I modeled the leg I tried to keep it as clean as possible. Everything that came out was not avoidable. Quote Link to comment Share on other sites More sharing options...
Josh Posted April 17, 2021 Share Posted April 17, 2021 I think what is happening is the rotation calculation is probably somehow "naive". It works fine with a simple hierarchy but breaks down when parents have rotations on other axes, or something like this. This happens all the time in animation code, it is very difficult stuff... Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Josh Posted April 17, 2021 Share Posted April 17, 2021 Is it possible to create and display a box at the calculated position of the knee and foot? Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 1 minute ago, Josh said: Is it possible to create and display a box at the calculated position of the knee and foot? Hard to make because only distance is taken into account. To place boxes at the starting position and then relate them to copy over the rotation would be possible. I will do this right now and post the script. Quote Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 I have replicated the issue with three boxes. They are now doing the same weird rotation as the leg with bone (but are just boxes with relation) 1 Quote Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 At this time I have come to the conclusion that every type of entity has different rotation "offset" that is all over the place. I have had the boxes align to the leg model without bones, align it to the leg with bones but now I broke everything and cant revert it. I need to find some universal rule for inversing the rotations. They are as I found out by default not inverse. Thats why it's called "Inverse Kinematics" ha. Here is the script that creates boxes as knee etc. Still need to experiment with it to make it work on everything oldSpiderLeg.lua Quote Link to comment Share on other sites More sharing options...
Slastraf Posted April 17, 2021 Author Share Posted April 17, 2021 I have played around some more and managed to align the boxes to the other spider leg again. But as soon as I enable another leg and it comes into view , not before, the whole thing breaks again. Here another script where you can enable/disable. Look at the video, its very weird. oldSpiderLeg.lua Quote Link to comment Share on other sites More sharing options...
Josh Posted April 18, 2021 Share Posted April 18, 2021 I think you need to make a choice now. You have a basic implementation that will work in simple controlled circumstances. One option is to try to tune everything so that it will work in this one controlled situation. Get a basic rig working and then maybe copy the orientations of some hidden boxes to the model's bones, and just experiment with that very carefully and try to hide / avoid the situations where that implementation is not complete. This is something that AAA games do all the time. They don't showcase their weaknesses, they try to hide them. The other option is to develop a general-purpose IK feature for any model. IK is a very complex topic. At NASA there are special libraries they use to control robotics. However, they are working with six joints and you are working with two that are aligned to the same plane, so that makes life a lot simpler. If you went this route I would be implementing this programmatically in C++ and testing with a lot of different models. The benefit is you have something that works 100%, but it will take a long time to figure out. Which is better for your purposes? Only you can decide. 1 Quote My job is to make tools you love, with the features you want, and performance you can't live without. Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.