The Heatmap Plugin - What it is and how you can help
- Thread starter Fruity Snacks
- Start date
We'll make it happen. If it's been tested in the past few days I can get scoop up the data and get it processed for you quickly.
I don't understand. If you mean me/my tool with "we":
The demo data is no-touch. Only headers are documented and some packets are compressed, some not. There's no use for demos either way. The plugin can do its job just fine.
On a different note:
Multithreading is added.
What I still want to do:
-Save/load calibration data
-Make the GUI look pretty
-Add filters
-Different imaging modes (Simple points for example - faster and therefore good for calibration)
-Maybe a progress bar and the typical "time left"-label.
So far the performance is very good. I optimized this as much as possible. A 4096xSomething overview with the "Smoothing/Radius" maxed out (20/100 is actually enough), takes 9 seconds on my 2600k with the biggest log file I have at the moment.
Performance scaling is pretty straight forward:
-Linear to pixel count
-Linear to entry count
-Linear to smoothing value
The demo data is no-touch. Only headers are documented and some packets are compressed, some not. There's no use for demos either way. The plugin can do its job just fine.
On a different note:
Multithreading is added.
What I still want to do:
-Save/load calibration data
-Make the GUI look pretty
-Add filters
-Different imaging modes (Simple points for example - faster and therefore good for calibration)
-Maybe a progress bar and the typical "time left"-label.
So far the performance is very good. I optimized this as much as possible. A 4096xSomething overview with the "Smoothing/Radius" maxed out (20/100 is actually enough), takes 9 seconds on my 2600k with the biggest log file I have at the moment.
Performance scaling is pretty straight forward:
-Linear to pixel count
-Linear to entry count
-Linear to smoothing value
I think when he said "we" he was talking about him and the competitive community. All his data has been from actual testing with competitive teams.
Different smoothing settings:
10:
20:
50:
70:
100:
EDIT:
Sorry, is it possible to resize these here?
EDIT2:
Oh, now they're resized. Never mind. Obviously had to reload the page.
10:
20:
50:
70:
100:
EDIT:
Sorry, is it possible to resize these here?
EDIT2:
Oh, now they're resized. Never mind. Obviously had to reload the page.
Last edited:
Out of curiosity, how exactly does the heatmap image get lined up with the overview image? I'm curious, because I'd think you would need some sort of data about real-world coordinates vs. image coordinates, and I'm also wondering if there's any way to automate the overview image creation.
Last edited:
You have to calibrate the image with the data. Basically you get a quick render (of points, as mentioned above) and you move it around.
Regarding the image automation:
There is, but it's nothing you'd do "at home". For own uses you'd be better off taking the overview image yourself. Actually the dialog between me and FrozenR started because I was offering him an overview image for each map tf2maps offers. He said he'd rather have heatmaps.
Regarding the image automation:
There is, but it's nothing you'd do "at home". For own uses you'd be better off taking the overview image yourself. Actually the dialog between me and FrozenR started because I was offering him an overview image for each map tf2maps offers. He said he'd rather have heatmaps.
Demos are replayed client-side only. There is no server on which sourcemod is running. The client just parses the packets and makes a replay out of it.
The thing about sentries got me thinking about ways to indicate the good sentry spots, and what I came up with was putting a marker at each spot where a sentry was put up, and coloring it from red to green based on how long it stayed up. And maybe the luminosity of the spots could be based on representing the most common location at 100% and scaling down proportionally. So, for example, suppose there are 20 rounds played in all. During 12 of those rounds, a sentry is erected in the same exact spot. That spot would be a color between #FF0000 and #00FF00 representing the average length of time it stayed up between 0 seconds and, oh, let's be generous and say three minutes. Over on another part of the map, another spot was the home to 3 different sentries over the course of the test. So it would be a color somewhere between #3F00000 and #003F00.
Then maybe a second version of the same map could use colors between red (most) and blue (least) to represent the damage outputs of those respective sentries.
Then maybe a second version of the same map could use colors between red (most) and blue (least) to represent the damage outputs of those respective sentries.
Project is on hold at the moment until some other stuff I'm working on is finished (which is more or less time-critical). Although that doesn't rule out me working on it (In fact I was in the mood to implement flowmaps a few days ago).
Some detailed results and explanations when this project reaches perfection as I don't want to start a hype train until public use is available.
Some detailed results and explanations when this project reaches perfection as I don't want to start a hype train until public use is available.
