Lecture 200 - Detecting Pins Have Settled (1) Feedback

[Farhan]

Hi everyone,
I have just started on the BowlMaster Section and was having some trouble following this particular lecture. I know Unity 5 has been updated since the lecture was recorded, and it is possible that’s the reason, but I couldn’t follow the part where Ben simplifies the bowling pins by copy pasting collider and render components as doing so makes the pins disappear. I have tried doing it multiple times, and maybe I am missing something, but it wasn’t simply working for me. So here’s the alternative code I am using in PinSetter.cs (without changing any pin prefabs) -

void OnTriggerExit(Collider collider){

    GameObject collidedWith = collider.gameObject;

    if(collidedWith.GetComponentInParent<Pin>()){

        Destroy(collidedWith.transform.parent.gameObject);

    }

This seems to work as intended and saves the trouble of going through all the pin settings, but I am not sure if leaving the pins as they are, is going to make it harder following the future lectures.

If anyone can let me know if this is OK, or provide me a solution for the pins disappearing, I would really appreciate it.

Thanks!

[JoseCuenca]

Hi @Farhan,

I had the same issue. Actually, the bowling is not disappearing (at least in my case), but it gets scaled down a lot. I think that might be related with some process at the beginning, when creating the prefab of the bowling. I’m not really sure why that happened.

I did the same than you, let’s see if that makes some problem in the future. But at the moment, I’ll consider this as a good solution.

If at some point that creates some issue, and I need to fix it, I’ll let you know.

Regards!

PS: maybe, just scaling them up would work fine. I don’t think scaling will create any issue in this kind of game. So we could consider that as a solution?

[JoseCuenca]

BTW, I’ve just noted that, when the pin is small you need to scale it up x100. That means, that the problem might be some information about the scale, but was converting cm into m, and now it’s using just cm as default for the pin.

Just t let you know that the scale is exactly x100, just in case you want to try.

[JoseCuenca]

Well, at the end I just cleaned the pins, so I could remove the children, and I scaled then x100.
Everything looks working fine. That way I have exactly the same than @ben has in the scene.

Best!

[Mike_Schoenhals1]

[HELP]Has anyone actually got this working? Every time I try and follow Ben’s instruction on simplifying the Pin, the Render Mesh disappears. Mine doesn’t scale down as you mention, it just goes away completely. As soon as I delete the Pin_Render, it’s gone. All I can see is the collider when I click on it.

[UPDATE]I’m going to use the code mentioned above but it would be nice to see how you get a collider and render version together for a model (ie: no parent child).

[Farhan]

@JoseCuenca @Mike_Schoenhals1
Sorry for replying so late guys. Unfortunately it’s been a while since my last post and I have moved on to other projects.
I don’t remember the problem clearly but the code I shared does work and is in fact lot simpler.
Hope it works out for you guys.
Goodluck!

[JoseCuenca]

@Mike_Schoenhals1 I hope you got this working fine. Sorry for answering so late. I’m always thinking that I’ll get some kind of notification in my email when someone adds a comment in a topic where I was writing, but it’s not like it works, and then, when I logging here, I get several messages waiting.

In my case, I only can say that the problem was the scale. So, I don’t know exactly the reason why yours just disappears. I know that you already said that yours is not scaled down. But I have to say, that it happened to me as well that I though mine was gone, and when I scaled the pins to 100, I got them back.

Well, let me know if at least the code from @Farhan worked for you or not.

Cheers!

[Michael_Fontanini]

The steps in this video flat out do not work. I am using Unity 5.4.1f1 on Windows.

You cannot rotate a pin to -90 as he does in the video. If you do, it reports a rotation of -90 in-game rather than 270 like he shows. Worse, this rotation runs you straight into a bizarre problem. When you rotate the pin to -90 or 270 on the X axis, and then you try to rotate it on the y or z axis, you will find that those two axis now act as if they are one and the same when you rotate. So a 30 degree y rotation results in the same physical orientation as a 30 degree rotation on the z axis. I looked up this behavior and found on the Unity Forums that it is a manifestation of the dreaded gimble lock (and that most game engines internally use Quaternions for rotations to avoid this problem).

Additionally, the code detecting that the pins have settled doesn’t work. This is because a further consequence of this setup and the gimble lock problem is that in-game you will notice that the rotation on the y and z axis both fluctuate wildly from -60 to 60 (or something like that) on each pin.

I have no idea how Ben made this video without running into this incredibly serious show-stopper of a problem! I’m also surprised no one else has commented about this issue either. Surely I can’t be the only one experiencing it, right?

Luckily, there is a fairly simple way to fix this issue. Create an empty object and put it inside the Pins group object. Reset its transform to 0,0,0. Copy the values of the pin’s transform component onto this new object. Now parent Pin 1 to this object. Change Pin 1’s X-axis rotation to 0 (reset its transform since it’s position should be 0,0,0 relative to the parent). Set the rotation of its new parent object to -90 or 270 on the X-axis. Now the rotation properties behave normally in-game. Edit the IsStanding() method in the Pin script and remove the “270 -” that he added in this video. Change the code for the Z-axis to target the Y-axis instead, because Z is now the vertical axis due to that initial 90 degree rotation. Lastly, go to the line in the IsStanding() method that gets the rotation and change “.EulerAngles” to “.LocalEulerAngles” so we get the local angles without the parent transform added in. Repeat for the other 9 pins. So basically, we’re just giving each pin a parent object again, and putting the rotation onto that parent. Then the pin’s rotation is completely independent of that initial -90 degree rotation, preventing the gimble lock issue from rearing its ugly head!

By the way, I did not experience any of the other issues people have mentioned in here as I followed the video. The renderer is still there on my pins and scaling is fine.

[Antonio_Gallo]

The same here, but I get it to work by copying also the Pin_Render (Mesh Filter).

[rob_willemse1]

I’m also on Unity 5.4.1f1 and doesn’t encounter the same problem as you do. I’m just fine with following this lecture.

[Michael_Fontanini]

That’s interesting and odd. I’m glad it worked for you without that hassle I ran into, though! I wonder what caused it.

[Bram_Weinreder]

My simple fix is actually also GetComponentInParent (singular not plural, so no array). I think that’s a bit of an oversight in the video. My simple code is as follows:

	void OnTriggerExit (Collider other)
	{
		Pin pin = other.GetComponentInParent<Pin> ();
		if (pin) {
			Destroy (pin.gameObject);
		} 
	}

To clarify: I fetch the Pin component in the parent object if it has one, and destroy the gamecomponent it is attached to (so basically the parent of the child that has the collider). Didn’t take much tinkering, and is a full repeat of things we’ve done before.
Hope this helps!

[Donald_Whisenhunt]

I have the exact same problem - I need to read on up gimble lock. I avoided this problem for a while by using what others have said about GetComponentinParent (not the array). But latter when you are working on the Renew() it makes more sense to have the Collider on the Pin. I will try your solution. I thought I was going crazy!!

[Michael_Fontanini]

I thought I was going crazy too when I had this problem. lol. I hope my solution or at least someone’s works for you! That solution fixed it quite nicely for me.

[Donald_Whisenhunt]

I had everything working fine, until the falling through the floor, video. I know understand that so I may just go back to having the child Pin_Collider and Pin_Render-- I am trying to decide which is easier at this point…

[Donald_Whisenhunt]

Ok I think I finally solved this problem for real. It is odd there is not much out there on shaking ridgebodys. I tried your solution and it improved the situation but the pins were still vibrating slightly (the game would work but it bothered me). So I found that if you increase the Default Solver Iterations from 6 to 50 the shaking completely stops. It seems for these objects 6 iterations was not enough to figure out a final spot for them to be sitting. You could also get them to stop moving by Increasing the Sleep threshold from 0.05 to 1. I did not like this solution since it takes a second or two to kick in and it was also just masking the problem. I feel much better now!!!

[Bitty]

Thanks, Michael. Your tip works perfectly in 5.5.1f1 and saved my sanity. Hopefully this will be changed in the next iteration of the lesson.

[Cndymn]

Thanks for this! Thought I was going mental trying to figure out why my IsStanding() counts were jumping all over. Found the setting in Edit->Project Settings->Physics and changed it to 50 as you stated. Works perfect now!

[Unreal_N]

I did as you said and the pins stopped wobbling. I read up about default solver iterations and it says if you are having problem with rigidbodies, then you should increase the value. But what is this value actually? What does it do? I am really confused about it.

[Donald_Whisenhunt]

I believe there is an optimization routine that is used in the physics engine. If you don’t give it enough cycles it does not really know the exact position of the rigid body. Of course too many cycles hurts performance.

Donald