hello again, guys :)

greg, I finally managed to understand (or not) the velocity based movements with a help of a physicist friend. I'm not onto the steering behaviours thing and studying the "goal based pathfinding". am I in the right direction? whats the best or the most used pathfinding algorithm used together velocity based movements? I just found this vector-pathfinding.klyta.it

Hello! What defines a developer? He should have projects behind but i feel like fields other than game development do not provide much room for creation am i right or wrong?

@0x00004 why do you feel fields other than gamedev do not provide room for projects? why do you feel a developer should have, i assume you mean, public projects?

@Henri My name's not Greg, and even if it were, it would start with an uppercase letter. 😉

Pathfinding is usually agnostic to the propulsion method of your agents. Its job is to just find the path. Then it's a control problem to steer the agent to follow that path.

We might make exceptions for things like cars or space ships that have a large turning radius, but if I recall correctly your use case was a top-down game with humanoid agents that walk/run? Generally they don't need any extra considerations for velocity/momentum in path planning.

oh wow, I used to call you greg for short. wasnt sure whether to ping you either

I was looking at the "flow field navigation/pathfinding". is this a common technique?

You found it, so it can't be that rare.

I generally don't find "is it common?" to be as useful a question as it might seem. Usually what the asker really wants to know is "should I use this?" - and whether the solution is common or not does not answer that real question.

@Henri Unless you know the person's full name and how they like to be called, better go with the name that is displayed ;) I'm not sure you'd want us to be call you Hen ;)

For the record, the D stands for Douglas. 😉

Hahahahaha 🤣

Vaillancourt, honestly, I dont really care lol. I wouldnt mind such a thing

I kinda got your point, DMGregory. knowing whether to use something or not, is also a matter of choice. I'm just asking if on the right path

To judge whether the path is right, we need to know where you're trying to go. Solutions aren't right or wrong in a vacuum, they're right or wrong for solving specific problems.

Flow field pathfinding is great when you have a LOT of agents, dozens, hundreds or more, all pathfinding to the same goal simultaneously. Especially so when they may be coming from all over the map.

Oh, okay! Just keep in mind that some would mind; better just to use their displayed name and not assume their genre until you know enough :) (That's kind of part of the CoC of the site.) No harm done until now :)

If you have just a couple agents pathfinding at a time, or your agents need to navigate to different goals, or they're all moving in a tight cluster, you might not gain as much from a flow field. Flow fields find shortest paths from all starting points, but for many cases we only need one or a small cluster of starting points.

If you're dealing with swarms of agents that pour through the map like a liquid, you almost certainly want a flow field. If you're dealing with AI that need to make their way to individual tactical positions, and look intelligent doing it, you almost certainly want individual A* queries. If you're somewhere in the middle you might want a hybrid strategy.

the problem is that I'm pretty lost about velocity-based movements. I've done a grid-based movement in the past and used A*. it fit and worked perfectly for such situation. I'm not sure about velocity-based.

ohhhhh..... I think I just got an idea!

You pick your next point along the path, then you steer your velocity to take you there. There's not much other interaction these two phases need to have.

I always wondered how to create the path for agents that can move by single pixels instead of a whole grid ("bigger pixels"), whether would it be like (1,1) > (1,2) > (1, 3) and so on

because that would be a giant path list

we can just assume the grid's center point, calculate the distance between our position and that position and then set the velocity accordingly. right?

Sure. Generally you'll want to aim a step or two ahead along the path to make the movement look more natural, but in principle there's nothing wrong with that.

I never thought about this!

so basically I'm going to implement that "jump point search" algorithm here: qiao.github.io/PathFinding.js/visual

Why jump point search?

I'm not sure tbh lol. just thought it gives me the lesser amount of path nodes to move on

You can always tackle that as a post-process if it becomes an obstacle: using run length encoding or string pulling to simplify a path after you've generated it.

Honestly though, I'd do the simplest thing first and check whether it's a real problem.

any smart ways on how to measure if a pixel is 'dark'? and then to darken it equally without shifting it's colour to another hue?

(shaders; glsl)

The hue/saturation (chromaticity) is the ratio between the values of the colour channels. So if you scale all three by the same scalar, you'll get a brighter/darker colour without changing its chromaticity.

You can get a quick luma or luminance measure by dotting the colour with the coefficients shown here

@DMGregory wonderful

@Tyyppi_77 true, always forget about HSL