Physics.raycasts and physicsless objects

[allmhuran]

I may have posed this question in the wrong forum before.

What is the default behaviour of a physics.raycast with respect to parts that have physicsSignificance = 1?

It appears to me that, by default, if a raycast hits a physicless object, it will walk up the tree until it finds the first physics object, and return that object rather than the one that was actually hit.  But @NathanKell was dealing with the same problem in this old thread about thermo and physics significance, and it reads to me as though the original skipping the physicsless part was part of KSP's implementation, not a unity thing (" the engine exhaust damage, after it raycasts and detects a hit, finds the root transform of whatever transform it hits. And physicssig=1 parts are parented to the part that has full physics. So that 'root' check gives the parent part, not the hit part ") , whereas what I see suggests that this is the default behaviour of a raycast.

I've tried looking at unity docs for help, but of course I don't really know what "physicsSignificance=1" in a KSP part config file really means in terms of properties in the unity engine.

For reference, the code that appears to be walking up the tree to the first "normal physics" options is as follows (from BD armory):

 

if (Physics.Raycast(ray, out hit, dist, 557057))
{
	Part hitPart = null;   
	try
	{
		hitPart = Part.FromGO(hit.rigidbody.gameObject);
	}
	catch (NullReferenceException)
	{
	}
}

 

[sarbian]

Raycast does not care about the part flag. It cares about colliders and the layers they uses. Using magic number like 557057 hides the actual layers that are checked. And if the part does not have a collider it will not be hit by a raycast.

NK comment about physicsless part is about the part where the heat is applied, not the raycast itself.

The only thing that could go up the tree in that code is the FromGO call, that I guess is part of BDA

[allmhuran]

FromGO appears to be a function in KSP code, not unity or BD Armory.

Yes, the thread in which NK posted is about where heat is applied. I started the thread reporting that heat was applied to the wrong part if a physicsless part was the initial target of the heat (in this case, engine exhaust), and NK seemed to confirm that the raycast was indeed hitting the physicless part, but that it was looking for the root transform. So, there is certainly an implication there that raycasts do indeed "hit" physicsless parts - as long as they have the appropriate unity attributes (ie, like you said, a collider). 

I have a feeling the original KSP code for engine exhaust raycasts was using the same code as BD armory, ie, calling the "FromGO" method, and that this is why both of them initially walked up the tree to the first "physical" part. However, I think the way to return the actual part that was hit (even if physicsless) might be:
 

Part p = hit.collider.gameObject.GetComponentInParent<Part>();

Just a hunch based on code I see elsewhere, I am about to try it.
 

[sarbian]

5 minutes ago, allmhuran said:

I think the way to return the actual part that was hit (even if physicsless) might be:
 

Part p = hit.collider.gameObject.GetComponentInParent<Part>();

Just a hunch based on code I see elsewhere, I am about to try it.

Which is exactly what FromGO does

[allmhuran]

Sorry, didn't you just say you thought FromGO was part of BD Armory? Did you just go and find the actual definition of the method?

[sarbian]

Yes

[allmhuran]

What, so you fired up reflector and looked at the dll internals?

[sarbian]

No, I used my ouija board.

[allmhuran]

Are you deliberately supplying incorrect information for lulz?

[sarbian]

I am unmasked. I spent the last 4 years on this board spreading alt fact.

[allmhuran]

It's hard to believe, yeah. But you seem to be doing it here.

hit.collider.gameObject.GetComponentInParent<Part>() is decidedly not "exactly what FromGO does". I just commented out the FromGO call (which results in a walk up to a physics part) and replaced it with that instead, and it returns the physicsless part. Two identical sections of code do not return different results. So I dunno man, you tell me what you're actually doing, because right now it looks like you're not just being unhelpful, you're being actively misleading.

[sarbian]

That or you are just wrong and the call does what I say it does, and not what you assume it does based on a 2 year old post.

[allmhuran]

Well, I actually just altered the code, compiled a new version of BDA, and tested it in the game, so I think I'll stick with my actual experience running it over your assertions.

[flywlyx]

On 1/24/2017 at 7:49 AM, allmhuran said:

FromGO appears to be a function in KSP code, not unity or BD Armory.

Yes, the thread in which NK posted is about where heat is applied. I started the thread reporting that heat was applied to the wrong part if a physicsless part was the initial target of the heat (in this case, engine exhaust), and NK seemed to confirm that the raycast was indeed hitting the physicless part, but that it was looking for the root transform. So, there is certainly an implication there that raycasts do indeed "hit" physicsless parts - as long as they have the appropriate unity attributes (ie, like you said, a collider). 

I have a feeling the original KSP code for engine exhaust raycasts was using the same code as BD armory, ie, calling the "FromGO" method, and that this is why both of them initially walked up the tree to the first "physical" part. However, I think the way to return the actual part that was hit (even if physicsless) might be:
 

Part p = hit.collider.gameObject.GetComponentInParent<Part>();

Just a hunch based on code I see elsewhere, I am about to try it.
 

BDA use FromGO for for heat effect only and for force reaction, he use "GetComponentInParent<Part>()" and process a physicsSignificance after that. It is highly possible FromGO doesn't work with physicsSignificance. 

[allmhuran]

Nah, they're used in different spots. For example, GetComponentInParent is used for the lasers, FromGO is used for bullet hits.

But the difference is that when making the FromGO call it uses hit.rigidbody.gameobject, vs hit.collider.gameobject for the other call. So the two lines of code operate differently.

Switching everything to the hit.collider.gameobject.getcomponent version makes it all work as expected, I've recompiled it myself and everything is fixed. I have an issue open on the BDA git site showing where to make the changes.