| Time |
Nick |
Message |
| 00:28 |
|
selah joined #minetest-dev |
| 00:40 |
|
eeew joined #minetest-dev |
| 00:41 |
|
rmilan joined #minetest-dev |
| 02:03 |
|
proller joined #minetest-dev |
| 02:08 |
|
Zeno` joined #minetest-dev |
| 02:22 |
|
chchjesus joined #minetest-dev |
| 02:45 |
|
deltib1 joined #minetest-dev |
| 03:02 |
|
VanessaE joined #minetest-dev |
| 03:13 |
|
rickmcfarley joined #minetest-dev |
| 03:46 |
ShadowNinja |
sfan5: Pong. |
| 03:51 |
VanessaE |
damn, that's one long ping time |
| 03:59 |
ShadowNinja |
Yeah... Been busy. |
| 04:00 |
ShadowNinja |
sfan5: Just PM me (or message me in-channel) if I'm not around when you come back. |
| 04:32 |
|
proller joined #minetest-dev |
| 04:33 |
|
alexxs joined #minetest-dev |
| 04:48 |
|
Miner_48er joined #minetest-dev |
| 04:51 |
|
paramat left #minetest-dev |
| 05:07 |
|
proller joined #minetest-dev |
| 05:31 |
kahrl |
has anyone else had trouble editing issue comments lately? |
| 05:31 |
kahrl |
guess I'll just post a second comment |
| 05:32 |
kahrl |
ShadowNinja: 6bc4cad0ed has been "first bad commit" in a couple recent issues :P |
| 05:36 |
ShadowNinja |
kahrl: Yeah... Better than rotting away in the PR list though IMO. |
| 05:37 |
kahrl |
yeah |
| 05:37 |
ShadowNinja |
kahrl: And comment editing worked fine for me yesterday, haven't tried today. |
| 05:37 |
kahrl |
the delete button even results in a 404 |
| 05:38 |
ShadowNinja |
kahrl: Can you look into 1708 for me? I can't now. |
| 05:38 |
kahrl |
yeah, I'm investigating 1708 still |
| 05:40 |
kahrl |
ShadowNinja: ah, you moved that error message from infostream to errorstream in 6bc4cad0ed |
| 05:40 |
kahrl |
ShadowNinja: any particular reason for that? |
| 05:40 |
* ShadowNinja |
checks... |
| 05:41 |
kahrl |
it's the first one in ServerMap::loadMapMeta() |
| 05:42 |
ShadowNinja |
kahrl: Well, because it's an error. |
| 05:43 |
kahrl |
but it always happens when you first start a new world, so not really |
| 05:43 |
kahrl |
tbh though, map_meta.txt should really be created on world creation and not on first load |
| 05:43 |
kahrl |
but that would be a lot of work |
| 05:44 |
ShadowNinja |
Oh, just remove the loadMapMeta call for new worlds then, or something like that. |
| 05:44 |
kahrl |
there is no m_new_world flag |
| 05:45 |
ShadowNinja |
It really should be created then though, so createworld(mgparams1), createworld(mgparams2), loadworld(1) doesn't use the second params. |
| 05:46 |
kahrl |
exactly |
| 05:47 |
ShadowNinja |
Well, comment on the issue saying as much and fix it if you can. I'm off to bed. G'Night! |
| 05:47 |
kahrl |
gn8 |
| 06:05 |
|
proller joined #minetest-dev |
| 06:23 |
|
Miner_48er joined #minetest-dev |
| 06:27 |
|
nore joined #minetest-dev |
| 06:33 |
|
Anchakor_ joined #minetest-dev |
| 06:39 |
|
sol_invictus joined #minetest-dev |
| 06:58 |
|
Krock joined #minetest-dev |
| 07:03 |
sfan5 |
ShadowNinja: why does minetest.compress ignore the method argument? |
| 07:09 |
hmmmm |
std::list<std::pair<std::string, std::vector<content_t> *> > m_pending_content_vecs; |
| 07:09 |
hmmmm |
I got infected by some STDs |
| 07:13 |
Zeno` |
kahrl, a possible workaround. Not ideal, but *shrug*. https://gist.github.com/Zeno-/bdc7c26752443e9ef2df |
| 07:16 |
|
Krock joined #minetest-dev |
| 07:16 |
|
Hunterz joined #minetest-dev |
| 08:19 |
|
ImQ009 joined #minetest-dev |
| 08:29 |
Hunterz |
hi, Im trying compile minetest with leveldb, but get this error: http://pastebin.com/Zu2Yt2ay |
| 08:30 |
|
jin_xi joined #minetest-dev |
| 08:31 |
Hunterz |
hmm my fail, use bad path to libleveldb.so |
| 08:38 |
|
selat joined #minetest-dev |
| 08:42 |
|
proller joined #minetest-dev |
| 08:48 |
|
Amaz joined #minetest-dev |
| 08:53 |
|
PenguinDad joined #minetest-dev |
| 09:22 |
Megaf |
Hi everyone |
| 09:22 |
Megaf |
is there any thick or cmake flag to make a 100% static binary of minetest? |
| 10:06 |
|
proller joined #minetest-dev |
| 10:39 |
sfan5 |
Megaf: add "-static" to the cmake linker flags |
| 10:41 |
Megaf |
ok |
| 10:45 |
Krock |
quick question: did the protocol version change in 0.4.10-dev versions? |
| 10:49 |
|
kilbith joined #minetest-dev |
| 10:50 |
Krock |
nvm. yes it did. |
| 10:50 |
kilbith |
sfan5 : https://github.com/minetest/minetest_game/pull/324#issuecomment-57901236 |
| 10:52 |
|
iqualfragile joined #minetest-dev |
| 10:55 |
|
edlothiol joined #minetest-dev |
| 11:19 |
|
PilzAdam joined #minetest-dev |
| 11:37 |
Krock |
Thumbs up or down? #1715 |
| 11:37 |
|
kilbith joined #minetest-dev |
| 11:38 |
kilbith |
hi there, devs. could you add the OpenGL ES libs in MT, please ? |
| 11:39 |
Megaf |
kilbith: im here since yesterday trying to make that work |
| 11:39 |
Megaf |
sfan5: proller: so, I got no luck at all |
| 11:40 |
Megaf |
http://paste.debian.net/plain/124457 |
| 11:46 |
kahrl |
Zeno`: I think if the file is empty, that should be regarded an error as well |
| 11:47 |
kahrl |
because it could be a result of the previous save failing |
| 11:48 |
Zeno` |
probably, that's why I didn't make a PR |
| 11:52 |
Zeno` |
It *would* be possible to pass the gamedef to that init function, but I didn't have a close look |
| 11:55 |
Zeno` |
shallow copy, Krock? |
| 11:55 |
Krock |
Zeno`, idk how to call it.. maybe you've found the right word |
| 11:55 |
Zeno` |
err nvm. what does core.copy_table work? |
| 11:55 |
Zeno` |
how does* |
| 11:55 |
Krock |
it copies a table.. |
| 11:56 |
Zeno` |
oh, it's a deep copy ok |
| 11:56 |
Zeno` |
yeah I like it (not a dev though) |
| 11:57 |
sfan5 |
Megaf: static linking does not always work how you want it |
| 11:57 |
Zeno` |
I suppose recursion related overflows *might* be a worry, but I dunno |
| 11:57 |
Krock |
Zeno`, http://pastebin.com/pKiK8XsH |
| 11:57 |
Megaf |
sfan5: that was with a normal linking |
| 11:57 |
Megaf |
I didnt try static yet |
| 11:58 |
sfan5 |
oh |
| 11:58 |
sfan5 |
Megaf: use ENABLE_OGLES |
| 11:58 |
Megaf |
I did |
| 11:58 |
sfan5 |
http://dev.minetest.net/CMake_Options |
| 11:59 |
sfan5 |
ENABLE_GLES I mean |
| 11:59 |
sfan5 |
and you need to make sure it finds the libs too |
| 12:01 |
Zeno` |
I guess it's no more of a "risk" than dump or dump2() |
| 12:02 |
Zeno` |
possibly clone_table might be more descriptive |
| 12:17 |
|
mos_basik joined #minetest-dev |
| 12:17 |
|
mos_basik_ joined #minetest-dev |
| 12:22 |
|
nore joined #minetest-dev |
| 12:31 |
|
chchjesus joined #minetest-dev |
| 12:41 |
sfan5 |
kilbith: is your problem solved? |
| 12:47 |
Megaf |
sfan5: |
| 12:47 |
Megaf |
cmake ../../ -DVERSION_EXTRA=MinetestPi -DRUN_IN_PLACE=1 -DIRRLICHT_SOURCE_DIR=~/ogl-es/ -DENABLE_SOUND=0 -DENABLE_GLES=1 |
| 12:48 |
Megaf |
-- Found system opengles2 library /usr/lib/arm-linux-gnueabihf/libGLESv2.so;/usr/lib/arm-linux-gnueabihf/libGLESv2.so;/usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so |
| 12:50 |
kilbith |
sfan5 : the solution is to enable OpenGL ES on compiling ? the libs are already provided ? |
| 12:50 |
sfan5 |
kilbith: you need to ensure the libs are available |
| 12:51 |
sfan5 |
kilbith: then just pass -DENABLE_GLES=1 to cmake |
| 12:51 |
kilbith |
hmm, i thought these libs was already available on git |
| 12:52 |
sfan5 |
why would be provide OpenGL ES libraries? |
| 12:54 |
kilbith |
ARM is not that unused for MT I think. |
| 12:54 |
sfan5 |
ARM is mostly used by phones |
| 12:54 |
kilbith |
should be a good addition |
| 12:54 |
sfan5 |
(for mt at least) |
| 12:54 |
sfan5 |
the opengl es libraries are highly platform specific anyway |
| 12:55 |
sfan5 |
we can't provide them |
| 12:56 |
kilbith |
these libs are not heavy... |
| 12:56 |
sfan5 |
yes |
| 12:56 |
sfan5 |
but 100 different ones of them are heavy |
| 12:56 |
sfan5 |
it's not even in the scope of a project to provide libraries |
| 12:56 |
kilbith |
we need a serious competitor to the pre-installed "Minecraft-Pi" on Raspbian. |
| 12:57 |
sfan5 |
it's not like we'd maintain our own linux distro just for minetest |
| 12:57 |
kilbith |
minimalist game for a minimalist OS/computer |
| 12:58 |
sfan5 |
you are aware that raspbian has the gles libraries preinstalled? |
| 12:59 |
kilbith |
yes |
| 13:00 |
kilbith |
sorry for my noobism, i thought that these libs should be installed IN the client -_- |
| 13:01 |
kilbith |
s/installed/provided |
| 13:01 |
sfan5 |
Megaf: did it find libEGL too? |
| 13:03 |
kilbith |
sfan5 : could re-post the link you have posted above plz ? i'm in the console, I lost it. |
| 13:03 |
sfan5 |
kilbith: http://dev.minetest.net/CMake_Options this one? |
| 13:03 |
Megaf |
sfan5: http://paste.debian.net/plain/124461 |
| 13:03 |
kilbith |
thanks, will try that |
| 13:04 |
sfan5 |
thats a no |
| 13:04 |
sfan5 |
Megaf: make it link to libEGL |
| 13:05 |
kilbith |
so : cmake --ENABLE_GLES, that's exact ? |
| 13:05 |
sfan5 |
nah |
| 13:05 |
sfan5 |
cmake -DENABLE_GLES=1 |
| 13:06 |
kilbith |
noted |
| 13:11 |
kilbith |
ok now 5 hours for compiling... |
| 13:15 |
|
kaeza joined #minetest-dev |
| 13:16 |
Megaf |
[14:04:18] <sfan5> Megaf: make it link to libEGL |
| 13:16 |
Megaf |
you mean, the OpenGL thing? |
| 13:16 |
sfan5 |
no |
| 13:16 |
sfan5 |
libEGL |
| 13:28 |
|
iqualfragile_ joined #minetest-dev |
| 13:45 |
|
zat joined #minetest-dev |
| 14:07 |
|
rickmcfarley joined #minetest-dev |
| 14:08 |
kilbith |
Megaf : if you success with the compiling, you should open a new build for Raspi on the forums. |
| 14:09 |
Megaf |
kilbith: I would, but I dont know what Im doing :P |
| 14:10 |
Megaf |
I mean, I think it should work using the ogles version of irrlicht and the flag -DENABLE_GLES=1 |
| 14:10 |
Megaf |
but I now I have to link I dont know what to I dont know what |
| 14:25 |
sol_invictus |
is there any way to aligh text hud to a side (considering text length is variable)? |
| 14:32 |
kaeza |
sol_invictus, doesnt align = { x=1, y=0 } work? (this is for vertically-centered, right-aligned text) |
| 14:32 |
kaeza |
err, alignment = * |
| 14:32 |
|
NakedFury joined #minetest-dev |
| 14:33 |
sol_invictus |
sorry, what does mean 'vertically-centered'? |
| 14:34 |
sol_invictus |
vertically relatively to screen? |
| 14:34 |
kaeza |
vertically relative to the position on screen |
| 14:34 |
|
iqualfragile joined #minetest-dev |
| 14:34 |
sol_invictus |
got it |
| 14:35 |
sol_invictus |
but what if I want to position it in the left bottom corner? |
| 14:35 |
sol_invictus |
when line gets big whole hud shift outside the screen |
| 14:36 |
sol_invictus |
not whole, part of the text |
| 14:36 |
kaeza |
isn't it best if you simply left-align in that case? |
| 14:38 |
sol_invictus |
umm, how do I do that? |
| 14:38 |
sol_invictus |
I have alignment = {x=0.2, y=0.95}, |
| 14:39 |
kaeza |
alignment = { x=-1, ...} |
| 14:39 |
sol_invictus |
-1? :O |
| 14:39 |
sol_invictus |
where is it documented? |
| 14:39 |
kaeza |
it was in lua_api |
| 14:40 |
kaeza |
here: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L551 |
| 14:41 |
kaeza |
err, except it's 1, not -1 |
| 14:41 |
kaeza |
1 == shift to the right (i.e. left-align), -1 is the opposite |
| 14:42 |
sol_invictus |
oh, I was looking inside HUD definition |
| 14:43 |
sol_invictus |
is there any appropriate highlighting for lua_api? |
| 14:46 |
sol_invictus |
or it's actually freely formatted text? |
| 14:47 |
kaeza |
just plain text |
| 14:48 |
|
hmmmm joined #minetest-dev |
| 14:49 |
|
shadowzone joined #minetest-dev |
| 14:53 |
|
Taoki joined #minetest-dev |
| 15:07 |
|
alexxs joined #minetest-dev |
| 15:51 |
|
Calinou joined #minetest-dev |
| 16:04 |
|
OldCoder joined #minetest-dev |
| 16:13 |
|
shadowzone joined #minetest-dev |
| 16:13 |
|
shadowzone joined #minetest-dev |
| 16:32 |
|
CraigyDavi`` joined #minetest-dev |
| 17:14 |
kilbith |
sfan5 : http://paste.debian.net/124480/ |
| 17:14 |
kilbith |
Megaf ^ |
| 17:15 |
kilbith |
OpenGL ES has not been added in the settings |
| 17:16 |
|
GrimKriegor joined #minetest-dev |
| 17:17 |
sfan5 |
kilbith: run rm -Rf CMakeCache.txt CMakeFiles before running cmake agian |
| 17:17 |
kilbith |
ok I take note |
| 17:18 |
Megaf |
100%] Built target minetestserver |
| 17:18 |
Megaf |
real 67m51.780s |
| 17:18 |
Megaf |
thats how long it takes to build minetest server on the raspberry pi |
| 17:19 |
kilbith |
4h for compiling |
| 17:19 |
kilbith |
minetest + server |
| 17:21 |
kilbith |
perhaps can I run the executable 'minetest' with the OGLES option ? |
| 17:24 |
sfan5 |
no |
| 17:25 |
kilbith |
I don't see what was wrong with the cmake... |
| 17:25 |
sfan5 |
did you try the rm before running cmake again? |
| 17:26 |
kilbith |
I'll try now ! |
| 17:26 |
|
Miner_48er joined #minetest-dev |
| 17:27 |
ShadowNinja |
sfan5: Because there's only one method currently, easier to ignore it for now. |
| 17:28 |
kilbith |
well, same result. |
| 17:28 |
sfan5 |
ShadowNinja: modders will abuse everything they can, if minetest.compress("text text text ", "lzma") is valid right now, they'll expect it to be valid later |
| 17:28 |
kilbith |
i don't see any trace of the ogles libs |
| 17:31 |
ShadowNinja |
sfan5: Go ahead and add a check then. |
| 17:31 |
sfan5 |
ShadowNinja: why would I do that, it's your code? |
| 17:32 |
sfan5 |
(aka. the arguemnt sapier uses) |
| 17:32 |
sfan5 |
argument* |
| 17:33 |
ShadowNinja |
sfan5: I can't code right now, maybe in an hour or so. |
| 17:37 |
hmmmm |
I found that LZMA is slightly worse than gzip for small file sizes |
| 17:38 |
hmmmm |
if you lzma chunks of data that are only 16^3 * 4 bytes long, that's not going to have much of an effect |
| 17:38 |
hmmmm |
the larger the file size, the better the compression ratio (generally speaking) |
| 17:46 |
RealBadAngel |
lol, further i am into meshes it turns out to be way more easier than expected |
| 17:46 |
RealBadAngel |
http://pastebin.com/JcAkPhMd |
| 17:47 |
RealBadAngel |
^^ the current content_mapblock code for meshes |
| 17:48 |
|
rickmcfarley joined #minetest-dev |
| 17:48 |
RealBadAngel |
have just modified our collector to apply the tranformations on the fly |
| 17:49 |
RealBadAngel |
so no need for doubling the collectors methods |
| 17:50 |
RealBadAngel |
fun fact. our code (collector) is way faster than original irrlicht one |
| 17:51 |
Calinou |
what is the state of meshnodes? |
| 17:51 |
Calinou |
are they ready to be merged or still have a bug? |
| 17:51 |
Calinou |
hmmmm, gzip is much faster |
| 17:52 |
RealBadAngel |
im coding now facedir rotations |
| 17:52 |
Calinou |
can meshnodes be animated? |
| 17:52 |
RealBadAngel |
not yet |
| 17:52 |
RealBadAngel |
collector (compiled one mesh) is a static one |
| 17:52 |
RealBadAngel |
for mesh to be animated it has to be scene node |
| 17:53 |
Calinou |
can all mesh formats be used? |
| 17:53 |
Calinou |
that is, all supported by Irrlicht |
| 17:53 |
RealBadAngel |
i think so |
| 17:53 |
Calinou |
lastly, can you change selection box? |
| 17:54 |
RealBadAngel |
im using wavefronts ones |
| 17:54 |
Calinou |
.obj is a good unanimated format, so use it, yes |
| 17:54 |
Amaz |
RealBadAngel, is there any chance that we could test the meshnodes code? |
| 17:54 |
RealBadAngel |
selection box can be predefined by modder or at last instance a copy of current mesh |
| 17:55 |
RealBadAngel |
there are cases that a mesh is a better selection box |
| 17:55 |
RealBadAngel |
and in some cases the opposite |
| 17:55 |
RealBadAngel |
ie flowers |
| 17:56 |
Calinou |
can you use curved selection boxes using that? |
| 17:56 |
Calinou |
since meshnodes can be sloped, curved… |
| 17:56 |
RealBadAngel |
yes |
| 17:56 |
Calinou |
can you define collision box yourself, like you'd do in a nodebox? |
| 17:56 |
Calinou |
(I'd really like that for nodeboxes too) |
| 17:56 |
RealBadAngel |
erm i mean highlight box |
| 17:56 |
RealBadAngel |
selection box is not useable in this case at all |
| 17:57 |
RealBadAngel |
highlight is just a copy of selected node |
| 17:57 |
RealBadAngel |
so can be exact shape as original |
| 17:58 |
Calinou |
does it support old node highlighting too? |
| 17:59 |
RealBadAngel |
as a simple plain boxes |
| 17:59 |
RealBadAngel |
for example old selection box for a crystal formation will be a box of node size |
| 17:59 |
RealBadAngel |
while highlighting will use crystal shape |
| 18:01 |
RealBadAngel |
old selection boxes defs are treated as fall back |
| 18:02 |
RealBadAngel |
also i think we need some kind of standards here |
| 18:02 |
RealBadAngel |
Jordach propably will know how to define them |
| 18:03 |
RealBadAngel |
we are having an range -0.5 to 0.5 |
| 18:03 |
RealBadAngel |
blender units are slightly different |
| 18:04 |
|
proller joined #minetest-dev |
| 18:04 |
RealBadAngel |
its better imho to predefine correct range for the models than apply visual scale factor all the time |
| 18:07 |
RealBadAngel |
and one more thing |
| 18:08 |
Calinou |
1 blender unit = 1 game unit? |
| 18:08 |
RealBadAngel |
stuff like stairs will have to be converted into meshes |
| 18:09 |
RealBadAngel |
see highlight of the stair node to get why |
| 18:09 |
RealBadAngel |
Calinou, atm i think that factor is 5.0 |
| 18:09 |
Calinou |
yes, selection box of stairs renders a bit buggily |
| 18:10 |
Calinou |
doesn't make much sense, RealBadAngel |
| 18:10 |
RealBadAngel |
jordach said it was 10.0 but i got a model from him and had to use 5.0 to be exact size of a node |
| 18:10 |
Calinou |
16 would as the default grid is 16² |
| 18:10 |
Calinou |
so 1 unit = equivalent of 1 pixel |
| 18:10 |
|
sol_invictus joined #minetest-dev |
| 18:10 |
RealBadAngel |
Calinou, stairs do have extra surfaces |
| 18:11 |
RealBadAngel |
theyre not optimized just |
| 18:11 |
ShadowNinja |
1 blender unit = 1/10 of a game unit would make sense, because of the BS constant. |
| 18:12 |
ShadowNinja |
It should be scaled if possible though. |
| 18:12 |
RealBadAngel |
collector.append(f.tiles[j], (video::S3DVertex *)buf->getVertices(), vc, |
| 18:12 |
RealBadAngel |
buf->getIndices(), ic, pos, f.visual_scale, c); |
| 18:12 |
RealBadAngel |
thats not a problem to apply that |
| 18:13 |
RealBadAngel |
as you can see in a call |
| 18:13 |
RealBadAngel |
but a standard is needed imho anyway |
| 18:13 |
RealBadAngel |
so the visual scale of 1.0 will be standard sized node |
| 18:14 |
RealBadAngel |
also the orientation of the model has to be defined |
| 18:15 |
RealBadAngel |
my crystal model ive found is turned by XY axis by 90 degs ;) |
| 18:15 |
|
groknsberger joined #minetest-dev |
| 18:15 |
ShadowNinja |
0 rotatoion, X+ facing blender X+, etc. |
| 18:15 |
RealBadAngel |
so imho Jordach part starts here |
| 18:16 |
RealBadAngel |
hes our blender master |
| 18:17 |
RealBadAngel |
better to ask him how to do that than later apply weird black magic factors into cod |
| 18:17 |
RealBadAngel |
*code |
| 18:18 |
RealBadAngel |
ah, one more thingy |
| 18:19 |
RealBadAngel |
i do convert all the nodeboxes into meshes |
| 18:19 |
RealBadAngel |
im not sure bout it, but it can be an end to the era |
| 18:20 |
RealBadAngel |
meshes are way more flexible than nodeboxes |
| 18:21 |
RealBadAngel |
theyre marked as an experimental stuff anyway ;) |
| 18:24 |
RealBadAngel |
brb |
| 18:29 |
VanessaE |
as long as I don't have to adapt all those 400000000 nodeboxes I have in my mods :P |
| 18:30 |
kilbith |
:s |
| 18:31 |
VanessaE |
otherwise ^^^^^^ he will kick your ass ;) |
| 18:31 |
kilbith |
s/kick/whip |
| 18:34 |
|
Amaz joined #minetest-dev |
| 18:38 |
sol_invictus |
is it possible to open inventory from lua? I can't find where this formspec is called |
| 18:40 |
ShadowNinja |
sol_invictus: player:set_inventory_formspec(formpec). |
| 18:40 |
ShadowNinja |
It's static to pervent lag. |
| 18:41 |
sol_invictus |
oh, thank you |
| 19:03 |
|
sol_invictus joined #minetest-dev |
| 19:04 |
RealBadAngel |
VanessaE, transformation is done in nodedef.cpp at update textures |
| 19:04 |
VanessaE |
col |
| 19:04 |
VanessaE |
cool |
| 19:05 |
RealBadAngel |
after leaving nodedef will have mesh ptr filled in when applicable |
| 19:05 |
RealBadAngel |
either being mesh model or nodebox, doesnt matter |
| 19:06 |
RealBadAngel |
only stuff that wont have pre made mesh will remain stuff like fences etc |
| 19:06 |
RealBadAngel |
at least for now |
| 19:08 |
RealBadAngel |
we got used to nodeboxes so change will take some time propably |
| 19:08 |
RealBadAngel |
but in the long run it can be only a benefit |
| 19:09 |
RealBadAngel |
and hey, i can see at horizon one method i always wanted to use |
| 19:10 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_mesh_manipulator.html#ab849bd2c83b206de1e5da19ce3481e35 |
| 19:11 |
|
zat joined #minetest-dev |
| 19:11 |
RealBadAngel |
yikes :) |
| 19:11 |
RealBadAngel |
that gonna mean faster shaders with better visuals |
| 19:12 |
RealBadAngel |
also shaded entities |
| 19:13 |
RealBadAngel |
not to mention straight way for correct liquids surfaces |
| 19:14 |
RealBadAngel |
since more than a year i was fighting to get per surface tangents |
| 19:14 |
RealBadAngel |
and now im at the doorstep |
| 19:14 |
RealBadAngel |
and will be able to trash all the temporary code |
| 19:47 |
|
proller joined #minetest-dev |
| 19:48 |
sol_invictus |
ShadowNinja: oops, it's definition |
| 19:49 |
sol_invictus |
ShadowNinja: I meant actually <showing> inventory from lua |
| 19:56 |
|
proller joined #minetest-dev |
| 20:01 |
ShadowNinja |
sol_invictus: You want a callback to be called when a player opens their inventory or you want to open an arbritrary formspec? |
| 20:02 |
sol_invictus |
I want to arbitrarily open inventory formspec from lua |
| 20:03 |
Krock |
ShadowNinja, I would like to know your opinion to pull #1715 |
| 20:03 |
ShadowNinja |
sol_invictus: Look up detached inventories then. |
| 20:03 |
ShadowNinja |
sol_invictus: You can't forcibly open the inventory or node formspecs though. |
| 20:04 |
sol_invictus |
): |
| 20:05 |
Calinou |
<RealBadAngel> i do convert all the nodeboxes into meshes |
| 20:05 |
Calinou |
is this better for performance? |
| 20:05 |
Calinou |
especially the coordinates-set-every-frame issue |
| 20:07 |
|
iqualfragile joined #minetest-dev |
| 20:07 |
RealBadAngel |
Calinou, yes its way faster method |
| 20:08 |
RealBadAngel |
nodeboxes do not change during gameplay, yet theyre interpreted all the time |
| 20:08 |
RealBadAngel |
at each mapblock mesh refresh |
| 20:09 |
RealBadAngel |
thats why areas with more nodeboxes are causing fps drops |
| 20:10 |
RealBadAngel |
please do trace how nodeboxes are shown |
| 20:10 |
RealBadAngel |
its a diseaster |
| 20:11 |
RealBadAngel |
starting here: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L1642 |
| 20:12 |
ShadowNinja |
Krock: Commented. |
| 20:12 |
RealBadAngel |
then this is called for each box here: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L45 |
| 20:13 |
Sokomine |
RealBadAngel: ah. good to see you. i have a slight problem with nodeboxes, although it might not be worth doing much in this regard...problem is: i want to mirror/flip a house (in order to increase diversity). this works fine for normal nodes, but may not be doable for all nodeboxes |
| 20:14 |
RealBadAngel |
also: selection boxes and rotations are applied |
| 20:14 |
Sokomine |
RealBadAngel: many players have complained about nodeboxes slowing down their clients. having a house with many nodebox-using sloped roof nodes caused trouble to some it seems |
| 20:14 |
RealBadAngel |
200+ lines of code instead of 15 as for meshes |
| 20:15 |
kaeza |
ShadowNinja, uh... >local k = { }; local nt = copy({ [k] = 1234 }); print(nt[k]) --> 1234 |
| 20:15 |
RealBadAngel |
Sokomine, nodeboxes are slowly taking their way into the museum |
| 20:15 |
Sokomine |
noooo! |
| 20:15 |
RealBadAngel |
yup |
| 20:15 |
* Sokomine |
loves nodeboxes |
| 20:15 |
RealBadAngel |
you gonna love meshes even more ;) |
| 20:16 |
Sokomine |
just make sure the new system can use the old definitions and worlds don't break :-) |
| 20:16 |
RealBadAngel |
trust me |
| 20:16 |
Sokomine |
it's very likely that i'll do that :-) |
| 20:16 |
RealBadAngel |
ofc for the starters we will have both |
| 20:16 |
Calinou |
but making meshes is way harder |
| 20:16 |
RealBadAngel |
but as soon as meshes are here you will realize you dont want nodeboxes anymore |
| 20:16 |
Calinou |
need to do UV mapping and such |
| 20:16 |
Calinou |
nodeboxes are a great way to make 3D models |
| 20:17 |
Calinou |
something that is more complicated in Blender |
| 20:17 |
RealBadAngel |
either you will say that or im a chineese ballet dancer |
| 20:17 |
Calinou |
oh, also… it'd be great if you could use texture packs to replace models |
| 20:17 |
Sokomine |
with meshes i think those roofs could be done with far less triangles. instead of beeing a staircase with 16 steps, they could be done more directly |
| 20:17 |
Calinou |
this way clients can replace meshnodes :P |
| 20:17 |
kaeza |
ShadowNinja, you are using assert() wrong |
| 20:18 |
Sokomine |
that's a very good idea, calinou. people who prefer boxy appearance could use other shapes than those who don't mind the occasional roundish object |
| 20:19 |
proller |
using assert() always wrong |
| 20:19 |
RealBadAngel |
Sokomine, exactly thats the point |
| 20:20 |
Sokomine |
as for creating new nodebox/meshlike objects - nodeboxes as such are not the most easiest to create either. there are a few editors out there. if one of those could be used to create meshes, that'd be fine i guess. no idea about textures though |
| 20:20 |
RealBadAngel |
meshes done properly can have way less triangles |
| 20:20 |
RealBadAngel |
stairs here are the flagship |
| 20:20 |
Krock |
ShadowNinja, this copy function is not part of the default Lua functions, therefore it should use minetest. instead of extending table. iMO |
| 20:20 |
RealBadAngel |
atm theyre two overlaid boxes |
| 20:21 |
RealBadAngel |
with too many common vertices |
| 20:21 |
Sokomine |
in how far? i don't see much saving potential for stairs as such? the sloped roofs are a diffrent matter |
| 20:21 |
ShadowNinja |
Krock: It fits much better there, and Minetest already extends the string lib. |
| 20:21 |
RealBadAngel |
see stairs highlighted |
| 20:21 |
Krock |
okay. *commits* |
| 20:21 |
Sokomine |
ah. ok |
| 20:21 |
RealBadAngel |
you will see the problem clearly |
| 20:22 |
RealBadAngel |
lines wasnt able to show the problem |
| 20:22 |
Sokomine |
how do i enable highlighting? |
| 20:22 |
RealBadAngel |
while surfaces can |
| 20:22 |
RealBadAngel |
enable_node_highlighting = true |
| 20:22 |
hmmmm |
hmmm |
| 20:23 |
RealBadAngel |
RealBadAngel |
| 20:23 |
RealBadAngel |
lol |
| 20:23 |
VanessaE |
heh |
| 20:23 |
hmmmm |
if somebody codes a mod that uses nodes from a particular group, but it turns up with no nodes for that group, would you consider that a name resolution error? |
| 20:23 |
Sokomine |
i've wished for some time for a less strictly boxy appearance of nodeboxes. there are some situations where slopes are very popular (roofs, hills). the raillike drawtype is not a solution in most cases either |
| 20:23 |
|
rickmcfarley left #minetest-dev |
| 20:24 |
hmmmm |
i think nodeboxes are of the devil. horrible dumb and retarded. it should've been meshes all along. |
| 20:24 |
hmmmm |
furthermore, nodebox support should be COMPLETELY DROPPED from the engine, and instead a little shim should be added to convert nodeboxes to meshes |
| 20:24 |
VanessaE |
hmmmm: NOOOOOOOO |
| 20:24 |
VanessaE |
oh wait |
| 20:25 |
RealBadAngel |
hmmmm, agree 100% |
| 20:25 |
kaeza |
hmmmm, I'd say no. make the relevant functions simply ignore the group, or return an error indicator |
| 20:25 |
VanessaE |
actually, RBA aren't you doing just about the same thing? |
| 20:25 |
kaeza |
(re: groups) |
| 20:25 |
RealBadAngel |
but with given a bit time to do so |
| 20:25 |
hmmmm |
kaeza, that's what I was thinking |
| 20:25 |
RealBadAngel |
folks will just realize that nodeboxes are not worth the time |
| 20:25 |
hmmmm |
kaeza, this is printing out to errorstream about nodes that couldn't get resolved |
| 20:26 |
Calinou |
Sokomine, ideally we'd have full resource packs, to replace textures, models and sounds |
| 20:26 |
Calinou |
like Minecraft |
| 20:26 |
VanessaE |
hmmmm: c55 wanted to keep the cubical style, that's why he went with nodeboxes. he even threatened to remove them if they were to be too heavily abused into making non-cubic things |
| 20:26 |
hmmmm |
I'm thinking of situations where somebody registers a node to get matched up with something else |
| 20:26 |
Sokomine |
hmmmm: the way you describe the mod, it might as well be a tool/machine/whatever which can do something with nodes from a special group but does not ship with any such nodes? it would then pretty useless if no other mod is installed that supplies suitable nodes, but apart from that, there's not much harm done. or did i misundersand? |
| 20:26 |
Calinou |
Sokomine, the upside of using models is that you use triangles, not cuboids |
| 20:26 |
Calinou |
higher performance even for simple stuff |
| 20:26 |
Calinou |
no useless faces or duplicate vertices |
| 20:26 |
hmmmm |
bit of a political statement here, but I think the game should be defined by the game creator |
| 20:26 |
hmmmm |
not celeron 8) |
| 20:27 |
Calinou |
VanessaE, there's way too much abuse of them too |
| 20:27 |
Calinou |
meshnodes are a potential fix |
| 20:27 |
RealBadAngel |
Calinou, everything on the GPU side is a triangle |
| 20:27 |
Calinou |
RealBadAngel, I know |
| 20:27 |
kaeza |
VanessaE, I think the thing here is again, letting the subgame dev having the option to use non-voxels |
| 20:27 |
VanessaE |
oh don't get me wrong, meshes are absolutely a good idea |
| 20:27 |
kaeza |
key word: option |
| 20:27 |
Calinou |
nodeboxes will be available for some time anyway |
| 20:27 |
RealBadAngel |
kaeza, freedom to own the gun does not mean you have to shoot down everybody out there |
| 20:27 |
VanessaE |
but we can't remove nodebox support. WAY too late now |
| 20:28 |
kaeza |
RealBadAngel, exactly |
| 20:28 |
Calinou |
VanessaE, it may go away after a year or so |
| 20:28 |
Calinou |
I wouldn't be surprised |
| 20:28 |
hmmmm |
Sokomine: what I'm doing is unifying the node resolving code for all my mapgen-related things that take a node name from lua on mod load, and then uses it to either place or search for |
| 20:28 |
Sokomine |
calinou: that's a very big upside |
| 20:28 |
hmmmm |
so there are 5 different categories of such things |
| 20:28 |
VanessaE |
Calinou: then a tool is needed to convert existing nodebox models into mesh models. |
| 20:28 |
RealBadAngel |
no need to |
| 20:28 |
Calinou |
or considered depreciated (like minetest.env) |
| 20:28 |
RealBadAngel |
code will do that |
| 20:28 |
Calinou |
can animated textures be used on meshnodes? |
| 20:29 |
hmmmm |
internal mapgen, biomes, decorations, ores, and schematics |
| 20:29 |
Calinou |
I don't think you can use animated textures on entity meshes currently |
| 20:29 |
Calinou |
VanessaE, NBE export to .obj? :P |
| 20:29 |
RealBadAngel |
Calinou, no |
| 20:29 |
Calinou |
or .x |
| 20:29 |
VanessaE |
minetest.env is just a sed/// operation away from translating. nodeboxes need a dedicated tool to convert them to meshes if they were to be dropped. |
| 20:29 |
VanessaE |
Calinou: NBE can't import a nodebox :P |
| 20:29 |
Calinou |
minetest.env still works today |
| 20:29 |
Calinou |
when was it deprecated? |
| 20:29 |
RealBadAngel |
animated ones will have to be treated in a very special way |
| 20:29 |
RealBadAngel |
separated from static mapblock mesh node |
| 20:30 |
Calinou |
I said textures |
| 20:30 |
RealBadAngel |
gathered in a list propably and added to the scene on refresh |
| 20:30 |
RealBadAngel |
that means the same |
| 20:30 |
Sokomine |
hmmmm: i don't yet understand entirely what you're after, but you're generally doing a very good job |
| 20:30 |
RealBadAngel |
model textures are quite different |
| 20:30 |
hmmmm |
erm |
| 20:30 |
RealBadAngel |
you could propably switch them |
| 20:31 |
RealBadAngel |
but uv definition will remain there |
| 20:32 |
Sokomine |
hmmmm: place or search for...don't think you mean get_content_id/get_name_by_content_id? that has turned up to be required pretty often when i was adjusting the landscape for the villages. those are probably relatively fast functions not to worry about too much? |
| 20:32 |
hmmmm |
I mean when you're registering an ore for example |
| 20:32 |
hmmmm |
there's place_in |
| 20:32 |
hmmmm |
right now place_in just takes a specific node name |
| 20:33 |
Calinou |
RealBadAngel, have you tried adding yaw interpolation to entities/players? |
| 20:33 |
Sokomine |
hmmmm: what could need improvement is vanessae's plantslib. it is so universal that i have no idea how it could be optimized - except by making parts less universal and thus much faster |
| 20:33 |
hmmmm |
what this would do is add the ability to make it either a single string, or a table containing multiple strings |
| 20:33 |
Calinou |
currently we only interpolate position, not angles |
| 20:33 |
hmmmm |
and the strings may be groups now |
| 20:33 |
hmmmm |
so you could have like |
| 20:33 |
Calinou |
celeron said it would be very easy |
| 20:33 |
Calinou |
just a class edit |
| 20:33 |
hmmmm |
place_in = "group:soil" |
| 20:33 |
Calinou |
in content_cao.cpp IIRC |
| 20:33 |
hmmmm |
or maybe place_in = {"default:stone", "default:desert_stone", "group:sand"} |
| 20:33 |
hmmmm |
or something like that |
| 20:35 |
RealBadAngel |
Calinou, i havent touched entities so far, but i have adapted some code used by them for nodes |
| 20:35 |
Sokomine |
hmmmm: ah! that sounds well |
| 20:35 |
hmmmm |
so if you register an ore that has place_in = "group:soil", for example, but group:soil turns up 0 results, would that not be a resolution error? |
| 20:35 |
Sokomine |
hmmmm: you might print an error in that case. but i'd say the conditions the mod requires are just not met - thus no nodes placed |
| 20:36 |
hmmmm |
where on the other hand if you have |
| 20:36 |
hmmmm |
place_in = {"default:water_source", "group:soil"} for example |
| 20:36 |
RealBadAngel |
Calinou, and one more thing, all the falling nodes/waving things gonna be made software side, without shaders or entities |
| 20:36 |
hmmmm |
if it can't resolve default:water_source, that would be an error |
| 20:36 |
RealBadAngel |
just by playing with vertices |
| 20:37 |
kaeza |
hmmmm, oh, I thought you meant "error" more like "raise an exception" |
| 20:37 |
Sokomine |
hmmmm: and if you ignore nodes that don't exist? if there's nothing left where that ore wants to be placed, then it can't get placed. an error message might be helpful, but only if it doesn't cost too much to implement. most people won't find it in their debug.txt anyway |
| 20:38 |
kaeza |
then yes, issuing an error message would be best I think |
| 20:40 |
hmmmm |
hmm |
| 20:42 |
Calinou |
RealBadAngel, hmm, currently we're using shaders for waves? can you use waves without shaders? |
| 20:42 |
RealBadAngel |
yes i can now |
| 20:42 |
RealBadAngel |
same for falling sand or waving plants |
| 20:43 |
RealBadAngel |
they turned out to be simple playing with vertices |
| 20:44 |
RealBadAngel |
no need to bother GPU with such irrevelant shit |
| 20:45 |
Sokomine |
regarding nodeboxes/meshes: somebody mentioned that the collusion box is also an issue. for nodes, a simplified and independent collusion box might be sufficient |
| 20:46 |
RealBadAngel |
Sokomine, that is not a problem |
| 20:46 |
RealBadAngel |
irrlicht have methods to get proper bounding box |
| 20:46 |
RealBadAngel |
have you thought we are pioneers or what? |
| 20:46 |
RealBadAngel |
just rtfm ;) |
| 20:48 |
Sokomine |
no :-) just not much experience with graphic engines. good to hear that that's also been taken into consideration :-) |
| 20:49 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/structirr_1_1scene_1_1_s_mesh.html#a7a16bc83094ab242ae779baf817dc7f9 |
| 20:49 |
RealBadAngel |
that will calculate bounding box for your mesh |
| 20:53 |
|
Ritchie joined #minetest-dev |
| 20:53 |
ShadowNinja |
hmmmm: I don't think it should be an error. You may have, eg, an ABM that works on nodes from another mod to better integrate the functions of the two mods if the other mod is installed. On the other hand you could just wrap in in a `if minetest.get_modpath("othermod") then ... end`. |
| 21:06 |
|
iqualfragile joined #minetest-dev |
| 21:16 |
|
rickmcfarley joined #minetest-dev |
| 21:17 |
|
mos_basik joined #minetest-dev |
| 21:20 |
kahrl |
so meshes can be redefined by texture packs and collision boxes are calculated from meshes? |
| 21:21 |
kahrl |
oh, also: how do you calculate the collision on an irrlicht-free server? (for entity physics) |
| 21:21 |
kahrl |
collision box* |
| 21:23 |
iqualfragile |
how do you even calculate collision at all? if you are not using the exact edges of the model this is a hard thing to do automatically iirc |
| 21:24 |
kahrl |
iqualfragile: well the method that RBA linked to calculates the smallest axis-aligned box that contains all vertices of the mesh |
| 21:24 |
iqualfragile |
oh, well, that is a way |
| 21:25 |
kahrl |
it would be if the server was running irrlicht |
| 21:25 |
iqualfragile |
not good for general meshes, but as minetest is blockbased anyways it should be sufficient |
| 21:25 |
kahrl |
so I'd say the collision box should be simply read from the nodedef in nodebox format like it is now |
| 21:26 |
kahrl |
(in particular the default collision box would be a full node) |
| 21:28 |
iqualfragile |
why does that depend on irrlicht? |
| 21:29 |
kahrl |
you can't even read a mesh file without irrlicht |
| 21:29 |
kahrl |
well, unless you reimplement the whole parser |
| 21:34 |
|
jin_xi joined #minetest-dev |
| 21:36 |
|
mos_basik joined #minetest-dev |
| 21:39 |
|
DuDraig joined #minetest-dev |
| 21:54 |
RealBadAngel |
kahrl, collision boxes are recalculated on the meshes |
| 21:54 |
RealBadAngel |
exact bounding box is get |
| 21:55 |
RealBadAngel |
for highlighting i choose the model itself, a bit bigger to create halo effect |
| 21:55 |
|
JZTech101 joined #minetest-dev |
| 21:57 |
RealBadAngel |
iqualfragile, you seem to forget whats native here |
| 21:57 |
RealBadAngel |
meshes are |
| 21:57 |
RealBadAngel |
nodeboxes are alien body |
| 21:58 |
RealBadAngel |
mt is built on top of irrlicht |
| 21:58 |
iqualfragile |
RealBadAngel: for irrlicht and rendering: yes |
| 21:58 |
iqualfragile |
for collision: boxes are easier then meshes |
| 21:58 |
RealBadAngel |
no |
| 21:58 |
RealBadAngel |
you are wrong to the bone |
| 21:59 |
RealBadAngel |
nodeboxes are weird implementation of meshes |
| 22:00 |
RealBadAngel |
that what you think is natural there is just a side effect |
| 22:01 |
hmmmm |
wondering if I should make NodeResolver part of INodeDefManager or put it in IGameDef on its own |
| 22:01 |
RealBadAngel |
for me as a modder took quite a while to understand the nodeboxes, how they work |
| 22:02 |
RealBadAngel |
and at the very end it turned out to be a complete weird |
| 22:02 |
RealBadAngel |
idk what c55 thought while creating the system |
| 22:02 |
RealBadAngel |
but definitely he was on high |
| 22:02 |
jin_xi |
i think its nice to be able to make boxy models |
| 22:03 |
RealBadAngel |
you can do the same with meshes |
| 22:03 |
RealBadAngel |
more easily |
| 22:03 |
jin_xi |
but you need an editor and all. for me its more easy to do simple nodebox by hand |
| 22:03 |
RealBadAngel |
you think its easy? |
| 22:04 |
VanessaE |
it is. |
| 22:04 |
jin_xi |
its not too bad |
| 22:04 |
RealBadAngel |
its a piece of bloody shit |
| 22:04 |
VanessaE |
I can code a nodebox by hand in less time than it takes to even launch blender. |
| 22:05 |
RealBadAngel |
yes yes |
| 22:05 |
RealBadAngel |
and you remember the times? |
| 22:05 |
RealBadAngel |
we were sitting there for weeks trying to get easier shapes working |
| 22:06 |
jin_xi |
i'm all for converting nodeboxes to meshes for internal use but i think the format has its place. its boxes, plain and simple. |
| 22:06 |
RealBadAngel |
and i dont know even english translation for words i used |
| 22:07 |
RealBadAngel |
its not plain, its not simple, its not fast |
| 22:07 |
RealBadAngel |
its a cancer |
| 22:07 |
iqualfragile |
RealBadAngel: not fast to render, but relatively fast to write |
| 22:07 |
RealBadAngel |
faster is to learn blender than nb |
| 22:08 |
iqualfragile |
i don't think so, additonally with blender you have to make sure that the scale is right |
| 22:08 |
iqualfragile |
but thats just a secondary concern |
| 22:08 |
RealBadAngel |
or use visual_scale factor |
| 22:08 |
RealBadAngel |
yes it is |
| 22:08 |
|
shadowzone joined #minetest-dev |
| 22:08 |
|
shadowzone joined #minetest-dev |
| 22:08 |
RealBadAngel |
but its not blender just |
| 22:09 |
RealBadAngel |
irrlicht does support most of them |
| 22:09 |
RealBadAngel |
name the one |
| 22:09 |
iqualfragile |
model formats? |
| 22:10 |
RealBadAngel |
mesh drawtype means you can use all of them |
| 22:10 |
iqualfragile |
yes, obviously |
| 22:11 |
iqualfragile |
we could ask rubenwardy to update his nodebox editor to output some simple model format |
| 22:11 |
kahrl |
RealBadAngel: did you read what I wrote? |
| 22:11 |
RealBadAngel |
kahrl, about collision boxes? |
| 22:11 |
kahrl |
<RealBadAngel> kahrl, collision boxes are recalculated on the meshes <-- no, they are not, because the server does not read the meshes |
| 22:12 |
RealBadAngel |
hmmm |
| 22:12 |
RealBadAngel |
thats an issue then |
| 22:12 |
iqualfragile |
does the server even need to know? |
| 22:13 |
RealBadAngel |
should have |
| 22:13 |
RealBadAngel |
for the boxes |
| 22:13 |
iqualfragile |
at least for projectiles |
| 22:13 |
RealBadAngel |
ok, mesh is loaded while in nodedef.cpp |
| 22:14 |
RealBadAngel |
i will just update defs with proper collison boxes there |
| 22:14 |
kahrl |
if it didn't, we'd have items sitting 0.5 nodes above slabs again (like a bug in the early days of nodeboxes) |
| 22:14 |
kahrl |
I mean if the server simply used the full node as collision box |
| 22:15 |
RealBadAngel |
if not given then yes |
| 22:15 |
RealBadAngel |
fallback |
| 22:15 |
RealBadAngel |
but should be defined or got from mesh itself |
| 22:15 |
RealBadAngel |
note that mesh can be way bigger than regular node |
| 22:16 |
kahrl |
I think the collision box should just be read from node_box and not calculated |
| 22:17 |
RealBadAngel |
it will fail with flowers etc |
| 22:17 |
kahrl |
how? |
| 22:17 |
RealBadAngel |
since when a flower is a box? |
| 22:17 |
RealBadAngel |
you want to collide with two planes? |
| 22:17 |
kahrl |
flowers aren't even walkable so it doesn't matter |
| 22:18 |
kahrl |
also when did I say it should use the rendered geometry as collision boxes? |
| 22:18 |
RealBadAngel |
imho modders supplied collison box in the first place, then mesh, then default |
| 22:19 |
kahrl |
I'd say the same thing except "then mesh" |
| 22:19 |
RealBadAngel |
no you wouldnt |
| 22:19 |
kahrl |
force the modder to supply proper collision information so it will work on server and client |
| 22:20 |
RealBadAngel |
you have seen models with visual factor 15.0 |
| 22:20 |
RealBadAngel |
for that bounding boxes would be overkill |
| 22:20 |
kahrl |
well that's just dumb abuse anyway |
| 22:20 |
RealBadAngel |
abuse but showing the problem |
| 22:20 |
kahrl |
nodes are 1x1x1 large and not 15x15x15 |
| 22:22 |
|
HLuaBot joined #minetest-dev |
| 22:22 |
|
shmancelot joined #minetest-dev |
| 22:22 |
RealBadAngel |
http://i.imgur.com/eKgfuns.png |
| 22:22 |
kahrl |
also in that case the modder could just supply a 15x15x15 bounding box (even though I assume there will be glitches with that) |
| 22:22 |
RealBadAngel |
think about collision boxes for those blue crystals |
| 22:23 |
RealBadAngel |
models are the same for all |
| 22:23 |
RealBadAngel |
just textures and visual size is different |
| 22:23 |
kahrl |
boxes are not the proper way to do collision for those things |
| 22:23 |
ShadowNinja |
kahrl: The server already depends on Irrlicht. |
| 22:23 |
kahrl |
huh, since when? |
| 22:24 |
|
kaeza joined #minetest-dev |
| 22:24 |
ShadowNinja |
At least for types, eg v3s32. |
| 22:24 |
ShadowNinja |
Since forever AFAIK. |
| 22:24 |
kahrl |
ok, but not the library |
| 22:25 |
ShadowNinja |
I don't know how heavily it depends on it, but we already depend on it so depending on it for a feature isn't such a big issue. |
| 22:25 |
kahrl |
the server doesn't create an irrlicht device |
| 22:25 |
kahrl |
(which would be required to load meshes) |
| 22:28 |
kahrl |
also the server is kinda lightweight right now (at least compared to the client and to minecraftserver.jar) |
| 22:29 |
kahrl |
it wouldn't be anymore if it created an irrlicht device and loaded all the meshes to memory |
| 22:29 |
RealBadAngel |
yeah, especially with smooth lighting ;) |
| 22:30 |
RealBadAngel |
thats a specialized killer stuff |
| 22:30 |
RealBadAngel |
server calculating lights for each client out there |
| 22:30 |
kahrl |
RealBadAngel: getSmoothLight is a client function. |
| 22:31 |
RealBadAngel |
smooth yes |
| 22:31 |
kahrl |
if you work on mapblock_mesh a lot you should know that :P |
| 22:32 |
RealBadAngel |
but all the other light code is a mess |
| 22:33 |
RealBadAngel |
what i say, ALL the lights are a mess |
| 22:33 |
kahrl |
tbh you can take any minetest part X and say X is a mess |
| 22:33 |
kahrl |
:P |
| 22:34 |
RealBadAngel |
the code is so spreaded around that it is almost impossible to find out what its doing |
| 22:35 |
RealBadAngel |
see the attempts to properly smooth light the nodeboxes |
| 22:35 |
RealBadAngel |
darkrose tried to do that |
| 22:36 |
kahrl |
should be mostly a matter of calling getSmoothLight in the drawtype code in content_mapblock |
| 22:36 |
ShadowNinja |
I'll push this in a minute: http://sprunge.us/Ydgd?diff |
| 22:36 |
RealBadAngel |
no |
| 22:36 |
kahrl |
the tough part is what to do with vertices in the middle |
| 22:37 |
ShadowNinja |
(Some functions push to the main thread rather than the current thread) |
| 22:37 |
RealBadAngel |
calling that wouldnt help at all |
| 22:37 |
ShadowNinja |
kahrl: Can you check that? |
| 22:37 |
RealBadAngel |
i had to get all the nodes around to get proper light level at node for highlighting |
| 22:38 |
RealBadAngel |
that gone just too far, its messy, not easy to modify |
| 22:38 |
ShadowNinja |
kahrl: Fixes https://github.com/minetest/minetest/issues/1709 |
| 22:39 |
RealBadAngel |
and primarily hard to understand why not hardware lights were not used |
| 22:39 |
RealBadAngel |
propably just to make things harder |
| 22:40 |
RealBadAngel |
if getting proper and coloured lightigting to the scene is as hard as 2 lines of code |
| 22:40 |
RealBadAngel |
the approach we are using cannot be called another way as masochism |
| 22:40 |
kahrl |
ShadowNinja: what about other functions that use getStack()? |
| 22:41 |
kahrl |
RealBadAngel: what are those 2 lines? |
| 22:41 |
ShadowNinja |
kahrl: Do you know of any others that use it and are called from Lua functions? |
| 22:41 |
RealBadAngel |
http://i.imgur.com/wHjL1dJ.png |
| 22:42 |
RealBadAngel |
kahrl, here i added just 3 lights, of different colours |
| 22:42 |
kahrl |
ShadowNinja: every function with SCRIPTAPI_PRECHECKHEADER uses it |
| 22:43 |
kahrl |
that's 58, I don't know them all |
| 22:43 |
RealBadAngel |
no modifications to our code, expect of enabling the lights |
| 22:43 |
kahrl |
s/58/60 |
| 22:44 |
kahrl |
RealBadAngel: I mean without cheating |
| 22:44 |
RealBadAngel |
cheating? i just used add light scene node |
| 22:44 |
kahrl |
show me code that displays light_sources nodes with hardware lights |
| 22:45 |
kahrl |
RealBadAngel: yeah, too bad we can't just hardcode the location of 3 lights and be done... people will place torches and want them to create light |
| 22:46 |
RealBadAngel |
http://irrlicht3d.org/wiki/index.php?n=Main.HowToUseLightsAndMaterials |
| 22:46 |
RealBadAngel |
thats general |
| 22:46 |
RealBadAngel |
and here you go for the torches: http://irrlicht.sourceforge.net/docu/example020.html |
| 22:47 |
kahrl |
still a limit of 8 lights per scene node |
| 22:47 |
kahrl |
that's not enough |
| 22:48 |
RealBadAngel |
read the second |
| 22:48 |
kahrl |
I did |
| 22:48 |
RealBadAngel |
it the solution to that |
| 22:48 |
kahrl |
I mean even if we make each mapblock a different scene node, 8 is not enough |
| 22:48 |
RealBadAngel |
Written by Colin MacDonald. This tutorial explains the use of the Light Manager of Irrlicht. It enables the use of more dynamic light sources than the actual hardware supports. Further applications of the Light Manager, such as per scene node callbacks, are left out for simplicity of the example. |
| 22:48 |
jin_xi |
...You are still limited to 8 lights, but the limit is per scene node. |
| 22:49 |
RealBadAngel |
It enables the use of more dynamic light sources than the actual hardware supports |
| 22:49 |
kahrl |
what jin_xi said |
| 22:49 |
RealBadAngel |
theres no limit |
| 22:50 |
kahrl |
can you read? the tutorial clearly says there is a limit |
| 22:50 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/020shot.jpg |
| 22:50 |
RealBadAngel |
cant you read? |
| 22:50 |
RealBadAngel |
the tutorial is about how to get more than a limit |
| 22:51 |
kahrl |
ok, I will repeat it again |
| 22:51 |
kahrl |
"You are still limited to 8 lights, but the limit is per scene node." |
| 22:51 |
jin_xi |
so im guessing we only have one scene node atm? |
| 22:51 |
kahrl |
yes |
| 22:52 |
kahrl |
for the map, anyway (objects have their own scene nodes) |
| 22:53 |
kahrl |
it could be split so that each mapblock is a scene node; anything finer would be a performance killer |
| 22:54 |
RealBadAngel |
i think you shoul read the text bout lights |
| 22:54 |
RealBadAngel |
8 lights yes, but the code can find 8 nearest ones |
| 22:55 |
kahrl |
a typical mapblock with buildings in it contains a lot more than 8 lights |
| 22:55 |
RealBadAngel |
ofc |
| 22:56 |
RealBadAngel |
but you seems to forget bout one thing |
| 22:56 |
jin_xi |
idk how its gonna look but 8 lights per block sounds like a limit you're gonna hit. maybe it still looks good with enough light around |
| 22:56 |
RealBadAngel |
this is per point |
| 22:56 |
RealBadAngel |
so each point being rendered will get 8 lights |
| 22:56 |
kahrl |
wut |
| 22:57 |
kahrl |
the tutorial clearly says it is per scene node |
| 22:57 |
kahrl |
also I've read the code and it says the same thing |
| 22:57 |
RealBadAngel |
either you or i cant read english ;) |
| 22:57 |
RealBadAngel |
The 8 lights nearest to the camera will be turned on, and other lights will be turned off. |
| 22:58 |
kahrl |
that's NO_MANAGEMENT mode and it uses the same set of lights for everything in the whole scene |
| 22:58 |
kahrl |
not something you'd want to use |
| 22:58 |
RealBadAngel |
ok |
| 22:58 |
RealBadAngel |
then lets go another way |
| 22:59 |
RealBadAngel |
single hardware light |
| 22:59 |
RealBadAngel |
the sun/moon |
| 22:59 |
kahrl |
yeah, that'd work, but you can't get rid of the ugly code :P |
| 22:59 |
RealBadAngel |
we can |
| 23:00 |
RealBadAngel |
we can remove smooth shading code |
| 23:00 |
kahrl |
how? |
| 23:00 |
RealBadAngel |
the directional light will do that for us |
| 23:00 |
kahrl |
then smooth lighting will only work above ground |
| 23:00 |
RealBadAngel |
since when sun shines underground irl? |
| 23:01 |
RealBadAngel |
:) |
| 23:01 |
kahrl |
exactly; it doesn't |
| 23:01 |
kahrl |
so there will be no smooth lighting in caves |
| 23:01 |
RealBadAngel |
but we do have a flag |
| 23:01 |
RealBadAngel |
we can pretend its here |
| 23:01 |
kahrl |
? |
| 23:02 |
RealBadAngel |
we can easily determine if sun is present on the scene |
| 23:02 |
RealBadAngel |
right? |
| 23:02 |
kahrl |
and then? |
| 23:02 |
RealBadAngel |
if it isnt we can use another lighting model |
| 23:03 |
kahrl |
so you'd like to rebuild all meshes when the sun toggles in and out of view? |
| 23:03 |
RealBadAngel |
noooo |
| 23:03 |
RealBadAngel |
why to do so? |
| 23:03 |
kahrl |
I thought that's what you meant |
| 23:04 |
RealBadAngel |
i mean turn off directional light source (the sun) |
| 23:04 |
RealBadAngel |
and operate just on vertices colours as till now |
| 23:04 |
kahrl |
how do you operate on them without rebuilding the meshes? |
| 23:05 |
RealBadAngel |
we dont care bout meshes |
| 23:05 |
RealBadAngel |
we care bout vertices |
| 23:06 |
kahrl |
explain |
| 23:06 |
RealBadAngel |
even our system doesnt need rebuilding for the lights to work |
| 23:06 |
kahrl |
you mean the daylight cycle? |
| 23:07 |
kahrl |
yeah but we don't switch lighting models suddenly |
| 23:07 |
RealBadAngel |
http://i.imgur.com/b3usu4B.png |
| 23:08 |
RealBadAngel |
this is achieved with placing single light node with radius 100.0 |
| 23:08 |
RealBadAngel |
in the middle of the scene |
| 23:08 |
kahrl |
I think the lighting we have looks a lot more natural than that screenshot |
| 23:08 |
RealBadAngel |
this was a mini sun ;) |
| 23:08 |
kahrl |
the nodes in the screenshot are kinda glossy, too |
| 23:08 |
kahrl |
ok |
| 23:08 |
RealBadAngel |
http://i.imgur.com/T8wf2tp.png |
| 23:09 |
RealBadAngel |
this one is a bit bigger |
| 23:09 |
kahrl |
again the same thing; the whole scene looks slightly metallic |
| 23:09 |
RealBadAngel |
because of shadows |
| 23:09 |
kahrl |
or s/slightly// in the desert region |
| 23:09 |
VanessaE |
kahrl: I think that's just because of where the light is placed |
| 23:10 |
RealBadAngel |
you can clearly see where the light source is |
| 23:10 |
RealBadAngel |
theres distance to it shown on the screen |
| 23:11 |
RealBadAngel |
raise it, move, and you will get perfect daylight |
| 23:11 |
RealBadAngel |
change its colour to get moonlight |
| 23:11 |
VanessaE |
RealBadAngel: I still wanna know how you will handle e.g a field with dozens of visible torches |
| 23:12 |
|
proller joined #minetest-dev |
| 23:12 |
RealBadAngel |
the torches can be handled in two ways |
| 23:12 |
RealBadAngel |
one could be vertex lighting the same code as we are using now |
| 23:13 |
RealBadAngel |
or limiting the visible sources at the vertex to 8 nearest ones |
| 23:13 |
RealBadAngel |
as in the example |
| 23:13 |
kahrl |
the first one would work |
| 23:14 |
RealBadAngel |
the second too |
| 23:14 |
kahrl |
the second one not, because you can't make each vertex its own scene node |
| 23:14 |
RealBadAngel |
i can limit them by vertex |
| 23:14 |
RealBadAngel |
think of node, our node |
| 23:14 |
kahrl |
I will only believe you if you upload that code |
| 23:15 |
RealBadAngel |
8 sources is almost all around covered with lightsources |
| 23:16 |
kahrl |
every mapnode a scene node? uh... nope |
| 23:16 |
RealBadAngel |
and a vertex is just 1/24th of a node |
| 23:16 |
RealBadAngel |
its way more than needed |
| 23:16 |
jin_xi |
and one scenenode per 8 torches? not possible? |
| 23:17 |
|
mos_basik joined #minetest-dev |
| 23:17 |
RealBadAngel |
well |
| 23:17 |
RealBadAngel |
animated mesh nodes will become individual scene nodes on the other hand |
| 23:17 |
RealBadAngel |
so why not the lights as well? |
| 23:18 |
RealBadAngel |
but still i think that hybrid approach will be the best |
| 23:19 |
kahrl |
<RealBadAngel> animated mesh nodes will become individual scene nodes on the other hand <-- which is why you don't want too many of them visible at once |
| 23:20 |
kahrl |
if lights are the same, navigating caves with large deep lava lakes will be fun |
| 23:20 |
RealBadAngel |
animated ones cannot be combined |
| 23:20 |
RealBadAngel |
thats why |
| 23:20 |
RealBadAngel |
so have to be separate nodes |
| 23:21 |
RealBadAngel |
kahrl i see such nodes treated in a very special way |
| 23:22 |
RealBadAngel |
added and removed from scene together with whole mapblock mesh |
| 23:22 |
RealBadAngel |
just based on a separate list |
| 23:22 |
RealBadAngel |
that shouldnt be much of a problem |
| 23:24 |
kahrl |
might be ok (but I haven't benchmarked how well irrlicht copes with a large number of scene nodes; one might have to use octrees or something like that) |
| 23:25 |
kahrl |
btw, something else about lava (not performance related for once) |
| 23:25 |
kahrl |
look at this screenshot: http://i1139.photobucket.com/albums/n542/x_death1/lava.jpg |
| 23:25 |
kahrl |
how would the lava light the top face of the nodes above it? |
| 23:26 |
RealBadAngel |
idk |
| 23:26 |
RealBadAngel |
ask the allmighty c55 ;) |
| 23:26 |
kahrl |
yeah, hardware lights are very poor at global illumination |
| 23:27 |
shadowzone |
He is AFK all the time it seems. |
| 23:27 |
kahrl |
the voxel based light isn't great at it but it's at least decent |
| 23:28 |
RealBadAngel |
voxel based one should be a node property just |
| 23:28 |
RealBadAngel |
and i will make the engine lit it all properly |
| 23:28 |
proller |
irrlicht octree too slow |
| 23:28 |
shadowzone |
Why isn't celeron55_ not voiced? |
| 23:29 |
kahrl |
shadowzone: every dev is voiced |
| 23:29 |
shadowzone |
Oh. |
| 23:30 |
kahrl |
oh, you mean why he isn't voiced? |
| 23:30 |
kahrl |
idk |
| 23:30 |
RealBadAngel |
propably wrong nick |
| 23:31 |
kahrl |
yeah sounds right |
| 23:31 |
RealBadAngel |
the clients choose fallback nicks on reconnect |
| 23:31 |
RealBadAngel |
not the registered ones propably |
| 23:31 |
kahrl |
isn't it based on registrations? |
| 23:32 |
kahrl |
not that it really matters though |
| 23:32 |
RealBadAngel |
in my case i do have one nick registered |
| 23:33 |
RealBadAngel |
if it fails to rejoin (old one is still here due to lag) client choose another |
| 23:33 |
RealBadAngel |
which is not registered |
| 23:33 |
RealBadAngel |
so i wont be voiced then |
| 23:34 |
RealBadAngel |
so c55 should just awake and go back for original nick |
| 23:44 |
kahrl |
RealBadAngel: I think I misunderstood you. Did you mean the top faces shouldn't be lit at all? (assuming the torch wasn't there) |
| 23:46 |
RealBadAngel |
im not sure, maybe light level for the node should be a light on top of it? |
| 23:46 |
RealBadAngel |
and same for interior |
| 23:48 |
RealBadAngel |
thats the problem with current lighting |
| 23:49 |
RealBadAngel |
damn slow, faulty and looking bad |
| 23:50 |
RealBadAngel |
why the heck we are staying with it? |
| 23:52 |
kahrl |
sorry you lost me |
| 23:52 |
kahrl |
what thing were you talking about right now that looks bad |
| 23:55 |
kahrl |
in fact I feel we've been talking at cross purposes so often that we should quit this conversation |
