| Time |
Nick |
Message |
| 00:00 |
Exio |
wut? |
| 00:00 |
hmmmm |
still can't really come up with a solid way to add decorations that would be cut off |
| 00:02 |
hmmmm |
i don't want to use that overly-complicated method i was talking about yesterday, so i said i'd just queue the position to get added later, outside of makechunk |
| 00:03 |
hmmmm |
so do i have a separate decoration queue as part of emergemanager? |
| 00:03 |
hmmmm |
it'd have to be thread-safe, all mapgens share this same thing |
| 00:04 |
hmmmm |
and perhaps one decoration will be done at a time, or else i'll have to find a way to not have them run on areas with intersecting blocks |
| 00:07 |
Exio |
why is that needed? |
| 00:10 |
Exio |
(as, wouldn't be doing the decorations just in the same place to where they "are done" actually? - the lua on_generate / the v6-trees, the caves, etc?) |
| 00:13 |
hmmmm |
lua on_generate is completely different and has nothing to do with this |
| 00:13 |
Exio |
but i mean, the place where it "runs" |
| 00:13 |
hmmmm |
trees and caves aren't going to be taller than a chunk |
| 00:14 |
hmmmm |
the place where it "runs" is the most "horrible" place possible |
| 00:14 |
hmmmm |
when on_generate runs, the rest of the server just pretty much stops |
| 00:16 |
|
Taoki joined #minetest-dev |
| 01:06 |
hmmmm |
ugh man |
| 01:06 |
|
dexter0 joined #minetest-dev |
| 01:07 |
hmmmm |
so what do you guys think is a better idea? recalculate the lower adjacent chunk's positions and see if anything would've got cut off, and then place the rest of that decoration |
| 01:07 |
hmmmm |
or have those decorations that would be cut off added to a queue and placed in their own specially-sized voxelmanipulator |
| 01:53 |
|
jojoa1997 joined #minetest-dev |
| 02:26 |
RealBadAngel |
imho own sized manipulator |
| 02:32 |
hmmmm |
you do realize what i'd need to do for that to happen, right? |
| 02:33 |
VanessaE |
tear your hair out? ;) |
| 02:33 |
RealBadAngel |
but if that would overcomplicate things im fine with other solution |
| 02:33 |
hmmmm |
after finishBlockMake, i'd have to loop through each decoration that didn't fit (which is basically all of the l-systems trees), lock environment, emerge the blocks, unlock environment, generate the tree, lock environment again, blit back, unlock environment, bladdy blah, bladdy blah |
| 02:34 |
hmmmm |
and another thing is that it'd be disjoint from the map generator |
| 02:34 |
RealBadAngel |
for own blit i had trees in mind ofc |
| 02:35 |
hmmmm |
the only advantage of this approach is that it's simpler |
| 02:36 |
hmmmm |
and that you don't need to duplicate computations |
| 02:37 |
hmmmm |
the disadvantages otoh, is that it locks more and it's outside of the mapgen, and lighting computations would be duplicated |
| 02:38 |
hmmmm |
another advantage is that i wouldn't have to make a separate case for horizontally out-of-bounds structures |
| 02:39 |
hmmmm |
humungous buildings would therefore be possible, the only problem is that it'd be shitted up by dirt being placed on top of it |
| 02:40 |
hmmmm |
and let's be honest |
| 02:40 |
hmmmm |
it's much harder to figure out what's part of a discretely placed structure and actual map |
| 02:40 |
hmmmm |
this all goes back to the fundamental "it's not about what was placed, it's about why it was placed" issue |
| 02:45 |
RealBadAngel |
so i would have to check if the tree will fint in generated area? |
| 02:45 |
RealBadAngel |
*fit |
| 02:46 |
hmmmm |
wait, what? why would you be doing anything |
| 02:46 |
RealBadAngel |
to make sure it will be generated whole, not cut |
| 02:47 |
RealBadAngel |
but if you mean treegen doesnt bother about it, then pick the way which is better |
| 02:47 |
hmmmm |
are you sure you read the original idea? |
| 02:50 |
RealBadAngel |
"and see if anything would've got cut off, and then place the rest of that decoration" |
| 02:50 |
RealBadAngel |
so what happens with the cut off part? |
| 02:51 |
hmmmm |
in both cases, i'd have the written to a buffer first |
| 02:51 |
hmmmm |
the tree written to* |
| 02:51 |
hmmmm |
the whole tree |
| 02:52 |
hmmmm |
what i'd actually place would be the contents of that buffer, up to the y position that fits in that chunk |
| 02:52 |
hmmmm |
and for the "rest of it", i'd just blit the part that didn't fit below |
| 02:54 |
hmmmm |
you know the more i think about it, the more i'm liking this idea |
| 02:54 |
hmmmm |
except instead of having to recalculate everything, what i would do is add the positions of things that did not fit and their height to a queue that's shared among all mapgens |
| 02:55 |
hmmmm |
that would simplify things a bit, remove the need for duplicating lighting computations, remove the extraneous envlocks |
| 02:55 |
|
[0gb-us] left #minetest-dev |
| 02:56 |
|
jojoa1997 joined #minetest-dev |
| 02:56 |
hmmmm |
of course you can overfill the buffer by never having the chunks above the cut-off areas generated, it'd be difficult for a totally legitimate client to do that though |
| 02:56 |
hmmmm |
if the buffer is overfilled, naturally you'd just drop things |
| 02:56 |
RealBadAngel |
and the chunk that will need it will take it off the not added yet things list? |
| 02:56 |
hmmmm |
yes |
| 02:57 |
hmmmm |
would you people please stop playing nick games |
| 02:57 |
hmmmm |
jeez |
| 02:57 |
RealBadAngel |
that sounds reasonable |
| 02:57 |
keaza |
ok sorry i thought i got out of this channel |
| 02:57 |
|
keaza left #minetest-dev |
| 02:58 |
hmmmm |
and now to decide which chunks each request fulfillment "belongs" to would be obviously an O(n) operation |
| 02:58 |
hmmmm |
......i try to avoid O(n) |
| 02:59 |
hmmmm |
especially if it involves factors you can't control, like this |
| 02:59 |
hmmmm |
who knows if it can grow into the thousands |
| 02:59 |
hmmmm |
well easy, i'll just make the limit 1024 |
| 03:00 |
hmmmm |
alright so any objections? that's how i'll handle decorations that would be cut off |
| 03:02 |
|
BackupCoder joined #minetest-dev |
| 05:51 |
|
proller joined #minetest-dev |
| 06:00 |
|
emptty joined #minetest-dev |
| 06:07 |
celeron55 |
hmmmm: and in the end, all the thing will actually be used for will be single node plants? 8) |
| 06:14 |
hmmmm |
of course not.. the l-system trees will get cut off quite often |
| 06:16 |
hmmmm |
single node plants, and even cacti and papyrus are handled with the simple decoration type. they won't ever get added to the cut-off queue |
| 06:16 |
hmmmm |
only schematic and l-system types might |
| 06:28 |
|
emptty joined #minetest-dev |
| 06:42 |
|
darkrose joined #minetest-dev |
| 06:47 |
|
emptty joined #minetest-dev |
| 07:11 |
|
darkrose joined #minetest-dev |
| 07:26 |
|
iqualfragile joined #minetest-dev |
| 07:31 |
|
darkrose joined #minetest-dev |
| 08:28 |
|
iqualfragile joined #minetest-dev |
| 09:42 |
|
proller joined #minetest-dev |
| 10:03 |
|
PilzAdam joined #minetest-dev |
| 10:19 |
|
Taoki joined #minetest-dev |
| 10:29 |
|
darkrose joined #minetest-dev |
| 10:47 |
|
Zeg9 joined #minetest-dev |
| 11:04 |
|
Calinou joined #minetest-dev |
| 11:39 |
|
Taoki joined #minetest-dev |
| 12:29 |
|
Taoki joined #minetest-dev |
| 13:04 |
|
kahrl joined #minetest-dev |
| 13:07 |
|
Taoki joined #minetest-dev |
| 13:08 |
|
Zeg9 joined #minetest-dev |
| 13:11 |
|
salamanderrake joined #minetest-dev |
| 13:11 |
|
hmmmm joined #minetest-dev |
| 13:34 |
|
emptty joined #minetest-dev |
| 13:58 |
|
Taoki joined #minetest-dev |
| 14:19 |
|
BlockMen joined #minetest-dev |
| 14:51 |
|
kaeza1 joined #minetest-dev |
| 15:33 |
|
serengeor joined #minetest-dev |
| 15:50 |
|
Calinou joined #minetest-dev |
| 15:52 |
|
dexter0 joined #minetest-dev |
| 16:06 |
|
rubenwardy joined #minetest-dev |
| 16:22 |
|
dexter0 joined #minetest-dev |
| 16:49 |
|
ImQ009 joined #minetest-dev |
| 16:54 |
|
rubenwardy joined #minetest-dev |
| 17:18 |
|
iqualfragile joined #minetest-dev |
| 17:32 |
rubenwardy |
+1 for http://dev.minetest.net/User:Rarkenin/Proposal_System |
| 17:38 |
|
sapier joined #minetest-dev |
| 17:39 |
RealBadAngel |
im not quite sure with this. this rules means ONE dev with unknown number of community folks behind (not to be verified, counted or whatever) could be able to push everything |
| 17:40 |
RealBadAngel |
this is unaceptable |
| 17:41 |
sapier |
-1 to proposal system suggestion |
| 17:41 |
rubenwardy |
how many core devs are there? |
| 17:41 |
RealBadAngel |
following this quide lets say one core dev thought lets make pokemon game out of it |
| 17:42 |
RealBadAngel |
published the idea on forums, gather some pokemon fans |
| 17:42 |
RealBadAngel |
and... |
| 17:42 |
sapier |
imho any successfull oss project needs a strong lead I don't know any system wich doesn't have one |
| 17:42 |
RealBadAngel |
we have PokemonTest |
| 17:43 |
rubenwardy |
how about if 5/7 devs say yes, it is merged? |
| 17:43 |
PilzAdam |
sapier, for some resons people think that MTs development is "community driven" |
| 17:43 |
PilzAdam |
-s |
| 17:43 |
RealBadAngel |
replace ONE with AT LEAST TWO of devs |
| 17:44 |
RealBadAngel |
than it will have legs and arms |
| 17:44 |
sapier |
rba I don't even think this is worst thing but what I'm frightened of is all "cool" features beeing added while the really important low level maintenance changes don't get majorities |
| 17:44 |
sapier |
rubenwardy it's already something like that |
| 17:45 |
RealBadAngel |
we are specializing as you may propably noticed |
| 17:45 |
RealBadAngel |
im from some time are not leaving drawtypes |
| 17:45 |
RealBadAngel |
hmmm is mapgen |
| 17:46 |
RealBadAngel |
others are also picked own niches |
| 17:46 |
RealBadAngel |
PA is minecrafting our game for example ;) |
| 17:46 |
sapier |
I guess it's only working this way as mit is to big for one person to know everything |
| 17:47 |
RealBadAngel |
time that ONE know everythin about MT are long time gone |
| 17:47 |
sapier |
is the texture not found problem already fixed? |
| 17:48 |
RealBadAngel |
not my area of expertise :) |
| 17:48 |
RealBadAngel |
dunno |
| 17:48 |
sapier |
maybe it's not working that good :-P |
| 17:48 |
RealBadAngel |
my ass is glue sticked to mapblock_mesh.cpp and the like |
| 17:48 |
kahrl |
what texture not found problem? |
| 17:49 |
RealBadAngel |
at the client shutdown it reports weird error |
| 17:49 |
RealBadAngel |
cannot find or load texture |
| 17:49 |
RealBadAngel |
after ALC is closed |
| 17:50 |
sapier |
my guess is irrlicht tries to create inventorycubes from already unloaded textures |
| 17:50 |
kahrl |
oh the lines with the ^[forcesingle textures? |
| 17:50 |
RealBadAngel |
propably client wants to free memory but texture is already gone |
| 17:50 |
RealBadAngel |
yes |
| 17:50 |
sapier |
it's not a crash issue but a glitch |
| 17:50 |
sapier |
I don't think so if it tried to free it'd crash |
| 17:52 |
sapier |
once I'm able to reproduce it I'll try to find it |
| 17:53 |
RealBadAngel |
install texture pack |
| 17:53 |
RealBadAngel |
turn off preload visuals |
| 17:53 |
RealBadAngel |
shut down client |
| 17:54 |
sapier |
oh no preload visuals |
| 17:54 |
PilzAdam |
it also appears without a TP |
| 17:54 |
sapier |
hmm I don't have preload enabled |
| 17:54 |
RealBadAngel |
OFF |
| 17:55 |
sapier |
its 0 in my config this is off ? |
| 17:55 |
RealBadAngel |
error mesages clearly says that it is all about generated inventory images |
| 17:55 |
PilzAdam |
sapier, yes |
| 17:55 |
kahrl |
I did some dstream-assisted debugging |
| 17:56 |
kahrl |
the culprit is the driver->getTexture call in ~TextureSource |
| 17:56 |
|
jin_xi joined #minetest-dev |
| 17:57 |
sapier |
maybe it isn't even a problem? |
| 17:59 |
sapier |
~TextureSource tries to find the texture for all added textures |
| 17:59 |
sapier |
if it finds one its deleted, if not nothing is done |
| 17:59 |
kahrl |
why is ^[forcesingle even needed anymore? |
| 17:59 |
kahrl |
I thought the texture atlas was gone |
| 17:59 |
kahrl |
oh, it is not |
| 17:59 |
sapier |
it's just not really used anymore |
| 18:00 |
kahrl |
I think it should be removed from the code, especially since it doesn't work with the new facedir |
| 18:00 |
sapier |
me too but I was more eager to fix the memory leaks |
| 18:01 |
sapier |
but getting back to the error message maybe there's a way to check for a texture not using getTexture to avoid that message beeing shown |
| 18:01 |
sapier |
this message is issued by irrlicht not mt |
| 18:01 |
kahrl |
^[forcesingle is basically wasted video memory nowadays |
| 18:05 |
sapier |
II'll have a look how to remove it |
| 18:05 |
sapier |
looks like some work on first glance |
| 18:06 |
|
celeron55 joined #minetest-dev |
| 18:08 |
RealBadAngel |
kahrl, texture atlas is obsolete |
| 18:08 |
RealBadAngel |
and is defaulted to off |
| 18:10 |
RealBadAngel |
current namespace is like each texture has its own atlas |
| 18:11 |
sapier |
still kahrl is right this should be cleaned up |
| 18:11 |
RealBadAngel |
ofc |
| 18:12 |
kahrl |
some mesh making code could be optimized by removing members for AtlasPointer, etc. |
| 18:12 |
emptty |
sapier: your mods depend on "default", but I get a warning that this mod does not exist. Should I fill an issue? |
| 18:12 |
kahrl |
members of* |
| 18:12 |
sapier |
yes ... why does default not exist? |
| 18:12 |
emptty |
I've no idea |
| 18:12 |
RealBadAngel |
c55 made some significant changes to it lately |
| 18:12 |
PilzAdam |
emptty, the default mod in common is just not recognized |
| 18:13 |
PilzAdam |
everything should work, though |
| 18:13 |
emptty |
everything works, yes |
| 18:13 |
sapier |
so not a mobf bug but core |
| 18:13 |
RealBadAngel |
im familiar with the code after the changes |
| 18:13 |
RealBadAngel |
i just put the last nail to texture atlas coffin |
| 18:15 |
sapier |
argh ... I thought I've fixed all memory leaks ... could each of you plz stop adding new ones !? ;-) |
| 18:15 |
PilzAdam |
no |
| 18:15 |
RealBadAngel |
are you lookin at me sapier? :) |
| 18:16 |
sapier |
no I'm not looking at anyone special :-) as I don't know who added this :-) maybe it's even a special case that didn't occcur before |
| 18:17 |
RealBadAngel |
name the case |
| 18:17 |
sapier |
CItemDefMangager:RegisterItem |
| 18:17 |
RealBadAngel |
uhhh, definitely this region have never seen my cursor blinkin |
| 18:18 |
sapier |
allocates memory in a quite complex stl structure that isn't freed correctly |
| 18:19 |
|
kahrl_ joined #minetest-dev |
| 18:20 |
kahrl_ |
sounds like that was me |
| 18:20 |
RealBadAngel |
hehe |
| 18:20 |
sapier |
if(m_item_definitions.count(def.name) == 0) |
| 18:20 |
sapier |
m_item_definitions[def.name] = new ItemDefinition(def); |
| 18:20 |
sapier |
else |
| 18:20 |
sapier |
*(m_item_definitions[def.name]) = def; |
| 18:20 |
sapier |
oops |
| 18:21 |
sapier |
who wants to be blamed for this? :-) |
| 18:21 |
RealBadAngel |
kahrl, btw have you tested this nested meshbuffers fix? |
| 18:21 |
sapier |
if there's already memory used forget about it and get new one without freeing the old memory :-) |
| 18:22 |
sapier |
stop .., I'm wrong |
| 18:22 |
kahrl_ |
RealBadAngel: yes but only a bit |
| 18:22 |
RealBadAngel |
how? |
| 18:23 |
kahrl_ |
a mapblock full of allfaces nodes |
| 18:23 |
kahrl_ |
used to simply not show some of the nodes, with my fix it shows all |
| 18:23 |
RealBadAngel |
have u dumped how many buffers are you using? |
| 18:23 |
kahrl_ |
no |
| 18:23 |
sapier |
no not quite ... Itemdef is a struct not working correct with = operator |
| 18:24 |
RealBadAngel |
you know that in the first place mt way is RAPE agaisnt irrlicht engine |
| 18:24 |
RealBadAngel |
meshbuffers are supposed to dispaly scene nodes |
| 18:25 |
kahrl_ |
sapier: ItemDefinition has an operator= |
| 18:25 |
RealBadAngel |
models |
| 18:25 |
RealBadAngel |
not whole world |
| 18:25 |
sapier |
yes but somehow there's still memory lost allocated here |
| 18:25 |
kahrl_ |
maybe a bug in operator=? |
| 18:26 |
sapier |
I'm looking for it |
| 18:26 |
kahrl_ |
RealBadAngel: are there any bad consequences of that? |
| 18:26 |
RealBadAngel |
maybe we shall take a step in separating elements of the world |
| 18:26 |
sapier |
but seams to be fine |
| 18:26 |
RealBadAngel |
yes |
| 18:26 |
RealBadAngel |
we hit the vertices limit for ONE MODEL |
| 18:27 |
kahrl_ |
a model doesn't have a vertex limit |
| 18:27 |
RealBadAngel |
folks in irrlicht forums responded to such question: who the fuck would need so many vertices for one model... |
| 18:27 |
kahrl_ |
a meshbuffer has an indices limit |
| 18:27 |
sapier |
argh |
| 18:27 |
RealBadAngel |
vertices/indices |
| 18:27 |
sapier |
there's my fix of fix missing in CItemDefManager |
| 18:27 |
RealBadAngel |
same for me ;) |
| 18:27 |
RealBadAngel |
effect is the same |
| 18:28 |
kahrl_ |
link to that forum post? |
| 18:28 |
RealBadAngel |
to much stuff pushed into one bin |
| 18:28 |
sapier |
https://github.com/minetest/minetest/pull/635 |
| 18:28 |
sapier |
could someone plz merge this? |
| 18:29 |
RealBadAngel |
maybe if we could spilt meshbuffers for nodeboxes, water, entities etc? |
| 18:30 |
kahrl_ |
RealBadAngel: why would you do that |
| 18:31 |
kahrl_ |
other than having separate meshbuffers for different materials, which is already done |
| 18:31 |
RealBadAngel |
first of all avoid the limits |
| 18:31 |
kahrl_ |
my patch makes it avoid the limits |
| 18:31 |
|
kaeza joined #minetest-dev |
| 18:31 |
sapier |
by some time there need to be changes for shaders |
| 18:32 |
RealBadAngel |
im not sure about proper alpha handling |
| 18:32 |
RealBadAngel |
this is sorted for scene nodes |
| 18:32 |
RealBadAngel |
not meshbuffers |
| 18:32 |
emptty |
sapier: how can I generate locally the doc that is on http://animalsmod.comuf.com/? I'm sick of the advertisements :/ |
| 18:33 |
RealBadAngel |
if everythin is put into one bin we have weird problems |
| 18:33 |
kahrl_ |
No, irrlicht does not do transparency sorting |
| 18:34 |
kahrl_ |
It renders the opaque nodes before transparent nodes, but that's it |
| 18:34 |
sapier |
it's difficult you need lua2dox in an updated version ... didn't know about the advertisement till now, I'll create a download zip |
| 18:34 |
emptty |
thx |
| 18:34 |
kahrl_ |
parts of nodes* (depending on how the scenenodes are implemented) |
| 18:35 |
RealBadAngel |
kahrl_, i dont know enough about it yet, just repeatin what other devs said |
| 18:35 |
kahrl_ |
I'm talking about scenenodes here, not minetest nodes |
| 18:36 |
RealBadAngel |
propably c55 took "node" name from irrlicht namespace |
| 18:36 |
RealBadAngel |
scene node is complete object, mesh |
| 18:36 |
kahrl_ |
in minetest the entire world is 1 scene node |
| 18:37 |
RealBadAngel |
in our case, whole mt world is irrlicht's scene node |
| 18:37 |
RealBadAngel |
genau |
| 18:37 |
sapier |
genau? :-) |
| 18:37 |
RealBadAngel |
exactly |
| 18:37 |
kahrl_ |
richtig |
| 18:37 |
sapier |
lol |
| 18:37 |
RealBadAngel |
hehe |
| 18:38 |
RealBadAngel |
thus node to node interaction is not possible |
| 18:38 |
RealBadAngel |
like alpha sorting |
| 18:38 |
kahrl_ |
like I said, irrlicht doesn't do transparency sorting |
| 18:39 |
RealBadAngel |
c55 said it does, but between nodes |
| 18:39 |
RealBadAngel |
or at least i think he did |
| 18:40 |
RealBadAngel |
some1 did for sure :) |
| 18:40 |
RealBadAngel |
if not him then hmmmm |
| 18:42 |
RealBadAngel |
anyway, for mesh drawtype i will introduce next meshbuffer |
| 18:43 |
sapier |
mesh drawtype for nodes? |
| 18:43 |
RealBadAngel |
i pretty sure it will be good solution |
| 18:43 |
RealBadAngel |
yes |
| 18:43 |
sapier |
are you sure this is the right way to go? |
| 18:43 |
RealBadAngel |
*im |
| 18:43 |
RealBadAngel |
yup |
| 18:44 |
RealBadAngel |
crystal thingies/animated nodes etc |
| 18:44 |
sapier |
this means breaking simplicity of map while giving up exact collision handling |
| 18:45 |
kahrl_ |
I can't find any reference to depth sorting in the irrlicht documentation |
| 18:45 |
RealBadAngel |
collision box will have to be defined as a box, for sure |
| 18:45 |
sapier |
as I said giving up exact collision handling |
| 18:45 |
kahrl_ |
what does rendering have to do with collision handling? |
| 18:46 |
RealBadAngel |
we r livin in a voxel world |
| 18:46 |
sapier |
currently you collide to what you see in a world (not considering special entitiy case) |
| 18:46 |
RealBadAngel |
box is enough |
| 18:46 |
sapier |
but with entities you can see what anyoing effects giving up visible<->collision box incoherence has |
| 18:47 |
RealBadAngel |
separate from what you can actually see. box is good aproximation |
| 18:47 |
sapier |
try mobf you'll see what I mean |
| 18:47 |
RealBadAngel |
sapier, you mean no "headshots" possible |
| 18:47 |
kahrl_ |
well you'd collide with air if you set it to walkable |
| 18:48 |
sapier |
.... no I mean ppl standing in the air because of colision boxes not fitting to meshes |
| 18:48 |
kahrl_ |
also: try walking through a door while sneaking |
| 18:48 |
RealBadAngel |
price for doing so fancy things we had in mind? ;) |
| 18:48 |
kahrl_ |
(sneaking increases the player's collision box, causing you to collide with the door sometimes even though you shouldn't) |
| 18:49 |
sapier |
it's not a new problem true but if even map isn't node based the problem will become much more visible and anoying |
| 18:50 |
sapier |
maybe a limited set of new node geometrys would be a better approach |
| 18:51 |
RealBadAngel |
this is problem of tuning just imho, not a real problem like we are fighting atm |
| 18:51 |
sapier |
no it's not a tuning problem the only real way of fixing this problem is creating a mesh aware collision system |
| 18:51 |
RealBadAngel |
better tell me why before adding luajit i had 25-30fps, after adding i jumped to 55-60 |
| 18:52 |
sapier |
maybe this is an easy task, but I don't have any idea how to do this in a performant way |
| 18:52 |
RealBadAngel |
and last two weeks it dropped to 15-20 |
| 18:52 |
sapier |
don't know ... maybe object object collision handling? |
| 18:53 |
sapier |
depends on how many objects are in your world |
| 18:53 |
kahrl_ |
I downloaded the irrlicht source and apparently it does sort transparent nodes by distance |
| 18:53 |
RealBadAngel |
something pushed recently caused signigificant frame drop |
| 18:53 |
RealBadAngel |
with luajit onboard (which is at least 2x faster) |
| 18:54 |
kahrl_ |
but still, you can't make a new scene nodes for each minetest node without tossing all performance down the drain |
| 18:54 |
sapier |
is luajit still enabled? |
| 18:54 |
kahrl_ |
-s |
| 18:54 |
sapier |
maybe a scene node for each block? |
| 18:54 |
kahrl_ |
that wouldn't fix the glitches |
| 18:54 |
RealBadAngel |
if its in your system it is autodetected |
| 18:55 |
sapier |
and this is working correct? |
| 18:55 |
RealBadAngel |
yes |
| 18:55 |
sapier |
volonteers for bisecting changes? ;-) |
| 18:56 |
RealBadAngel |
luajit was tested on vanessae server month before merging |
| 18:56 |
sapier |
I'm not talking about luajit I know its way more performant |
| 18:59 |
RealBadAngel |
look thats somethin in between my glasslike_framed push and 2 weeks back in the history |
| 18:59 |
RealBadAngel |
i made freeze while i was workin on it |
| 19:00 |
RealBadAngel |
code before was workin fine, addin the _framed too |
| 19:00 |
RealBadAngel |
but when i merged the trees i noticed slowdown |
| 19:01 |
sapier |
luahud? |
| 19:02 |
RealBadAngel |
dunno, first thing i noticed that hearts 128x textures takes whole screen and doesnt fit |
| 19:03 |
RealBadAngel |
i had to go back for 16x textures for it |
| 19:04 |
RealBadAngel |
i do have workin trees on my hdd for 5-6months back in time |
| 19:04 |
RealBadAngel |
i do name them by dates and project involved |
| 19:05 |
RealBadAngel |
so i can easily step back and check who did it |
| 19:06 |
RealBadAngel |
i dont like github so im doin my own trees and branching |
| 19:08 |
|
jojoa1997 joined #minetest-dev |
| 19:08 |
|
rubenwardy left #minetest-dev |
| 19:09 |
|
StrayBytes joined #minetest-dev |
| 19:09 |
|
StrayBytes joined #minetest-dev |
| 19:10 |
RealBadAngel |
kahrl, btw: http://i.imgur.com/OapBLIO.jpg |
| 19:14 |
|
Jordach joined #minetest-dev |
| 19:15 |
|
Jordach_ joined #minetest-dev |
| 19:15 |
|
Jordach_ joined #minetest-dev |
| 19:16 |
sfan5 |
my client crashes when i join the server i host for markveidemanis: http://pastie.org/7744540 |
| 19:16 |
|
Jordach__ joined #minetest-dev |
| 19:16 |
kahrl_ |
RealBadAngel: these guys should randomly spawn as mobs on the surface |
| 19:17 |
kahrl_ |
anyway, what do you mean with that screenshot? |
| 19:17 |
sapier |
mobs > 1 block are a little bit difficult to do movement |
| 19:18 |
sapier |
-block + node |
| 19:18 |
RealBadAngel |
kahrl_, i mean with this we can use all irrlicht code |
| 19:19 |
sapier |
is using all irrlicht code target? |
| 19:19 |
sapier |
if so we need to do some basic changes in code |
| 19:19 |
kahrl_ |
hm? we already had 3d players using models |
| 19:19 |
RealBadAngel |
this is from irrlicht examples |
| 19:19 |
sapier |
but what s new? |
| 19:20 |
RealBadAngel |
imho separation is needed |
| 19:20 |
sapier |
separation of what? |
| 19:21 |
RealBadAngel |
displayed things |
| 19:21 |
sapier |
currently separation is block like static objects --> nodes |
| 19:21 |
sapier |
dynamic things --> entities |
| 19:22 |
RealBadAngel |
and buffers said: NO |
| 19:22 |
kahrl_ |
what? |
| 19:22 |
sapier |
:-) you have to tell me what you're aiming at |
| 19:22 |
RealBadAngel |
NODE is not a single node in the world |
| 19:22 |
kahrl_ |
are you seriously saying 1 minetest node should be 1 scene node? |
| 19:23 |
RealBadAngel |
block, box, node, stone whatever you call it |
| 19:23 |
RealBadAngel |
no |
| 19:23 |
RealBadAngel |
one kind of them |
| 19:23 |
RealBadAngel |
solid ones, water, objects, players, etc |
| 19:24 |
RealBadAngel |
split them into groups |
| 19:24 |
kahrl_ |
water? you know there are giant oceans with thousands of water nodes |
| 19:24 |
RealBadAngel |
ofc |
| 19:25 |
RealBadAngel |
we are talkin about different display ways |
| 19:25 |
RealBadAngel |
now all is in fact the same |
| 19:25 |
kahrl_ |
not really, since they are in separate meshbuffers |
| 19:26 |
kahrl_ |
with different materials |
| 19:26 |
RealBadAngel |
excuse me |
| 19:26 |
RealBadAngel |
now is in ONE meshbuffer |
| 19:27 |
RealBadAngel |
*all |
| 19:27 |
kahrl_ |
have you read the source of MeshCollector::append()? |
| 19:27 |
RealBadAngel |
all nodes at least |
| 19:28 |
RealBadAngel |
im talkin nodes only by now |
| 19:29 |
kahrl_ |
I don't think you know what you're talking about, I'm sorry :| |
| 19:29 |
RealBadAngel |
i used to hear such phrase |
| 19:30 |
kahrl_ |
I tried to delay saying it |
| 19:31 |
RealBadAngel |
sorry. but when i do see adding to mesh collector, and it says its out of vertices/indices i dont think it sorted and using any more than just one |
| 19:32 |
kahrl_ |
Yep. That's because the nodes that caused the meshbuffer to overflow were all the same kind of node. |
| 19:33 |
kahrl_ |
Or used the same texture/material, at least |
| 19:35 |
kahrl_ |
In my test I had a mapblock full of allfaces nodes. That's 16*16*16 nodes, with 6 faces each, with 6 indices per face, for a total of 147456 indices |
| 19:35 |
RealBadAngel |
youre tryin to tell me that we had multiple buffers for each materials before? |
| 19:35 |
kahrl_ |
One buffer for one material |
| 19:35 |
kahrl_ |
With a limit of 65535 indices. My patch makes it so it begins a new buffer when that limit is reached |
| 19:35 |
RealBadAngel |
shit, i should dig code deeper then |
| 19:36 |
RealBadAngel |
mea culpa |
| 19:36 |
RealBadAngel |
i thought its overall |
| 19:37 |
RealBadAngel |
so, this case, i think your patch is the right thing |
| 19:38 |
RealBadAngel |
extend the limit just with going for next buffer |
| 19:40 |
RealBadAngel |
and the sidenote: i should really shut up about the code i havent read to the last bit |
| 19:41 |
kahrl_ |
meh, I do that too at times |
| 19:41 |
kahrl_ |
like with the irrlicht and transparency sorting thing |
| 19:41 |
RealBadAngel |
i just judged it by behavuir |
| 19:42 |
RealBadAngel |
and some c55 and hmm comment too, to be honest |
| 19:44 |
RealBadAngel |
ehhh, man is learnin whole the lifetime and dies stupid |
| 19:44 |
RealBadAngel |
at least i do try to learn more |
| 19:44 |
sapier |
that's why we are here ;-) |
| 19:44 |
sapier |
to learn more |
| 19:45 |
RealBadAngel |
c55 didnt believed me on my very first days i was her that i came to mod and code |
| 19:45 |
kahrl_ |
ok, I made it print when it has to start a new mesh (with my patch) |
| 19:46 |
kahrl_ |
with the mapblock full of allfaces nodes, that's 2 times |
| 19:46 |
RealBadAngel |
now i think he believes, but i, on the other hand more and more are realiznin i need to learn mor |
| 19:46 |
RealBadAngel |
e |
| 19:46 |
kahrl_ |
so 3 meshbuffers, as expected |
| 19:46 |
kahrl_ |
start a new meshbuffer* |
| 19:49 |
RealBadAngel |
etities have own meshbuffer or not? |
| 19:57 |
RealBadAngel |
bbl, have to go |
| 19:57 |
kahrl_ |
"it's complicated" |
| 19:57 |
kahrl_ |
they don't use the same meshbuffer as any mapblock |
| 19:57 |
kahrl_ |
they have their own mesh |
| 19:57 |
kahrl_ |
however, entities with the same mesh reuse that mesh, depending on the entity drawtype |
| 19:57 |
|
hmmmm joined #minetest-dev |
| 20:07 |
sapier |
anyone plz merge this one? https://github.com/minetest/minetest/pull/635 |
| 20:09 |
|
fuzzywuzzy joined #minetest-dev |
| 20:10 |
|
fuzzywuzzy left #minetest-dev |
| 20:50 |
|
serengeor joined #minetest-dev |
| 20:59 |
emptty |
sapier: I was considering adding a new NPC to your framework, but I'm a bit lost. Do you have some time to chat about it, please? |
| 21:01 |
|
Taoki joined #minetest-dev |
| 21:14 |
celeron55 |
20:43:58 <+RealBadAngel> following this quide lets say one core dev thought lets make pokemon game out of it <+RealBadAngel> published the idea on forums, gather some pokemon fans <+RealBadAngel> and... <+RealBadAngel> we have PokemonTest |
| 21:14 |
celeron55 |
did you actually read it at all? |
| 21:15 |
celeron55 |
it specifically disallows that kind of thing |
| 21:15 |
celeron55 |
anyone's opinion counts just as much as it contains rational reasoning |
| 21:16 |
|
StrayBytes left #minetest-dev |
| 21:16 |
celeron55 |
and you aren't going to get any of that from some random forum fan |
| 21:17 |
celeron55 |
and if you do, and it's wrong, it can be made to count as none by proper counter reasoning (eg. for that pokemon example, just say there that it's not possible because of trademark reasons) |
| 21:18 |
celeron55 |
doing everything based on proposal has it's problems, but that is not one of them |
| 21:18 |
celeron55 |
proposals* |
| 21:19 |
|
jojoa1997 joined #minetest-dev |
| 22:02 |
|
BlockMen joined #minetest-dev |
| 22:03 |
BlockMen |
hi, can someone tell me if that could work? http://pastie.org/private/wabue9etdjqb5mhyfblg#910-913 and http://pastie.org/private/uhr8c4gf0nmwyos1r5g7bg#189 (its guiFormSpecMenu.cpp and guiFormSpecMenu.h) |
| 22:06 |
|
jojoa1997 left #minetest-dev |
| 22:12 |
kahrl_ |
BlockMen: does anything call closeFormSpec()? |
| 22:13 |
BlockMen |
not yet, i just wanted know if it is "that easy" |
| 22:13 |
kahrl_ |
it should work |
| 22:14 |
emptty |
How far are we from the next stable release? |
| 22:14 |
BlockMen |
ok, thx. then i can try to get it called from lua |
| 22:14 |
BlockMen |
*now |
| 22:20 |
BlockMen |
kahrl_, do i have to include guiFormSpecMenu.h (with #include "") in scriptapi.ccp if i want call it from lua? |
| 22:20 |
Exio |
emptty: i know leveldb "should be" in 0.4.7 |
| 22:21 |
emptty |
Exio: what it this? |
| 22:21 |
Exio |
emptty: a new and "faster" level format |
| 22:21 |
Exio |
https://github.com/minetest/minetest/pull/326 |
| 22:24 |
emptty |
Exio: so you mean that we are quite far away from releasing 0.4.7 because this big blob must still go in, right? I'm not sure I see the connexion here |
| 22:24 |
PilzAdam |
emptty, we dont when we the next stable release will be released |
| 22:26 |
emptty |
sure, it's released when it's ready, as usual. My question was whether you guys were thinking of releasing or thinking that you need more features to go in |
| 22:26 |
Exio |
i just know what "needs" to be in 0.4.7 is leveldb, no idea about other stuff |
| 22:40 |
|
sapier1 joined #minetest-dev |
| 23:00 |
kahrl_ |
BlockMen: yes |
| 23:01 |
kahrl_ |
erm I mean no |
| 23:01 |
|
jojoa1997 joined #minetest-dev |
| 23:01 |
kahrl_ |
lua is on the server and formspec menus are on the client |
| 23:01 |
kahrl_ |
so you have to send a network message and handle it in CLient |
| 23:01 |
kahrl_ |
-L +l |
| 23:02 |
kahrl_ |
oh, just saw the discussion in #minetest |
| 23:03 |
BlockMen |
kahrl_, sry that im so impatient ;) |
| 23:03 |
BlockMen |
and just wanted send http://irc.minetest.ru/minetest/2013-04-30#i_3060580 link to that at #minetest |
| 23:14 |
BlockMen |
kahrl_, so something like that? -> http://pastie.org/private/obxjxl6tm16mgtwwhpg7ga |
| 23:14 |
kahrl_ |
nah |
| 23:15 |
kahrl_ |
in requestCloseFormSpec, send a TOCLIENT_CLOSEFORMSPEC message |
| 23:15 |
kahrl_ |
which you need to design |
| 23:15 |
sapier1 |
and make sure you don't mess up the formspec name fix :-) |
| 23:16 |
BlockMen |
damn, that is more complex than i hoped... |
| 23:17 |
Exio |
you wanted to change things in the client with a server-side command :P |
| 23:17 |
sapier1 |
:-) it's not that complicated I've it on my list for quite some time but didn't have time by now |
| 23:17 |
PilzAdam |
also an on_formspec_close() would be nice |
| 23:18 |
PilzAdam |
since you are already working in that part of the code... |
| 23:18 |
sapier1 |
not even my old bugs are fixed I wont add new ones to that code ;-) |
| 23:19 |
BlockMen |
PilzAdam, you are kidding? im glad i came so far already... |
| 23:20 |
BlockMen |
and do i send messages to client like here -> https://github.com/minetest/minetest/blob/master/src/server.cpp#L856 ? |
| 23:20 |
sapier1 |
and closing isn't as simple as opening ... currently never ever a form is closed without user interaction |
| 23:21 |
sapier1 |
last time I had a look at this I didn't even find a reference to the current open formspec. if I didn't miss it this would have to be added first |
| 23:22 |
kahrl_ |
BlockMen: look at Server::SendShowFormspecMessage |
| 23:22 |
BlockMen |
kahrl_, thx |
| 23:23 |
sapier1 |
sending the message is the easy part ;-) |
| 23:24 |
kahrl_ |
actually a list of currently open formspecs or can there only be one? |
| 23:24 |
sapier1 |
only one at a time on a client |
| 23:25 |
sapier1 |
currently there's a bug a formspecs name isn't updated if you send a new one, but gui is updated |
| 23:25 |
sapier1 |
thats what my changeset fixes |
| 23:25 |
kahrl_ |
oh, so you'd send a CE_CLOSE_FORMSPEC from the client to the main loop and close current_formspec there |
| 23:25 |
kahrl_ |
that would work, yes? |
| 23:25 |
sapier1 |
still as far as I know there is no reference or pointer to the open gui |
| 23:26 |
VanessaE |
kahrl_: regarding the out-of-indicies/too-many-verticies issue... would you mind testing it against something insane like the 'slopes' branch of homedecor, or those 'noncubic' type mods? |
| 23:26 |
sapier1 |
updating gui and formname works by updating guis content elements |
| 23:26 |
kahrl_ |
VanessaE: sure |
| 23:26 |
VanessaE |
thanks |
| 23:27 |
kahrl_ |
how many of the slopes would I have to place in a mapblock? |
| 23:27 |
VanessaE |
I would say around 30. |
| 23:27 |
VanessaE |
of the ones in homedecor that is |
| 23:27 |
kahrl_ |
Okay, that's doable |
| 23:27 |
VanessaE |
and place them up high |
| 23:27 |
VanessaE |
(the rendering glitch manifested itself as the uppermost polys disappearing as I panned down. |
| 23:28 |
BlockMen |
ok, i guess it was a bad idea to start that with my noob "skills"... |
| 23:28 |
BlockMen |
what is the peer_id (https://github.com/minetest/minetest/blob/master/src/server.cpp#L3453) and where i get it from? |
| 23:28 |
kahrl_ |
sapier1: in GUIFormSpecMenu::drawMenu it grabs the new formspec |
| 23:29 |
VanessaE |
BlockMen: everyone is a noob in the beginning. |
| 23:29 |
kahrl_ |
if that is an empty string, the menu could close itself |
| 23:30 |
VanessaE |
kahrl_: each slope, in my code, consists of 256 individual nodeboxes, so you can figure how many vertexes/indexes that is :) |
| 23:31 |
VanessaE |
(it would be a simple eight-poly node mesh, which RBA is working on, but I'm impatient. :D ) |
| 23:31 |
kahrl_ |
heh that's insane. I like insane |
| 23:31 |
VanessaE |
:DDD |
| 23:31 |
BlockMen |
VanessaE, nice words :P |
| 23:32 |
VanessaE |
BlockMen: my point is, don't let it get you down if you fail now - eventually you'll succeed. |
| 23:33 |
|
proller joined #minetest-dev |
| 23:35 |
BlockMen |
VanessaE, ya i know. but i can remember how much time it needs to learn...and i dont know if i will have the time(and will) for it |
| 23:35 |
BlockMen |
but we will see... |
| 23:36 |
BlockMen |
ok, what is the "peer_id" now? |
| 23:37 |
sapier1 |
you need to get it same way it's fetched for show_formspec |
| 23:38 |
VanessaE |
BlockMen: well time isn't much of an issue, if you can give even a few minutes at a time to learning a concept, you can learn it. Having the motivation or not, I can surely understand that. :-/ |
| 23:38 |
sapier1 |
it's just an identifier for a client ... it doesn't matter what it is in current implementation (at least not for your usecase) |
| 23:39 |
BlockMen |
ahh, there it comes from... |
| 23:40 |
sapier1 |
blockmen you'll never be finished with learing each of us (except those with really big egos) is still in learning phase ;-) |
| 23:42 |
BlockMen |
VanessaE, for me the time is a fact because i have alot other things to learn every day. but i agree that the motivation is the more important point |
| 23:42 |
BlockMen |
sapier, thats true. but the beginning sucks most (IMO). having a solid base is often enough :) |
| 23:43 |
sapier1 |
imho best thing to learn is to do mistakes :-) it's a hard way to learn but most effective one |
| 23:43 |
VanessaE |
BlockMen: the way I figure it, if you have time to spend chatting on IRC, you can find a few minutes to learn a craft as well - no one's life should be so crammed full of activities that they have no time to just relax and play. |
| 23:44 |
VanessaE |
it's neither physically nor socially healthy. |
| 23:44 |
sapier1 |
and of course relaxing is best way to get distance to recognize you're path to solution is actually directed in opposite direction ;-) |
| 23:44 |
VanessaE |
exactly |
| 23:45 |
BlockMen |
true. best solutions are found from distance :) |
| 23:45 |
VanessaE |
how many times have you been working diligently on a problem, only to be stonewalled for hours, until you sleep for a while. Then you wake up and the solution hits you in so obvious a way as to make you feel like a complete idiot :-) |
| 23:45 |
sapier1 |
I wouln't say this that general but at least for some situations distance helps |
| 23:46 |
BlockMen |
btw solutions: wouldnt it be alot easier to close a formspec when name = nil, like kahrl said here "kahrl_: if that is an empty string, the menu could close itself" (idk if he actually ment that) |
| 23:47 |
Exio |
VanessaE: well, that is how i program |
| 23:47 |
sapier1 |
would be an option to avoid adding a new message |
| 23:47 |
Exio |
i'm a whole day doing stuff |
| 23:47 |
Exio |
then when i wake up the other way |
| 23:47 |
sapier1 |
imho a good idea |
| 23:47 |
Exio |
i just remove the files, and write the "proper" code what is 10% or 15% of what it was and is far better, :D |
| 23:48 |
sapier1 |
"del" is programmers best friend ... removes bugs without need to find them first |
| 23:48 |
BlockMen |
sapier, then i will follow that way. but not today anymore... |
| 23:49 |
sapier1 |
you'll have to find a way to close the current formspec once you found it, remaining part is writing some text only |
| 23:50 |
BlockMen |
sapier1, when doin it that way i could just add that -> http://pastie.org/private/wabue9etdjqb5mhyfblg#910-913 |
| 23:50 |
BlockMen |
*and call it when formname = nil |
| 23:51 |
sapier1 |
not quite |
| 23:51 |
BlockMen |
not? why? |
| 23:52 |
sapier1 |
as long as a formspec is shown no new formspecmenu is created but the old one is updated |
| 23:52 |
sapier1 |
if you create a new one without cleaning up the old one you loose memory |
| 23:52 |
VanessaE |
kahrl_: so, did your video card blow up? ;) |
| 23:53 |
sapier1 |
wait |
| 23:53 |
sapier1 |
yes you could call the quit if you had the object to call it from |
| 23:54 |
|
jordan4ibanez joined #minetest-dev |
| 23:54 |
jordan4ibanez |
We need tin. |
| 23:54 |
BlockMen |
ok, you said when a formspec is open that one is just updated, right? |
| 23:55 |
sapier1 |
yes but it's updated in a quite strange way |
| 23:55 |
BlockMen |
so then void GUIFormSpecMenu::drawMenu() is called i guess |
| 23:55 |
BlockMen |
and that means i have the object, correct? |
| 23:55 |
sapier1 |
not the formspec itself is updated but the content |
| 23:55 |
sapier1 |
it's done this way because you don't actually have the formspec gui element |
| 23:56 |
BlockMen |
hmm, ic |
| 23:56 |
sapier1 |
I guess you need to change it so you actually have the formspec gui element available where you need it |
| 23:56 |
kahrl_ |
oh my lord the framerate |
| 23:57 |
kahrl_ |
it's so high |
| 23:57 |
kahrl_ |
http://imgur.com/wKgoflV |
| 23:57 |
kahrl_ |
that's 256 slopes |
| 23:57 |
sapier1 |
move your head from ground kahrl it'll drop :) |
| 23:57 |
VanessaE |
kahrl_: how's your ....ouch, drawtime = 75? |
| 23:58 |
kahrl_ |
nope, still around 12 FPS :D |
| 23:58 |
VanessaE |
that translates to what, around 5fps? :) |
| 23:59 |
VanessaE |
oh heh |
| 23:59 |
VanessaE |
what's your normal rate? |
| 23:59 |
kahrl_ |
around 60 |
| 23:59 |
VanessaE |
haha |
| 23:59 |
VanessaE |
well it's good to know they work |
| 23:59 |
VanessaE |
but I think long-term, that particular node is a dead idea :D |
| 23:59 |
kahrl_ |
interestingly the framerate dropped quick when I placed the first few nodes |
| 23:59 |
VanessaE |
but it makes for a good stress test :D |
| 23:59 |
kahrl_ |
but then it settled |
