| Time |
Nick |
Message |
| 00:03 |
|
fluxflux joined #minetest-dev |
| 00:28 |
|
Edgy1 left #minetest-dev |
| 00:42 |
|
kaeza joined #minetest-dev |
| 00:46 |
p_gimeno |
entuland: that would be best, if you want it visible, otherwise it won't appear in any place that the developers routinely check and it will probably be forgotten |
| 00:47 |
entuland |
thanks p_gimeno, I'll open an issue linking the current version of that file |
| 01:51 |
paramat |
merging game#2225 |
| 01:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2225 -- Beds: Improve on_rotate function by 12Me21 |
| 03:15 |
|
Lia joined #minetest-dev |
| 04:54 |
|
ssieb joined #minetest-dev |
| 06:32 |
|
Ruslan1 joined #minetest-dev |
| 06:33 |
|
thePalindrome joined #minetest-dev |
| 08:53 |
|
fwhcat joined #minetest-dev |
| 09:05 |
|
proller joined #minetest-dev |
| 09:14 |
|
Beton joined #minetest-dev |
| 09:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:02 |
|
twoelk joined #minetest-dev |
| 11:43 |
|
Fixer joined #minetest-dev |
| 11:45 |
|
kaeza joined #minetest-dev |
| 12:24 |
|
kaeza joined #minetest-dev |
| 13:29 |
|
Gael-de-Sailly joined #minetest-dev |
| 14:02 |
|
entuland joined #minetest-dev |
| 14:16 |
|
proller joined #minetest-dev |
| 15:53 |
|
Wuzzy joined #minetest-dev |
| 18:19 |
|
Cornelia joined #minetest-dev |
| 18:20 |
|
Cornelia joined #minetest-dev |
| 18:25 |
|
Lia joined #minetest-dev |
| 19:15 |
|
ssieb joined #minetest-dev |
| 22:19 |
|
paramat joined #minetest-dev |
| 22:20 |
paramat |
now 3 axis rotations is merged please can we release RC2 this weekend to get testing on that? |
| 22:21 |
|
hecks joined #minetest-dev |
| 22:22 |
fwhcat |
would be great, how can we test 3 axis rotations ? any idea ? |
| 22:22 |
entuland |
I would help but I don't even know if that only applies to entities or to nodes as well |
| 22:23 |
entuland |
and we could really use a saner approach at rotating nodes instead of those axis+rotation values crammed into param2 |
| 22:25 |
hecks |
Here's something to grab your attention because I have related questions https://a.uguu.se/xsGyivGkdKiu_screenshot_20190208_232200.png |
| 22:26 |
entuland |
eheheh |
| 22:26 |
hecks |
First; To make this possible I made a ^[raw texture modifier which allows sending raw images in an optimized way |
| 22:26 |
hecks |
My rationale is that sending images is already possible, only inefficient as all hell |
| 22:26 |
hecks |
My approach is to take an indexed image, deflate it, base64 it and then send that |
| 22:27 |
p_gimeno |
the new set_rotation applies to entities only |
| 22:27 |
hecks |
Willing to pack this into a PR if anyone's interested |
| 22:27 |
entuland |
what are we looking at exactly? a real terrain blending against a fake one depicted by a background? hecks |
| 22:27 |
entuland |
thanks for the clarification, p_gimeno |
| 22:28 |
hecks |
entuland; I do some raytracing against the map's perlin noise and render it to the skybox |
| 22:28 |
entuland |
so it's a way to fake stuff that hasn't emerged/loaded yet? |
| 22:28 |
hecks |
Yes |
| 22:28 |
entuland |
that's great |
| 22:29 |
hecks |
The raytracer is entirely in lua; but to send the image efficiently I had to make a new texmod |
| 22:29 |
hecks |
And, of course, it would be better if this were part of the engine |
| 22:29 |
entuland |
it would immensely improve the experience, assuming it could be made performant enough (which dunno, maybe it already is) |
| 22:29 |
hecks |
It's very performant if you don't count the bugs |
| 22:29 |
entuland |
ehehe |
| 22:29 |
hecks |
If it were a part of the engine, it would be almost free |
| 22:30 |
entuland |
that "modulo" is to consider built-in :) |
| 22:30 |
hecks |
and I could make it work at realtime speeds; at lower res it can pull realtime already |
| 22:30 |
hecks |
Not having to send all this crap over the network would help a lot |
| 22:30 |
entuland |
even just low res would feel better than seeing the sharp edges of the loaded terrain against the unloaded chunks |
| 22:31 |
hecks |
It's not without issues; skybox textures are leaked and deflate corrupts the image every now and then |
| 22:31 |
hecks |
https://a.uguu.se/aPA323ZXTb2q_screenshot_20190208_232759.png |
| 22:32 |
hecks |
Effects range from "tilted cartridge" to a segfault; possible cause would be null-in-string issues |
| 22:32 |
hecks |
Base64 alone renders fine |
| 22:32 |
entuland |
implementation details apart, this feature is already a must for me |
| 22:33 |
hecks |
There are basically two separate useful things here; one is sending textures assets dynamically |
| 22:33 |
hecks |
an often requested feature by the people who make and use all those horrible skins |
| 22:33 |
hecks |
Would also make mods like painting a lot less horrible |
| 22:34 |
hecks |
The other is the raytracer, which does not necessarily need this texture thing; as of now it's in lua as a part of my subgame |
| 22:35 |
entuland |
well, dynamic assets like textures and models would have lots of uses, not just ugly skins |
| 22:35 |
hecks |
Raytracing is not the only way to go about it either; I've discussed this before in my farmap proposals |
| 22:35 |
hecks |
Oh, of course. But this concerns procedural, indexed textures only. 256 colors maximum |
| 22:35 |
hecks |
I sure would like it for things like faction flags |
| 22:35 |
entuland |
my wesh mod is pretty much rendered useless by the inability to load models at runtime (along with other limitations, file-access wise) but I guess the underlying irrlicht engine has its part of the blame there |
| 22:36 |
hecks |
It is, ironically, sometimes more efficient than clobbering the texture together with modifiers |
| 22:36 |
hecks |
Irrlicht loads stuff dynamically just fine |
| 22:36 |
hecks |
Problem is that it loads models very slowly |
| 22:36 |
entuland |
then I must have misunderstood some past discussion about that |
| 22:37 |
hecks |
On an unrelated note, I had some ideas for how to make a "script reload" or "soft reset" possible |
| 22:38 |
entuland |
isn't that already possible by proper checks and a simple dofile()? |
| 22:38 |
hecks |
Not if you consider entity state |
| 22:38 |
hecks |
Join callbacks and such |
| 22:38 |
entuland |
yep, those are the checks I've been warned about |
| 22:38 |
entuland |
anyway, what is your idea there? |
| 22:38 |
hecks |
Too many of these "checks" really |
| 22:39 |
hecks |
My idea is to actually restart the server but hide it from users |
| 22:39 |
entuland |
oh |
| 22:39 |
entuland |
that would solve all of the problems I have with wesh! |
| 22:39 |
entuland |
cause I need a restart to make new models available |
| 22:39 |
entuland |
actually, just a world reload, but I guess you meant just that |
| 22:40 |
hecks |
Depends on whether you want new assets or just a script reload |
| 22:41 |
hecks |
For scripts only, all you have to do is freeze the world, reload lua, and treat every player as if they just rejoined |
| 22:41 |
entuland |
no, in my case those models are created by the mod at runtime, saved in the world folder (the only place where I can store stuff at runtime) then moved and loaded from the mod's folder (the only place where I can get textures and models from) |
| 22:42 |
hecks |
Keep in mind that if you only need to make models in init, you can already do this |
| 22:42 |
hecks |
I do some model file postprocessing this way |
| 22:43 |
entuland |
yep, as I said, the mod itself is an .obj generator (it captures nodes from the world, miniaturizes them into a single node) |
| 22:43 |
paramat |
3 axis rotations themselves are tested and behave well, what needs testing is no breakage of existing entity yaw or entity attachment positions, essentially, checking for any breakage |
| 22:43 |
entuland |
so I think I'll always need a full restart |
| 22:44 |
hecks |
Attachments are fubar even without 6DOF, paramat |
| 22:44 |
paramat |
nice farmap |
| 22:47 |
hecks |
oh, right, I got the noise to work with the map seed |
| 22:47 |
hecks |
This also required some api changes |
| 22:48 |
hecks |
There's a bug; the noise functions that didn't work, they don't work in init but they're fine a frame later |
| 22:50 |
p_gimeno |
entuland: do you have a better idea of how to implement node rotations? |
| 22:50 |
paramat |
ok issue please. the noise problem you encountered has been bugging me slightly |
| 22:50 |
paramat |
node rotations are fine |
| 22:51 |
hecks |
another issue with noise; 3D noise doesn't work as expected, it's stretched across one axis |
| 22:51 |
entuland |
p_gimeno: yep, the one I am using in my rhotator mod - matrices |
| 22:51 |
hecks |
Is anyone using this kind of noise successfully? |
| 22:52 |
entuland |
my rhotator already replaces completely the screwdriver behavior, and I use matrices in three of my mods to allow arbitrary placements of nodes and various correlations thereof (wesh and imaging being the other two mods, apart from rhotator) |
| 22:52 |
p_gimeno |
entuland: it would be possible to implement a matrix_to_param2 converter, if that'd help |
| 22:52 |
entuland |
I already have that in place inside all of those mods |
| 22:52 |
entuland |
I also suggested to make all of those matrix functions available in default minetest |
| 22:53 |
hecks |
Are matrices a thing in the lua api yet? |
| 22:53 |
entuland |
I believe I have opened an issue about that |
| 22:53 |
p_gimeno |
entuland: can I read the discussion? |
| 22:53 |
entuland |
not that I know of, hecks, I use a separate repo for that (it's pretty self contained after all) |
| 22:53 |
entuland |
sure, let me get you the link |
| 22:54 |
hecks |
In case some poor soul decides to merge that part from your repo; are your matrices plain arrays? |
| 22:54 |
entuland |
uhm... can't recall off the top of my head, I should look back at them |
| 22:55 |
p_gimeno |
entuland: what's your MSGH username? |
| 22:55 |
entuland |
#7478 |
| 22:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/7478 -- Have math matrix facilities built in Minetest itself |
| 22:55 |
entuland |
I use entuland everywhere |
| 22:56 |
entuland |
and my mods are under entuland as well on github |
| 22:56 |
hecks |
I'm asking because they should be either flat [16] tables or 4x4 tables |
| 22:56 |
paramat |
3D noise is stretched on an axis? i haven't noticed, issue please :) |
| 22:56 |
entuland |
checking |
| 22:57 |
hecks |
Implementing anything else into core will earn you a big fat slap from me; vectors are already badly messed up and I retch every day working with them |
| 22:57 |
entuland |
I'm building those matrices with 3x3 tables fed into the matrix library itself |
| 22:57 |
p_gimeno |
a search for author:enthuland only shows 2 issues, #7478 (open) and #7416 (closed) |
| 22:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/7478 -- Have math matrix facilities built in Minetest itself |
| 22:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/7416 -- MeshCollector::append() called with numIndices=89628 (limit 65535) |
| 22:57 |
entuland |
https://github.com/entuland/rhotator/blob/master/init.lua#L63-L125 |
| 22:57 |
hecks |
paramat: specifically 3D noise sampler, I don't know and don't care about noisemaps |
| 22:58 |
entuland |
sorry, I just realized I have no idea what MSGH stands for |
| 22:58 |
p_gimeno |
MS GitHub |
| 22:58 |
entuland |
ah okay |
| 22:58 |
entuland |
then yes, still entuland :P |
| 23:01 |
p_gimeno |
nodes can't be flipped (as in, mirror image), right? |
| 23:03 |
entuland |
I'd say not but I'm already pushing myself probably too far by just speaking in this channel :P |
| 23:07 |
hecks |
Anyway, hypothetically, if I felt like rolling farmap into the engine, or going with my original proposal https://a.uguu.se/UneYZk4kAroQ_chart.png |
| 23:08 |
paramat |
ok what i mean is, there are 24 axis-aligned orientations and the encoding of those in param2 seems fine |
| 23:08 |
entuland |
yep, the encoding is fine, the problem is the lack of any facility allowing intuitive rotation between all of those orientations |
| 23:08 |
hecks |
...it would add some burden on mapgen maintenance; mapgens would need sampleNodeAt and sampleHeightAt functions |
| 23:09 |
entuland |
that's why I had to bring matrices in (if I'm not mistaken the combination of those is 24 factorial or something) |
| 23:09 |
hecks |
Screwdriver node rotations? 6*4 |
| 23:10 |
entuland |
that's the outcome of the rotations, not the desirable changes of orientation |
| 23:10 |
hecks |
Tell me what you're trying to do because I joined late on this |
| 23:10 |
entuland |
each orientation could lead to other 8 depending on the performed rotation |
| 23:11 |
entuland |
it all started from the default screwdriver, which only allows rotation around the positive Y axis of the node, and changing the direction that axis point related to the world |
| 23:11 |
hecks |
yup |
| 23:11 |
entuland |
the rhotator allows to rotate any face, no matter the internal positive Y axis of the node |
| 23:12 |
entuland |
and does that using matrices, to combine the current orientation with the desired arbitrary rotation, mapped back to one of the 24 values of axis+rotation to be stored in param2 |
| 23:12 |
entuland |
there is a stupid video of mine there in the readme of rhotator, which exposes the problem |
| 23:13 |
hecks |
Rotating the texture on a single face, right? |
| 23:13 |
entuland |
rotating the whole node according to the face you're pointing at |
| 23:13 |
entuland |
hang on a second |
| 23:13 |
entuland |
5 minutes: https://youtu.be/Z2a1iWJNqgs |
| 23:13 |
hecks |
oh, a better screwdriver |
| 23:13 |
paramat |
personally i'm only interested in a completely neutral and general c55 type 3D farmap that doesn't assume a normal surface landscape, this is a game engine and worlds are 3D and can be any type of structure. your farmap wouldn't work for floatlands or underground caverns, or many types of modded structures, or large player builds |
| 23:14 |
entuland |
a better screwdriver is just one of the possible uses of it |
| 23:14 |
entuland |
I've seen other people worrying about the same kind of things when they want to have nodes inspect the surrounding (for instance, the core of a nuclear reactor that will only work depending of certain nodes being around in a specific position) |
| 23:15 |
entuland |
as of now, doing that type of design-dependent nodes is extremely tricky due to the inability to easily work out relative positions of arbitrarily rotated nodes |
| 23:16 |
entuland |
I had the same problem with my capture nodes in wesh, which, again, use matrices to work out both the capture and the rebuilding, no matter what the original orientation is or the rebuilding orientation is |
| 23:16 |
entuland |
wesh works both as an .obj creator and as a dummy world-edit tool |
| 23:17 |
entuland |
which for example allows to capture a build orientated, say, top up, and rotate it to any direction in 90 degrees steps |
| 23:22 |
hecks |
Sounds like trivial stuff, though useful |
| 23:23 |
hecks |
Converting from/to matrices is a good approach |
| 23:24 |
entuland |
oh well, depends who you ask - I had my good moments of despair wrapping my mind around matrices, and people seeing my mod say "a full matrix library just to implement a screwdriver? you're nuts!" and discard my proposal about adding rhotator to their server |
| 23:26 |
entuland |
that's why sooner or later I'll propose to add rhotator to minetest_ game, unless matrices and the rhotator behavior get implemented in other ways (which would be just fine with me) |
| 23:27 |
hecks |
I support adding param_to_matrix and matrix_to_param mappers to core |
| 23:27 |
entuland |
that would be great |
| 23:29 |
p_gimeno |
I'm trying to understand the values enabled by is6d |
| 23:30 |
hecks |
As for the matrix format, let the JIT decide; prefer { {} {} {} {} } but use a flat list if the generated assembly is better |
| 23:30 |
entuland |
I've inspected that as well, but despite the looks, it's of no use for arbitrary rotations, p_gimeno |
| 23:31 |
p_gimeno |
MUCH better if flat, hecks. 20% the number of objects. |
| 23:31 |
hecks |
Have you looked at the actual JIT output? |
| 23:33 |
entuland |
https://github.com/minetest/minetest/blob/master/builtin/game/item.lua#L40 is where that dir_to_facedir() is implemented, and doesn't take in account any rotation only deals with axis orientation, if I understand the code properly |
| 23:33 |
|
twoelk|2 joined #minetest-dev |
| 23:35 |
p_gimeno |
hecks: no need, really. It's about allocation/deallocation. The values are always allocated and eligible for garbage collection. Note that LJ uses interpreted code until it finds enough repetitions to grant a trace, and even in case of a trace, sometimes it needs to switch to interpreter mode, therefore it does need to allocate them. |
| 23:36 |
p_gimeno |
entuland: if it's really an axis, then a quaternion fits the glove :) |
| 23:36 |
hecks |
Fair point, I've been thinking of lower order matrices but I suppose a flat [16] will still be more efficient than a 3x3 |
| 23:36 |
p_gimeno |
flat [9] but yes :) |
| 23:37 |
entuland |
oh well, I could have used quaternions as well, but it was already a struggle to wrap my mind around matrices |
| 23:37 |
hecks |
No, flat [16] because you want the functions to work for all orders; 2D matrices would permit this, but with flat, you kinda have to store it in a 4x4 no matter what |
| 23:38 |
hecks |
it's not a huge penalty though |
| 23:38 |
entuland |
long story short: I've implemented what I believe to be a saner screwdriver, and the only thing I am selfishly interested in is having that behavior in the servers I play in to be able to build my stuff rotating stuff at will |
| 23:38 |
entuland |
and since the discussion here is already passing way over my head I'll take a step back :) |
| 23:38 |
p_gimeno |
entuland: and what I'm interested in is finding an efficient way to do it, in order to implement it in the core |
| 23:39 |
hecks |
For something that happens on a user click, the definition of "efficient" is very lenient |
| 23:39 |
hecks |
and matrices are pretty efficient, no need to reinvent the wheel |
| 23:40 |
entuland |
that's why it's better if I take a step back - I've had hard time doing my mods already and I've been told that it was a stupid approach to begin with, that I should have simply mapped all 24 values into all possible combinations and be done with it |
| 23:40 |
hecks |
mapping param to matrix and back, purely in lua, that's absolutely good enough |
| 23:40 |
hecks |
this is the correct approach, you've been talking to idiots |
| 23:40 |
entuland |
I'm happy to read that :) |
| 23:40 |
hecks |
some people around here just hate matrices though, ha |
| 23:41 |
hecks |
I use matrices in MT just the way I would do in a "big" engine, they're absolutely not the bottleneck |
| 23:42 |
* entuland |
phews :P |
| 23:42 |
entuland |
you're giving me back a little self esteem there, cause I thought just the same but I could also understand how a table lookup could beat any calculation |
| 23:43 |
entuland |
just felt stupid to hardcode all the combinations in a huge table |
| 23:43 |
hecks |
from my vector experiments I've concluded that LJ crunches linear algebra almost as well as native implementations, as long as you make code that traces nicely |
| 23:43 |
hecks |
no, a lookup table is the way to go; but you might want to generate this table in init instead of typing it in manually like a moron |
| 23:44 |
p_gimeno |
what is definitely unacceptable for the core is to use strings for comparison, the core should avoid generating garbage as much as possible |
| 23:44 |
p_gimeno |
the vector lib is bad enough already |
| 23:45 |
entuland |
the building of lookup tables on init is there for me, but I still pass through matrices, and yes, I use strings to make lookups because I couldn't think of any better key type there |
| 23:45 |
hecks |
minetest vectors delenda est |
| 23:45 |
hecks |
anyway; matrices involved in the matrix-param map will be entirely integer |
| 23:46 |
hecks |
you can encode them into single numbers for lookups |
| 23:46 |
p_gimeno |
exactly my point |
| 23:46 |
hecks |
*at the same time though* lua handles strings well and it's not a tragedy to string something for a key |
| 23:47 |
entuland |
that's were I couldn't see the simplicity of it - converting a unique matrix into a unique integer, and I still don't see how I could do that other than with a bitmask or the alike, since I deal with unit matrices |
| 23:47 |
p_gimeno |
luajit, not so well |
| 23:47 |
hecks |
especially in server code which doesn't cause stutter, and especially in minetest where there's a hundred of other things that will absolutely bang your performance before the GC ever does |
| 23:47 |
hecks |
oh right, jit |
| 23:55 |
|
nerzhul joined #minetest-dev |
| 23:58 |
|
nerzhul joined #minetest-dev |
| 23:58 |
|
nerzhul joined #minetest-dev |
| 23:58 |
|
nerzhul joined #minetest-dev |
