| Time |
Nick |
Message |
| 00:26 |
|
cranezhou joined #minetest-dev |
| 02:14 |
kilbith |
phew, I did it: https://www.youtube.com/watch?v=3RmYVBPkDgY |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:04 |
MTDiscord |
<freelikegnu> cool! |
| 05:07 |
|
v-rob joined #minetest-dev |
| 06:08 |
|
calcul0n_ joined #minetest-dev |
| 06:55 |
|
calcul0n_ joined #minetest-dev |
| 06:56 |
|
appguru joined #minetest-dev |
| 07:06 |
|
v-rob joined #minetest-dev |
| 07:37 |
|
cranezhou joined #minetest-dev |
| 07:48 |
|
appguru joined #minetest-dev |
| 07:56 |
|
appguru joined #minetest-dev |
| 08:03 |
nrz |
kilbith: and now MT engine can become a STR engine ? 😄 |
| 08:03 |
nrz |
you are really hacking original engine and make it a voxel generic engine 🙂 |
| 08:03 |
nrz |
there is no way to handle this server side currently and send orders i think :p |
| 08:20 |
MTDiscord |
<luatic> kilbith: how do the maths work? do you check whether the projection of the selectionboxes on the viewport intersects with the selected rectangle? |
| 09:06 |
celeron55 |
if you know the camera's parameters you can calculate the screen space position of any 3d position of the world |
| 09:07 |
celeron55 |
i made a couple of 3d rts prototypes many years back, that wasn't much of a hassle at all |
| 09:10 |
celeron55 |
hmm, now that i looked at my code, actually i think i didn't end up doing the screen space rectangle thing at all |
| 09:11 |
celeron55 |
i did the rectangle in world space instead |
| 09:15 |
MTDiscord |
<luatic> wouldn't that be less efficient? |
| 09:15 |
MTDiscord |
<luatic> because world space is 3d and screen space is 2d |
| 09:15 |
MTDiscord |
<luatic> well, ignoring the depth of the screen space |
| 09:16 |
MTDiscord |
<luatic> now I wonder how (if at all?) visibility of the units is checked |
| 09:17 |
MTDiscord |
<luatic> the usual hack would be to paint each object (or its selectionbox) in a unique color (you have 255^3 colors available after all) to another buffer, then check which colors the rectangle intersects |
| 09:17 |
MTDiscord |
<luatic> this is often faster because it lets the graphic card do all the math |
| 09:17 |
MTDiscord |
<luatic> also it is easier to have it line up with what is rendered |
| 09:19 |
celeron55 |
well the thing is, in my rts prototype you don't have a mouse cursor except in menus |
| 09:19 |
celeron55 |
i didn't remember that at first, i had to launch it and play to remember how it worked |
| 09:22 |
celeron55 |
it plays mostly like flying in minetest |
| 09:37 |
celeron55 |
about visibility in an rts... well, usually you want the map to be fairly flat in which case you want the selection to grab all the objects regardless if there's something temporarily in the way |
| 09:38 |
celeron55 |
but if you want to make your life miserable using a real 3d map with large overhangs and even floating islands or something, then you probably want to account for occlusions somehow. but i can't imagine what would be very enjoyable to play anyway |
| 09:38 |
celeron55 |
s/what/that/ |
| 10:07 |
|
Fixer joined #minetest-dev |
| 10:16 |
|
MTDiscord1 joined #minetest-dev |
| 10:48 |
|
proller joined #minetest-dev |
| 11:26 |
|
appguru joined #minetest-dev |
| 11:37 |
|
cranezhou joined #minetest-dev |
| 11:48 |
|
appguru joined #minetest-dev |
| 12:11 |
|
cranezhou joined #minetest-dev |
| 12:40 |
|
appguru joined #minetest-dev |
| 12:52 |
|
appguru joined #minetest-dev |
| 13:53 |
kilbith |
@luatic: rectangles are in 2D screen-space position, then converted to 3D world-space position using a complex algorithm that I have to bring back to Irrlicht |
| 13:55 |
kilbith |
I mean the rects stay in screen-space but the node collision checking is done in 3D |
| 14:06 |
|
fluxionary_ joined #minetest-dev |
| 14:14 |
|
proller joined #minetest-dev |
| 14:29 |
|
kilbith joined #minetest-dev |
| 14:34 |
|
Fixer joined #minetest-dev |
| 16:46 |
|
vampi__ joined #minetest-dev |
| 16:50 |
|
jwmhjwmh joined #minetest-dev |
| 16:52 |
jwmhjwmh |
Merging #12902, #12930, #12940, and #12945 in 5m. |
| 16:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12902 -- Fix typos and en_US/en_GB inconsistency in various files by Abdou-31 |
| 16:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12930 -- Resize hotbar immediately before drawing by x2048 |
| 16:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12940 -- Flip player_back.png by GoodClover |
| 16:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12945 -- Fix get_tool_wear_after_use for one use (insta-break) by grorp |
| 16:57 |
|
olliy joined #minetest-dev |
| 17:17 |
|
v-rob joined #minetest-dev |
| 17:45 |
|
appguru joined #minetest-dev |
| 17:47 |
|
v-rob joined #minetest-dev |
| 18:16 |
|
v_rob joined #minetest-dev |
| 18:35 |
pgimeno |
looks like: calculate the frustum for the rectangle, then apply (sort of) frustum culling |
| 18:36 |
pgimeno |
easy-ish if you have the projection matrix |
| 18:54 |
|
kilbith joined #minetest-dev |
| 18:56 |
|
Fixer_ joined #minetest-dev |
| 20:15 |
|
Desour joined #minetest-dev |
| 20:29 |
|
appguru joined #minetest-dev |
| 20:32 |
|
v_rob joined #minetest-dev |
| 20:32 |
Desour |
^ FYI, that's also how irrlicht calculates the planes for frustum culling (see <https://github.com/minetest/irrlicht/blob/a549d0bfed02801d642ef281697f8ac7c3dbc2cf/include/SViewFrustum.h#L297>). it's just a transformation of clip-space plane vectors to world-space (= multiplication with the inverse (because from clip to world) of the transposed of the inversed (because it's planes) (= the transposed) of the projection matrix) |
| 20:54 |
|
proller joined #minetest-dev |
| 21:03 |
|
vampi__ joined #minetest-dev |
| 21:03 |
|
diceLibrarian joined #minetest-dev |
| 22:46 |
|
cranezhou joined #minetest-dev |
| 23:10 |
|
paradust joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
