Thanks for the reply. But I believe yes, I tried checking for the collision properties for both actors, skeletal meshes and static meshes and the physical surface seems to always be empty.
But also, I created a simple trace from my player Blueprint and the Physical Material is returned normally from that one.
Didnât have a whole lot of time to test earlier, but having spent a few minutes on it now, it looks like 3D is just broken. Debug logs for 2D and 3D below, same ability, just with the toggle flipped.
Sorry, I misspoke earlier. I meant to say itâs a part of the returned hit struct, not that values are being passed inherently. I did some experimentation with returning physical materials some time ago and found it to be a bit of a pain. It looks like, since they are Objects, Able Abilities donât have direct access to some of the things you need to make this work, so take a look at the screenshots here: Imgur: The magic of the Internet
Hmm, 2D and 3D use the exact same code under the hood (except 3D has one extra check for height). Iâll dig into it. What FOV are you using in your test?
Captured some video. I can throw it in Dropbox or something if the quality is a problem, but itâs just me scrubbing the FOV value back and forth, toggling 2D on midway through.
Thereâs a really interesting âstepperâ sort of behavior going on that repeats over the FOV range of 1-179.9. More screens: Imgur: The magic of the Internet
Yea, thatâs the visual behavior I was talking about. That draw method is junk (it uses the engineâs draw cone - but something is off there or Iâm passing it the wrong parameters), so I just need to write my own (which is what I did for 2D). Also one reason why a 2D query may find something, but 3D doesnât, is because the height check goes against the playerâs location (meaning their feet). so, if your location is outside of that cone (too close for example), despite that your body may be inside it - it would fail.
So if Iâm understanding this correctly⌠assuming two character descendants in the transaction, the 3D cone is only going to detect a collision with what amounts to its leading bottom edge, and only if the other characterâs location is a point on that line?
E.g., Scotty stands at 0,0,0 and projects a cone (500 FOV, 100 length) forward, and it only detects if is standing at 100,0,0?
Or would the same cone catch jumping in place from say, 90,0,0?
Silly question, answered it myself.
Something purpose-built probably isnât a bad idea. The obvious workaround that comes to mind would be a primitive attached somewhere center-mass for responding to 3D cones, possibly on their own channel, but that doesnât strike me as particularly scalable.
500 FOV is slightly meaningless as itâs going to get wrap around to 0 - 360 (so, 500 would 140 degrees). It should catch either of your examples, but if the ââ character was close (say 20 units away), I could definitely see the cone missing that as that cone expands along the length (but 2D would grab it).
Yeah, definitely shouldâve been âheightâ instead of âFOVâ there. Tunnel-vision bit me on that.
This has been super informative, though. Iâve only been working with 2D cones until now, and it definitely wouldâve thrown me for a loop whenever I got into 3D.
Again, Iâll double check. But when I did a pretty exhaustive look at 3D cone a few weeks back - the math was always correct and it was always my assumption of where the player was in relation to that cone that was wrong (e.g., I move the character back just a tad and it hits it). The fact that the Debug Draw is totally wacky doesnât help show that fact, so Iâll definitely re-write that portion.
Ah gotcha! And thank you for uploading those images too.
Having the interface approach is not totally feasible in this scenario as this hitscan is used for bullet impacts and it could hit simple meshes too, not just actors. To support that, I created a method in a Blueprint Function Library that would do the material extraction as you suggested.
But I noticed that the the Face Index is coming up as â-1â, on both approaches - interface or function library.
This is also a parameter that you could provide to your hitscan, via FCollisionQueryParams (parameter âbReturnFaceIndexâ). This is also similar to the physical surface (âbReturnPhysicalMaterialâ), but these are not exposed in the Able Editor.
Iâm considering creating a custom ray trace task for this context, but I still feel I might be missing something as it would be odd that such simple things wouldnât be available OOTB. And as you said, it seems that you have a working solution, right?
If you see something not exposed in Able itâs generally because 1.) I donât use it in my own projects, or 2.) No one asked yet. Itâs trivial to expose those and I have some outstanding work to do in Raycast Task anyway, so Iâll toss these in as well.
Ah thatâs great, thank you for the info! Makes sense.
So, to summarize what Iâm seeing right now, the ablRayCastQueryTask performs the traces between lines 75-103, where 1 out of 4 traces will be executed depending on the task setup. They all use a version of the trace calls from the World class, using 4 arguments.
The 5th argument thatâs being omitted would be a FCollisionQueryParams with the flags above. The default version of this struct thatâs being used is initialized with those flags set to false.
I didnât mean to say it needed to be double-checked, just that I meant to say âheightâ where I said âFOVâ. I was agreeing with you, I just didnât communicate that very clearly. My bad.
The height of 500 was to ensure itâd be tall enough at the far extent to hit a roughly six foot tall humanoidâs root position, assuming both are standing on the same plane at roughly the same elevation. I goofed and said nonsense instead.
As for doing this on standalone meshes, would it not make more sense to query the shooter about the gun and ammo type fired in the bullet impact scenario you mentioned, rather than how the wall responds to specific stimuli? If the brick wall is the same brick wall whether you shoot it with a watergun or an RPG-7, then in my mind, it seems reasonable to do the VFX/SFX handling in the context of the shooter/weapon/ammo, with consideration for the brick material of the wall.
There are other use cases, Iâm sure. Iâm just spitballing at this one, as it were.
Youâre all good, soctty. I didnât take any offense or anything. It was more âhuh, yea, Iâve seen this before and this is what it normally isâ. Intent is hard to read over the internet.
Yeah, absolutely! Maybe I explained poorly, but hereâs what Iâm doing:
The weapon actor has an ability that ray traces for hits;
Once it hits something, whatever it is, it gets the Physical Material from it;
It then queries a DataTable, to get a struct from that PhysMat surface. It contains the SFX/VFX to be rendered on that impact.
Still, each actor, static mesh or skeletal mesh hit has its own Physical Material assigned which needs to be fetched on that weaponâs hitscan, But it really seems that - at least OOTB - the Face or PhysMat really isnât available.
But generally speaking, yes, the weapon actor handles all the spawning and so. It just needs to know the Physical Material that it hit.
