Time |
Nick |
Message |
04:39 |
|
neko259 joined #minetest-delta |
05:11 |
celeron55 |
Taoki|away: the only place where the filesystem is accessed is Server::fillMediaCache(); that is where the files are listed, filtered and read to memory |
05:11 |
celeron55 |
they are then sent to the client |
05:12 |
celeron55 |
when the client receives sound files, it puts them into the sound manager |
05:12 |
celeron55 |
and when it receives textures, it gives them to the TextureSource |
05:12 |
celeron55 |
those then store them into RAM |
05:12 |
celeron55 |
and will use them when asked for it |
05:14 |
celeron55 |
maybe if you used irrlicht's createMemoryReadFile() with the original filename when the meshes are received, irrlicht would use them directly from memory when you ask the file with the name |
05:18 |
jyfl987_ |
celeron55: cool irrlicht support read directly from memory? |
05:18 |
jyfl987_ |
i am considering to use lua for generating dynamic texture |
05:20 |
celeron55 |
Taoki|away: that you will need to do in Client::loadMedia() |
05:21 |
celeron55 |
Taoki|away: irrlicht has kind of it's own filesystem in memory, so you can "inject" a file into it with a name you want, with what i said above |
05:21 |
jyfl987_ |
celeron55: what's the goal of minetest-engine? and minetest-game |
05:41 |
|
LunaVorax joined #minetest-delta |
07:12 |
|
Calinou joined #minetest-delta |
07:21 |
|
Calinou_ joined #minetest-delta |
08:35 |
|
SpeedProg joined #minetest-delta |
09:46 |
|
PilzAdam joined #minetest-delta |
11:13 |
|
PilzAdam joined #minetest-delta |
11:44 |
|
rsiska joined #minetest-delta |
12:07 |
|
tango_ joined #minetest-delta |
12:19 |
Taoki |
For everyone who's interested in the progress of 3D models: http://minetest.net/forum/viewtopic.php?pid=48827#p48827 |
12:19 |
Taoki |
Pretty much, everything is done apart from the code to switch animations. I'll be getting to that next |
13:15 |
|
mrtux joined #minetest-delta |
13:33 |
|
PilzAdam joined #minetest-delta |
14:32 |
|
Calinou joined #minetest-delta |
14:48 |
celeron55 |
Taoki: #minetest is quite flooded so i'll ask here: where exactly are you stuck now= |
14:48 |
celeron55 |
?* |
14:48 |
Taoki |
celeron55: With the models... the situation is as follows: |
14:49 |
Taoki |
celeron55: With the obj format, I had no problem loading the mesh. I'm switching to b3d because it's an animated format. But now the code wants to load the mesh differently, and puts it through another function which it didn't with obj. That function apparently interprets eash format distinctively |
14:49 |
Taoki |
It's client.cpp line 808, bool Client::loadMedia(const std::string &data, const std::string &filename) |
14:50 |
Taoki |
obj meshes didn't go through there, but b3d ones do. Images and sounds are handled there, but each with their own specific codes I can't understand. Apparently, mesh would need its own interpreting code there too |
14:51 |
celeron55 |
did you read what i said... umm... this morning? |
14:52 |
celeron55 |
in here |
14:52 |
Taoki |
My main confusion is why the mesh format is making it go through a different function. What could be different between obj and b3d to do that? Worst of all is how to fix it, because that suddenly goes into very complicated matters I can't understand, and it's likely someone else will have to help there |
14:52 |
Taoki |
Just a sec, I think you replied to multiple things |
14:52 |
celeron55 |
through a different function? what do you mean by that? |
14:53 |
Taoki |
Ah, I read now. That seems related to this issue undeed |
14:53 |
Taoki |
celeron55: client.cpp line 808. For the obj format this function wasn't used, because it's filtered by extension and I didn't add anything there. |
14:53 |
Taoki |
What I meant |
14:54 |
Taoki |
Yes, apparently I didn't read what you said this morning yet, or at least in detail. It is the problem I'm running into |
14:54 |
celeron55 |
i think there can't have been any difference in the obj and b3d formats themselves in this regard |
14:55 |
Taoki |
celeron55: So in this case, for Client::loadMedia() I need to find the way to translate mesh files and put them in the memory. Same way sounds and images are |
14:55 |
celeron55 |
nothing is translated in any way at any point |
14:55 |
celeron55 |
it's just the raw file data that is moved around |
14:56 |
Taoki |
ok. Thought that because images and sounds appear to have different codes from each other to put files there. Hard to understand either |
14:56 |
Taoki |
As I tried inspiring myself from those |
14:56 |
Taoki |
But I thought MineTest handles it. If Irrlicht does, I need to poke more into its functions |
14:57 |
celeron55 |
yeah, they are handled specially due to... well, due to... well, due to because they need to have special handling (irrlicht doesn't support sound and textures need to be constructed into atlases and "texture modifiers" applied and whatever) |
14:57 |
celeron55 |
models should be able to go directly into irrlicht at this point |
14:57 |
Taoki |
That's good. Need to find its functions for loading stuff in memory then |
14:57 |
Taoki |
One mor major concern though: |
14:57 |
celeron55 |
i have never used irrlicht's internal filesystem like i described this morning |
14:57 |
celeron55 |
but it *should* work |
14:58 |
Taoki |
Does this means models can't be set or controlled by the server any more? eg: That I need to send animations to the client and apply them to the mesh there? Hope not, cuz then there's nothing I can do |
14:58 |
Taoki |
Or each client knows what happens with the model on the server |
14:58 |
celeron55 |
umm... |
14:59 |
celeron55 |
i am not too knowledgeable of what kind of information needs to move around for mesh animation |
14:59 |
celeron55 |
does the mesh file contain the animations? |
14:59 |
Taoki |
For textures and sounds at least... they're completely configured on the server right? The client just noticed them and their usage, and the caching is just for the file data |
14:59 |
Taoki |
yes |
15:00 |
celeron55 |
then you need to think in terms of how you need to have the animations trigger |
15:00 |
Taoki |
I'm aiming to make it LUA-triggered, but that's server side |
15:00 |
Taoki |
Irrlicht has the function to set a mesh to loop from frame X to frame Y |
15:01 |
celeron55 |
think of launching sounds - there are walking sounds that the client will play based on things it knows, and then there are custom-played sounds that the server tells the client to play |
15:01 |
Taoki |
Normally that would work, but I don't know how the code pipes and if maybe each client expects that done |
15:01 |
celeron55 |
just replace "sound" with animation and it is this case |
15:01 |
Taoki |
Ãd need to see first is it already knows to see the animation |
15:02 |
Taoki |
But, for obj format it already worked. And I think it's all server side |
15:02 |
celeron55 |
for server(mod)-selected custom animations you could just add an active_animation field into object properties |
15:02 |
celeron55 |
or something like that |
15:03 |
celeron55 |
for client-side triggered, it needs some more information... dunno how that'd exactly go |
15:03 |
Taoki |
First step is to get b3d meshes to render like obj ones did, then I must see how animations and other details would be sent |
15:05 |
celeron55 |
anyway, first get the basic mesh to transfer and load and then you can start thinking how to trigger animations |
15:06 |
celeron55 |
(i'd do it that way) |
15:07 |
Taoki |
celeron55: Ah, an interesting question would be: Currently, how does the client know what textures each voxel block has? Does the minetest code have to send the information to all clients, or does irrlicht automatically know to tell all clients about each block (and minetest code only needs to texture the blocks server-side)? |
15:07 |
celeron55 |
the server doesn't run any irrlicht code, except use some vector and other basic datatypes from the headers |
15:07 |
celeron55 |
and irrlicht doesn't do any networking |
15:08 |
Taoki |
ah |
15:09 |
Taoki |
Yet oddly, obj worked. Without me adding client settings (I think). Mesh displays and is textured |
15:09 |
celeron55 |
irrlicht basically just wraps opengl/direct3d, loads files and adds some 3d scene management and gui stuff |
15:09 |
Taoki |
Maybe that means I won't have to for b3d either |
15:09 |
celeron55 |
if irrlicht supports b3d, it should work just like obj |
15:09 |
Taoki |
That's good then |
15:10 |
celeron55 |
you don't need to transfer it over network for testing |
15:10 |
celeron55 |
(eventually that has to be done though) |
15:10 |
Taoki |
A mystery remains however: Why wasn't Client::loadMedia used for obj, but is now used for b3d. Because Client::loadMedia filters by extension, and obj was never there yet it worked |
15:11 |
Taoki |
Might mean obj managed to squeeze through there if not |
15:11 |
celeron55 |
if you didn't add any code to Client::loadMedia, that couldn't have mattered at all |
15:11 |
celeron55 |
you have some other problem |
15:11 |
Taoki |
ok. Interesting |
15:16 |
Taoki |
celeron55: I ran a test with an interesting result. I put a return; at the beginning of Client::loadMedia (disabied that function) and tried with the obj mesh. Although that cuased all textures and sounds to no longer be loaded, my mesh still displayed, and was properly textured. I imagine this means something bad ? |
15:17 |
celeron55 |
it means you don't transfer it over network |
15:17 |
celeron55 |
which is expected (to me, at least) |
15:18 |
celeron55 |
there's really *nothing* automatic in it; you either make it do something, or it doesn't do it 8) |
15:18 |
celeron55 |
(it may seem different from the modding standpoint though) |
15:19 |
Taoki |
ok. Need to figure where I get it to be transfrred over the network then |
15:20 |
celeron55 |
*if* you add it on the server-side media gathering file extension filter list, it will end up in Client::loadMedia |
15:20 |
Taoki |
In content.cao.cpp I simply do scene::IAnimatedMesh *mesh = smgr->getMesh(m_prop.mesh.c_str()); |
15:20 |
celeron55 |
in which you need to actually load it to irrlicht |
15:20 |
Taoki |
But yes, thinking about it that doesn't transfer anything over the network |
15:20 |
Taoki |
Plus it sets the model server-side. Then again everything else is set server-side so this part shouldf be separate from the sending |
15:21 |
Taoki |
Ah, it is added on that file list |
15:21 |
celeron55 |
that makes irrlicht first check it's internal filesystem cache for a file named m_prop.mesh, and if it isn't found, it checks the real filesystem |
15:21 |
Taoki |
I added models there already, so that should be sending it to the client. Which explains the b3d issue |
15:21 |
celeron55 |
you need to load it to irrlicht's in-memory filesystem with the wanted name in loadMedia |
15:22 |
celeron55 |
(or, that is one way to do it, which i would try) |
15:25 |
celeron55 |
(the alternative is to create a "mesh manager" or somehting like that to load the mesh into, and add an interface to it into IGameDef... and then make the CAO get the mesh from there, but it's overcomplicated if the mentioned way works) |
15:28 |
Taoki |
yeah. I first need to make Client::loadMedia get the mesh from memory. That should be it |
15:40 |
Taoki |
Asking on #irrlicht, but it's hard to explain all of the code in minetest. Apparently it's more minetestps-ecific code in Client::loadMedia |
15:41 |
celeron55 |
your situation is, from a generic standpoint: |
15:42 |
celeron55 |
- You have the data of a mesh file in one point of the program, which you want to insert into irrlicht for future loading |
15:42 |
celeron55 |
- You want to load the mesh afterwards multiple times in an another completely different place of the program |
15:43 |
Taoki |
Yeah. Issue is how I load the mesh in the client function. Which function gets it as a raw file or what it's needed as |
15:43 |
celeron55 |
and the reason for that is a custom network content distribution system |
15:44 |
celeron55 |
as i said, createMemoryReadFile() |
15:45 |
celeron55 |
if it works, that is how it works |
15:46 |
Taoki |
ok |
15:47 |
|
PilzAdam joined #minetest-delta |
15:47 |
celeron55 |
http://irrlicht.sourceforge.net/docu/classirr_1_1io_1_1_i_file_system.html#ac60a4b7912a7f2364426dc1aaf9bccae |
15:48 |
Taoki |
I'll try with that again |
15:48 |
celeron55 |
have you tried with it? |
15:48 |
celeron55 |
because i am not sure whether it works, and there are many things that can go wrong |
15:49 |
Taoki |
Yes, I already have it in my attempt, but thought more is needed |
15:49 |
Taoki |
io::IReadFile *rfile = irrfs->createMemoryReadFile(*data_rw, data_rw.getSize(), "_tempreadfile"); |
15:49 |
Taoki |
assert(rfile); |
15:49 |
Taoki |
But I think after that comes something to read and understand the file |
15:49 |
celeron55 |
the things that come to mind that can go wrong are: 1) it gets loaded AFTER getMesh() is used, 2) you use a different filename in getMesh() and it |
15:49 |
celeron55 |
you need to use the same name |
15:50 |
celeron55 |
that is how irrlicht knows it needs to get it for getMesh |
15:50 |
celeron55 |
also you need to set the last parameter to true |
15:50 |
celeron55 |
so that it will keep it in memory |
15:50 |
celeron55 |
AND you need to drop() the result |
15:51 |
celeron55 |
if all of those go right and my assumption about what the fileName parameter is supposed to do, then it will work |
15:51 |
Taoki |
Think I am getting closer to the source of it slowly, must mess with these settings a bit more |
15:51 |
celeron55 |
otherwise no |
15:52 |
celeron55 |
also i have noticed you have been using the full path in the mesh field in object properties; you want to change that to the filename without the path (or whatever goes to createMemoryReadFile) |
15:52 |
celeron55 |
if that is not the same, nobody will tell you |
15:52 |
celeron55 |
if it is the same, it might work |
15:54 |
Taoki |
I fixed that with RealBadAngel last night, he aaid it's the right way to do it. It seems odd to me too... I'll see if it gets fixed during this |
15:54 |
Taoki |
But to be sure I'm right: io::IReadFile *rfile = irrfs->createMemoryReadFile(*data_rw, data_rw.getSize(), "_tempreadfile"); ---- and ---- assert(rfile); Should be the only things needed in that client function |
15:54 |
celeron55 |
RealBadAngel basically outputs completely random things from his hands, was it code or discussion 8) |
15:55 |
celeron55 |
i once looked at some of his code |
15:55 |
celeron55 |
won't look anymore |
15:55 |
Taoki |
Was asking for help about how to do something |
15:55 |
Taoki |
Anyway, I guess pastebin can help. This is how I changed the function so far, and I'm not sure if I should continue the code somewhere for it to be complete: http://www.pasteall.org/36557 |
15:56 |
Taoki |
line 80 in that paste - Wasn't sure if mor eneeds tob e added there like its done for images |
15:56 |
celeron55 |
irrfs->createMemoryReadFile(*data_rw, data_rw.getSize(), "_tempreadfile", true); assert(rfile); rfile->drop(); |
15:56 |
celeron55 |
AND |
15:56 |
celeron55 |
replace "_tempreadfile" with the name you will be supplying to getMesh() |
15:57 |
celeron55 |
which is called filename in there |
15:57 |
Taoki |
ah, right |
15:57 |
celeron55 |
you don't need to load the model at all in there |
15:58 |
celeron55 |
remove everything after // Read model |
15:58 |
celeron55 |
you have nowhere to put it |
15:58 |
Taoki |
Yes, correct. |
15:58 |
celeron55 |
the only thing you can do is hope irrlicht will store it as filename somewhere inside itself |
15:59 |
celeron55 |
so that you can get it back by referring to filename in the CAO |
16:00 |
Taoki |
Did it like this now: http://www.pasteall.org/36558 Am going to compile that and test it |
16:00 |
Taoki |
After replacing _tempreadfile, forgot to do that and doing it now |
16:01 |
celeron55 |
also, don't log it as "Client: Attempting to load model ", rather something like "Client: Storing model into irrlicht: " |
16:02 |
celeron55 |
good logs are very helpful |
16:02 |
Taoki |
Weird, minetest crashes once i try to connect to the server |
16:02 |
Taoki |
sure |
16:02 |
celeron55 |
to the assertion? 8) |
16:03 |
Taoki |
Looking at the output |
16:03 |
Taoki |
ouch, big crash log. Just a sec |
16:03 |
celeron55 |
i hope it's crashing in the code using getMesh() with an unknown filename |
16:03 |
Calinou |
(totally irrleevant, feel free to ignore) talking about logs, I think debug.txt should be disabled by default, it writes a lot to disk when it's big and takes space |
16:04 |
Taoki |
http://www.pasteall.org/36559 |
16:05 |
Taoki |
^ crash backtrace |
16:05 |
celeron55 |
run it in gdb |
16:07 |
Taoki |
ok, doing so now... |
16:08 |
Taoki |
celeron55: http://www.pasteall.org/36561 |
16:09 |
celeron55 |
hmm, what does the gdb command "bt" do after a crash like that? |
16:10 |
Taoki |
celeron55: Continued right from that last paste: http://www.pasteall.org/36562 |
16:11 |
celeron55 |
you appear to not run a debug build, you might want to do cmake . -DCMAKE_BUILD_TYPE=Debug |
16:12 |
celeron55 |
that'd make it give line numbers rather than just functions |
16:12 |
celeron55 |
aaanyway |
16:12 |
celeron55 |
it's quite obvious that ->drop() kills it |
16:12 |
celeron55 |
i don't understand why though; can you paste the code as how it is now? |
16:12 |
Taoki |
ill try without that |
16:12 |
Taoki |
sure, |
16:12 |
celeron55 |
do you call drop() twice? |
16:13 |
|
jin_xi_ joined #minetest-delta |
16:13 |
Taoki |
celeron55: http://www.pasteall.org/36563 And not that i know of |
16:13 |
celeron55 |
"filename" lol |
16:14 |
celeron55 |
you are either trying too fast or not thinking |
16:15 |
Taoki |
Yeah, I don't know how that happene... |
16:15 |
Taoki |
I get very tired when spending hours on one issue like wtih :P |
16:15 |
Taoki |
I will fix it, sorry |
16:15 |
celeron55 |
that doesn't cause the crash but... i meant you have to use the filename variable |
16:15 |
Taoki |
Yes the "" were a typo |
16:16 |
celeron55 |
just remove the rfile->drop() line for now, irrlicht is probably broken or irrlicht's documentation is broken |
16:17 |
celeron55 |
i actually love figuring out crap like this; it's sad other people don't, and also it happens way too rarely 8D |
16:18 |
Taoki |
ok, now it starts and no more errors. But the model doesn't render either. The causes for that can be a different story |
16:18 |
celeron55 |
then check that the filename is the same in both places |
16:19 |
Taoki |
I'll try with the filename only. In LUA I still use mesh=modpath.."/models/player.b3d", |
16:19 |
celeron55 |
hmm... shit |
16:20 |
celeron55 |
i just started browsing irrlicht's documentation |
16:20 |
celeron55 |
eh |
16:20 |
celeron55 |
source code, i mean |
16:20 |
celeron55 |
it seems the filename does nothing in that |
16:20 |
Taoki |
the path was good, now it gives werros it doesnt see the mesh |
16:20 |
Taoki |
ah |
16:21 |
Calinou |
Taoki: what if we want model replacements? |
16:21 |
Taoki |
Calinou: Model replacements? |
16:21 |
Calinou |
we lack sound replacements already :| (or, is it possible to use sounds/all?) |
16:21 |
Calinou |
eg. put textures in textures/all |
16:21 |
Taoki |
Calinou: Ah. My script allows setting models to anything easily |
16:21 |
Taoki |
I can get to that later |
16:22 |
Taoki |
celeron55: How else should I attempt to change that code? |
16:22 |
celeron55 |
so this looks like a mesh manager needs to be written |
16:22 |
Taoki |
ok |
16:22 |
Taoki |
So there's no way to get the file from that emmory stream? |
16:23 |
celeron55 |
i'll look at the scenemanager end of this, wait for a bit |
16:23 |
Taoki |
celeron55: I need to go now for 1-2 hours, but I'm still here and will read when I get back |
16:23 |
celeron55 |
well, in fact there is a trivial spaghetti solution to this |
16:23 |
Taoki |
If it requires a whole new mesh manager and bigger code, it means I need to find someone else to take it from here sadly |
16:23 |
celeron55 |
actually no |
16:23 |
celeron55 |
it isn't rivial.... forget that 8D |
16:24 |
celeron55 |
a mesh manager sounds way more complicated than it is |
16:25 |
Taoki |
I need to go, will read when I get back. If a mesh manager is needed, that's bad... will see who can look into it |
16:25 |
Taoki |
Ah, before I go, |
16:25 |
Taoki |
celeron55: All my changes can be read here if it helps, and it's also the GIT branch the code is on: https://github.com/MirceaKitsune/minetest/compare/models |
16:25 |
celeron55 |
i'll think of a reasonable solution while you're away |
16:26 |
Taoki |
Thanks, I'm glad someone is helping. I'll push those useless changes on GIT too so it's easier |
16:27 |
celeron55 |
apparently irrlicht's scene managers contain a thing called "mesh cache" |
16:28 |
Taoki |
Pushed. https://github.com/MirceaKitsune/minetest/compare/models |
16:28 |
celeron55 |
CMeshManager->getMesh() first looks in it's mesh cache and only after that from the real filesystem |
16:28 |
celeron55 |
and you can actually push meshes directly into the cache |
16:29 |
Taoki |
But yeah, https://github.com/MirceaKitsune/minetest/tree/models is the code and https://github.com/MirceaKitsune/minetest_game/tree/models is the data with script and mesh |
16:29 |
Taoki |
Would help if you could add to the code in case you find a better way, I'm barely understanding any of it any more. |
16:29 |
Taoki |
Anyway BRB now, thanks a lot for the help so far |
16:30 |
celeron55 |
so... |
16:31 |
celeron55 |
1) load the mesh from the data in loadMedia() |
16:32 |
celeron55 |
2) somehow get the SceneManager from somewhere... i can't immediately figure out what is the right "data path" for making that happen |
16:32 |
celeron55 |
3) smgr->getMeshCache()->addMesh(filename, loaded_mesh); |
16:32 |
celeron55 |
THEN smgr->getMesh(filename) will work in the CAO |
16:35 |
celeron55 |
(2) is done like this: video::ISceneManager *smgr = m_device->getSceneManager(); |
16:37 |
celeron55 |
so there it is; i'll leave it for Taoki to try (should be simple enough) |
16:50 |
|
MiJyn joined #minetest-delta |
17:16 |
|
PilzAdam joined #minetest-delta |
17:25 |
|
neko259 joined #minetest-delta |
17:51 |
|
Anchakor_ joined #minetest-delta |
17:58 |
|
PilzAdam joined #minetest-delta |
17:59 |
Taoki |
celeron55: Back. Solving some non-minetest matters first then getting to testing that |
18:00 |
Taoki |
celeron55: If however we can't solve it for now, I'd also like to know: Is there any way to NOT load the mesh through the data stream and use the direct paths for both server and client? That is a very bad idea... but if we don't figure out the data stream, I still wish to finish the animation system and have a way to test it. In this case I could leave the stream for the last |
18:00 |
Taoki |
As functionallity shouldn't change no matter where it's added from |
18:01 |
celeron55 |
you can just load it like you were doing for the .obj file before |
18:01 |
|
MiJyn joined #minetest-delta |
18:01 |
celeron55 |
but i don't see why the above would not work |
18:07 |
Taoki |
ok. So it works the same as the obj file did... means the reason it's not being rendered is a different one |
18:44 |
Taoki |
celeron55: http://www.pasteall.org/36567 This how the code looks now, and it compiles. I'll try to add the getMesh part in CAO and see if that changes |
18:45 |
Taoki |
I wonder what I should do about the texture though, if that is sent through the stream too |
18:45 |
Taoki |
Ah wait, it's already there in CAO. So it should work already if it does |
18:49 |
Taoki |
ok, now it crashes again: Could not load mesh, because file could not be opened: : player.obj |
18:49 |
Taoki |
^ output in console for minetest client when the crash happens |
18:53 |
|
AllegedlyDead joined #minetest-delta |
18:54 |
celeron55 |
scene::IAnimatedMesh *mesh = smgr->getMesh(filename.c_str()); |
18:54 |
celeron55 |
you can't do that in loadMedia() |
18:55 |
celeron55 |
the file is in the data parameter of loadMedia |
18:55 |
celeron55 |
it does not exist anywhere else |
18:55 |
Taoki |
ahh |
18:56 |
celeron55 |
you need to make an io::IReadFile of it like for images |
18:56 |
celeron55 |
and... umm... |
18:57 |
celeron55 |
yeah, you can then stuff that into smgr->getMesh |
18:58 |
celeron55 |
from which you get the mesh, which you then proceed to feeding to the mesh cache... ehm |
18:59 |
celeron55 |
actually, if you supply the correct filename to the memory file, SceneManager will already cache it when you getMesh() it the first time from it :-D |
19:00 |
celeron55 |
this is quite unintuitive to design |
19:02 |
Taoki |
Niiice, seems to be working now |
19:02 |
Taoki |
For the obj file at least |
19:02 |
Taoki |
But, how do I know it's being read from the stream this time and not the old direct path? |
19:02 |
Taoki |
Actually, I think the answer is to use the filename directly |
19:02 |
celeron55 |
as long as you are giving getMesh() only a flat filename without any path, that is likely |
19:03 |
Taoki |
not yet, trying now... |
19:04 |
Taoki |
yep, it surely works now. Awesome stuff :D |
19:04 |
celeron55 |
simple things, but not that simple to get right |
19:06 |
Taoki |
This felt very complex. But, I got it so it's good |
19:07 |
Taoki |
One little detail: Should I mesh->drop() after I get the file through cache? |
19:09 |
Taoki |
eh... the textures array isn't sent through though. Wonder what I did wrong there... will have to check now that I have a basic understanding of how it all works |
19:29 |
jin_xi |
wow, this is cool. nice work Taoki and celeron55. its textured also! sweet |
19:30 |
Taoki |
jin_xi: Yes. Now I'm getting to the part of adding animations, which will be tricky but if things keep going well it will be ready in a few days at most |
19:30 |
Taoki |
And aniated players will be possible |
19:40 |
jin_xi |
what about mobs? |
19:46 |
celeron55 |
players and mobs are basically the same thing |
19:51 |
Exio |
entities? :P |
19:52 |
Taoki |
Fron what I know, anything the player can be set to draw as any other entity can. I looked at the code and I'm pretty sure it's the case |
19:52 |
Taoki |
So yet. You can set the player to render as a voxel if you want, or you can set a voxel to render as a mesh (which is normally bad, but in some cases you might want that) |
19:53 |
Taoki |
So you can expect that in that whole blocky world, you'll smoeday come across a high-poly vase or chair or something :) |
19:54 |
Taoki |
Or that you'll see a player of the detail of an Unreal Tournament character. Imagine that XD |
19:54 |
Taoki |
I'm not sure yet if I might try to port Erebus from Xonotic ;) |
19:55 |
Taoki |
Meaning this guy: http://pics.nexuizninjaz.com/images/rebu6x8rmgfvijtlqls.jpg |
19:55 |
Taoki |
(and yes that's a GPL model). Of course not by default, but as a custom mod on servers :) |
19:56 |
Taoki |
Just saying it will be possible after the code is ready |
19:56 |
Taoki |
Not sure if MineTest has directional lighting and such however... at least yet |
19:58 |
celeron55 |
minetest's lighting is pretty crudely implemented |
19:58 |
celeron55 |
that is, it doesn't use 1) any shaders, 2) even any of the fixed pipeline |
19:59 |
celeron55 |
it just sets vertex colors and that is it |
19:59 |
Taoki |
celeron55: Any plans to make it directional? Doesn't mean to add dynamic shadows, but simple directional lighting based on sun and moon direction. That would be really awesome |
19:59 |
celeron55 |
i have zero plans |
19:59 |
Taoki |
and since we use Irrlicht, easy too. Might be a few lines of code |
19:59 |
celeron55 |
for anything |
19:59 |
Taoki |
ok |
20:00 |
Taoki |
It's on my mental list to look into this too. Later... the models are important for now until they're ready |
20:00 |
celeron55 |
(except putting somebody else in charge of plan-making 8)) |
20:01 |
celeron55 |
the problem is, hardware lighting does not fit well at all with the no-lighting vertex color setting stuff |
20:01 |
celeron55 |
the brightnesses are almost random |
20:01 |
celeron55 |
you need to do one or another |
20:02 |
Taoki |
Yeah, will have to see how it looks first of course |
20:02 |
celeron55 |
to mix voxel lighting and traditional lighting, you basically need to write a custom shader |
20:03 |
Taoki |
Ahhh... seems Blender has native support for the .x model format (directX). I wonder if the format is free otherwise... Irrlicht supports it |
20:03 |
Taoki |
as b3d seems to be giving me a hard time |
20:03 |
celeron55 |
which tends to make many of our supported old-ass GPUs really struggle with the huge polygon count |
20:03 |
celeron55 |
(huge for them, laughable for recent stuff) |
20:03 |
Taoki |
I see. Thought we could just set lighting to directional and it'd work :P |
20:11 |
Taoki |
OMG! I got a mesh to animate :D Really sweet |
20:11 |
Taoki |
Not code-controlled yet, it triggered on its own |
20:11 |
Taoki |
x format |
20:15 |
celeron55 |
you can probably get something somewhat reasonable out of it by setting a directional light... but it requires some trickery to make it behave sanely in caves and so |
20:16 |
Anchakor |
I think these days the way to do lighting is to use shadow volume shaders |
20:16 |
Taoki |
celeron55: Yes. It will require an amount of ambient light (existing light) as well as directional light |
20:16 |
Taoki |
BTW. How are torches currently doing it? Aren't they a normal directional light? |
20:16 |
celeron55 |
Taoki: minetest has a special voxel lighting system |
20:17 |
Taoki |
makes sense |
20:17 |
celeron55 |
they are far from what you imagine 8) |
20:17 |
Taoki |
I can understand then :P |
20:17 |
celeron55 |
Anchakor: that means dropping for example my laptop out of the supported HW |
20:18 |
celeron55 |
(except for view distances of like 8 nodes) |
20:18 |
Anchakor |
celeron55: I know, I think both the very simple voxel model should be supported along with the new shader shizzle |
20:18 |
Anchakor |
(if it even comes into existence) |
20:18 |
celeron55 |
that is probably quite complicated |
20:19 |
Taoki |
Yeah, a configuration setting would toggle both |
20:19 |
Taoki |
But I can imagine it's complicated |
20:20 |
celeron55 |
for example the voxel lighting makes servers do quite much more work (at least at map generation time, but at other points too), and many high-end people would want to take it out |
20:21 |
Taoki |
What I don't understand is: As I worked with the mesh code, I'm seeing that voxels are vey similar to meshes. Only that they're cubes where the surfaces and form is created by the code, not exported from Blender or something. So I'm thinking that theoretically, the same lighting technique could be applied |
20:21 |
Anchakor |
well worst case (aka if it is implemented rather badly) for all people there would be some redundancy in transfer & processing |
20:21 |
Taoki |
It would get messy at first, but theoretically |
20:22 |
celeron55 |
yeah sure, you can disable the voxel lighting and just use plain old directional light and set light sources to the nearest torches or so |
20:22 |
celeron55 |
it looks completely different and there is no way to for example make caves dark without shaders |
20:23 |
celeron55 |
except... well, *everything* is possible with enough trickery, but whether irrlicht exposes enough of the underlying graphics APIs is an another thing |
20:23 |
Taoki |
But can't you also set simple ambiental lighting? Like a minimal texture brightness, so lack of lighting doesn't mean complete blackness |
20:24 |
Taoki |
That way caves have no lighting, until you place a torch that is |
20:24 |
celeron55 |
that doesn't change the fact that everything is lit exactly the same |
20:24 |
celeron55 |
if you have sun outside, sun will be in caves too |
20:24 |
Taoki |
Ahhh, damn. I think I got the issue |
20:24 |
Taoki |
The sun would shine through objects |
20:24 |
Taoki |
Yes |
20:24 |
Taoki |
And the only way to stop that woud be... *drum roll* dynamic shadows :D |
20:25 |
celeron55 |
not exactly |
20:25 |
celeron55 |
with some backbuffer rendering and tricks it's completely doable |
20:25 |
celeron55 |
but not with irrlicht |
20:25 |
Anchakor |
even with dynamic shadows, if the top of the cave is not yet loaded it would appear as open to the algo |
20:25 |
Taoki |
Yes. But a new shader would be needed to check if another block is in the way |
20:25 |
celeron55 |
no |
20:25 |
celeron55 |
i could do a reasonable implementation without shaders |
20:25 |
Taoki |
Dynamic shadows are something I plan to add separately, and as an optional effect only |
20:25 |
celeron55 |
with some aid from a simpler voxel lighting than we currently have |
20:26 |
Taoki |
Sounds nice |
20:26 |
celeron55 |
but it's not doable with irrlicht |
20:26 |
celeron55 |
only plain opengl |
20:26 |
Anchakor |
implementation of what? sun lighting? |
20:26 |
Taoki |
meh, that is sad |
20:26 |
Taoki |
Wonder what is with Irrlicht. Must be some alternative somewhere |
20:26 |
celeron55 |
Anchakor: implementation of lighting that would fit models and the voxel world well together |
20:26 |
celeron55 |
without shaders |
20:27 |
Anchakor |
so software implemetation - on CPU |
20:27 |
Taoki |
celeron55: If we go the other way around though, how hard would it be for your lighting system do support directional lighting? So instead of making everything in an area bright, see where the source of the light is, and brigthen or darken based on face orientation |
20:28 |
Anchakor |
I don't think that would be a good alternative for the older machines |
20:28 |
celeron55 |
Taoki: not doable |
20:28 |
Anchakor |
it's not like they got shitty GPU but fast CPU |
20:28 |
Taoki |
For voxel cubes that would be easier I think cuz there's not a lot to calculate. The more "straight" or "parallel" a face is to the light, the brighter |
20:28 |
Taoki |
ah, ok |
20:28 |
celeron55 |
very expensive for voxels, even more expensive for high-poly models |
20:29 |
Taoki |
For models yeah. For voxels, well there are 6 faces at most since they're cubes. You'd only calculate how well each is facing the source of the light |
20:29 |
Taoki |
But I wouldn't know too well |
20:29 |
|
zweipktfkt joined #minetest-delta |
20:30 |
celeron55 |
if somebody wants to reimplement everything; go for it; but i do not wish to use my free time for that |
20:30 |
celeron55 |
i have other projects and want to leave minetest to the hands of people with more ideas for it |
20:32 |
Taoki |
sure |
20:32 |
Taoki |
Just curious: Are any of them other FOSS games? |
20:32 |
celeron55 |
of course i'm occasionally hanging around like now, but i don't want to start implementing a new rendering/map/object/whwatever systems |
20:33 |
celeron55 |
-a |
20:33 |
Taoki |
Yeah. Wasn't sure if you meant other minetest projects or other projects apart from minetest |
20:33 |
celeron55 |
not at the moment at least |
20:33 |
Taoki |
ok |
20:34 |
celeron55 |
they are quite low-profile and obscurish projects 8) not something to easily gain such popularity as minetest has done |
20:35 |
Taoki |
yeah. MineTest is quite an asweome thing :) |
20:37 |
celeron55 |
most of the other things i do in my free time are more indie gamedev minded, not so much FOSS... i just start making different things and see if i get inspired to continue |
20:38 |
celeron55 |
minetest is one of many |
20:38 |
celeron55 |
i am no sure if there's something else to it than just releasing it under the GPL and making a website |
20:39 |
celeron55 |
and it being a minecraft clone at the time when minecraft clones were rare |
20:39 |
Taoki |
nice |
20:39 |
Taoki |
I work on other FOSS games sometimes. Most very rarely. The one I contributed a lot to over the years is Xonotic, previously called Nexuiz |
20:39 |
Taoki |
Written in QuakeC so was easy to learn |
20:39 |
Taoki |
Helped me a lot to learn programming over the time. And now MineTest helps with learning actual C++ |
20:40 |
celeron55 |
i mean, it's VERY hard to find such a spot-on new niche now compared to minecraft clones back then |
20:41 |
Taoki |
MT is the best MineCraft-like game. Followed byterraria I think |
20:41 |
Taoki |
Terraria has much more beaufiful and fantascit environments. But is not as cunfogiurable and far as MT |
20:41 |
Taoki |
arely has some ite,s, IIRC only creative mode too |
20:41 |
Taoki |
*barely |
20:42 |
celeron55 |
a funny thing is that there are many minecraft-like voxel games around, almost all of which use more cutting edge rendering stuff and so on |
20:42 |
celeron55 |
but people just don't seem to like them |
20:42 |
Taoki |
Can confirm with Terraria. I don't like them because they're too simple so far. No items, nothing to do... not even multiplayer |
20:43 |
celeron55 |
i don't like to compare MT or MC with terraria |
20:44 |
celeron55 |
i guess it's just because it's 2D |
20:50 |
celeron55 |
i actually am working on a project right now that would accomodate more devs fairly easily |
20:50 |
celeron55 |
but i want to keep it not open source |
20:53 |
Taoki |
In my case, I like open-source too much to feel ok with not open-sourcing sometihng I do :P |
20:53 |
Taoki |
Even art (which I'm bad at) I release under a CC license. Just my like with everything I do being free, but it doesn't mean it's necessary all the time |
20:54 |
celeron55 |
i generally open source everything i do except not all games |
20:55 |
celeron55 |
well, i can't even say that yet because the games i haven't released as open source wouldn't be ready for release anyway |
20:56 |
celeron55 |
they are basically prototypes that could grow with the right inspiration |
20:56 |
Taoki |
I guess it's safe to say that for quite some time, I've been planning to make an open-source project, very related to voxel worlds. Something betwen MineCraft and Second Life. But to get a better image of what I dreamed of, imagine MineTest but with smooth terrains, high quality textures (1024 x 1024), all items as high-poly meshes, and basically graphics like UT3 / GTA4/ Skyrim). |
20:56 |
Taoki |
AND, smooth terrains, not blocky. Which requires marching cubes |
20:57 |
celeron55 |
sounds like a million hours of work 8) |
20:57 |
Taoki |
I already have some small code which doesn't do anything setup. My intent was to do it with OGRE and PolyVox. I'm unsure at this day if MineTest will ever have the features to allow me to do what I'm planning instead |
20:57 |
Taoki |
yeah |
20:58 |
Taoki |
Minetest actually would. But I'd need new features to get it where I want, which would be difficult and will probably take years. Not sure if all of them would be accepted either |
20:58 |
Taoki |
eg: You'll kill me, but I eventually want to add BulletX physics :P Doesn't mean they get merget to trunk of course, but I'd like that |
20:58 |
celeron55 |
i won't kill you for that |
20:58 |
Taoki |
Made a topic about it too. Of course it's not a priority or anything |
20:59 |
celeron55 |
but it's a lot of work compared to how much people expect to gain from it |
20:59 |
Taoki |
yeah, just that some might be unsure with the idea especially because it can take a lot of resources |
20:59 |
Taoki |
true |
21:01 |
Taoki |
Ahhh. Someone mentioned that the LUA API doesn't allow responding to key handlers yet. Is that true? Might need a way to implement that for player animations |
21:01 |
Taoki |
Since my aim is to have LUA set a new animation / frame range when pressing a new key |
21:01 |
Taoki |
Don't wanna hard code them, especially since each player mesh can have different animation ranges. |
21:02 |
celeron55 |
i would love to see a "minetest re-incarnation", keeping it as simple as possible, made with C, plain simple TCP and with almost nothing fancy except the qualities gotten from it being light per voxel |
21:02 |
celeron55 |
i have a base of a game that could be used as a base for that kind of thing too |
21:03 |
celeron55 |
i would love to make it but i love more making something different |
21:04 |
celeron55 |
if it'd make it, i'd be stuck at making it for at least months, taking out from something truly interesting and educative |
21:05 |
celeron55 |
and possibly something that could make some money sometime |
21:05 |
|
LunaVorax joined #minetest-delta |
21:06 |
celeron55 |
aaaanyway |
21:06 |
celeron55 |
Taoki: handling keys like that in server-side Lua would introduce quite a bit of lag to it |
21:07 |
celeron55 |
lag is a tricky question; there are always exactly two options: 1) allow lag to exist, making things simple, 2) fight lag with complicated systems |
21:07 |
Taoki |
I aim to animate everything from LUA. But how do I detect that the player is mining, walking forward or back or strafing, and all that |
21:08 |
celeron55 |
you'll want to detect those in the CAO |
21:08 |
celeron55 |
otherwise it'll just going to be laughably laggy |
21:08 |
celeron55 |
no options |
21:08 |
Taoki |
Ah. And animate players from the code? |
21:09 |
celeron55 |
what does that mean |
21:09 |
Taoki |
Must I trigger player animations for walking, mining, etc. from the code? Like I said I'd rather do it in LUA if it's possible and not laggy |
21:09 |
celeron55 |
where are you going to do it if not in code? 8D |
21:10 |
celeron55 |
ah you mean C++ vs. Lua |
21:10 |
Taoki |
Wanted to do it in LUA |
21:10 |
Taoki |
yeah |
21:10 |
Taoki |
I'd like LUA to trigger animations |
21:10 |
Taoki |
But for players, it would need to know what the player is doing |
21:10 |
Taoki |
At least for walking and mining |
21:11 |
Taoki |
If I can't get the pressed keys LUA-side, maybe I can use other factors. eg: detect if player has veolcity and touches the ground |
21:11 |
Taoki |
If the player is moving horizontally and touches the ground, I can get direction versus rotation and determine if he's strafing or walking forward or walking backward |
21:12 |
celeron55 |
i would define in the object properties what the waking animation is, what the mining animation is and so on (and allow defining "no animation" too) |
21:12 |
celeron55 |
for the sake of getting rid of lag |
21:13 |
celeron55 |
walking* |
21:13 |
Taoki |
Those must be defined in LUA, since each custom model can have different animation ranges |
21:14 |
Taoki |
Cut on the C++ vs LUA side, the only C++ code I want to add is the one that gets the start and end frame from a LUA command and executes them. I'd like LUA to fully decide when and how to run them |
21:14 |
Taoki |
Which can be tricky |
21:15 |
celeron55 |
ugh... i don't really want to even suggest anything; this is so horribly nontrivial |
21:15 |
Taoki |
My plan was / is to make start and end frames an object property like mesh is, this makes most sense. But then, I need a LUA function to detect what the player is doing so it knows how to switch |
21:15 |
Taoki |
ok |
21:16 |
Taoki |
I'm curious if currently, LUA can at least detect a player's speed and if the player is mining a block |
21:16 |
celeron55 |
the latter it can't |
21:17 |
celeron55 |
you'd need to begin with making it know those, somehow |
21:17 |
Taoki |
ok. If it can detect speed and if the player touches the ground, walk animation is easy |
21:17 |
Taoki |
yeah |
21:19 |
Taoki |
celeron55: I wonder how laggy this would be: Whenever the player presses a key, a LUA function is called once (also sending it that player). Same when un-pressing it. But otherwise not loop anything or constantly check tihngs |
21:20 |
celeron55 |
there is the network in between, to both ways |
21:20 |
celeron55 |
and also the server's execution tends to be somewhat choppy |
21:20 |
Taoki |
ah, yes |
21:20 |
celeron55 |
(sometimes waiting for some slower thing for hunderds of milliseconds) |
21:21 |
celeron55 |
(or in the case of current map generator mods, many seconds) |
21:21 |
Taoki |
If the animation updates a little more slowly that's ok. But I hope it wouldn't slow down or lag the server or cause other problems |
21:21 |
Taoki |
I'd still rather get the keys... feels like the best implementation. It can be a bit slower... later there might be ways to improve it |
21:24 |
celeron55 |
oh well, just do it somehow... it can't be made perfectly the first time anyway |
21:25 |
|
donaldr3 joined #minetest-delta |
21:26 |
celeron55 |
i have talked too much tonight 8) |
21:26 |
Anchakor |
you can make up to it in following months |
21:26 |
Taoki |
sure |
21:27 |
Anchakor |
celeron55: btw is the latest version of minetest which is coded solely by you can could be used under much more liberal license ten GPL available somewhere? |
21:27 |
celeron55 |
just take your own initiative and talk with other devs than me 8) |
21:28 |
celeron55 |
Anchakor: i don't think it is specially marked in any way |
21:28 |
celeron55 |
i have said it in multiple e-mails and multime times in IRC though |
21:29 |
Anchakor |
ok I think I got the version number somewhere in my logs |
21:29 |
Anchakor |
though if I were ever to do something close to minetest I would probably code it from the scratch :) |
21:30 |
celeron55 |
i think the commit is called "extended content type range" |
21:30 |
Anchakor |
when you moved to git, were the hg commits preserved? |
21:30 |
celeron55 |
90d793f8f369bf1431d7a915198cd49b98bbe2d7 |
21:30 |
celeron55 |
they are all there |
21:31 |
celeron55 |
(you can thank tango_ for that) |
21:31 |
celeron55 |
the repo literally contains all commits ever made to minetest |
21:32 |
Anchakor |
cool thanks |
21:45 |
Taoki |
This is weird. In LUA, you register functions to several C++ hooks. For exmaple, minetest.register_on_punchnode. But if I grep the word register_on_punchnode in the code, it does not exist. WTF? |
21:48 |
celeron55 |
it's implemented in Lua 8) |
21:48 |
celeron55 |
grep it in builtin/ |
21:49 |
celeron55 |
the registered things will end up in registered_punchnodes or something like that, which will be found in C++ |
21:49 |
celeron55 |
registered_on_punchnodes* |
21:49 |
Taoki |
Ah. So the hooks are in another source folder than src? |
21:49 |
Taoki |
I'll look |
21:52 |
celeron55 |
so here's the unarguably best picture of today: http://c55.me/random/2012-10/natsikarhu2.jpg |
21:53 |
Taoki |
ahhh, one of those things that are probably hilarious and I don't get :P |
21:54 |
celeron55 |
it's utter nonsense with style |
21:55 |
celeron55 |
me sleeps -> |
22:03 |
Taoki |
night |
22:14 |
Taoki |
Anyone know if ther's a way for LUA to read settings from minetest.conf? |
22:17 |
Anchakor |
lol that pic has so many funny things |
23:52 |
|
Octupus joined #minetest-delta |