| Time |
Nick |
Message |
| 00:30 |
|
Soni joined #minetest |
| 00:35 |
MTDiscord |
<MisterE> anyone want to play the newly finished balloon bop minigame, based on Exevirus' ludum Dare game? |
| 00:40 |
|
Verticen joined #minetest |
| 00:57 |
|
TheAltHacker joined #minetest |
| 01:04 |
|
cation joined #minetest |
| 01:17 |
|
specing joined #minetest |
| 01:28 |
|
v-rob joined #minetest |
| 01:46 |
|
Verticen joined #minetest |
| 01:58 |
|
Toothless joined #minetest |
| 02:14 |
|
v-rob joined #minetest |
| 02:21 |
|
v-rob joined #minetest |
| 02:40 |
ghoti |
So.. I know I can skin a basic_robot using things like this: self.set_properties({visual="mesh", mesh="mobs_tree_monster.b3d", textures={"mobs_tree_monster2.png"}, visual_size={x=2, y=2}}) |
| 02:40 |
ghoti |
But how do I do this if I'm given a .obj file instead of a .b3d file? If I just change files, I get .. weird shapes instead of the the ones I'm expecting. |
| 03:00 |
|
Fulgen joined #minetest |
| 03:25 |
|
v-rob joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:25 |
|
paradust joined #minetest |
| 04:26 |
|
mugli[m] joined #minetest |
| 04:29 |
|
loggingbot_ joined #minetest |
| 04:29 |
|
Topic for #minetest is now The official Minetest channel | Latest version: 5.5.0 (2022-01-30) | General, player and modding discussion is on-topic. If in doubt, post here | Responses may take a while, be patient | Rules: https://wiki.minetest.net/IRC#Rules | Development: #minetest-dev | Server list: https://minetest.net/servers | IRC logs: https://irc.minetest.net/minetest |
| 04:30 |
|
hook54321 joined #minetest |
| 04:33 |
|
v-rob joined #minetest |
| 04:34 |
|
programmerjake joined #minetest |
| 04:35 |
|
GNUverkty[m] joined #minetest |
| 04:36 |
|
Kimapr joined #minetest |
| 05:29 |
|
lemonzest joined #minetest |
| 05:41 |
|
calcul0n joined #minetest |
| 06:33 |
|
acidbunny joined #minetest |
| 06:52 |
|
Gustavo6046 joined #minetest |
| 06:58 |
|
Gustavo6046 joined #minetest |
| 07:00 |
|
Pexin joined #minetest |
| 07:23 |
sfan5 |
@Warr1024 that does sound like it might be broken position interpolation esp. relating to low framerates |
| 07:26 |
erle |
for the nodebox drawtype, how can i make it culled? |
| 07:26 |
erle |
i tried to turn all the stone into lego bricks |
| 07:27 |
erle |
and it renders everything |
| 07:27 |
erle |
i can see it in wireframe view |
| 07:27 |
erle |
it's not good for the fps |
| 07:29 |
erle |
it looks like this https://mister-muffin.de/p/KyQM.png |
| 07:30 |
erle |
if i can fix the framerate problem, i can make a mod that adds studs on all the cube nodes :) |
| 07:34 |
sfan5 |
the engine can't do face merging for nodeboxes |
| 07:43 |
MTDiscord |
<ROllerozxa> yeah I don't think there's any way of doing culling with nodeboxes to make a mod like that work currently |
| 07:43 |
MTDiscord |
<ROllerozxa> I actually tested having 3d studs in openblox but it ended up becoming so laggy that the map loading just completely froze |
| 07:45 |
MTDiscord |
<ROllerozxa> you could of course go the texture trickery route and make a mod that overlays a stud outline texture on the top face of every node, but it won't be true 3D studs unfortunately |
| 07:47 |
erle |
yeah it's super laggy |
| 08:09 |
erle |
sfan5 ROllerozxa i thought this was horrible at first, but hahahaha rendering speed goes brrrrrrr https://mister-muffin.de/p/Fgdj.png |
| 08:10 |
erle |
obviously this neighbour check could be made a bit better |
| 08:10 |
erle |
because i only want to catch opaque nodes |
| 08:12 |
erle |
and obviously the nodebox can extend {-8/16,-8/16,-8/16,8/16,8/16,8/16} |
| 08:15 |
MTDiscord |
<ROllerozxa> oh nice |
| 08:15 |
erle |
yeah so how would a proper check for “surrounded by opaque nodes” look? |
| 08:18 |
erle |
because if anyone can code some check like that, it's free fps for all drawtypes that can not be automagically culled |
| 08:18 |
erle |
celeron55 rubenwardy any idea? |
| 08:20 |
|
v-rob joined #minetest |
| 08:22 |
MTDiscord |
<GoodClover> Was about to point out nodeboxes can extend up to 3 nodes³, but no that's not an issue. |
| 08:24 |
MTDiscord |
<GoodClover> oh wait, it is. You need to check the diagonals too. |
| 08:24 |
sfan5 |
this issue has been known for a few years, it's one of the reasons MTG didn't get nodebox snow |
| 08:25 |
sfan5 |
so it won't be that nobody has tried solving it |
| 08:25 |
erle |
yeah i want to know what they ran into |
| 08:26 |
erle |
like, suppose i a) check the diagonals and b) figure out how to find out how to check for “is this node fully occluded” |
| 08:26 |
erle |
what remains? |
| 08:26 |
erle |
or is the ”fully occluded” check too difficult? |
| 08:26 |
erle |
if so, in what way? |
| 08:27 |
erle |
sfan5 if you could point me to discussions or implementations of ideas like that, maybe i can learn from it |
| 08:28 |
sfan5 |
that's a different, simpler approach than I was thinking of |
| 08:28 |
sfan5 |
you want to skip entire nodes if they cannot possibly be seen |
| 08:29 |
sfan5 |
what we really need is to remove any duplicate faces (at least) at node borders |
| 08:29 |
MTDiscord |
<GoodClover> Looking at lua_api the recommended limit is actually 2.9n³ (1.45 in each direction), and only for collision boxes. So this would introduce a new "restriction" of sorts. |
| 08:29 |
MTDiscord |
<GoodClover> I'm all for it though |
| 08:30 |
sfan5 |
here's one of them https://github.com/minetest/minetest/issues/6409 |
| 08:31 |
|
jluc joined #minetest |
| 08:32 |
sfan5 |
duplicate but with more detail https://github.com/minetest/minetest/issues/9126 |
| 08:34 |
sfan5 |
the obvious question is how would you implement this efficiently |
| 08:35 |
sfan5 |
(I have no idea) |
| 08:38 |
|
jluc joined #minetest |
| 08:40 |
|
___nick___ joined #minetest |
| 08:41 |
MTDiscord |
<GoodClover> erle: your current solution would cause issue with people surrounding nodeboxes by transparent nodes. |
| 08:42 |
MTDiscord |
<GoodClover> oh, sorry, you mentioned that above |
| 08:48 |
|
___nick___ joined #minetest |
| 08:53 |
|
orwell96 joined #minetest |
| 08:54 |
erle |
GoodClover give me a check for opaque nodes and you get legos everywhere |
| 09:08 |
|
Thelie joined #minetest |
| 09:30 |
|
jluc joined #minetest |
| 09:49 |
|
Fixer joined #minetest |
| 10:33 |
|
YuGiOhJCJ joined #minetest |
| 10:57 |
|
Wuzzy joined #minetest |
| 10:57 |
MinetestBot |
Wuzzy: Apr-30 14:19 UTC <rubenwardy> no idea, maybe ask on the thread |
| 11:00 |
|
definitelya joined #minetest |
| 11:22 |
|
grouinos joined #minetest |
| 12:26 |
|
Thelie joined #minetest |
| 12:46 |
|
debiankaios joined #minetest |
| 12:48 |
|
orwell96_ joined #minetest |
| 13:01 |
|
_Zaizen_[m] joined #minetest |
| 13:15 |
|
specing_ joined #minetest |
| 13:16 |
|
kamdard joined #minetest |
| 13:32 |
MTDiscord |
<Warr1024> sfan5: re: position interpolation: I tried peeking at the code, and there were some fudge factors in it that had a strong "last person to work on this didn't actually understand how it works" kind of smell to it. :-) |
| 13:33 |
MTDiscord |
<Warr1024> I was thinking of filing it as an issue (client visuals) but an existing-bug search is part of that process, and I couldn't be sure that I had the right terminology and wasn't missing some duplicate. |
| 13:35 |
MTDiscord |
<Warr1024> I also ran into a fun one where player:set_look_dir() always happens on a different client step AFTER player:set_pos(), even if it's called BEFORE set_pos() on the same tick server-side. This causes "camera jumpcuts" to have a few frames of an intermediate cut that doesn't belong. |
| 14:09 |
|
Taoki joined #minetest |
| 14:36 |
|
qur joined #minetest |
| 14:57 |
|
Sven_vB joined #minetest |
| 15:03 |
|
qur joined #minetest |
| 15:07 |
|
Thelie joined #minetest |
| 15:11 |
|
Talkless joined #minetest |
| 15:12 |
|
TheCoffeMaker joined #minetest |
| 15:14 |
|
panwolfram joined #minetest |
| 15:26 |
|
TheCoffeMaker joined #minetest |
| 15:29 |
|
qur joined #minetest |
| 15:40 |
|
appguru joined #minetest |
| 16:06 |
|
panwolfram joined #minetest |
| 16:12 |
|
Verticen joined #minetest |
| 16:18 |
|
panwolfram joined #minetest |
| 16:20 |
|
TheCoffeMaker joined #minetest |
| 16:23 |
MinetestBot |
[git] JakobDev -> minetest/minetest: Add German translation to AppData file (#12161) 41e79d9 https://github.com/minetest/minetest/commit/41e79d902d536f31b7b5fe2fb63a7272ce38d437 (2022-05-02T16:22:23Z) |
| 16:24 |
|
debiankaios joined #minetest |
| 16:47 |
|
TheCoffeMaker joined #minetest |
| 16:48 |
|
v-rob joined #minetest |
| 16:58 |
|
Yad joined #minetest |
| 17:23 |
settl3r[m] |
If player A built a travelnet with name X, can player B (who doesn't know A) connect his own travelnet booth to network X (eg. if he accidentally discovers the name), and then travel to player A's (secret) location ? |
| 17:25 |
|
qur joined #minetest |
| 17:32 |
|
Thelie joined #minetest |
| 17:37 |
calcul0n |
settl3r[m], no, this will just create another network |
| 17:43 |
|
x2048 joined #minetest |
| 17:44 |
x2048 |
erle, sfan5: Rergarding nodeboxes, I've been thinking about simple optimization that would focus on snow and similar stuff |
| 17:45 |
x2048 |
step1: enumerate neighboring solid nodes |
| 17:45 |
x2048 |
step2: enumerate neighboring nodes with the same node type |
| 17:46 |
x2048 |
When drawing a cuboid, when a dimension has bounds [-0.5, 0.5], check neighbours lef and right and skip drawing faces if a neighbor is a solid or the same type |
| 17:46 |
x2048 |
That was step3 |
| 17:48 |
sfan5 |
o/ |
| 17:48 |
sfan5 |
that's missing a step where you precompute for each node which side is entirely covered |
| 17:48 |
sfan5 |
but yeah that'd work |
| 17:49 |
sfan5 |
as the graphics person I expected that you'd have an idea how to efficiently implement generic "If a triangle [...] facing a box face co-planarly" tests |
| 17:49 |
sfan5 |
my google-fu failed me on this |
| 17:49 |
|
TheCoffeMaker joined #minetest |
| 17:50 |
x2048 |
I was thinking about that too, but sounds more complicated, like, a next step |
| 17:50 |
x2048 |
What I propose is much simpler and has two assumptions: |
| 17:51 |
x2048 |
(1) solid nodes most likely win over nodeboxes (yes, there are easy exceptions) |
| 17:51 |
x2048 |
(2) we need to optimize large arrays of typical nodeboxes, not snowflakes |
| 17:52 |
sfan5 |
well it'd also be nice if internal duplicate faces of nodeboxes could be removed |
| 17:52 |
sfan5 |
but you can precompute that and do it with a different algorithm if needed |
| 17:55 |
|
nisa joined #minetest |
| 18:04 |
|
kabou joined #minetest |
| 18:05 |
|
qur joined #minetest |
| 18:07 |
|
TheCoffeMaker joined #minetest |
| 18:10 |
|
Verticen joined #minetest |
| 18:13 |
MTDiscord |
<luatic> "If a triangle [...] facing a box face co-planarly" tests - do you want generic tests (for arbitrarily rotated triangles and boxes) or just for AABBs? |
| 18:16 |
sfan5 |
AABB suffices |
| 18:19 |
settl3r[m] |
<calcul0n> "settl3r, no, this will just..." <- ok, what about elevators? do these function less strictly? |
| 18:24 |
MTDiscord |
<x2048> @criticalfault42 I had to step away, and you picked my thought. We need to analyze AABB, not triangles. |
| 18:26 |
MTDiscord |
<luatic> The first question to ask would be: Do we event want to check against co-planarity? I don't think so. |
| 18:26 |
sfan5 |
why not |
| 18:26 |
MTDiscord |
<luatic> We want to perform occlusion checks, but not every co-planar face is occluded |
| 18:27 |
MTDiscord |
<luatic> Co-planar faces may be Z-fighting, but even that might be resolved by backface culling |
| 18:27 |
MTDiscord |
<luatic> We want to find interior faces, which for two solid bodies next to each other happen to be co-planar faces |
| 18:29 |
sfan5 |
you're un-simplifying the problem |
| 18:30 |
MTDiscord |
<luatic> I may indeed be complicating it, oof |
| 18:31 |
MTDiscord |
<luatic> Anyways, if we restrict our stuff only to fully solid nodes (alpha = opaque) |
| 18:32 |
MTDiscord |
<luatic> Well, finding equal faces is pretty easy for nodeboxes < 1 node, just check whether the neighbor has a face there |
| 18:32 |
MTDiscord |
<luatic> Otherwise this theoretically is a case for R-trees |
| 18:34 |
rubenwardy |
ERROR[Main]: OpenGL procedures were not loaded correctly, please open a bug report with details about your platform/OS. |
| 18:35 |
rubenwardy |
this is new |
| 18:35 |
rubenwardy |
outdated irrlicht maybe |
| 18:36 |
sfan5 |
if irrlicht is oudated you should get a compile error instead |
| 18:36 |
sfan5 |
but try that |
| 18:39 |
rubenwardy |
same error |
| 18:39 |
rubenwardy |
maybe needs a clean build |
| 18:40 |
erle |
i don't even want to |
| 18:40 |
erle |
think about this in terms of faces |
| 18:40 |
erle |
i just want to not render stuff that is surrounded by other stuff so it can never be seen |
| 18:40 |
erle |
so i can make everything lego |
| 18:41 |
erle |
also i think the studs represent a bunch of problems for doing it later |
| 18:41 |
erle |
“later” as in later in the rendering process |
| 18:51 |
sfan5 |
rubenwardy: sounds like a bug report you need to file |
| 18:52 |
rubenwardy |
sounds like it. Just wanted to confirm whether it was a me problem first |
| 18:56 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Remove some unused variable from Lua class wrappers 5362f47 https://github.com/minetest/minetest/commit/5362f472ff75ffe1885b54d09f22faa85284f817 (2022-05-02T18:54:55Z) |
| 18:56 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Reorganize some builtin functions in preparation for async env e6385e2 https://github.com/minetest/minetest/commit/e6385e2ab74af7b01163ea91d4e3cfd5dfe6552e (2022-05-02T18:54:55Z) |
| 18:57 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Refactor some Lua API functions in preparation for async env 56a558b https://github.com/minetest/minetest/commit/56a558baf8ef43810014347ae624cb4ef70b6aa3 (2022-05-02T18:54:55Z) |
| 18:57 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix synchronization issue at thread start 663c936 https://github.com/minetest/minetest/commit/663c9364289dae45aeb86a87cba826f577d84a9c (2022-05-02T18:54:55Z) |
| 18:57 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Async environment for mods to do concurrent tasks (#11131) e765988 https://github.com/minetest/minetest/commit/e7659883cc6fca343785da2a1af3890ae273abbf (2022-05-02T18:56:06Z) |
| 19:01 |
|
Thelie joined #minetest |
| 19:01 |
erle |
sfan5 about “Keep the first four commits intact / Squash the rest into a single one” … do you know about interactive rebase? if yes, what is the reason for first making a bunch of commits only to then squash them? |
| 19:02 |
sfan5 |
I use git rebase -i more than git rebase |
| 19:02 |
erle |
oh okay |
| 19:02 |
sfan5 |
the reason is that I don't want to amend during development all the time and also it allows me to go back/look at older dev snapshots |
| 19:02 |
erle |
then why only squash on merge? is there an advantage? |
| 19:02 |
erle |
ok |
| 19:02 |
erle |
i see |
| 19:02 |
erle |
thx |
| 19:07 |
erle |
<MTDiscord> <luatic> Well, finding equal faces is pretty easy for nodeboxes < 1 node, just check whether the neighbor has a face there |
| 19:07 |
erle |
luatic show me the code |
| 19:07 |
erle |
so i can make the legos |
| 19:07 |
erle |
how to check if neighbour has a face |
| 19:08 |
sfan5 |
locate window, look at neighbor |
| 19:08 |
sfan5 |
if your neighbor is faceless call the police |
| 19:09 |
|
debiankaios joined #minetest |
| 19:09 |
erle |
“you must wear a face” https://nitter.net/Shitty_Future/status/1285346849298292736 |
| 19:11 |
|
behalebabo joined #minetest |
| 19:11 |
MTDiscord |
<ROllerozxa> aw man, what if I forgot my face at home? |
| 19:33 |
MTDiscord |
<luatic> yay async evn! |
| 19:48 |
sfan5 |
released a windows build with it too |
| 20:01 |
|
jluc joined #minetest |
| 20:01 |
MTDiscord |
<PrairieWind> I always wear my face |
| 20:02 |
MTDiscord |
<PrairieWind> Im not quite sure how to painlessly take it off. |
| 20:04 |
|
behalebabo joined #minetest |
| 20:06 |
MTDiscord |
<x2048> erle, sfan5, @criticalfault42 : Started optimizing nodeboxes here: https://github.com/x2048/minetest/tree/nodeboxes. MCL2 snow: https://ibb.co/BLJtCBx |
| 20:06 |
sfan5 |
great |
| 20:10 |
|
panwolfram joined #minetest |
| 20:11 |
erle |
x2048 wow, that looks good! but you don't do any diagonal checks so far, right? |
| 20:11 |
sfan5 |
what's so special about diagonals? |
| 20:12 |
erle |
i was thinking of oversized nodeboxes |
| 20:12 |
erle |
i mean my stupid check was also missing them |
| 20:12 |
erle |
bc i just wanted to see if it's viable |
| 20:12 |
erle |
i like the x2048 solution very much |
| 20:13 |
erle |
sfan5 regarding the snow layers, was it such a performance hog to draw all the node boxes? if so, wouldn't it be a horrible performance thing to draw 4 studs on top every top surface of a node? |
| 20:15 |
MTDiscord |
<x2048> So far I would not care to optimize oversized nodeboxes, unless there's a viable case with a 100x100 field of those. |
| 20:16 |
erle |
so what exactly is your criterion right now? same type or solid, right? |
| 20:17 |
erle |
(i have skimmed the source) |
| 20:18 |
erle |
x2048 so what would happen if an oversized nodebox is surrounded by 6 solids? |
| 20:18 |
MTDiscord |
<x2048> yes, because that's the two worst cases. |
| 20:18 |
|
v-rob joined #minetest |
| 20:18 |
erle |
so yeah, i am missing a check for a nodebox going out of bounds diagonally. maybe i am not seeing it where you exclude them? |
| 20:20 |
MTDiscord |
<x2048> ah, the current algorithm is dumb. if should also check that the face to mask is at the node boundary (+-0.5), and for sametype there's a matching face on the other side. |
| 20:20 |
MTDiscord |
<x2048> I did not add it yet |
| 20:20 |
MTDiscord |
<x2048> *it should |
| 20:22 |
erle |
well it is an improvement on my dumb algo obv |
| 20:22 |
erle |
i didn't even check for NDT_NORMAL hehe |
| 20:23 |
erle |
well you don't check for ignore, but not sure if that's relevant here |
| 20:23 |
erle |
x2048 do you want to test your current solution with my lego brick nodebox? |
| 20:24 |
MTDiscord |
<x2048> not yet ? |
| 20:24 |
MTDiscord |
<x2048> did you replace all solids with legobrick? |
| 20:24 |
MTDiscord |
<x2048> or do you only apply it to nodes under air? |
| 20:27 |
erle |
i made drawtype for stone lego and minetest crapped it's cuboid pants fps-wise |
| 20:27 |
erle |
this all came out of a conversation with my bf about how LEGO did not buy minecraft |
| 20:27 |
erle |
the reason for that is actually moderation |
| 20:27 |
erle |
LEGO universe (the “lego minecraft” that they developed around 2010 to 2012) was supposed to be a classic lego product |
| 20:28 |
erle |
i.e. trusted by parents |
| 20:28 |
erle |
which means they did everything to make sure that kids don't see dicks or so |
| 20:28 |
erle |
the problem is that everyone likes to build dicks in block games. especially kids. |
| 20:28 |
erle |
so they had whitelisted moderation |
| 20:29 |
erle |
you could build what you want, but others could only see it if mods whitelisted it |
| 20:29 |
erle |
because the LEGO group was of the opinion that they want to be 100% trusted by parents |
| 20:29 |
erle |
mojang on the other hand was like “you can't stifle creativity likei that and also IT COSTS A LOT OF MONEY” |
| 20:30 |
erle |
the money question and creativity stifling allegedly led to lego universe going the way of the dodo |
| 20:30 |
erle |
meanwhile, minecraft became a hit, but |
| 20:30 |
MTDiscord |
<x2048> to no surprise |
| 20:30 |
erle |
there are a lot of dicks and swastikas in random minecraft streamer's videos on youtube |
| 20:30 |
erle |
like if they just go explore |
| 20:30 |
MTDiscord |
<ROllerozxa> ohh my god, lego universe, I remember that |
| 20:31 |
erle |
i once saw a video where someone found a base full of swastikas in minecraft actually. and added some new ones. only the new ones were completely out of TNT, hahahahahahahaha. |
| 20:31 |
MTDiscord |
<ROllerozxa> was it that thing where you would rebuild the entire world in lego? you would click somewhere on the world map and you would get a small baseplate to build on |
| 20:31 |
erle |
no i think that is lego creator? |
| 20:31 |
erle |
not sure |
| 20:32 |
erle |
last time i used lego stuff i used legCAD |
| 20:32 |
erle |
anyway, that is actually a thing i like about the minetest community. even the griefers seem to hate nazis. |
| 20:32 |
erle |
i mean, that's different from a bunch of other games |
| 20:33 |
erle |
so back to the lego bricks |
| 20:33 |
erle |
my bf and me wondered like, how bad can it be |
| 20:33 |
erle |
and i made this nodebox with the 4 studs on top of a regular node |
| 20:33 |
erle |
and was like this should work right |
| 20:33 |
erle |
and then the framerate fell over and died |
| 20:34 |
erle |
so i made the culling thing and then x2048 improved on the idea |
| 20:34 |
MTDiscord |
<x2048> well, if you set view range to, like, 40, it should work |
| 20:34 |
MTDiscord |
<x2048> somehow |
| 20:34 |
erle |
*record scratch* just in case you wondered, how we got here |
| 20:35 |
erle |
x2048 well, i can play minetest on a potato if i set viewing range to 40, but still someone making a lot of meshes will ruin my day |
| 20:35 |
MTDiscord |
<x2048> you mean mesh nodes / entities? |
| 20:37 |
erle |
yes |
| 20:37 |
erle |
they are drawn irrespective of occlusion |
| 20:37 |
erle |
did i just make that word up? it seems weird. |
| 20:37 |
erle |
well, entities are drawn |
| 20:37 |
erle |
you can see that if the map does not load fast enough |
| 20:38 |
MTDiscord |
<x2048> yeap, mesh nodes and enities are your way to kill performance |
| 20:38 |
erle |
x2048 have you seen the cheat client optimizations btw, where they turn off node rendering based on features like textures? |
| 20:38 |
erle |
it's mostly used to find ores underground, but i wonder if there is some gem in there that can make vanilla minetest faster |
| 20:40 |
erle |
x2048 so how would your thing deal with the studs on top of the legos, they would still be drawn, right? |
| 20:40 |
erle |
or not? |
| 20:41 |
erle |
or would they be half-drawn |
| 20:41 |
erle |
like if there is an opaque node left of them the left side of the stud would not be drawn |
| 20:41 |
MTDiscord |
<x2048> I may have seen some cheats but was not interested enough to dig deep. |
| 20:44 |
MTDiscord |
<x2048> if I get it right, the studs should be drawn unless they are inside of an opaque box. |
| 20:45 |
MTDiscord |
<x2048> opaque box may be a nodebox or a solid block above the lego block |
| 20:47 |
erle |
nice |
| 20:47 |
erle |
x2048 can you open an issue or is there already one? |
| 20:48 |
erle |
for nodebox optimization? |
| 21:00 |
|
Verticen joined #minetest |
| 21:41 |
MTDiscord |
<x2048> erle, #6409 and #9126 |
| 21:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/6409 -- Efficient ways to render layered nodes like default:snow (discuss) |
| 21:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/9126 -- Mesher should discard triangles more aggressively |
| 21:46 |
erle |
x2048 maybe retitle 6409 to “efficient ways to render nodeboxes (like default:snow)” |
| 21:51 |
|
Sven_vB joined #minetest |
| 22:00 |
|
Sven_vB joined #minetest |
| 22:16 |
MTDiscord |
<x2048> The title reflects the discussion in the issue, I am not going to change it. |
| 22:19 |
erle |
x2048 yeah but if i open an issue about optimizing legos it will be fired upon and it will die as a duplicate |
| 22:34 |
|
panwolfram joined #minetest |
| 22:42 |
|
grouinos joined #minetest |
| 23:12 |
erle |
Warrr1024 continuing from #minetest-dev … how do you budget hud stuff? |
| 23:14 |
rubenwardy |
given it's nodecore, I imagine their budget is something like has_budget_for_ui(spec) { return false; } |
| 23:15 |
|
AliasStillTaken joined #minetest |
| 23:19 |
MTDiscord |
<Warr1024> I've got a fulltime hotbar and a part-time crosshair. I'd like to get rid of that hotbar sometime. |
| 23:20 |
erle |
rubenwardy as much as i enjoy snark, right now i actually *do* want to learn something |
| 23:20 |
erle |
;) |
| 23:20 |
MTDiscord |
<Warr1024> Totally eliminating the hotbar is a sort of bonkers ideal, and I don't see myself doing it in an already mature established game. But if I could like fade it out or something when the player isn't actively switching, or could otherwise have tighter control over it, that'd be cool. |
| 23:20 |
rubenwardy |
oh I was serious, NodeCore's design philosophy is as little G/HUI as possible |
| 23:20 |
erle |
oh okay |
| 23:20 |
erle |
i thought it was more about rendering speed |
| 23:21 |
erle |
or dropping parts of the HUD when it is not necessary |
| 23:21 |
MTDiscord |
<Warr1024> Nothing has a strict "budget" in the sense of a hard-limit. Anything I have a limit for is a soft-limit based on fuzzy criteria. Mostly I just want things as thin and light as possible, and I balance concerns where I can based on my understanding of costs as they are now. |
| 23:22 |
MTDiscord |
<Warr1024> But when it comes to HUD, my ideal would be nothing, and everything that's present on there now is a compromise of that ideal for playability. |
| 23:23 |
MTDiscord |
<Warr1024> The crosshair is only present part-time, while you're looking at a node. You almost don't need it, since the looktips will show you which side of a node you're pointing at because they always appear at the center of that face, not of the node's volume. |
| 23:23 |
MTDiscord |
<Warr1024> So the only thing that's ALWAYS visible is part of the crosshair (25% opacity when not pointing at anything) and the hotbar. |
| 23:24 |
MTDiscord |
<Warr1024> I actually rather like how the breath HUD turned out, because it's not visible unless you're actually using most of your breath, and it doesn't require you to look at any part of the screen because it surrounds the field of view. |
| 23:25 |
MTDiscord |
<Warr1024> There's really no good way to show "sneaking" within this design framework though. |
| 23:26 |
MTDiscord |
<Warr1024> I've played with eye height as well, and it's not particularly useful. You only notice the difference when transitioning in and out of the sneak state, but it doesn't do a good job of indicating that you're IN that state. |
| 23:26 |
MTDiscord |
<Warr1024> Currently the best feedback you get is tactile, i.e. you feel the pressure on your finger from the sneak key. |
| 23:27 |
MTDiscord |
<Warr1024> Hence, when you were talking about visual indication, I had assumed you meant from a 3rd-person perspective, i.e. crouching model. |
| 23:30 |
MTDiscord |
<Warr1024> A player can be walking or not, swimming or not, mining or not, and now crouching or not, and when you add various other states like laying, sitting, waving or other emotes, that's an awful lot of animations to sort out. |
| 23:31 |
MTDiscord |
<Warr1024> My budget for animations is especially tight, since I generally need to get a 3rd party involved to support complex 3d models like the player. |
| 23:34 |
erle |
here, have more lego minetest https://mister-muffin.de/p/Wqf7.png |
