Camera follows a character ever cut by a wall?

[Dad72]

How can we ensure that the camera is always behind a character but ever cut by a obstacle, for example. 

Imagining that one is on the inside of a house, if you enter a room and it orbits the character, it is found behind the wall. 
If that would be useful is that the camera moves inside the room to always face the character.
 

 

Do I proposed the idea of this ​​camera? (I do not know how it is technically called).

[Aerion]

Give the camera collision?

[Dad72]

The collision of the rotating camera freezes as soon as it collides.

[Stephen Andrews]

Raycasting would probably be useful for this. See if there is a clear line-of-sight for the camera, then move closer until there is.

[joshcamas]

I've been working on this for a while. So far nothing has been achieved, but I'll post if anything happens.

 

Also, love the image! XD

[Dad72]

Raycasting would probably be useful for this. See if there is a clear line-of-sight for the camera, then move closer until there is.

 

Can you elaborate a bit more your idea, I'm not sure I understand. Thank you   

 

PS: @joshcamas: The link in your signature is dead 

[Stephen Andrews]

 

Can you elaborate a bit more your idea, I'm not sure I understand. Thank you   

 

PS: @joshcamas: The link in your signature is dead 

I'd elaborate, but I have no idea how to do it, only the concept.... Sorry.

[joshcamas]

The idea is that you shoot a ray from the camera to it's target, and then see if it intersected with anything. Then position the camera at the intersection nearest to the target.

 

Yea I need to change the link  I'll do that when I update SamacEditor

[Dad72]

Thank you anyway Triblade9. Josh yes, I can see a better idea. I'll try to experiment and see if I succeed to a result.

[joshcamas]

I built a really simple playground right here: http://playground.babylonjs.com/#1VITHH

Basically the camera is the yellow sphere, the green box is the target, and the grey cube is a piece of terrain. The idea is that you push a mesh that you want to be considered "solid" into an array.

But why doesn't the intersection detection work right? It should turn red when it touches, but it doesn't do it completely...

[Dad72]

Thank you Josh, this seems a very good starting point.

and for : It should turn red when it touches, but it doesn't do it completely.

I think that for the detection is not complete, is that the camera see the cube green while the wire is still in contact with the cube grey.

Thank you for the start. it remains only that the camera moves past the gray cube when the wire is red.

 

 

 

 

 

[joshcamas]

Yea even when the line IS intersecting with the mesh, it thinks it isn't unless at the very center:

 

Why doesn't the ray intersect this? Shouldn't it?

[joshcamas]

Actually... ok this is very weird:

http://playground.babylonjs.com/#1VITHH#2

If I move the mesh, it still detects it strange! Why!

[Dad72]

Ah, yes indeed, it's very strange. I think you found a bug. What do you think Deltakosh,this looks like a bug?
 
I try a different approach, but same thing there to bug I think :
http://playground.babylonjs.com/#1VITHH#8 (Having said that the fil is still in contact with the cube ???)
 
PS: Josh It's a small detail, but the right syntax:  new BABYLON.Color3.Yellow => BABYLON.Color3.Yellow(); 

[joshcamas]

After over an hour of banging my head against the wall and finding nothing, im 99% sure its a bug

[RaananW]

Hi Guys, did a little personal debugging :-)

the problem is in the Ray.prototype.intersectsBoxMinMax() function (Class Ray in Typescript).

Found out that when one of the direction's value (x,y or z) is 0, the code reacts weird.

in general, this code : 

 

if (Math.abs(this.direction.y) < 0.0000001) {                if (this.origin.y < minimum.y || this.origin.y > maximum.y) {                    return false;                }}

is the cause of the bug.

I managed to "fix"it by commenting it out and adding the following lines to the "else" part (three times, once for x, once for y and once for z, else should be removed, of course, since there is no if):

var inv = 1.0 / this.direction.x;var min = (minimum.x - this.origin.x) * inv;var max = (maximum.x - this.origin.x) * inv;/* My addition */if(max==-Infinity) {     max = Infinity; }

The -Infinity happens due to the inv value (division with 0). It should be Infinity, since at a later part of the function maxValue is being determined, and if it is -Infinity (well, the smallest value JS can produce ) maxValue is always too low and the fucntion returns false.

This is just a hack (which solves the problem). I couldn't quite understand the math part of the if() section. What is being tested there? Maybe the one who wrote it can elaborate

[GameMonetize]

Hey sounds like you fixed the bug:)

 

could you send me a PR?

[RaananW]

Sure, will have to update my repository. Will be sending it later today.

[Dad72]

this is done: I sended the correction of Raananw on the deposit GITHUB.

 

[edite] Oops: Raananw sorry, I ais done while you were writing the message. But I mentioned that the correction is you.

[RaananW]

hola,

 

I was working on uploading the fix and found out this goes deeper than i thought. After my fix is in (looks a bit different than what i wrote before, but in general works the same), the intersectsBox function in the Ray class can be used to determine whether the ray intersects with the BoundingBox of the Box (which is == the box). But, After further checking the intersects function in Mesh :

var intersection = cube.intersects(ray);

I found out this function has some other problems as well. The main problem is the intersectsTriangle in the Ray class, which delivers wrong results.

I am not yet sure which function is to blame, but the root of the problem is this function. I am working on a fix for that, this might take some time.

A few things i found - 

To determine the triangles, subMashes is being used. the problem here is that the triangles are in local coordinates, but should be in world coordinates to determine if a ray (in world coordinates) intersects with the triangle.

I believe this is the main problem of the function (it is simply tested, try moving the box a few units up, the result (red line) will still be in the same position).

Other than that, the direction vector should be normalized etc' etc'.

I am working on a fix, but don't have all day for that. So this might not be today.

@Deltakosh, you have used the Möller–Trumbore intersection algorithm, which is delivering weird results in that case. Do you have any idea where I should look (apart from the two things i wrote before)?

[RaananW]

Wow, that was a long day.

Ok, a few corrections, new findings etc' etc' :

The only thing missing in the code is the world/coordinates conversion of the submesh vectors. The rest was simply an error in understanding what origin and direction means. I haven't noticed that at the beginning, but it is now clearer - 

Look at this example - http://playground.babylonjs.com/#1VITHH#9 . It works! Check lines 41 and 42, this is the fix for the problem - a direction vector between the cam and the target objects. If the middle box is not at 0,0,0 the detection will be weird due to the missing local-to-world conversion of the submeshes. This is a way to fix it - http://playground.babylonjs.com/#1VITHH#10

@JoshCamas and others - the mistake here was that direction is NOT the end point. Origin is the starting point, direction should be a vector pointing at the target and not the target itself.

@Deltakosh , the fix that i wanted to push ( and was pushed by dad72) might fix a single problem if the target not in 0,0,0 , it is not a global fix. I am not sure it is necessary. I think the Ray class should be extended with a few needed help functions to make this easier for everyone. I will send you a pull request tomorrow. Would be nice to have a Ray.GenerateRayFromTo(origin : Vector3, target : Vector3)  to fix those kind of mistakes, plus a ray should have a distance to prevent unlimited ray tracing in case a target is set.

Tl;dr : 

Direction != Target , intersects missing submeshes to world coordinates conversion. 

 

//Edited after a few further tests

[Dad72]

Cool, Thank you for patches. I've clean up the code on that basis. the next step is to make the sphere either the front the box gray when the line is contacts.

http://playground.babylonjs.com/#1VITHH#12

[Stephen Andrews]

It might be easier if you did the raycast from the object to the camera instead, as that would give you the proper side of the intersection to move the camera to.

[joshcamas]

On 11/25/2014 at 1:45 PM, raananw said:

Direction != Target , intersects missing submeshes to world coordinates conversion.

Ahhhh that explains it! Awesome! And I agree with having that new function. Would be useful.

 

On 11/25/2014 at 6:57 PM, TriBlade9 said:

It might be easier if you did the raycast from the object to the camera instead, as that would give you the proper side of the intersection to move the camera to.

That's probably true! Thank you for that idea!

 

EDIT: Well, I got something! 

http://playground.babylonjs.com/#1VITHH#14

However, it seems the distance value is strange, or something. Probably something wrong with my math. 

[Stephen Andrews]

On 11/25/2014 at 7:36 PM, joshcamas said:

Ahhhh that explains it! Awesome! And I agree with having that new function. Would be useful.

That's probably true! Thank you for that idea!

EDIT: Well, I got something! 

http://playground.babylonjs.com/#1VITHH#14

However, it seems the distance value is strange, or something. Probably something wrong with my math. 

I'm working on it, though I need to leave here pretty soon.

I'd say to use the picked point->World space conversion and then make it a tad closer to the camera.

 

Darn, I'm out of time. I just did similar math for this, so I'm a bit confused on why I don't get it yet.

Anyways, it should be something to do with picked point and picked mesh, convert that to world coords, and stuff.

 

I'm still not sure what space pickedPoint is in.