Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed plot bugs, added functionality, updated images #353

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

ventsiR
Copy link

@ventsiR ventsiR commented Oct 28, 2024

Added functions in awpy.plot.utils that transform in the opposite direction (i.e. from map pixel coordinates to in-game coordinates) and added documentation indicating direction of transform.

Updated the vertigo map images to show the new layout after the map got updated.

Added functions in awpy.plot.utils that transform in the opposite direction (i.e. from map pixel coordinates to in-game coordinates) and added documentation indicating direction of transform.

Updated the vertigo map images to show the new layout after the map got updated.
…ke Vertigo and Nuke)

awpy.plot.utils.is_position_on_lower_level() was always returning False trivially; if statement in line 122 was checking if pos is greater than max instead off less than max.

Added `is_lower` argument to all plot functions. plot() (and _generate_frame_plot() & gif(), which use it) now correctly set alpha to 0.4 for lower points.

heatmap() now ignores points not on the level provided by the user and spits out a warning.

Also cleaned up map_data file.
@ventsiR ventsiR changed the title Added plot.utils functions and updated map images Fixed bug with awpy.plot not handling lower levels points, added plot.utils reverse transform functions and updated map images Oct 29, 2024
vary_alpha functionality of plot.heatmap() was not working correctly because values were set to np.nan before applying alpha arithmetic. I also added vary_alpha_range as an argument for users to set min and max alpha for each point
@ventsiR ventsiR changed the title Fixed bug with awpy.plot not handling lower levels points, added plot.utils reverse transform functions and updated map images Fixed plot bugs, added functionality, updated images Nov 8, 2024
Added ignore_extreme_points argument. When set to True, it will ignore points that are outside of the bounds of the default map image. Previously, code functioned as if this was set to False. Default value is False.
Copy link
Owner

@pnxenopoulos pnxenopoulos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really appreciate the PR! There are some interesting and helpful additions here. I think the PR looks mostly good and I left some more clarification/discussion-based comments. Once we sort those minor comments out, we can merge this into the 2.0.0b5 branch. I should just make it 2.0, but alas...

@@ -40,6 +46,10 @@ def plot( # noqa: PLR0915
- 'armor': int (0-100)
- 'direction': Tuple[float, float] (pitch, yaw in degrees)
- 'label': str (optional)
ignore_extreme_points (bool, optional): If set to True, will ignore
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting proposition. Is there any reason we would want to allow this in the first place? Or, in other words, do you think there's any danger to making this a default?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were designing this function from the ground-up, I would have the default set to True.

In the commit I have set it to default as False because it mimics the previous behavior of the function (i.e. it plotted points way outside of the map). My reasoning was backwards compatibility for people who have already written code with the current behavior in mind.

I'm kind of new to GitHub and commits so I'm leaving the decision up to you :D

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally understand the backwards compatibility concerns. I think given that this is still a beta version, we can feel ok with breaking the previous functionality, particularly in this case, where there is little noticeable value to plotting points outside the map. I say we remove this arg and make it default behavior! It's a nice safeguard that I overlooked when first writing the function.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, will remove the arg and integrate the functionality.

@@ -22,14 +23,19 @@
def plot( # noqa: PLR0915
map_name: str,
points: Optional[List[Tuple[float, float, float]]] = None,
is_lower: Optional[bool] = False,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if this parameter were reworked into a "lower fraction"? As in, we assume that upper points are plotted with alpha = 1.0, and then lower are lower_frac*alpha ? This would allow for a more expressive form of what it appears you are going for.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which, we may also want to offer a param for the "dead player alpha" that we default to 0.15, too

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea!

The only thing to note is that when is_lower = True, it also changes the image to the lower part of the map, but then again, you can control this via the map_name argument.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Perhaps in the docstring we can say something like "if you want to plot a specific lower part of a map, use *_lower. However, then this could imply that a user may want to plot only the top part of the map, too. Perhaps we search for a "_lower" and "_upper" if we want to plot only those.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I look at this, perhaps we want to just have a generic game_to_pixel(tuple). That tuple can be an (x,y) pair. What do you think?

{"name": "default", "altitude_max": 10000, "altitude_min": -5},
{"name": "lower", "altitude_max": -5, "altitude_min": -10000},
],
"lower_level_max": -5.0,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this simplification, but I may offer a rewording -- perhaps lower_level_max_units or something. Just to put the "units" into the name (which unfortunately in this case is just generic "units").

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

Sidebar: I am a bit new to GitHub & commits; is it good etiquette for me to implement your feedback, or to let you implement it?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it depends from person-to-person, repo-to-repo, but usually the one who opened the PR will make the changes, unless it's a super small change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Will implement everything you've mentioned; they're pretty small changes and everything is still relatively fresh in my mind :D

size (int, optional): Size of the heatmap grid. Defaults to 10.
cmap (str, optional): Colormap to use. Defaults to 'RdYlGn'.
alpha (float, optional): Transparency of the heatmap. Defaults to 0.5.
vary_alpha (bool, optional): Vary the alpha based on the density. Defaults
to False.
vary_alpha_range (List[float, float], optional): The min and max transparency
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit unclear as to what this parameter is doing -- do you mind explaining again? I realize I don't quite remember what I wrote 🤣

Copy link
Author

@ventsiR ventsiR Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously (before I added vary_alpha_range) when vary_alpha was set to True, it would plot the densest points with alpha equal to the alpha argument, the least dense points with alpha = 0, and anything in between would be assigned linearly between 0 and alpha.

vary_alpha_range lets the user set a custom range (instead of 0 and alpha).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I now realize that vary_alpha_range might be a confusing name - it was intended to sound like "the range of argument vary_alpha", but it sounds like, "vary the alpha's range".

Can't think of anything better though - I considered alpha_range, but it's even more ambiguous :D

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. If an alpha range is specified, should we assume the user wants to vary_alpha? This may allow us to remove one arg. If so, then I think having alpha_range is a fine name, as long you add just a tiny bit more explanation in the docstring!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea!

@@ -34,10 +34,40 @@ def position_transform_axis(
return (start - position) / scale


def position_revert_axis(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the intended use for this function?

Copy link
Author

@ventsiR ventsiR Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given a point that is plotted on an image, users can feed the point's pixel co-ordinates into position_revert_axis() and get the in-game co-ordinates of that point (assumes that user didn't modify the dimensions of the image from the default 1024x1024).

I am using this function in my code to plot points on a matplotlib graph, draw a polygon over it, and return my polygon to a database in terms of in-game coordinates.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Perhaps what we can do is rename the function. Usually for these transformer-style function we can name them like "X_to_Y". We probably should rename the position_transform() function, we can still do that, I'm all ears for names!

Copy link
Author

@ventsiR ventsiR Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree; I didn't take the liberty due to - again - backwards compatibility reasons.

Maybe rename the functions to in-game_to_pixel_transform & pixel_to_in-game_transform and create "new" functions that go by the old names (position_transform_axis & position_revert_axis) that simply call in-game_to_pixel_transform & pixel_to_in-game_transform and send a deprecation warning in the console?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can do the following:

game_to_pixel(...)
pixel_to_game(...)

since "in game" is redundant with "game" and "transform" is implied by the "to"

then, the interface is much cleaner and imo, easy to tell what the functions do

@pnxenopoulos
Copy link
Owner

Also, DM me on Discord so I know which account you are!

Renaming of variables/functions, removal/additions of function arguments.
More renaming (should've pushed it with last commit)
)
if (
transformed_x < 0
or transformed_x > 1024
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because these are constants, it would be helpful to have a comment above here stating that these are the maximum expected bounds

This is the old name of function `game_to_pixel_axis`. Please update
your code to avoid future deprecation.
"""
warnings.warn(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to add the deprecation warnings. I think we can drop the _renaming_warning() however, and just include the specific strings in the deprecation messages!

return pixel_to_game_axis(map_name, position, axis)


def position_transform(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think these functions would still live in plot, rather than live in utils (so the import path would be the same)

@@ -1,15 +1,16 @@
"""Utilities for plotting and visualization."""

from typing import Literal
import warnings
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should generally do

import warnings

from typing import Literal

from awpy.data.map_data import MAP_DATA

Applying linting fixes to the code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants