| Time |
Nick |
Message |
| 00:34 |
|
xy joined #minetest-delta |
| 01:37 |
|
SpeedProg joined #minetest-delta |
| 01:39 |
|
Anchakor_ joined #minetest-delta |
| 02:11 |
|
Neological joined #minetest-delta |
| 06:03 |
|
MineTest joined #minetest-delta |
| 06:35 |
|
MineTest joined #minetest-delta |
| 06:57 |
|
cy1 left #minetest-delta |
| 07:03 |
|
MineTest joined #minetest-delta |
| 07:18 |
|
MineTest left #minetest-delta |
| 07:19 |
|
MineTest joined #minetest-delta |
| 07:30 |
|
asm|nop joined #minetest-delta |
| 07:35 |
|
LunaVorax joined #minetest-delta |
| 08:21 |
|
MineTest joined #minetest-delta |
| 08:30 |
|
asm|nop joined #minetest-delta |
| 13:29 |
|
LunaVorax joined #minetest-delta |
| 13:51 |
|
PilzAdam joined #minetest-delta |
| 14:51 |
|
Calinou joined #minetest-delta |
| 15:09 |
|
sstrandberg joined #minetest-delta |
| 15:26 |
|
LunaVorax joined #minetest-delta |
| 15:46 |
|
SpeedProg joined #minetest-delta |
| 16:09 |
|
BloodyFire joined #minetest-delta |
| 16:32 |
|
sstrandberg joined #minetest-delta |
| 17:22 |
|
rubenwardy joined #minetest-delta |
| 17:46 |
|
OWNSyouAll joined #minetest-delta |
| 17:46 |
|
nyuszika7h joined #minetest-delta |
| 17:59 |
|
OWNSyouAll joined #minetest-delta |
| 18:28 |
|
doserj joined #minetest-delta |
| 18:31 |
|
MiJyn joined #minetest-delta |
| 18:31 |
|
MiJyn joined #minetest-delta |
| 19:20 |
|
celeron55 joined #minetest-delta |
| 19:50 |
|
PilzAdam_ joined #minetest-delta |
| 20:01 |
|
MrDJK joined #minetest-delta |
| 20:02 |
MrDJK |
#minetest |
| 20:03 |
MrDJK |
Oops. >_< |
| 20:12 |
Taoki |
Latest updates on the models code: http://minetest.net/forum/viewtopic.php?pid=51559#p51559 The code is nearly ready, and there's just two more issues which need to be fixed first (related to an Irrlicht problem it appears) |
| 20:23 |
|
MiJyn joined #minetest-delta |
| 20:29 |
MrDJK |
May I ask an advice question in here? It's relating to Minetest mods. |
| 20:30 |
PilzAdam |
#minetest-mods |
| 20:30 |
MrDJK |
Oh okay, thank you much appreciated. |
| 20:44 |
Taoki |
BTW: If anyone knows Irrlicht and is interested in seeing the models code finished and working well, please see those two threads: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=1&t=47579 and http://irrlicht.sourceforge.net/forum/viewtopic.php?f=1&t=47580 It would help if someone could poke around the code and see what's causing that... I personally have no idea. |
| 20:45 |
PilzAdam |
Taoki, this might interest you: https://github.com/PilzAdam/carts/tree/attachment |
| 20:46 |
Taoki |
PilzAdam: Nice. Thanks... glad to see people are using it already. Yes, that's onevery useful case for it |
| 20:46 |
PilzAdam |
it works pretty good |
| 20:47 |
Taoki |
Nice. Using my latest GIT code? |
| 20:47 |
PilzAdam |
yep |
| 20:47 |
Taoki |
I tried player to player attachments, but not player to lua ent |
| 20:47 |
Taoki |
Awesome |
| 20:48 |
Taoki |
Yes it took quite a bit of work... was about to give up and remove attachable players altogether. Since it was tricky to find how to update local position and block movement |
| 20:48 |
PilzAdam |
but you should cahnge set_detachment() into detach() or something like this |
| 20:48 |
PilzAdam |
and extend the lua-api.txt |
| 20:48 |
Taoki |
Yeah, will think about that. I used that (ugly) name so it would be easy to find with set_attachment |
| 20:48 |
Taoki |
I might rename those however |
| 20:49 |
Taoki |
PilzAdam: If you're on my GIT branch though, feel free to try more test cases. Testing will be needed soon, to see if there are any other bugs. Only ones I'm aware of are issues with mone animations and attachments |
| 20:50 |
Taoki |
**bone animations and attachments |
| 20:56 |
celeron55 |
i'd imagine those should be called .attach() and .detach(), or if it has to be more specific, then .attach_object() and .detach_object() |
| 20:57 |
celeron55 |
or maybe no .detach() at all, just .attach(nil) |
| 20:57 |
celeron55 |
dunno 8) |
| 20:58 |
celeron55 |
great work anyways |
| 20:59 |
PilzAdam |
Taoki, what does the second param of set_attachment() mean? |
| 20:59 |
Taoki |
celeron55: Thanks. I'll think on how to rename these tomorrow |
| 21:00 |
Taoki |
PilzAdam: The string? It's the skeletal bone / joint to attach to, if the parent is an animated mesh |
| 21:00 |
Taoki |
Does not work yet... I'm waiting for input from the Irrlicht people |
| 21:00 |
PilzAdam |
ah, ok |
| 21:03 |
Taoki |
setBonePosRot also. Which should allow manually rotating a bone, for the head to look up / down and that sort of thing |
| 21:05 |
celeron55 |
oh lol, started browsing a full diff of taoki/models |
| 21:06 |
celeron55 |
you changed the loggings of everything in Client::loadMedia to say "loading into irrlicht" while the only one that loads anything into irrlicht is the one you added there 8) |
| 21:07 |
celeron55 |
http://pastebin.com/V6QXy7Mf |
| 21:07 |
celeron55 |
"loading sound into irrlicht" *proceeds stuffing it into the custom sound manager* |
| 21:09 |
celeron55 |
oh well, i might just as well browse through all of this |
| 21:09 |
Taoki |
Ah yes, I remember I did that to match the rest. Hope that's fine, if not I'll ut it back |
| 21:09 |
Taoki |
**put |
| 21:09 |
celeron55 |
"std::vector<core::vector2d<int> > attachment_list;" in content_cao.cpp should probably be stored as a member variable of ClientEnvironment |
| 21:10 |
Taoki |
celeron55: If you're looking at the diff, let me know if you find anything that could be considered "bad coding". This is my first big try at C++ after all |
| 21:10 |
celeron55 |
Taoki: it should log what it does |
| 21:10 |
Taoki |
Thought that's accurate for the other media types too |
| 21:11 |
Taoki |
And yes, that list is just a client-side global. I'll move it if that's better |
| 21:13 |
celeron55 |
well, in practice it doesn't matter, but making globals is quite selfish because you can only make a certain amount of them until everything becomes very unreadable |
| 21:13 |
Taoki |
I see |
| 21:14 |
Taoki |
And yeah. If it works well it's good, though clean and correct code matters too. Did my best to keep it as consistent as possible to my knowledge |
| 21:14 |
celeron55 |
also, technically you *can* make two Clients and ClientEnvironments, but not if that is a global |
| 21:18 |
Taoki |
I have a TODO list so if there's something else that's bad and not too difficult to change I can look into it tomorrow |
| 21:19 |
celeron55 |
the bad line ratio of this is surprisingly low 8) |
| 21:22 |
Taoki |
That's good :) |
| 21:23 |
Taoki |
Most things to do from this point are tweaks, so it will likely stay that way too |
| 21:24 |
celeron55 |
most of this seem to be just changing "doStuff();" to "if(attached) doSomethingElse(); else doStuff();" |
| 21:24 |
celeron55 |
this is kind of obvious |
| 21:24 |
celeron55 |
which* |
| 21:25 |
Taoki |
yeah. Part of attachments filters other events. Such as setting position in other places, or sending position to clients and wasting bandwidth (since if it's attached to an object that's aready sent the client will know where to see it) |
| 21:29 |
celeron55 |
the addition of irrlichttypes_bloated.h to other headers should be avoided like plague; you should rather include only the precise thing you need |
| 21:29 |
celeron55 |
because it will bloat up compile time by the enormous amount of useless stuff it contains, and headers spread it to many .cpp files |
| 21:31 |
celeron55 |
umm... actually it doesn't seem to include "enormous amounts"... well, but many useless things anyway |
| 21:31 |
Taoki |
ok. A lot of files seem to have that already. Not sure if that can be avoided in some parts |
| 21:31 |
celeron55 |
that was pretty much all |
| 21:31 |
Taoki |
ok |
| 21:32 |
Taoki |
Will get to those things tomorrow :) Then the code can go on servers for testing.\ |
| 21:33 |
Taoki |
Hope the Irrlicht people will help find out why bone attachments and animations break though |
| 21:33 |
celeron55 |
do you know any software based on irrlicht that does use them? |
| 21:35 |
Taoki |
None where I seen it working. But the functions are there and should work |
| 21:35 |
Taoki |
It's probably a bug or another flag I should be setting |
| 21:35 |
celeron55 |
supertuxcart is the "known" game based on irrlicht |
| 21:35 |
Taoki |
For bone attachments sure, many games were attempted in Irrlicht with people holding a sword in hand |
| 21:37 |
Taoki |
Seen some on Youtube myself IIRC. For manual joint rotations no, but the function for that is there and people have mentioned using them IIRC. |
| 21:37 |
Taoki |
Might be an issue with the x format. Which would be bad, since it's the only skeletal format that seems to work and can be exported from Blender (natively even). So I'm sticking to it |
| 21:37 |
Taoki |
But we'll see |
| 21:39 |
celeron55 |
i know roughly nothing of this subject, so you are on your own |
| 21:40 |
celeron55 |
or, well, with the irrlicht people |
| 21:40 |
Taoki |
yeah |
| 21:40 |
Taoki |
it's ok, a solution has to be found eventually |
| 21:41 |
celeron55 |
http://www.irrlicht3d.org/wiki/index.php?n=Main.IrrlichtPoweredGames |
| 21:42 |
celeron55 |
lol why is minetest in the "free" section, not "open source" |
| 21:42 |
celeron55 |
well whatever... |
| 21:44 |
Taoki |
That's a sad mistake |
| 21:46 |
celeron55 |
http://www.google.com/trends/explore#q=minetest%2C%20Star%20Sonata%202%2C%20SpaceWork%2C%20SuperTuxKart%2C%20Bolzplatz%202006&cmpt=q |
| 21:46 |
celeron55 |
some other somewhat known irrlicht games versus minetest 8) |
| 21:47 |
Taoki |
oh my, nice :D |
| 21:47 |
celeron55 |
it's funny how popular it is |
| 21:47 |
celeron55 |
it's like the only thing irrlicht is used for these days, in addition to STK |
| 21:47 |
Taoki |
Indeed. Still can't believe so many people are liking it. Didn't expect we'd be this lucky |
| 21:48 |
Taoki |
It's also in the Linux game repos... for my distro at least. So it's surely something |
| 21:48 |
Taoki |
Likely thaks to he lua API, and that MT can be used as an engine and it's so easy to create stuff. If everything stayed hard-coded it probably wouldn't have gotten very far, and be close to where it was 3 years ago |
| 21:49 |
Taoki |
**thanks to the lua API |
| 21:49 |
celeron55 |
minetest could catch openttd in popularity at the end of next year |
| 21:49 |
celeron55 |
http://www.google.com/trends/explore#q=minetest%2C%20openttd&cmpt=q |
| 21:49 |
celeron55 |
it's a funny comparison |
| 21:49 |
celeron55 |
dunno; of course it could just drop like dead too |
| 21:50 |
Taoki |
Likely not. Especially since new features are being added |
| 21:50 |
|
mrtux joined #minetest-delta |
| 21:50 |
celeron55 |
3 years ago? minetest did barely exist 2 years ago :P |
| 21:50 |
Taoki |
After the models patch I think people will like it even more |
| 21:50 |
Taoki |
True |
| 21:51 |
Taoki |
I think I'm among those who found it 3 or so years back. But I liked it since, sticked around but wasn't very active |
| 21:51 |
celeron55 |
there didn't exist even a line of minetest code 25 or 26 months ago |
| 21:51 |
celeron55 |
i don't know where you get that 3 years figure from :-D |
| 21:52 |
Taoki |
Menas time passed faster than I thought |
| 21:52 |
Taoki |
Erm, or slower |
| 21:52 |
Taoki |
Actually yes. It was around the beginning of 2011. That's when I remember I was on a public server for the first time and made a house |
| 21:52 |
Taoki |
http://www.youtube.com/watch?v=coI1rX6gclI&feature=related |
| 21:54 |
celeron55 |
the early times of 0.2, that i |
| 21:54 |
celeron55 |
is* |
| 21:56 |
celeron55 |
http://www.google.com/trends/explore#q=minetest%2C%20minecraft&cmpt=q |
| 21:56 |
Taoki |
Yeah. Quality improved quite a bit too. I remember those static torches and water, the old texture... and when the only tol was the mese rockpick. And obviously there was no sound. Flat clouds and... a very ugly day / night cycle (instant snapping to three phases of the day) |
| 21:56 |
Taoki |
Playing minetest_game now surely feels a lot more improved |
| 21:56 |
Taoki |
**old textures |
| 21:57 |
celeron55 |
hmm, the minecraft graph is interesting |
| 21:57 |
celeron55 |
i wonder if it's starting to decline |
| 21:58 |
celeron55 |
http://www.google.com/trends/explore#q=terraria&cmpt=q |
| 21:58 |
celeron55 |
these really do vary a lot |
| 21:58 |
Taoki |
It eventually will. Since most poeple who like MC probably got it by now |
| 21:59 |
celeron55 |
and it's interesting how large scale even terraria is; if you make it compare it to minetest, it's 19:1 currently |
| 22:00 |
Taoki |
yeah. It is a nice project too |
| 22:01 |
celeron55 |
http://www.google.com/trends/explore#q=braid%20game%2C%20minetest&cmpt=q |
| 22:01 |
Taoki |
What makes it special are the graphics. But I plan to optionally allow for graphics like that in MT too, with shaders and post-processing effects. Later on, not sure how hard those will be to add |
| 22:01 |
celeron55 |
from the indie scene, braid seems to be equally popular at the present moment |
| 22:01 |
Taoki |
nice |
| 22:05 |
celeron55 |
i guess you know of kahrl's shader branch |
| 22:06 |
Taoki |
I heard about it, didn't try it yet. Wonder if there's a video or images of it |
| 22:06 |
Taoki |
Also if it has bugs given it wasn't merged yet |
| 22:06 |
celeron55 |
it adds some management stuff for shaders; you should be able to get going with some post processing stuff very fast with it |
| 22:06 |
celeron55 |
it has no real use |
| 22:06 |
celeron55 |
nobody implemented any useful shaders on it |
| 22:07 |
celeron55 |
it just inverts colors 8) |
| 22:07 |
celeron55 |
(the test shader that it has) |
| 22:08 |
Taoki |
ok. Hope its still updated and compatible with latest master. Need to find some shaders for it online perhaps |
| 22:08 |
Taoki |
If it's common GLSL ones |
| 22:08 |
Taoki |
If the code is good though, it could be added. Might encourage people to make new shaders more quickly |
| 22:09 |
celeron55 |
i won't do that until somebody makes at least something useful |
| 22:10 |
Taoki |
Fair enough. Will try to keep it on my list, maybe Irrlicht users have some good ones |
| 22:11 |
celeron55 |
we need to keep around a working shader-free implementation of rendering too though; lowest end cards can't cope with the polygon count even with the tiniest bit of a shader |
| 22:12 |
Taoki |
Shaders would be optional of course. And yeah, the polygon count is an issue. I have a high-end card and normally it works well. But if I enable full view range, it's very slow. I wonder why |
| 22:12 |
Taoki |
Mc renders the same amount of cubes times faster, and it's java rather than C++ even :P |
| 22:12 |
celeron55 |
well, high-end cards don't work optiomally with the small batch sizes minetest uses |
| 22:13 |
Taoki |
Plus that I tested, and blocks do culling (hiding other things behind themselves if no important part shows). Backfaces should also be hidden (like the opposite side of blocks too) so I wonder why |
| 22:13 |
celeron55 |
on the other hand, they can't be enlarged at all for crappiest cards |
| 22:13 |
Taoki |
hmm |
| 22:14 |
Taoki |
What does the batch size do exactly? Perhaps it can be turned into a client setting, if it's about rendering |
| 22:14 |
celeron55 |
minecraft takes the route of just not supporting crappiest stuff, but i don't think we really can |
| 22:14 |
celeron55 |
Taoki: well, minetest renders the bulk node stuff as MapBlocks |
| 22:14 |
celeron55 |
that is the unit of rendering |
| 22:14 |
celeron55 |
and culling |
| 22:15 |
celeron55 |
and everything |
| 22:15 |
Taoki |
Well, there are some users who play MT on very old machines. Wouldn't wand them left out either. But it won't help if the performance isn't somehow optimized |
| 22:15 |
Taoki |
I see |
| 22:15 |
Taoki |
Can't MT add some way to improve rendering without breaking old cards? By using client settings if needed, to disable unsupported techniques |
| 22:16 |
celeron55 |
for higher-end cards, the meshes of for example 2x2x2 or 3x3x3 MapBlocks could be combined to one and rendered as such |
| 22:17 |
celeron55 |
it's not entirely trivial though |
| 22:17 |
Taoki |
That sounds nice. A client setting could allow adjusting a size for that too, and disabling if unsupported |
| 22:17 |
Taoki |
yeah. Will still be needed eventually so players on normal machines can have a reasonable draw distance |
| 22:18 |
celeron55 |
the meshes of single mapblocks need to be stored too because regenerating the mesh of a mapblock when a node updates is already slow enough; making it any larger would be just not viable; combining meshes should be fast though |
| 22:18 |
celeron55 |
i've thinked through this quite many times 8) |
| 22:20 |
Taoki |
Hope it does happen :) It is one thing that's a bit complex to do though... doubt I know how. Surprised I knew to add the models so well... mostly thanks to them using Irrlicht functions |
| 22:30 |
Taoki |
I think things are advancing fast, and that's important. The way I see things personally, MT will have to advance with a lot of new features and more stability. Otherwise people will eventually get bored, once the current lua API has reached its limits and most interesting mods have been made. |
| 22:30 |
Taoki |
Many who use it likely have the hope this is just the beginning... I do to personally :) |
| 22:33 |
Taoki |
Right now, it's still pretty simple and basic. Not because of limits in the lua api... just that there are mechanics missing from the code. Like better physics, detail, and a lot more. Obviously no one can do it all at once, coding is really hard. But I think it's important that in 1-2 years at most it will have the same solid feel MC has. Plus new features that being C++ and using Irrlicht will |
| 22:33 |
Taoki |
... allow for |
| 23:19 |
|
LunaVorax joined #minetest-delta |
