Is there a better way to do this? (3D Armor - Transfer heat to adjacent armor)

[EvoPulseGaming]

So I have dynamic 3D armor (cubed, six sides) that interacts with everything (munitions(heat on impact and damage), weather(heat), cooling system(self cooling(weather), radiator cooling) ect ect ect

Anyways, so I implement a 3D heat transfer function, that basically takes extra heat from one side and spreads some of it to the other adjacent sides (permitted those sides are not hotter)

I was wondering if there is a better way of doing this? (BP only - However… I would make a tiny c++ function if it was powerful enough)

[anonymous_user_49a519741 (anonymous_user_49a51974)]

The overall mechanism looks good but you should probably set a timer and not update on every tick.

I’d also try doing the heat dissipation a bit simpler to speed it up. I’d just equalize the heat to all the sides regardless of adjacency. It should look believable enough and worst case it can be some kind of special alloy that channels heat more efficiency (like a thermal version of a superconductor). For very large armor I suppose it might not be ideal, but at some point you’d need to do better than you are now using vector fields or something surface-related.

A more radical thought is to not use the sides at all but points ‘within’ the mesh. Since armor is usually a plate, you really only need heat points within a plane-ish region. Like, for a rectangular piece of armor, just have four heat points rather than six sides. Then when a side gets heated, just update the heat point associated with that side (so there’s more than one side per heat point). That should cut down on the work as well.

[anonymous_user_49a519741 (anonymous_user_49a51974)]

I didn’t mean the special alloy would transfer the heat from one to the other, rather it would equalize the heat over time across all of them ala dissipation.

If what you have works then I’d stick with it. Getting it off of tick should be good.

[EvoPulseGaming]

I most certainly will put this on a .5 sec timer (maybe even 1 sec)

I could simply average all sides combined, and then set each side the same, however, I am explicitly looking for the more visually realistic approach.

Special Alloy… xD That actually sounds like an unlockable upgrade. (Allowing heat to be directly transferred to the opposite side, which is most likely to the be coolest of all sides!)

I thought about vectors and vector4, however I need granular control, I would only end up with a ton of set/make/break nodes, unless you had an idea of how to organize the calculation differently (Maybe X/Y/Z vs -X/-Y/-Z (two pair) instead of X/-X vs Y/-Y vs Z/-Z (3 Pair)

However you’re radical idea is quit interesting… but that actually increases the number of heat points by 2?
A cube has 6 sides, but 8 corners…

I don’t think I explained this correctly. I am not using the “traditional” gaming armor. This is actual, 3d space correlated armor.
1 Character - 1 mesh per sectional body part (torso, L arm, R arm, UpperLegR, LowerLegL ect)

Every Mesh, has an actor “container” married to it (Using MAP array variable)
Every Container has "3DArmor Comp, Cooling Comp, Damage Comp, 1 Child Actor)
Child actor = Weapon/Module/Radar/ect

So this is realistic in the sense of : The turret of a tank has 3D armor, probably has cooling (active or passive), can take damage, can contain X weapon / module ect, IF destroyed, Tank body has armor that is now exposed to damage

(Further complication with armor piercing through multiple containers)

Lets not talk about how i’m going to replicate this! (If = default value- do not replicate)

[EvoPulseGaming]

I have it on a 1 second timer and its a bit “laggy” looking, so ill try 1/2 or 1/3 seconds.

Also this is exactly how its setup, if you quickly and repeatedly hit the same side it gets red hot, and over the next 5 or 10 seconds the adjacent sides start turning red, and secondary adjacent side (back) is delayed by a second since it has to wait till the next run to actually receive a fraction of a fraction of the heat from the first run.

Well, I guess its safe to say there are no shortcuts or build in tricks so this will have to do… thats what 4+ core cpus are for anyways!

[anonymous_user_49a519741 (anonymous_user_49a51974)]

You’re bleeding off part of the heat into the air too right? Otherwise they’d never cool down.

What you have will not run in parallel. If you want to do that you need to run this heat stuff in a separate thread. Running a separate thread that handles the heat for all your armored actors should work pretty well since you’re just changing values. The game thread can read those and act on them without the need for any thread synchronization (barring any complications). It should speed things up significantly – and you could always spread your actors across two or more heat-handler threads.

There may also be a possibility of running it on the GPU via materials but that’s not something I know much about.

[EvoPulseGaming]

Yes, that is determined by the complete surface area of the mesh, so thicker armor can heat sink more heat, but still takes the same amount of time to bleed off heat as a thinner piece of same surface area.
Also world weather/sun/shade will affect the surface cooling coefficient
And characters can have “radiators” equipped to bleed off heat

My current Mech character has about 24 meshes w/ 3D armor
6 of those are calculated to be “big enough” to house “modules”, which (say, a weapon) has its own heat that it sinks into the surrounding armor.

The armor heat transfer has about 150 calculations, x24meshes = 3,600 calcs
6 modules transfer heat equally to all sides of armor add about 72 calcs
Then to transfer that between modules using the “radiator” add about another 150 calcs x6 =900
about 4.5k calcs per run (Not to mention surface checks for weather/sun)

So multi threading is in the works. It seems pretty easy to do in blueprints. And you are very correct, as the game thread does not rely on nano second correct data, heat can be done in the background.

Right now for debugging I am plugging in those values into vectors for the debug material I use for the meshes. I would be nice to off load it to the GPU if the CPU ends up bottle-necked over this system. There are many other systems that are going to be in play, and they all rely on the CPU.

I have no clue where to start with a material based calculation xD

Thank you for your feedback

[anonymous_user_49a519741 (anonymous_user_49a51974)]

That system sounds great. You’re welcome. Good luck and see you around.

[EvoPulseGaming]

Actually it turns out the logic in this is incorrect, heat bounces back and forth of opposing sides, so this function never stops.

[anonymous_user_49a519741 (anonymous_user_49a51974)]

Heat only goes from high to low and the amount transferred over time depends on the differential. Are you spreading the heat from one side to all the other sides? Maybe try only spreading to the sides that aren’t as hot. And never transfer more than the difference. If A is 10 hotter than B but you transfer 20 then B will be hotter than A. You want to clamp the transfer so A and B end up equal.

[EvoPulseGaming]

I ended up using a mix of clamp, range and multiplying by -1,
it transfers front to left,right,top,bottom, then does a l,r,t,b comparison, and then the back vs l,r,t,b. This however causes two issues
Front = 10 turns into 2,2,2,2,2,0 (f,l,r,t,b,back), but then turns into ~1.8,1.7,1.7,1.7,1.7,1.5
Basically, heat transfers too fast, and the proportions are wrong. But for now this will have to do until I can get proper heat (fluid dynamics)
Intel | Data Center Solutions, IoT, and PC Innovation

[anonymous_user_49a519741 (anonymous_user_49a51974)]

Progress. Good. Check out flow maps in UE4. That might work.