Monday, December 28, 2020

The sprites always orient towards the camera. It would be better if the decal reflected the orientation of the mesh normal hit by the ray cast.  

 Set is as follows:

A. Sets decal duration (e.g. time in seconds to despawn)
B. Sets scale
C. Sets rotation.
D. Sets value (brightness). I had a setup to randomize the color, but as of now value will suffice.





 Harry is going to expand the ShotCollisionResponse so it supports randomly choosing from a list of pools. I'm going to write a uscript to handle any number of things that might be beneficial when spawning the decals. A few considerations off the top of my head: 

  • randomization of rot.z
  • bounded (min/max) randomization of decal size
  • color float adjustment
  • Material/Shader adjustments (the BulletHoleDecal script already handles materials in some capacity, but I know nothing about this, so some digging is warranted).
  • material/shader adjustments despawn time (this already exists in the DespawnPoolObject script, but perhaps consolidation is in order)


Sunday, December 27, 2020

 While not ideal, I gave the decal prefab a parent object, which is offset by -.015 units, and this does produce the desired result. I suppose this will suffice...for now. Still, why should this be required in the first place? It was only required because the Saloon mesh was set 180° on the y axis due to its export orientation. The decals hover slightly above the mesh surface, so when the mesh is improperly oriented, the decals will exhibit less than ideal behavior.

Also, I created a customized duplicate of the decal--one that contains some value adjustments--and assigned it Multiplicative shader.


This produces a more natural, less garish bullet hole, which I like a little more. Perhaps I should also create a couple variants to prevent them from looking so similar?








 I offset the pos.z by -.015 thinking maybe I could force the issue, but this doesn't work; although I didn't think it would. There's also a flag for ApplyOrientToSurface, but IIRC that applies to the particle fx. Regardless, I tried it, and it also didn't fix the issue. I suppose I could force it by having the decals draw on top of everything else, but that's more of a hack than a solution... :/

 Reduced the scale by nearly a 1000% percent (maybe not the best way?) and while the decal looks to be about the correct size, it is slightly embedded (~.02 units) in the saloon mesh, which means it is not visible to the player


The decal should be visible inside the circle area, but as you can see, it is not. I'm not sure why this is. I would suspect that perhaps it is an issue representing the slight difference in position between the mesh and the collider, but in this case, the collider is the mesh, so I don't think that is it. It is also not a by product of the scaling as you can see the issue is also apparent in the previous post. Will have to dig 


 Well, it works...


...just not quite as expected. Scale is an issue.


 It looks as if the prefab is missing a required component, which when not attached does force the prefab to instantly get destroyed. 







I'm using a version of the BulletHole prefab in my attempt to troubleshoot exactly why this isn't working as expected. 



Layer has been reset to default and BulletHole script has been removed, but I'm still seeing the same result--the instances are being removed from the pool, but not only are they not visible in-game but also the hierarchy shows no evidence of the freshly "spawned" instance. WTF is going on here? Are they somehow being destroyed the moment after they are spawned? If so, why? how?


 For the large building facades that do not fracture, it would be nice if the decal system portion of the Shot Collision Response actually worked. The particle fx function, but not the decals. I'm still testing, but this might require a programmer. 




Thursday, December 17, 2020

While optimizing for performance, I think I've uncovered why Blender is distorting the UVs during the cell fracturing process. The window on the left will have distorted UVs while the one on the right will not and I suspect it has something (everything?) to do with the fact that the coplanar UVs are split along the corners.