| Time |
Nick |
Message |
| 00:02 |
|
Lunatrius` joined #minetest-dev |
| 00:05 |
|
Lunatrius joined #minetest-dev |
| 00:45 |
|
Taoki joined #minetest-dev |
| 04:21 |
|
crazyR joined #minetest-dev |
| 04:30 |
|
RealBadAngel joined #minetest-dev |
| 04:33 |
RealBadAngel |
hmmmm, around? |
| 04:35 |
|
celeron55 joined #minetest-dev |
| 05:22 |
hmmmm |
yes? |
| 05:38 |
|
Hunterz joined #minetest-dev |
| 05:40 |
|
Megaf joined #minetest-dev |
| 06:05 |
VanessaE |
hmmmm: RealBadAngel probably wants you to +1 the minimap pull request :) |
| 06:06 |
hmmmm |
mmmm |
| 06:06 |
RealBadAngel |
hmmmm, can you take a look on minimap pr? |
| 06:06 |
VanessaE |
told ya ;) |
| 06:07 |
hmmmm |
for the minimap shader, there seems to be a lot of math, but what does it do? |
| 06:07 |
hmmmm |
there's a lot of .r, are you shading it according to the map light? |
| 06:09 |
RealBadAngel |
that math is generating normalmap on the fly |
| 06:10 |
RealBadAngel |
.r is read from the heightmap |
| 06:10 |
hmmmm |
ahh okay, that makes sense, i didn't get to the part where the textures are uploaded yet |
| 06:10 |
hmmmm |
if shaders are disabled, what happens to the minimap? |
| 06:10 |
RealBadAngel |
its flat |
| 06:13 |
hmmmm |
what's the reasoning behind the 'step' logic in getTextureAverageColor? |
| 06:13 |
RealBadAngel |
i do just sample higher res textures |
| 06:13 |
hmmmm |
one, you're assuming that textures are always going to be square. is this valid? two, i don't get why in the first place |
| 06:14 |
RealBadAngel |
i need a color, most used (or close to) |
| 06:15 |
RealBadAngel |
if theyre not square theyre animations |
| 06:15 |
RealBadAngel |
so i got first frame sampled |
| 06:15 |
hmmmm |
i'm not too familiar with that |
| 06:16 |
hmmmm |
VanessaE, is that a valid assumption? |
| 06:16 |
VanessaE |
yuep. |
| 06:16 |
VanessaE |
yep* |
| 06:16 |
VanessaE |
particularly if height is more than 2x the width, you can assume it's an animation |
| 06:16 |
hmmmm |
right |
| 06:17 |
hmmmm |
but this does not do that |
| 06:17 |
RealBadAngel |
even if some1 supplied npot2 texture its not a problem |
| 06:17 |
hmmmm |
so if the width is greater than 16, then the number of samples is reduced by a factor of 16. ???? |
| 06:17 |
hmmmm |
so if I supplied an npot2 texture of 17x17, that's going to take the average of exactly 4 pixels unless I'm mistaken |
| 06:18 |
RealBadAngel |
step is reduced |
| 06:18 |
hmmmm |
is that really a good idea...? |
| 06:18 |
RealBadAngel |
not the resoultion |
| 06:18 |
RealBadAngel |
oops, increased |
| 06:19 |
hmmmm |
errrr |
| 06:19 |
hmmmm |
you're right |
| 06:19 |
RealBadAngel |
and after all its not important which pixels i do hit |
| 06:19 |
hmmmm |
okay nevermind I mixed something up |
| 06:19 |
RealBadAngel |
i just sample SOME of the pixels |
| 06:19 |
hmmmm |
yes it's increased, relative to the size |
| 06:19 |
RealBadAngel |
hopin to get right colour |
| 06:19 |
hmmmm |
okay sorry about that |
| 06:19 |
hmmmm |
for some reason I thought that was * |
| 06:19 |
hmmmm |
not / |
| 06:20 |
RealBadAngel |
best would be most used color but that would make code much slower |
| 06:20 |
RealBadAngel |
and avg and sampled one in practice works quite ok |
| 06:20 |
RealBadAngel |
colors found are correct |
| 06:20 |
hmmmm |
so, this algorithm isn't terribly accurate but you're at least limiting the amount of pixel fetches to 256 |
| 06:20 |
hmmmm |
roughly |
| 06:21 |
RealBadAngel |
something like that |
| 06:21 |
hmmmm |
worst case scenario is 31, where it'd be 31 * 31 |
| 06:21 |
hmmmm |
because step wouldn't == 2 at that point |
| 06:21 |
hmmmm |
in any case I hope the result of getTextureAverageColor() gets cached somewhere |
| 06:21 |
RealBadAngel |
result is stored in contentfeatures |
| 06:22 |
RealBadAngel |
its done only on startup |
| 06:22 |
hmmmm |
great |
| 06:22 |
RealBadAngel |
f.minimap_color |
| 06:30 |
|
est31 joined #minetest-dev |
| 06:31 |
RealBadAngel |
hmmmm, MinimapMode is enum, there are no increment operators for it |
| 06:32 |
hmmmm |
what happens if MinimapMode is at RADAR_MODEx4 when you call toggleMinimap again? |
| 06:32 |
est31 |
even then one can use c style casts |
| 06:32 |
est31 |
no? |
| 06:32 |
hmmmm |
yeah, static_cast<blahblah>(static_cast<blahblahlbalh>()) is soo god damn messy |
| 06:33 |
hmmmm |
you can't see what operation is actually being performed because so much of the line real estate is being taken up by this overly verbose cast syntax |
| 06:34 |
hmmmm |
i'm not even half done :\ |
| 06:34 |
hmmmm |
brb need a break |
| 06:37 |
RealBadAngel |
hmmmm, after minimap mode it will be OFF again |
| 06:38 |
hmmmm |
oh, i see, in the default case |
| 06:38 |
RealBadAngel |
value will be out of range so brought down to default ( 0 - off) |
| 06:38 |
hmmmm |
yeah it works I guess |
| 06:42 |
RealBadAngel |
that sleep_ms(10) is copied from mapblock mesh update thread, ive no idea what for it is ;) |
| 06:43 |
RealBadAngel |
to make my thread i took it and modified |
| 06:44 |
RealBadAngel |
iirc when i deleted that line engine frozen, so i left it as is |
| 06:45 |
est31 |
@ sfan5, other win builders |
| 06:45 |
hmmmm |
when will a QueuedMinimaUpdate contain NULL for data? |
| 06:45 |
est31 |
did you know that cmake comes with cpack which allows to generate installer binaries? |
| 06:46 |
est31 |
for windows |
| 06:46 |
est31 |
automatically |
| 06:46 |
est31 |
sfan5, http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS |
| 06:47 |
RealBadAngel |
hmmmm, when block got unloaded |
| 06:48 |
RealBadAngel |
it sends then just pos with no data |
| 06:49 |
hmmmm |
okay |
| 06:50 |
RealBadAngel |
thats a bit messy, because number of mapblock_meshes != minimap_mapblocks |
| 06:50 |
RealBadAngel |
blocks that contain only air have no mesh |
| 06:51 |
hmmmm |
well between nerzhul 's comments and mine it looks like you have enough to chew on for now |
| 06:52 |
RealBadAngel |
sure :) |
| 06:52 |
hmmmm |
there's probably more too |
| 06:52 |
RealBadAngel |
well i supposed that there will be a few problems ;) its almost 1k lines |
| 06:53 |
RealBadAngel |
btw, why you dont like switch-case for modes? |
| 06:53 |
hmmmm |
it's repetitive |
| 06:53 |
RealBadAngel |
ofc it is |
| 06:53 |
hmmmm |
there's a saying, "if code looks like it's repeating itself, it could be done better" |
| 06:53 |
RealBadAngel |
nerzhul didnt liked if-elseif |
| 06:54 |
hmmmm |
switch is better than if-elseif for this of course |
| 06:54 |
RealBadAngel |
you dont like switch-case |
| 06:54 |
hmmmm |
but there's an even better one |
| 06:54 |
hmmmm |
an array |
| 06:54 |
RealBadAngel |
i knew you are going to say that :P |
| 06:54 |
RealBadAngel |
lol |
| 06:55 |
hmmmm |
in general, if you're comparing a value to one of several constant values, use a switch statement |
| 06:55 |
hmmmm |
if the several constant values are consecutive in value AND they all do the same thing aside from using separate values, make it into an array |
| 06:56 |
hmmmm |
RealBadAngel, when people make comments on code, you should understand the reason why we're saying it |
| 06:56 |
hmmmm |
if you don't, please ask |
| 06:56 |
RealBadAngel |
so i did |
| 06:56 |
hmmmm |
this goes for any comment |
| 06:57 |
RealBadAngel |
if i see the point i dont comment back just fix it |
| 06:57 |
|
nore joined #minetest-dev |
| 06:57 |
RealBadAngel |
but back to that switch case |
| 06:57 |
RealBadAngel |
i think it will get a bit complicated at some point |
| 06:57 |
hmmmm |
well look |
| 06:57 |
hmmmm |
they're all setting the same expression to true |
| 06:58 |
RealBadAngel |
im plannin to add shift for a keystroke |
| 06:58 |
hmmmm |
the only thing varying between them is the status text |
| 06:58 |
hmmmm |
? |
| 06:58 |
hmmmm |
what do you mean |
| 06:58 |
RealBadAngel |
modifier on F9 that will toggle also square/round |
| 06:58 |
RealBadAngel |
ah, nvm |
| 06:58 |
hmmmm |
errm |
| 06:58 |
RealBadAngel |
i just figured out the solution |
| 06:59 |
RealBadAngel |
i wont switch mode then |
| 06:59 |
RealBadAngel |
just toggle shape |
| 06:59 |
hmmmm |
set a flag |
| 06:59 |
hmmmm |
honestly that's what I would've done if I were coding this |
| 06:59 |
RealBadAngel |
so point for an array |
| 06:59 |
hmmmm |
have the shape and the zoom separate variables in the first place |
| 06:59 |
hmmmm |
there's nothing completely wrong with the way you implemented it |
| 06:59 |
hmmmm |
it's just not how I would've |
| 07:00 |
RealBadAngel |
ok, now whats the story with sleep_ms(10) |
| 07:01 |
est31 |
btw is it regenerating normals on every draw |
| 07:01 |
est31 |
? |
| 07:02 |
hmmmm |
I don't really know what sleep_ms(10) does ther |
| 07:02 |
hmmmm |
you're not holding any locks inside getMap() from what it looks |
| 07:02 |
RealBadAngel |
est31,in shaders theyre calculated on the fly |
| 07:03 |
RealBadAngel |
hmmmm, i dont need to i think |
| 07:03 |
hmmmm |
right, you don't need to after you changed the way it works |
| 07:05 |
RealBadAngel |
later on i will move texture generation back to minimap thread to save main thread time |
| 07:06 |
RealBadAngel |
but for that i need to write my own pixel operations workin directly on texture in memory without involving driver |
| 07:07 |
RealBadAngel |
so i will treat that memory kinda as screen. main thread will just read from it |
| 07:07 |
est31 |
or I guess different irrlicht context if that works |
| 07:08 |
RealBadAngel |
i will just double buffer it to avoid flickering |
| 07:09 |
hmmmm |
ohh RBA i don't know man |
| 07:09 |
RealBadAngel |
so main will display already prepared one while thread will be working on another frame |
| 07:09 |
hmmmm |
that sounds good and all but there are incompatibilities |
| 07:09 |
hmmmm |
did you read about multithreaded irrlicht |
| 07:09 |
RealBadAngel |
yes, thats why i wont use irrlicht for that |
| 07:10 |
RealBadAngel |
i just need double buffered fixed size texture |
| 07:10 |
RealBadAngel |
with direct access to it, not a problem since i know the format |
| 07:11 |
RealBadAngel |
whats im going to do ask irrlicht to make those textures for me, give me format data and nothing more |
| 07:11 |
|
selat joined #minetest-dev |
| 07:12 |
RealBadAngel |
later on i dont need engine to handle it |
| 07:15 |
RealBadAngel |
this way or another it has to be done, 4-5fps cost of minimap is worth to be gained back |
| 07:26 |
RealBadAngel |
hmmmm, btw, some1 stated when delete has nothing to remove it does nothing |
| 07:26 |
est31 |
me |
| 07:26 |
est31 |
I said if you do delete NULL it does nothing |
| 07:27 |
est31 |
didnt say "nothing to remove" |
| 07:27 |
RealBadAngel |
*** Error in `./bin/minetest': double free or corruption (out): 0x0000000002fa5940 *** |
| 07:27 |
est31 |
afaik there is no double-delete protection |
| 07:27 |
RealBadAngel |
that is what i got when havent checked if theres something to delete |
| 07:27 |
est31 |
but a if (data) check wont save you there |
| 07:27 |
est31 |
its only true if data is not null |
| 07:27 |
est31 |
err false |
| 07:27 |
est31 |
and in that case, delete data works fine already |
| 07:28 |
RealBadAngel |
im talkin now about MinimapMapblock |
| 07:28 |
RealBadAngel |
which is created in mapblock_mesh |
| 07:29 |
RealBadAngel |
only place that should be able to delete is minimap thread |
| 07:29 |
est31 |
if you delete, set the pointer to null and be happy |
| 07:29 |
RealBadAngel |
but when i do that without checks i can see double free error so, a) theres no leak |
| 07:30 |
RealBadAngel |
b) who the f... is deleting it for me ;) |
| 07:31 |
RealBadAngel |
i delete only data from cache (pos + ptr to minimap mapblock) |
| 07:31 |
RealBadAngel |
m_blocks_cache.erase(it); |
| 07:32 |
RealBadAngel |
that shouldnt delete pointed object, right? |
| 07:32 |
est31 |
afaik erase calls delete, thats ok? |
| 07:32 |
est31 |
oh seems not ok :) |
| 07:33 |
RealBadAngel |
or destroying mapblock mesh does that |
| 07:33 |
est31 |
ok but as you are storing pointers, it should be ok |
| 07:33 |
est31 |
because then only those get erased |
| 07:34 |
RealBadAngel |
even when i havent manually add that to destructor |
| 07:34 |
est31 |
If I'm reading the docs right |
| 07:34 |
hmmmm |
wrong. |
| 07:34 |
hmmmm |
erase() on iterators calls the destructor. |
| 07:35 |
hmmmm |
if the destructor frees memory allocated over the course of the object's lifetime, then great. otherwise, not so much. |
| 07:35 |
RealBadAngel |
if (it->second) { |
| 07:35 |
RealBadAngel |
delete it->second; |
| 07:35 |
RealBadAngel |
} |
| 07:35 |
RealBadAngel |
m_blocks_cache.erase(it); |
| 07:35 |
RealBadAngel |
i just modifed it so |
| 07:35 |
RealBadAngel |
it hits error on delete |
| 07:35 |
RealBadAngel |
so, before erase iterator |
| 07:36 |
RealBadAngel |
it must be mapblock mesh class destructor |
| 07:36 |
RealBadAngel |
i cant see any other explanation |
| 07:37 |
RealBadAngel |
actually it cant be it, i keep minimapmapblocks ptrs for air chunks even when mesh for it got deleted |
| 07:37 |
hmmmm |
jesus christ. |
| 07:38 |
hmmmm |
this code is going into minetest and you people don't even know the correct semantics behind memory management? |
| 07:38 |
hmmmm |
:( |
| 07:38 |
hmmmm |
now where is this double free happening exactly? |
| 07:39 |
RealBadAngel |
hmmmm, i would like to delete the object as im supposed to do so, but something is doing it for me behind my back |
| 07:39 |
RealBadAngel |
a sec |
| 07:39 |
hmmmm |
delete which object |
| 07:40 |
RealBadAngel |
http://pastebin.com/5hNG3imd |
| 07:40 |
hmmmm |
right |
| 07:40 |
hmmmm |
the "if (it->second) {" there is unnecessary |
| 07:41 |
|
troller joined #minetest-dev |
| 07:41 |
hmmmm |
i can say with certainty you can change that to just "delete it->second; |
| 07:41 |
RealBadAngel |
https://github.com/RealBadAngel/minetest/commit/cfc0aa214285493f868bbd9efd08531a74c3e716#diff-c2f90db5de8c33a259c27113939c63c5R1032 |
| 07:41 |
RealBadAngel |
i cant |
| 07:41 |
RealBadAngel |
this is when i got "double free error" |
| 07:41 |
est31 |
hmmmm, yes it calls the destructor |
| 07:42 |
est31 |
but a destructor for a pointer type (which is integral), does nothing, no? |
| 07:42 |
est31 |
also here: http://stackoverflow.com/a/6353169 |
| 07:43 |
hmmmm |
est31: correct |
| 07:43 |
est31 |
(at least nothing on the pointed object) |
| 07:43 |
hmmmm |
a pointer is just some number |
| 07:43 |
hmmmm |
a destructor does nothing for a pointer |
| 07:43 |
hmmmm |
RealBadAngel, sounds like your bug is happening somewhere else. |
| 07:45 |
RealBadAngel |
atm i have no idea |
| 07:46 |
RealBadAngel |
i will check when it happens |
| 07:46 |
hmmmm |
is it possible that you have the same data MinimapMapblock assigned to multiple entries in that map? |
| 07:51 |
RealBadAngel |
not possible |
| 07:52 |
RealBadAngel |
it is exlusivelly created for each mapblock mesh instance |
| 07:52 |
est31 |
I am wondering about adding a new data structure to minetest |
| 07:52 |
est31 |
AreaStore |
| 07:53 |
est31 |
3 operations: addArea, removeArea, and isInArea |
| 07:53 |
|
Jasper joined #minetest-dev |
| 07:53 |
est31 |
err replace isInArea with getAreasAround(point) |
| 07:54 |
est31 |
because I see the "protection" problem solved from two directions |
| 07:54 |
est31 |
the ShadowNinja areas mod defines a large lua table which lists every area on the server |
| 07:55 |
est31 |
the tenplus1 protector mod (which bases on earlier mods with the same idea), does get_nodes_near or how its called on every build action |
| 07:55 |
est31 |
I've thought: what about combining the two approaches / trading off? |
| 07:56 |
est31 |
so instead of having one great list, making an octree and storing areas containing octree elements |
| 07:58 |
est31 |
it has other use cases too |
| 07:58 |
est31 |
(not just protection) |
| 07:58 |
RealBadAngel |
hmmmm, weird, it stopped crashing, i cant reproduce it now |
| 07:58 |
est31 |
e.g. technic windmill relies on the area around itself "being free", so that "wind can flow around it" |
| 07:59 |
est31 |
right now it re-checks the whole area every 20 seconds |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:01 |
est31 |
now my big question is where to store that |
| 08:01 |
est31 |
I mean I can think of nice serialisation methods, just where to put the data |
| 08:01 |
est31 |
preferrably so that you dont have to load it all into memory |
| 08:01 |
est31 |
like current map data for example |
| 08:01 |
Jasper |
Hey. I come from a company who wants to ship Minetest on ARM. On our platform, we only have GLESv2. I noticed that Minetest was using Irrlicht, which really doesn't have GLESv2 support -- it just seems to be dead upstream. |
| 08:02 |
Jasper |
We could fund / develop a custom GLESv2 renderer, but it would be nice if it was upstream or similar. |
| 08:02 |
Jasper |
Any thoughts on this? |
| 08:03 |
RealBadAngel |
Jasper, we do already have arm build |
| 08:03 |
est31 |
yea but shaders are broken |
| 08:03 |
RealBadAngel |
shaders have to be simplyfied for ES |
| 08:03 |
est31 |
also its arm android |
| 08:04 |
est31 |
which arm platform do you target Jasper ? |
| 08:04 |
Jasper |
est31, our own ARM-based OS called EndlessOS |
| 08:04 |
RealBadAngel |
one should strip shaders to only care for finalColorBlend and nothing more |
| 08:04 |
Jasper |
est31, based on traditional desktop Linux |
| 08:04 |
RealBadAngel |
rest of the effects wont work on ES, except for maybe waving plants |
| 08:05 |
Jasper |
Does Irrlicht even support GLES? |
| 08:05 |
Jasper |
All evidence I could find pointed towards no |
| 08:05 |
VanessaE |
hasn't Megaf done that once at least? |
| 08:05 |
VanessaE |
(MT + GLES) |
| 08:06 |
RealBadAngel |
googlin for irrlicht and GLES show lotsa examples |
| 08:06 |
Jasper |
I see an official branch / fork. |
| 08:06 |
Jasper |
er |
| 08:06 |
Jasper |
unofficial |
| 08:06 |
RealBadAngel |
oven on RPI |
| 08:06 |
RealBadAngel |
*even |
| 08:07 |
Hunterz |
btw is there any izometric map like dynmap known on the bukkit/minecraft? |
| 08:08 |
est31 |
Hunterz, there was one I think xyzz did it |
| 08:08 |
est31 |
but have no link |
| 08:08 |
est31 |
VanessaE has shared one |
| 08:08 |
Jasper |
RealBadAngel, yeah, see: http://svn.code.sf.net/p/irrlicht/code/branches/ogl-es/ogles-readme.txt |
| 08:09 |
VanessaE |
https://github.com/xyzz/onomatopoeia |
| 08:09 |
Hunterz |
thanks |
| 08:09 |
VanessaE |
it's way outdated though |
| 08:09 |
VanessaE |
doesn't even render nodeboxes :) |
| 08:11 |
RealBadAngel |
Jasper, i guess if you will add support for GLES to mt it could be merged |
| 08:11 |
RealBadAngel |
i can help you with shaders |
| 08:11 |
Jasper |
Any reason you guys use Irrlicht? |
| 08:11 |
RealBadAngel |
because c55 picked it some time ago? :) |
| 08:11 |
* Jasper |
was just thinking of writing a renderer from scratch |
| 08:12 |
hmmmm |
people have been talking about a move to a modern, advanced engine |
| 08:13 |
hmmmm |
i advocate OpenSceneGraph |
| 08:13 |
Jasper |
I haven't seen any modern, open-source renderer that isn't also just flat out dead. |
| 08:14 |
|
Calinou joined #minetest-dev |
| 08:14 |
Jasper |
I can't imagine your drawing needs are very complex... |
| 08:15 |
RealBadAngel |
heres still lotsa to do |
| 08:16 |
hmmmm |
most of the trouble parts are not in rendering, but rather streaming mesh changes to the gpu efficiently |
| 08:16 |
VanessaE |
hmmmm: ^^^^ which I've found out, seems to be the cause of my performance issues with minetest of late. |
| 08:17 |
VanessaE |
(both in and out of minetest) |
| 08:17 |
hmmmm |
? it's been a problem since the beginning |
| 08:17 |
hmmmm |
nothing changed recently in that respect |
| 08:17 |
Jasper |
hmmmm, what's your current architecture here? |
| 08:18 |
VanessaE |
well yeah it's been a problem, but lately it just seems..worse. in any case it's because a single 2.8 GHz core isn't fast enough to feed these bad-ass GPUs we have now - after some tests, in my case, three is. |
| 08:18 |
Jasper |
The silly way to do it would be to have each block as a separate draw call, but that's what I'd imagine minetest is doing... |
| 08:18 |
RealBadAngel |
VanessaE, your problems are driver related rather |
| 08:18 |
|
Darcidride joined #minetest-dev |
| 08:18 |
VanessaE |
RealBadAngel: nope. same performance in open source and closed-source drivers. it's a CPU bottlenbeck. |
| 08:18 |
VanessaE |
-b |
| 08:19 |
Jasper |
VanessaE, I highly doubt that, though. |
| 08:19 |
hmmmm |
the individual cube things are called MapNodes and are stored in MapBlocks, which is a 16x16x16-sized array of data about what each block is |
| 08:19 |
Jasper |
hmmmm, I'm more wondering how these things are drawn. Is each MapBlock one VBO? |
| 08:19 |
hmmmm |
each MapBlock has its own mesh that is generated in a separate thread and then rendered as part of the map |
| 08:19 |
Jasper |
Yeah. |
| 08:19 |
Jasper |
And I imagine you do some basic software culling on MapBlocks if they don't need to be drawn, then. |
| 08:19 |
RealBadAngel |
VanessaE, threads wont automagically spread over aviable cpus |
| 08:20 |
hmmmm |
there weren't any VBOs until very recently because of a dumb irrlicht bug causing a memory leak with VBOs in our use case |
| 08:20 |
Jasper |
Nice. |
| 08:20 |
hmmmm |
yes, software occlusion culling is performed |
| 08:20 |
VanessaE |
RealBadAngel: they will if your OS has a good scheduler and those threads need enough CPU time. |
| 08:20 |
RealBadAngel |
hmmmm, ive tested lately VBO |
| 08:20 |
VanessaE |
RealBadAngel: it's called thread migration |
| 08:20 |
hmmmm |
but anyway |
| 08:20 |
RealBadAngel |
and havent noticed any leaks |
| 08:20 |
hmmmm |
the problem is that any time a MapBlock is changed in some way |
| 08:20 |
hmmmm |
it needs to be regenerated and reuploaded to the gpu |
| 08:20 |
Jasper |
hmmmm, glMapBufferRange? |
| 08:20 |
hmmmm |
this is fine for nVidia but not so much for Intel |
| 08:21 |
hmmmm |
dunno, we can't work with raw OpenGL |
| 08:21 |
Jasper |
glMapBufferRange is great on Intel, it's all UMA. |
| 08:21 |
hmmmm |
honestly Minetest needs a lot of work but doesn't have enough manpower |
| 08:21 |
hmmmm |
there are a lot of things that could be tried |
| 08:21 |
RealBadAngel |
hmmmm, hold on, problem with VBO code was missed letting hardware know that mesh has changed |
| 08:21 |
hmmmm |
it just needs to be tried |
| 08:21 |
RealBadAngel |
and forcing reloading of that mesh |
| 08:22 |
Jasper |
Well, we'd be interested in funding / doing some of this development. |
| 08:22 |
Jasper |
But we really need direction -- we don't want to write anything that would be eventually thrown away. |
| 08:22 |
RealBadAngel |
when taken care of it, VBO works just fine |
| 08:22 |
hmmmm |
the majority of us have full time jobs :) |
| 08:22 |
Jasper |
Me included. |
| 08:22 |
Jasper |
My day job is actually writing the GPU driver for this thing :) |
| 08:23 |
hmmmm |
we never threw away any contributions unless they did nothing but rewrite a piece of code with absolutely no benefit |
| 08:23 |
hmmmm |
yeah, there is an Intel guy in this channel too |
| 08:23 |
|
chchjesus joined #minetest-dev |
| 08:23 |
hmmmm |
can't point out who at the moment but we talked about the same sort of challenges |
| 08:24 |
Jasper |
Don't recognize any of the standard Intel guys in here. |
| 08:24 |
hmmmm |
celeron55 or kahrl are probably the ones you'd want to talk to if you'd like to get more in depth about the graphics side of this project. i don't work on the graphics at all hardly |
| 08:24 |
Jasper |
OK. |
| 08:24 |
RealBadAngel |
<hmmmm> it needs to be regenerated and reuploaded to the gpu ----> m_mesh->setDirty(); |
| 08:24 |
Jasper |
RealBadAngel, yeah, that probably marks it for rebuilding. |
| 08:24 |
hmmmm |
RealBadAngel: does that fix the mesh streaming lag problem? |
| 08:24 |
hmmmm |
didn't think so! |
| 08:24 |
Jasper |
I just didn't know if you guys were attached to Irrlicht at all, given that I'd probably write a custom renderer. |
| 08:25 |
hmmmm |
the client is heavily attached to Irrlicht |
| 08:25 |
Jasper |
Sure, I'd imagine the code is, but I don't know if you guys are. |
| 08:25 |
RealBadAngel |
hmmmm, we need to do that ONLY when vertices has changed - pos or color |
| 08:25 |
hmmmm |
certainly not |
| 08:25 |
hmmmm |
all of us hate irrlicht |
| 08:25 |
Jasper |
vertex colors? |
| 08:25 |
RealBadAngel |
yes |
| 08:25 |
Jasper |
I suppose it fits the asthetic... |
| 08:26 |
RealBadAngel |
vertex color are used for lighting |
| 08:26 |
Jasper |
Yeah, for that authentic 80s per-vertex lighting feel. |
| 08:26 |
RealBadAngel |
also could be used for EMT_TRANSPARENT_VERTEX_ALPHA materials |
| 08:26 |
VanessaE |
hmmmm: zeno has been working off and on to abstract that out a bit so that irrlicht can be dropped in the future. |
| 08:26 |
hmmmm |
that's cool. haven't seen zeno in a while |
| 08:26 |
RealBadAngel |
in those cases driver has to be forced to reupload mesh |
| 08:26 |
hmmmm |
you haven't seen me in a while either though |
| 08:27 |
hmmmm |
I promise to be around more often |
| 08:27 |
hmmmm |
later, it's 4:30 am |
| 08:27 |
hmmmm |
I *need* to go |
| 08:27 |
VanessaE |
in that case I'll be hiding more ;) |
| 08:28 |
Jasper |
west coast represent |
| 08:28 |
* VanessaE |
mumbles something about being in the east |
| 08:28 |
Jasper |
i used to be over there |
| 08:34 |
RealBadAngel |
Jasper, anyway if you will need any help regarding shaders feel free to ask |
| 08:34 |
Jasper |
I'm pretty OK with shades. |
| 08:35 |
Jasper |
shaders, rather |
| 08:41 |
RealBadAngel |
btw, https://imgrush.com/qr9Ly_nmAwNI |
| 08:42 |
Jasper |
Nice seam. |
| 08:42 |
VanessaE |
RealBadAngel: first tests of the new skybox code? |
| 08:42 |
RealBadAngel |
had to rework irrlicht skyboxes code to support vertex alpha |
| 08:42 |
RealBadAngel |
background is black |
| 08:42 |
RealBadAngel |
you can see there one face of skybox with different alpha than others |
| 08:43 |
RealBadAngel |
so blending skyboxes will be definitely possible |
| 08:43 |
RealBadAngel |
also fading in and out skyboxes will be fast |
| 08:43 |
RealBadAngel |
its only change colour of 24 vertices per skybox |
| 08:45 |
celeron55 |
Jasper: you can ask me if you can't figure out something on your own or need a qualified opinion for whether doing something makes sense |
| 08:45 |
Jasper |
celeron55, would you be OK with a custom renderer? |
| 08:45 |
Jasper |
celeron55, I'm not sure how much of irrlicht you guys use -- I only started to poke through the code today. |
| 08:45 |
celeron55 |
Jasper: what you are wishing to do is really the hardest thing you can imagine doing to Minetest, so keep that in mind; it's also becoming increasingly wanted within the community so that does help though |
| 08:46 |
Jasper |
celeron55, also, besides just "support GLESv2", any other goals I should keep in mind? |
| 08:46 |
Jasper |
celeron55, heh, anything above the renderer that actually makes the game is just boring code to me. The renderer is the fun part :) |
| 08:47 |
celeron55 |
irrlicht does certain things very right, like being able to be packaged separately for linux without any project-specific build-time options and having a liberal license |
| 08:48 |
* est31 |
still wonders why that is this important |
| 08:48 |
celeron55 |
minetest uses a lot of irrlicht's types like vectors and vertexes and meshes and irrlicht |
| 08:48 |
est31 |
(the first part) |
| 08:48 |
celeron55 |
+'s model loading |
| 08:48 |
celeron55 |
and irrlicht also provides multi-platform windowing and input |
| 08:48 |
Jasper |
Because some distributions *really* care about not having packaged libraries. |
| 08:48 |
celeron55 |
it even supports android with ES 1 |
| 08:48 |
Jasper |
To the point of insanity. |
| 08:49 |
celeron55 |
that's what you're going against |
| 08:49 |
crazyR |
<celeron55> the windowing and input from irrlicht does look really old and outdated thought |
| 08:49 |
Jasper |
I was going to use SDLv2 for platform support, most likely. |
| 08:49 |
celeron55 |
irrlicht is good, but old |
| 08:49 |
Jasper |
I wouldn't go as far to say "good". |
| 08:49 |
celeron55 |
well, it's not good anymore because it's outdated :P |
| 08:50 |
celeron55 |
it once was, for a library with such licensing and so |
| 08:50 |
Jasper |
Yeah. SDLv2 has it beat on the platform support, I feel. |
| 08:50 |
Jasper |
And the renderer is just sort of... well, uh. |
| 08:50 |
celeron55 |
the renderer is ancient; i know |
| 08:51 |
Jasper |
Do you guys use any of its model loading parts? I don't really know what you guys do for models, if anything. |
| 08:51 |
Jasper |
All procedural? |
| 08:51 |
celeron55 |
irrlicht also has a lot of things that we don't use, like automatic asset loading from zip files and whatnot; so it's not a complete catastrophe |
| 08:51 |
celeron55 |
we use irrlicht's model loading support, and basically all of irrlicht's supported model formats are used by modders so if any is dropped, it probably makes someone very sad |
| 08:52 |
Jasper |
That's what, exactly? |
| 08:53 |
celeron55 |
also image formats |
| 08:53 |
crazyR |
celeron55 would it not be possible to create a wrapper with a library to keep irrlicht's model formats supported with what ever its used as a replacement? |
| 08:53 |
celeron55 |
https://github.com/minetest/minetest/blob/master/src/server.cpp#L2238 |
| 08:53 |
crazyR |
then pver time drop the wrapper |
| 08:53 |
celeron55 |
this is the server's file extension filter list |
| 08:53 |
Jasper |
What is .x? |
| 08:53 |
RealBadAngel |
we use obj without mtl and .x |
| 08:54 |
RealBadAngel |
i dont remember seeing some1 using another formats |
| 08:54 |
RealBadAngel |
d3d models |
| 08:54 |
Jasper |
It seems to be an extremely old DirectX format? |
| 08:54 |
celeron55 |
crazyR: it's probably reasonably easy to use irrlicht for just loading images and models |
| 08:54 |
Jasper |
.obj is easy enough to support. |
| 08:55 |
celeron55 |
it's also possible to just copy the model loaders from irrlicht; it's open source with a suitable license anyway |
| 08:55 |
est31 |
^ |
| 08:55 |
Jasper |
.b3d seems to be "Blitz Basic 3D" |
| 08:55 |
* est31 |
has copied openssl's sha1 |
| 08:55 |
celeron55 |
similarly as it is to fork irrlicht and replace large portions of it |
| 08:55 |
est31 |
into minetest |
| 08:56 |
celeron55 |
there are lots of options here; someone smart enough just has to do the work |
| 08:56 |
Jasper |
Yeah. |
| 08:56 |
RealBadAngel |
loaders are not a problem rather |
| 08:56 |
Jasper |
To be genuinely honest, I'm not a big fan of keeping around all the model formats here. |
| 08:56 |
Jasper |
But it's not an insurmountable problem. |
| 08:56 |
est31 |
and about the gui system: countless people want it to replaced anyway |
| 08:56 |
RealBadAngel |
imho internal mesh format counts here, dunno if other engines keep it the same as irrlicht do |
| 08:56 |
RealBadAngel |
and we are using it widely |
| 08:56 |
est31 |
We'd need to get stats about model formats |
| 08:56 |
crazyR |
Jasper. wouldnt it be posible to create a converter for the models. ? |
| 08:56 |
celeron55 |
if we research what formats are actually used and see that some are not, then it's fine to drop them |
| 08:57 |
Jasper |
crazyR, yeah, that's what I'd prefer to do. |
| 08:57 |
est31 |
lets do some bash magic on dreambuilder |
| 08:57 |
RealBadAngel |
est31, blends export to obj |
| 08:57 |
Jasper |
Everything exports to .obj. |
| 08:58 |
celeron55 |
it might very well be that we only need obj, i don't think this is an issue actually |
| 08:58 |
crazyR |
would actually make sense to have 1 standard |
| 08:58 |
celeron55 |
and even if it is, Jasper isn't going to have to make the loaders, someone else can just fine |
| 08:58 |
Jasper |
As for textures, .png + stb_image.h |
| 08:59 |
est31 |
RealBadAngel, I guess they are convertible into each other |
| 08:59 |
RealBadAngel |
as i said, loaders are not important |
| 08:59 |
Jasper |
Yeah. The important thing here is working out the structure of the renderer. |
| 08:59 |
Jasper |
And the internal mesh format. |
| 08:59 |
RealBadAngel |
whats important is the internal mesh format |
| 08:59 |
Jasper |
And even that isn't too important. |
| 08:59 |
celeron55 |
people basically only use .png and for some cases .jpg; nothing more needed there |
| 08:59 |
Jasper |
Do you support mesh animations at all? |
| 08:59 |
crazyR |
im getting excited already :/ thats probably a bad idea though |
| 09:00 |
est31 |
I think yes |
| 09:00 |
est31 |
but i have no gfx knowledge |
| 09:00 |
Jasper |
Do we need to support model animations at all? |
| 09:00 |
celeron55 |
Jasper: irrlicht supports mesh animations by specifying frame ranges for each animation, and MT supports that |
| 09:00 |
est31 |
how is moving skins done? |
| 09:00 |
Jasper |
celeron55, does it do HW skinning? |
| 09:00 |
celeron55 |
i don't know what that is |
| 09:00 |
Jasper |
I mean, is it a bone-based system? |
| 09:01 |
Jasper |
.obj doesn't have ways of specifying bones, so.. |
| 09:01 |
celeron55 |
i really don't know any model animation terminology and didn't implement it so you'll have to find out :P |
| 09:01 |
Jasper |
The traditional way you do it nowdays is doing joints on the GPU. |
| 09:02 |
Jasper |
http://http.developer.nvidia.com/GPUGems/gpugems_ch04.html seems like it has a rough overview |
| 09:02 |
Jasper |
haven't read it entirely though |
| 09:03 |
celeron55 |
oh. i'm dumb and forgot that we actually use one part of irrlicht that is a problem here: the GUI system |
| 09:03 |
celeron55 |
everybody hates it, but there is no replacement |
| 09:03 |
Jasper |
Yeah, there isn't any great open-source GUI system out there. |
| 09:03 |
crazyR |
haha but that really really really needs replacing anyway :D |
| 09:04 |
Jasper |
What widgets do we need, anyway? |
| 09:04 |
Jasper |
text input, checkbox, radio button? |
| 09:04 |
celeron55 |
but how the mods access the gui is independent of irrlicht though, so it *can* be relatively easily swapped |
| 09:04 |
celeron55 |
http://dev.minetest.net/formspec |
| 09:05 |
celeron55 |
just very basic things with fixed positioning |
| 09:06 |
celeron55 |
this needs to be reworked some day by some technique like client-side scripting or at least by adding custom skinning, but now that those don't exist yet, it makes this task easier |
| 09:06 |
|
kilbith joined #minetest-dev |
| 09:06 |
Jasper |
Now for a silly question here. |
| 09:07 |
Jasper |
Does Irrlicht allow me just calling OpenGL right in the middle of it? |
| 09:07 |
celeron55 |
i've never tried |
| 09:07 |
Jasper |
Would it be possible to hack this up by replacing parts of this with raw GL, so I can do it piecemeal? |
| 09:07 |
Jasper |
OK. |
| 09:07 |
celeron55 |
irrlicht is a quite thin wrapper in reality thoughh and it is also not threaded |
| 09:07 |
celeron55 |
so you might have luck there |
| 09:08 |
crazyR |
this looks interesting althought ive only had a quick glance http://sfgui.sfml-dev.de/ |
| 09:09 |
est31 |
ok stats here http://pastebin.com/0r2FTfRv |
| 09:09 |
Jasper |
Doesn't look very maintained, but it might be worth a shot. |
| 09:09 |
celeron55 |
for one, minetest does implement the main loop itself |
| 09:09 |
est31 |
for dreambuilder game |
| 09:09 |
est31 |
which is quite large |
| 09:09 |
Jasper |
est31, what is a .md |
| 09:09 |
est31 |
.md is text doc |
| 09:09 |
est31 |
markdown |
| 09:09 |
Jasper |
OK. |
| 09:09 |
Jasper |
So it uses .x and obj |
| 09:12 |
celeron55 |
Jasper: irrlicht renders its scene with three calls; beginScene, drawAll and endScene; i guess if you remove skyboxes and everything from the scene and draw before drawAll leaving the Z buffer intact, you might get a useful result... but it might be that irrlicht's interface has to be extended for this |
| 09:13 |
RealBadAngel |
i told ya |
| 09:13 |
celeron55 |
Jasper: anyway, try it and report back; it just might work |
| 09:14 |
Jasper |
Depends if I get time at work to actually work on this. |
| 09:14 |
crazyR |
:( |
| 09:14 |
Jasper |
How long do you think it would actually take? |
| 09:15 |
Jasper |
My guess would be 1-2 months of off-and-on work. |
| 09:15 |
Jasper |
celeron55, I think I would have to first hack up Irrlicht to always use OGL and never use D3D |
| 09:15 |
celeron55 |
well, it depends how good you are 8) but i would consider that if you manage to replace *only* the voxel rendering with that, leaving irrlicht in place to do all the complex less performance intensive stuff alongside it, it's not a big task |
| 09:15 |
Jasper |
I'd replace skybox rendering and GUI rendering too. |
| 09:16 |
Jasper |
My goal here is pure GLES |
| 09:17 |
RealBadAngel |
http://code.metager.de/source/xref/irrlicht/source/Irrlicht/CSceneManager.cpp#1380 |
| 09:17 |
RealBadAngel |
Jasper, i have rewrote skybox rendering already |
| 09:17 |
Jasper |
In pure GLES? |
| 09:17 |
RealBadAngel |
im doing them on my own with meshes just |
| 09:17 |
RealBadAngel |
they have nothing to do with shaders |
| 09:18 |
Jasper |
I have no idea why you keep bringing up shaders. |
| 09:18 |
celeron55 |
Jasper: RealBadAngel usually just messes around with irrlicht, none of it is really applicable to what you want to do |
| 09:18 |
Jasper |
OK. |
| 09:18 |
RealBadAngel |
Jasper, you have said you gonna replace skybox rendering |
| 09:18 |
celeron55 |
take a look at that code though, it's irrlicht's scene->drawAll which is interesting |
| 09:18 |
RealBadAngel |
skybox is just a cube made out of 24 vertices |
| 09:19 |
RealBadAngel |
shaders are not involved here |
| 09:19 |
celeron55 |
Jasper: i really don't know how long it would take to do all that |
| 09:19 |
celeron55 |
an infinite time for most people i'd think; it's not easy |
| 09:19 |
celeron55 |
a shorter time if you know what you're doing |
| 09:19 |
Jasper |
I mostly do. |
| 09:20 |
Jasper |
Irrlicht doesn't even do a depth-prepass. |
| 09:20 |
Jasper |
Jesus. |
| 09:20 |
Jasper |
I didn't realize it would be *that* bad. |
| 09:20 |
Jasper |
let's just throw all that early-Z out the window and shade everything |
| 09:21 |
RealBadAngel |
celeron55, all i do care about is internal mesh format, if that will change it will be a mess |
| 09:24 |
celeron55 |
Jasper: all i can say at this point is, try jamming in your modern stuff in there and see what happens; you don't have to do all the work as long as there is a base that can be built on |
| 09:24 |
Jasper |
Yeah. |
| 09:24 |
Jasper |
If I have some extra time this weekend I'll poke at it. |
| 09:26 |
Jasper |
For reference, last week's weekend hack was http://magcius.github.io/zelview.js/zelview.html#ydan_scene!0.0060,0.0600,-3.6797,136.1472,590.6298 |
| 09:26 |
celeron55 |
some people might find it bad that directx support would go away, but i think it is necessary to drop it in the long term |
| 09:26 |
celeron55 |
direct3d* |
| 09:26 |
Jasper |
So I'm pretty used to writing these kinds of renders. |
| 09:26 |
Jasper |
renderers |
| 09:26 |
Jasper |
Yeah, I admit I haven't used D3D at all. |
| 09:27 |
Jasper |
I just write OpenGL and OpenGL drivers :) |
| 10:07 |
Calinou |
we do need to drop it, it's simply obsolete |
| 10:07 |
Calinou |
SuperTuxKart did the same thing with their Antartica engine (fork of Irrlicht) |
| 10:22 |
est31 |
when all your downstream projects start forking you, you clearly have done something wrong. |
| 10:22 |
est31 |
or not done something |
| 10:54 |
Calinou |
Irrlicht is mostly unmaintained now |
| 10:56 |
Hunterz |
and have ugly bugs like https://github.com/minetest/minetest/issues/1898 |
| 10:56 |
Calinou |
maybe we should start supplying our own Irrlicht |
| 10:56 |
Calinou |
based on 1.9-dev |
| 10:58 |
est31 |
based on an unstable rendering engine? |
| 11:00 |
est31 |
whatever, I'm no gfx guy, so we should do whatever people who know things think is best. |
| 11:01 |
|
err404 joined #minetest-dev |
| 11:19 |
|
vorsalani joined #minetest-dev |
| 11:20 |
|
proller joined #minetest-dev |
| 11:37 |
sfan5 |
est31: yes, i know that cmake can use nsis but i never bothered to tale a look at it |
| 12:01 |
|
twoelk joined #minetest-dev |
| 12:20 |
|
TeTpaAka joined #minetest-dev |
| 12:26 |
|
SopaXorzTaker joined #minetest-dev |
| 12:28 |
|
Darcidride joined #minetest-dev |
| 12:31 |
|
Elinvention joined #minetest-dev |
| 12:42 |
Elinvention |
what is the unit of measure of player speed? |
| 12:43 |
Calinou |
Elinvention, nodes per second |
| 12:43 |
Calinou |
default is 4 (walking), 1.35 (sneaking) |
| 12:45 |
Elinvention |
if I call player->getSpeed() I get 40 and 13, so I guess it's 10x |
| 12:45 |
Calinou |
yes it's Irrlicht units |
| 12:45 |
Elinvention |
ok thank you |
| 12:45 |
Calinou |
we use BS (BlockSize, even though celeron55 calls it "bullshit"), which is 10 Irrlicht units :) |
| 12:45 |
Calinou |
1 node is 1 BS |
| 12:45 |
Calinou |
this is why coordinates may also be 10x |
| 12:45 |
|
Darcidride_ joined #minetest-dev |
| 12:45 |
Calinou |
(in the C++ code, not in Lua API) |
| 12:46 |
Elinvention |
I am trying to add get_player_velocity to lua api |
| 12:46 |
Calinou |
players have no velocity server-side, you might have trouble |
| 12:46 |
Calinou |
it probably won't work well, if at all |
| 12:51 |
Elinvention |
I might be lucky it seems someone implemented server side speed because it works very well |
| 13:09 |
Calinou |
does it work with several clients, on a dedicated server? |
| 13:09 |
Calinou |
(not an in-client server) |
| 13:11 |
AnotherBrick |
anybody had troubles with locale when minetest is compiled by MinGW? |
| 13:12 |
AnotherBrick |
and by "troubles with locale" i mean 'Character conversion failed' when trying to chat in non-english |
| 13:15 |
TeTpaAka |
related to #2574 |
| 13:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/2574 -- Character conversion failed |
| 13:15 |
|
husanux7 joined #minetest-dev |
| 13:18 |
AnotherBrick |
so, it's not related to mingw |
| 13:20 |
|
husanux4 joined #minetest-dev |
| 13:25 |
|
husanux5 joined #minetest-dev |
| 13:49 |
|
Elinvention joined #minetest-dev |
| 13:51 |
|
CraigyDavi joined #minetest-dev |
| 13:51 |
|
CraigyDavi joined #minetest-dev |
| 13:51 |
|
est31 joined #minetest-dev |
| 13:52 |
est31 |
5 mins till push https://github.com/est31/minetest/commit/3376d2e114767eef06b87645edefcd2d42696919 |
| 14:06 |
|
hmmmm joined #minetest-dev |
| 14:23 |
|
TeTpaAka joined #minetest-dev |
| 14:29 |
|
H-H-H joined #minetest-dev |
| 14:44 |
|
RealBadAngel joined #minetest-dev |
| 15:34 |
|
twoelk joined #minetest-dev |
| 15:34 |
kahrl |
https://forum.minetest.net/viewtopic.php?f=6&t=12675 |
| 15:34 |
kahrl |
this should no longer be a thing... |
| 15:34 |
kahrl |
what happened to the PR that added prediction for node meta inventories? |
| 16:16 |
|
Krock joined #minetest-dev |
| 16:20 |
|
proller joined #minetest-dev |
| 16:21 |
|
proller joined #minetest-dev |
| 16:24 |
|
Hunterz joined #minetest-dev |
| 16:34 |
|
Robert_Zenz joined #minetest-dev |
| 16:40 |
|
Hunterz joined #minetest-dev |
| 16:44 |
|
BubbleGum joined #minetest-dev |
| 16:52 |
Jasper |
Calinou, I didn't know SuperTuxKart was maintained, either |
| 16:52 |
Calinou |
it still is, quite actively |
| 17:00 |
Jasper |
Calinou, we ship that one too, and we also perhaps need a GLES port of it. |
| 17:01 |
Jasper |
Calinou, do you know if STK's Irrlicht fork supports GLES? |
| 17:02 |
Calinou |
no idea, unlikely |
| 17:53 |
hmmmm |
I could've sworn SuperTuxCart dropped irrlicht |
| 17:54 |
Jasper |
They forked it into a new engine, but it's still there. |
| 17:54 |
Jasper |
https://github.com/supertuxkart/stk-code/tree/master/lib/irrlicht/source/Irrlicht |
| 18:00 |
Calinou |
they call it Antarctica |
| 18:01 |
|
RealBadAngel joined #minetest-dev |
| 18:02 |
|
husanu1 joined #minetest-dev |
| 18:41 |
|
Robert_Zenz joined #minetest-dev |
| 19:05 |
twoelk |
could Antarctica be of any use for Minetest? |
| 19:06 |
Jasper |
Probably not. |
| 19:07 |
Jasper |
And the lead developer of Antarctica left the project because of some drama. |
| 19:07 |
Jasper |
So it's also dead. |
| 19:07 |
Jasper |
The big features are volumetric lights and deferred rendering, which we don't really need for our art style. |
| 19:23 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=18&t=11483&p=182764#p182764 |
| 19:23 |
Calinou |
do we support Android < 4.0? probably not |
| 19:25 |
twoelk |
volumetric lights? There was the Eye Candy discussion a few weeks ago -> https://forum.minetest.net/viewtopic.php?f=5&t=12261 |
| 19:29 |
|
MinetestForFun joined #minetest-dev |
| 19:33 |
|
err404 joined #minetest-dev |
| 19:36 |
|
ElectronLibre joined #minetest-dev |
| 19:52 |
|
asl97 joined #minetest-dev |
| 19:53 |
|
err404 left #minetest-dev |
| 20:12 |
|
Anchakor_ joined #minetest-dev |
| 20:30 |
|
cvtsx joined #minetest-dev |
| 20:31 |
|
troller joined #minetest-dev |
| 20:35 |
MinetestForFun |
Can you give your opinion about this please ? https://github.com/minetest/minetest/issues/2829 (i think it's an easy implemanted and very useful feature...) |
| 20:41 |
asl97 |
it can be done easily, just edit the chatcommand.lua, if you need hint on how to do it, just look at another command that allow additional args like deleteblocks |
| 21:03 |
|
proller joined #minetest-dev |
| 21:29 |
|
paramat joined #minetest-dev |
| 21:30 |
|
Lunatrius` joined #minetest-dev |
| 22:07 |
|
zat joined #minetest-dev |
| 22:10 |
paramat |
i discovered what was 'wrong' with mgv7 mountains. to stop them generating everywhere mountain noise had a negative offset, but doing this to 3D noise creates small fragmented volumes, mostly scattered floatlands. instead i added a negative offset to the modulating 2D mountain height noise. first test i get this http://i.imgur.com/0pAUrDZ.png more satisfying mountains with interesting structure and areas of rough hil |
| 22:10 |
paramat |
ls, which mgv7 was lacking |
| 22:53 |
|
paramat left #minetest-dev |
| 23:08 |
|
zat joined #minetest-dev |
| 23:23 |
|
Elinvention joined #minetest-dev |
| 23:43 |
|
zat joined #minetest-dev |
