| Time |
Nick |
Message |
| 00:13 |
|
erlehmann joined #minetest-dev |
| 00:24 |
p_gimeno |
Wuzzy: mind if I add one? |
| 00:25 |
p_gimeno |
item |
| 00:27 |
Wuzzy |
feel free |
| 00:29 |
p_gimeno |
done |
| 00:31 |
p_gimeno |
is it possible to implement a pathfinder that can also perform angled moves? |
| 00:31 |
p_gimeno |
hmm, for AABB collision boxes that may be irrelevant |
| 00:33 |
Wuzzy |
p_gimeno: angled moves? |
| 00:33 |
p_gimeno |
like, "move at a 60° yaw" |
| 00:34 |
Wuzzy |
Yes, that's the Theta* algorithm |
| 00:34 |
p_gimeno |
I was thinking about it for width clearance, but for AABBs I don't think there's an advantage |
| 00:48 |
p_gimeno |
oh, Minkowski! *slaps forehead* of course |
| 00:48 |
p_gimeno |
I have an idea for applying width clearance |
| 00:50 |
p_gimeno |
basically, reduce the traveller to one point and expand the maze accordingly, then apply pathfinding |
| 00:50 |
Wuzzy |
i don't get it. |
| 00:51 |
p_gimeno |
it's a concept I've used for collision detection and resolution |
| 00:52 |
Wuzzy |
define "reduce the traveller to one point" |
| 00:52 |
Wuzzy |
define "expand the maze accordingly" |
| 00:53 |
p_gimeno |
if you have two AABBs, and want to calculate whether they collide or not, it's easy, but if you want to resolve collisions, it's more useful to treat one of them as a point, and expand the other by the first one's width and height |
| 00:54 |
p_gimeno |
https://blog.hamaluik.ca/posts/simple-aabb-collision-using-minkowski-difference/ |
| 00:54 |
Wuzzy |
I don't see how this solves width clearance |
| 00:55 |
p_gimeno |
if you expand every obstacle by the traveller's width and height, you can then treat the traveller as a point |
| 00:56 |
p_gimeno |
with the traveller being a point, you already know how to apply patfinding |
| 00:57 |
Wuzzy |
hmmm wait a minute.... |
| 00:57 |
Wuzzy |
would that mean that you could collision-check with nodeboxes as welll??? |
| 00:58 |
p_gimeno |
if you can get the shape of the nodebox, maybe |
| 00:59 |
p_gimeno |
actually this reference is better: https://wildbunny.co.uk/blog/2011/04/20/collision-detection-for-dummies/ - scroll down to figure 4 and read the preceding few paragraphs |
| 01:00 |
Wuzzy |
yes you can get the shape of the nodebox. minetest.registered_nodes[nodename].node_box |
| 01:01 |
Wuzzy |
but its a lot of work to support all possible nodebox variants (fixed, wallmounted, connected_to...) |
| 01:01 |
p_gimeno |
and I know some shapes are made of an insane amount of boxes |
| 01:02 |
Wuzzy |
collisionboxes should generally be kept simple |
| 01:02 |
Wuzzy |
its pointless to have 100 boxes for for 1 node only |
| 01:02 |
Wuzzy |
collision-wise, at least |
| 01:03 |
p_gimeno |
anyway, theoretically yes it's possible |
| 01:03 |
Wuzzy |
the algorithm could also just discard any overcomplex collisionboxes and just treat them as 100% solid to boost performance |
| 01:03 |
p_gimeno |
yes |
| 01:04 |
Wuzzy |
but this should not be needed normally. overcomplex collisionboxe are a sign of poor coding |
| 01:04 |
p_gimeno |
does it currently have some way of aborting if it takes too long? |
| 01:04 |
Wuzzy |
just simplify your collisionboxes |
| 01:04 |
Wuzzy |
no |
| 01:05 |
Wuzzy |
the only safeguard the pathfinder currently has is limiting path length to 700 |
| 01:05 |
p_gimeno |
I think it was this one: https://raw.githubusercontent.com/narrnika/factory_bridges/master/screenshots/scr_01.png |
| 01:05 |
Wuzzy |
but even this safeguard is pretty useless as it applies *after* the full cost calculation |
| 01:05 |
p_gimeno |
that staircase is made with nodeboxes |
| 01:06 |
p_gimeno |
and IIRC they are all collidable |
| 01:06 |
erlehmann |
lol |
| 01:06 |
Wuzzy |
cool. i like catwalks |
| 01:07 |
p_gimeno |
yeah but the railing... well, is made of little tiny boxes |
| 01:07 |
erlehmann |
about simplifying collision boxes: a friend of mine has this issue that in mineclone 2 the newly hatched chickens escape the confinement |
| 01:07 |
erlehmann |
why? because they can duck (hehe) unter the fence |
| 01:07 |
Wuzzy |
this issue is ancient and has been fixed since long |
| 01:07 |
Wuzzy |
the solution was to increase the collisionbox size |
| 01:08 |
Wuzzy |
the collisionbox is not identical to the boxes that you see |
| 01:08 |
erlehmann |
so either i have an ancient version or they just … glitch through, when hatching? |
| 01:09 |
erlehmann |
p_gimeno, so what's the collision model for the staircases? everything visible is collidable? |
| 01:09 |
Wuzzy |
the only explanation i have is when they actually spawn inside the fence |
| 01:09 |
Wuzzy |
the default collision box is equal to the visible nodebox |
| 01:09 |
Wuzzy |
obviously this is very bad if you have a lot of boxes. this definitely needs to be simplified |
| 01:10 |
p_gimeno |
erlehmann: model boxes, selection boxes and collision boxes are identical for these stairs. It's insane. |
| 01:10 |
erlehmann |
p_gimeno, selection boxes |
| 01:10 |
erlehmann |
that is extremely user hostile |
| 01:10 |
erlehmann |
i hate clicking somewhere else accidentally |
| 01:10 |
Wuzzy |
since the rail is diagonal, this screams "I want to be a mesh!" |
| 01:11 |
p_gimeno |
there were complaints about that IIRC. But I've used them and it's not too bad. |
| 01:12 |
p_gimeno |
anyway, that's one of the craziest examples |
| 01:12 |
p_gimeno |
of course that's the exception, not the norm |
| 01:13 |
p_gimeno |
the idea of minkowski difference is that you reduce the player and expand the world, until the player is a single point, then calculate the path for a point |
| 01:14 |
p_gimeno |
the MD of two AABBs is another AABB and is simple to calculate |
| 01:14 |
p_gimeno |
your problems don't end there though, because you're no longer dealing with a grid |
| 01:20 |
p_gimeno |
perhaps you can treat each vertex of each AABB in the minkowski difference as a graph vertex, and connect two vertices iff there is a line of sight between both |
| 01:20 |
p_gimeno |
then use A* on the graph |
| 01:21 |
p_gimeno |
I need to draw a diagram |
| 01:22 |
p_gimeno |
Wuzzy: do you get the idea behind Minkowski difference? the reduction of the player to one point, by expanding each box in the world by the original player's size? |
| 01:23 |
Wuzzy |
and how do you pathfind through this mess? |
| 01:24 |
Wuzzy |
where are the nodes in this graph? |
| 01:24 |
p_gimeno |
that's what I was going to draw :) |
| 01:38 |
p_gimeno |
so let's take http://www.formauri.es/personal/pgimeno/temp/rect4572.png |
| 01:40 |
p_gimeno |
the same in Minkowski space: http://www.formauri.es/personal/pgimeno/temp/rect4574.png (with the original obstacles shown in outline in for clarity |
| 01:40 |
p_gimeno |
) |
| 01:40 |
|
Foz joined #minetest-dev |
| 01:41 |
p_gimeno |
the problem of traversing a rectangle through the maze in the first figure, is equivalent to the problem of traversing a point through the maze in the second figure |
| 01:43 |
p_gimeno |
now I need to draw the graph, and for that I will take each vertex of each rectangle (square in this case) in the second figure, as one vertex in the graph |
| 01:43 |
p_gimeno |
and two vertices are connected only if there is a line of sight between them |
| 01:43 |
p_gimeno |
so let me try to draw that |
| 01:48 |
Wuzzy |
so you always take the top left point. or do you use center? |
| 01:48 |
Wuzzy |
or doesn't it matter either way? |
| 02:00 |
p_gimeno |
as long as you're consistent, it doesn't matter |
| 02:00 |
p_gimeno |
still drawing, this is tough :) |
| 02:08 |
p_gimeno |
http://www.formauri.es/personal/pgimeno/temp/rect4758.png |
| 02:08 |
p_gimeno |
that would be the graph |
| 02:08 |
p_gimeno |
I may have missed a few lines of sight |
| 02:10 |
p_gimeno |
yeah, just updated |
| 02:10 |
p_gimeno |
the idea is that each vertex is a vertex of a rectangle in the MD |
| 02:11 |
p_gimeno |
and that there are edges between each pair of vertices which have a direct line of sight |
| 02:13 |
p_gimeno |
i.e. between each pair of vertices as long as the straight line between them doesn't cross one of the obstacles |
| 02:13 |
p_gimeno |
(in the MD) |
| 02:15 |
p_gimeno |
updated again, sorry |
| 02:25 |
p_gimeno |
http://www.formauri.es/personal/pgimeno/temp/rect4776.png |
| 02:25 |
p_gimeno |
^ possible solution |
| 02:38 |
p_gimeno |
I've made a mistake in the first picture |
| 02:39 |
p_gimeno |
http://www.formauri.es/personal/pgimeno/temp/rect4572.png |
| 02:40 |
p_gimeno |
if you extend the other boxes towards the right and bottom, it means your reference point is at the bottom right of the shape |
| 02:45 |
p_gimeno |
http://www.formauri.es/personal/pgimeno/temp/rect5158.png is the path back in the context of the original problem |
| 02:49 |
p_gimeno |
an obvious problem with this approach is the elaboration of the graph... as the number of vertices grows, the number of edges is probably going to skyrocket |
| 03:44 |
Wuzzy |
interesting |
| 04:42 |
|
pmp-p joined #minetest-dev |
| 05:45 |
|
ssieb joined #minetest-dev |
| 08:17 |
|
erlehmann_ joined #minetest-dev |
| 08:38 |
|
ShadowNinja joined #minetest-dev |
| 08:49 |
|
erlehmann joined #minetest-dev |
| 09:07 |
|
nepugia joined #minetest-dev |
| 09:38 |
|
erlehmann_ joined #minetest-dev |
| 09:52 |
|
troller joined #minetest-dev |
| 10:38 |
|
df458 joined #minetest-dev |
| 10:54 |
|
troller joined #minetest-dev |
| 10:56 |
|
Time_Styler joined #minetest-dev |
| 10:58 |
|
Time_Styler joined #minetest-dev |
| 11:00 |
|
Beton joined #minetest-dev |
| 11:07 |
|
Adnanudesu joined #minetest-dev |
| 11:13 |
|
Fixer joined #minetest-dev |
| 11:19 |
|
troller joined #minetest-dev |
| 11:33 |
|
Time_Styler joined #minetest-dev |
| 11:33 |
|
Time_Styler left #minetest-dev |
| 11:46 |
|
kilbith joined #minetest-dev |
| 12:00 |
|
troller joined #minetest-dev |
| 12:36 |
|
kilbith_ joined #minetest-dev |
| 13:34 |
|
troller joined #minetest-dev |
| 14:09 |
|
Djdjdjd joined #minetest-dev |
| 15:09 |
|
Wuzzy joined #minetest-dev |
| 15:10 |
Wuzzy |
Can someone please verify if <https://dev.minetest.net/Minetest_Schematic_File_Format> is correct? |
| 15:42 |
|
Dargod_ZNC joined #minetest-dev |
| 15:43 |
|
calcul0n joined #minetest-dev |
| 15:47 |
|
Dargod joined #minetest-dev |
| 15:57 |
|
Dargod_ZNC joined #minetest-dev |
| 16:07 |
|
kilbith joined #minetest-dev |
| 16:09 |
|
Dargod joined #minetest-dev |
| 16:13 |
|
Fixer_ joined #minetest-dev |
| 16:14 |
|
Dargod joined #minetest-dev |
| 16:57 |
|
Dargod joined #minetest-dev |
| 17:16 |
p_gimeno |
Wuzzy: I asked in Stack Exchange about the edges problem, they suggested to build a navmesh from the navigable area after the MD. That might be convertible to a practical algorithm. |
| 17:16 |
Wuzzy |
interesting |
| 17:16 |
Wuzzy |
note that we still must wait until my bugfixes are merged |
| 17:17 |
Wuzzy |
i'd say it would be pointless to touch pathfinder before it has been repaired |
| 17:17 |
p_gimeno |
yes, I'm just giving ideas for the future :) |
| 17:17 |
Wuzzy |
sure |
| 17:17 |
Wuzzy |
the first feature i'd like to see is height clearance. i suspect it would be simple, too |
| 17:17 |
p_gimeno |
yes, most likely |
| 17:17 |
Wuzzy |
and it has already been demonstrated in a pathfinder mod called "pathfinder" by burli |
| 17:18 |
p_gimeno |
since I proposed the width clearance, I felt I also had to show that it's feasible in practice |
| 17:22 |
|
Dargod joined #minetest-dev |
| 17:57 |
|
pmp-p joined #minetest-dev |
| 18:14 |
sfan5 |
guiFormSpecMenu.cpp includes scripting_server.h |
| 18:14 |
sfan5 |
just why |
| 18:17 |
|
absurb joined #minetest-dev |
| 18:34 |
|
NoctisLabs joined #minetest-dev |
| 18:35 |
|
NoctisLabs joined #minetest-dev |
| 18:38 |
Krock |
why not? everything needs scripting, even the render functions |
| 18:42 |
|
NoctisLa1 joined #minetest-dev |
| 18:43 |
sfan5 |
the form spec code never directly calls scripting |
| 18:47 |
Krock |
it would be handy to parse the code for unused included headers. Incremental compiling can be improved that way |
| 18:47 |
Krock |
although some headers are included explicitly rather than depending on other headers - for safety and a simpler structure |
| 18:48 |
|
NoctisLa1 joined #minetest-dev |
| 19:08 |
|
NoctisLa1 joined #minetest-dev |
| 19:57 |
|
Fixer joined #minetest-dev |
| 19:59 |
|
calcul0n joined #minetest-dev |
| 20:02 |
|
Andrey01 joined #minetest-dev |
| 20:03 |
Andrey01 |
hello |
| 20:05 |
|
Taoki joined #minetest-dev |
| 20:16 |
Andrey01 |
I`m currently learning Irrlicht and I have few issues: first one concerns the animated node at the scene that is for unknown reason a bit jerking and second is when the node disappears from the field of view for the camera rotating when it approaches to the window edges |
| 20:17 |
Andrey01 |
please help: https://ufile.io/3p25ez2m |
| 20:18 |
Krock |
that's related to the FOV and the optimization calculations |
| 20:18 |
Krock |
occlusion culling |
| 20:18 |
Krock |
this isn't an irrlicht help channel FYI |
| 20:29 |
|
NoctisLabs joined #minetest-dev |
| 20:32 |
|
troller joined #minetest-dev |
| 20:34 |
|
NoctisLa1 joined #minetest-dev |
| 20:37 |
|
TC01 joined #minetest-dev |
| 20:39 |
|
NoctisLa1 joined #minetest-dev |
| 20:46 |
Andrey01 |
I asked for it here because Minetest also uses Irrlicht API and also I have goals to use it later for Minetest, so could you please help or anybody else with those issues? I don`t know how to fix that |
| 20:47 |
|
NoctisLabs joined #minetest-dev |
| 21:21 |
sfan5 |
merging #9388 in a few minutes |
| 21:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/9388 -- Update some libraries for buildbot by sfan5 |
| 21:28 |
|
Foz joined #minetest-dev |
| 21:30 |
|
NoctisLa1 joined #minetest-dev |
| 21:32 |
|
NoctisLa2 joined #minetest-dev |
| 21:52 |
|
df458 joined #minetest-dev |
| 22:12 |
|
NoctisLabs joined #minetest-dev |
| 22:47 |
|
aldum joined #minetest-dev |
| 22:51 |
|
NoctisLabs joined #minetest-dev |
| 23:13 |
|
paramat joined #minetest-dev |
| 23:14 |
paramat |
merging #9394 |
| 23:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/9394 -- Throw an error when too many noise octaves by paramat |
| 23:35 |
|
Foz joined #minetest-dev |
| 23:48 |
paramat |
simple PR just needs 1 more approval game#2573 |
| 23:48 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2573 -- [REDO] Accelerate water/river water animations. by Andrey2470T |
| 23:52 |
|
troller joined #minetest-dev |
| 23:53 |
paramat |
game#2328 very simple bugfix PR open for a long time but i do not understand it. just needs 1 more approval |
| 23:53 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2328 -- Fix builtin item metatable. by sofar |
