Physics and bouncing/rolling question

I'm having fun learning about physic materials, but I'm having trouble getting my head around this one:

I want a ball to bounce perfectly (going forever with no loss of energy) within a maze of sorts. Is it possible to do that AND have it visibly roll?

I've made physic materials for the ground, walls, and ball that makes my ball bounce forever just as I wish--a bounceless ground with bouncy walls was key--BUT the ball floats along without turning. The moment I add surface friction, the ball rolls nicely--but every collision slows it down until it's soon basically dead.

Is there a good way to do this? (Or fake it?) Have the friction affect rotation but not have it affect velocity, somehow? OR have the rotation bounce perfectly into full speed too, so that it's not "dragging" on the ball's motion?

Thanks for any thoughts!

 

Also, maybe blob shadows aren't complete yet, but if they are, how do you make the shadow not spin with the ball? It's trippy but not what I want

I think what I need is to know how to make a child follow the parent's position but not the parent's rotation. Is there a place that documents how parents and children work? My searches haven't turned up much on the subject.

 

Instead of parenting the blob Shadow to the ball use something like...

Code (csharp):

1.  
2. var ball : Transform;
3.  
4. function Update ()
5. {
6.     transform.position = ball.position;
7. }
8.  

This will make the Blob follow the ball's position, but not its rotation.

 

Thanks! I got the blob shadow working.

But it doesn't cast on one of my surfaces, no matter what Shader I choose. It's an object with two materials, and the other material receives the shadow just fine. (It's not an Ignore Layer like I used for the Ball itself. It's just one material, part of a larger model.) Any leads I should pursue?

 

Attach that script to the Blob and then drag the "ball" GameObject over to the "Target" in the Blob's Inspector under the Script Component. That was just a bare bones example script, but if you changed the Blob's projection to ortho it would look ok I guess. But to get it above the ball do...

Code (csharp):

1.  
2. transform.position.y = ball.position.y + 10;
3.  

Put that in after the first line in the Update function.

 

Thanks

I actually found a way to use my hand-positioned projector location, and keep that relative placement. I'm not sure it was the BEST way, but in case it helps anyone else:

Code (csharp):

1. var object : Transform;
2. var diff : Vector3;
3.  
4. function Awake()
5. {
6. diff = transform.position - object.position;
7. }
8.  
9. function LateUpdate ()
10. {
11.     transform.position = object.position + diff;
12. }

(diff is the 3D difference between the object and the shadow as I have initially placed them by eye.)

EDIT: LateUpdate solves the lag issue noted below.

 

I've noticed a problem with the Update() "transform.position = ball.position" method: the shadow lags behind the object by one frame. It looks weird (depending on framerate) for fast-moving objects, including my mouse-driven player object that sometimes moves several inches per frame, leaving a glimpse of a lone shadow trailing far from the object.

Is there a better way to use the blob shadow, that won't lag but also won't spin with the object?

(Also, I've found a workaround for my original question, and my ball is now both frictionless AND rolling. I used FreezeRotation and programmed the rotation artificially instead of physically.)

 

You should put the code in a FixedUpdate() instead of an Update(). Fixed Update has a fixed frame rate for physics.

-Jeremy

 

Thanks. But FixedUpdate doesn't seem to make a difference--it's still one frame behind (which is logical to me--it can't mimic the movement of the object until after the object has moved).

(Also, this object isn't physics-driven, it's moved by mouse delta.)

 

Okay, that's clear then. The Update() functions of various behaviors get called in no particular order.

In one Update() you move your object A.
In another Update() you sync object B's position with A.

Think that through

(You could move your object A, then immediately sync B's position, in the same function.)

d.

 

I fixed it by using LateUpdate for the shadow script, so I'll update my example above.

(I thought I already tried that, but for some reason I accidentally used LateUpdate for the object instead of the shadow. Your post made me think to double-check that, and sure enough, there's the answer. Update for the object, LateUpdate for the shadow.)

I can see how combining them in one script could do the trick too--and I didn't know one script COULD manipulate different objects, so I'll have to look into that for future reference.

Nor did I know you could have multiple Update()s in one script. Very handy--thanks.

 

You can't have multiple Update() functions in the same script. What I belive David was saying, is you are moving your ball from a script attached to the ball, and it seems you are moving the shadow from a different script?

The solution David was talking about, is having a var set up like this in the code for the _ball_ control:

Code (csharp):

1.  
2. var myShadow : GameObject;
3.  

In the inspector, you can now drag your shadow projector object to that variable and refer to it in your script:

Code (csharp):

1.  
2. var myShadow : GameObject;
3.  
4. function Update()
5. {
6.   //-==Ball-moving code here==-
7.  
8.   //now move our shadow to sync it up
9.   myShadow.transform.position = ball.transform.position;
10. }
11.  

Like so. Makes things easier. Usually whenever you have to sync stuff like that, put it all in the same script.

-Jeremy

 

I see--thanks again!

Now if anyone's really bored and can't get enough of my delightful questions... I'm wondering, what is the difference between using...

Code (csharp):

1. var myvar : GameObject;

...vs. using...

Code (csharp):

1. var myvar : SomeScriptNameOnThatObject;

...?

I've been using the latter technique, in order to access variables from the other script. But it also has allowed me to change the transform of the object the script is attached to, just like your example did using GameObject. And both techniques seem to allow me to drag the other object to the inspector in a similar way (although I think the second technique displays MonoBehavior).

Are there advantages/differences between one technique and the other?

 

They are both the same.

Unity programming is OOP (object-oriented programming). So everything including your scripts is an object. So using

Code (csharp):

1.  
2. var myObject : GameObject;
3.  

Is getting the GameObject Class or object of whatever you assign in the inspector, and your second example is doing exactly the same. Same thing different objects.

If you look through the classes in the script ref, you can reference all or most of those as well. That's how you were able to modify the transform of another object, you code was getting the transform class/object/component of that object.

Confusing enough? ;-)
-Jeremy

 

That makes sense--early on I think was confused because many of the examples use variable and script names that sound like they might be pre-defined classes. But I'm getting used to what's user-named and what's not.

So just to be sure--you can do the same things regardless of whether you reference the GameObject class, or the object's script class? Just personal preference?

 

Not exactly... When you reference a custom script, you are just getting that script. So you can reference variables or call functions in it, etc. When you reference a GameObject you get only the GameObject class for that object.

The part where it can get confusing, is certain objects automagically have other objects attached by default. For example doing: var myObject : GameObject; Not only get's you the GameObject component of the object, but also the Transform, etc. If you look through the script ref for each class, you can see what unity automatically attaches/references. The MonoBehvaiour class is what you get when you reference a custom script that derives from MonoBehaviour (IE: any normal JavaScript). So you get your vars and fuctions PLUS whatever comes with MonoBehaviour.

HTH,
-Jeremy

 

Good to know--I'll be mindful of those issues.

I was surprised when referencing a script as a class allowed me to access variables in the script AND to change the transform of the object, but it was nice that it did!

 

Yeah, Unity is great like that. The script reference is a gold mine of useful info.

-Jeremy

 

My #1 resource is Cmd-F on the Alphabetic reference It's not as nice as being able to search ALL the docs, but Spotlight comes in handy there.