| Time |
Nick |
Message |
| 00:29 |
|
sofar joined #minetest-dev |
| 02:00 |
|
RealBadAngel joined #minetest-dev |
| 02:02 |
|
Ardonel joined #minetest-dev |
| 02:16 |
|
Kray joined #minetest-dev |
| 02:23 |
|
everamzah joined #minetest-dev |
| 02:47 |
|
RealBadAngel joined #minetest-dev |
| 03:24 |
|
Robby joined #minetest-dev |
| 03:38 |
|
kaadmy joined #minetest-dev |
| 03:54 |
|
paramat joined #minetest-dev |
| 03:56 |
paramat |
kahrl is #3673 ready for merge? if so i'll merge it along with #3686 #3688 |
| 03:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3673 -- Add '/clearobjects quick' by kahrl |
| 03:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3686 -- Small clean up and documentation additions. by kaeza |
| 03:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3688 -- Documentation: Remove now unused 'vertical spawn range' by paramat |
| 04:02 |
RealBadAngel |
also #3678, #3684, #3689 :) |
| 04:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3678 -- Formspec: recreate item_image_button pressed state for its image and … by RealBadAngel |
| 04:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3684 -- Dump shader programs on compile errors, fix mismatched pixel shader v… by RealBadAngel |
| 04:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3689 -- Use single box for halo mesh by RealBadAngel |
| 04:02 |
RealBadAngel |
hi |
| 04:05 |
paramat |
could you add a short description for 3689? if it's a single cuboid for all uses that seems good to me |
| 04:05 |
RealBadAngel |
theres explanation in code |
| 04:05 |
RealBadAngel |
but can add that in PR too |
| 04:05 |
RealBadAngel |
mainly, thats because of inner faces |
| 04:07 |
RealBadAngel |
i can solve that later on with mrt easily, but now overlapping boxes (and surfaces accumulating transparent layer colors are just ugly) |
| 04:08 |
RealBadAngel |
and its not single one for all, its calculated for each set of selection boxes, kinda bounding box |
| 04:09 |
kahrl |
paramat: 3673 is ready, yes |
| 04:11 |
paramat |
nice and simple, personally i don't think the halo needs to recreate the shape |
| 04:11 |
paramat |
ok |
| 04:13 |
RealBadAngel |
imho it should, but cant right now, at least ugly visual glitches |
| 04:13 |
RealBadAngel |
+without |
| 04:16 |
paramat |
yeah, i'm not too bothered either way |
| 04:18 |
RealBadAngel |
tried to find any method to optimize mesh and remove invisible parts of faces but failed so far |
| 04:20 |
paramat |
now merging the 3 i mentioned |
| 04:21 |
RealBadAngel |
i do have way simpler solution to that, just project selection mesh on screen plane, get its 2D shape and blit it back onto original render with transparency |
| 04:21 |
RealBadAngel |
with that approach we can also solve liquids rendering glitches |
| 04:22 |
RealBadAngel |
thats the exact same problem here |
| 04:23 |
RealBadAngel |
in fact this method can solve all the problems with rendering transparent things |
| 04:24 |
RealBadAngel |
but, for that i will need mrt in (so, laaaaater ;) |
| 04:26 |
RealBadAngel |
kahrl, could you check 3684 and 3689 too? |
| 04:28 |
paramat |
merged |
| 04:39 |
RealBadAngel |
kahrl, geometry shader is passed to GPU |
| 04:40 |
RealBadAngel |
i was playin already with geometry shaders |
| 04:40 |
kahrl |
yeah, but only for glsl shaders |
| 04:40 |
kahrl |
the line I commented was about assembly shaders |
| 04:40 |
RealBadAngel |
ah ok |
| 04:41 |
kahrl |
RealBadAngel: and just a minor stylistic choice, but I'd make the output stream a parameter of dumpShaderProgram |
| 04:41 |
RealBadAngel |
why? |
| 04:42 |
kahrl |
that makes it clear at the call sites of dumpShaderProgram that the error message goes to errorstream but the programs are dumped to warningstream |
| 04:43 |
kahrl |
and it makes dumpShaderProgram more general, so it could be used to dump to other stream later if needed |
| 04:43 |
RealBadAngel |
ok, can do that |
| 04:43 |
kahrl |
another stream* |
| 04:45 |
RealBadAngel |
so, thats all bout dump thingy? |
| 04:46 |
RealBadAngel |
btw, i wonder why i havent coded that before, that makes debugging glsl a lot easier |
| 04:46 |
kahrl |
the change of pixel shader version should be in a separate commmit, since it's completely unrelated to dumping |
| 04:46 |
kahrl |
commit* |
| 04:47 |
RealBadAngel |
i just noticed it btw, that propably have no meaning at all since we set ver in headers |
| 04:47 |
RealBadAngel |
but i dont believe drivers ;) |
| 04:48 |
RealBadAngel |
ok, will make another PR out of it |
| 04:49 |
RealBadAngel |
but it can have meaning, i remember folks reporting compile errors when for example float x = 1 was used |
| 04:49 |
RealBadAngel |
1.1 doesnt allow that, while 1.2 do |
| 04:50 |
RealBadAngel |
in 1.1 you have to use form "float x = 1.0" |
| 04:52 |
RealBadAngel |
on NVidia i was able to use both notations, AMD was reporting errors |
| 05:09 |
RealBadAngel |
kahrl, updated dump PR |
| 05:11 |
kahrl |
looks good |
| 05:15 |
sofar |
RealBadAngel: want me to test shaders on Intel ? |
| 05:15 |
sofar |
for one of your branches? |
| 05:16 |
RealBadAngel |
you can compile mrt_1 branch |
| 05:16 |
kahrl |
I can't comment on the halo PR too much, since I haven't played with halos yet, but I've commented a few things about aabb3f usage |
| 05:18 |
sofar |
compiling... |
| 05:18 |
RealBadAngel |
kahrl, yeah, pushing the changes now, your suggestion works |
| 05:20 |
RealBadAngel |
kahrl, about visual side theres not much to comment in fact, just single box instead of overlapping ones |
| 05:21 |
RealBadAngel |
overlapping transparent surfaces are not fixeable with current renderer, same as for water |
| 05:21 |
sofar |
RealBadAngel: mrt_1 branch works just fine, but that doesn't have the problematic bloom code in it |
| 05:22 |
RealBadAngel |
enable it |
| 05:22 |
RealBadAngel |
use config settings |
| 05:23 |
sofar |
o right |
| 05:23 |
sofar |
still one GLSL compile error with bloom |
| 05:23 |
kahrl |
RealBadAngel: makes sense |
| 05:23 |
sofar |
vec4/vec2 type mismatch |
| 05:24 |
RealBadAngel |
sofar, hold on i will update the branch in a few minutes |
| 05:24 |
sofar |
texture2D(sampler2D, vec4) |
| 05:25 |
RealBadAngel |
kahrl, could you merge the dump PR? i could add it to mrt branch and dump PP shaders compile errors |
| 05:26 |
RealBadAngel |
(thats why i have exposed the function for anyway) |
| 05:26 |
sofar |
cell & DoF are fine, no errors |
| 05:27 |
RealBadAngel |
sofar, how about speed? |
| 05:27 |
sofar |
looked entirely adequate, and my IVB isn't the snappiest at 1600x900, so, good |
| 05:29 |
RealBadAngel |
kahrl, updated halo PR, im not sure if i should shorten the section with offset and expand |
| 05:31 |
kahrl |
I think the shortened version may be a bit too confusing |
| 05:32 |
kahrl |
about convertNodeboxesToMesh - is the offset_boxes parameter needed? It seems to be always set to false |
| 05:32 |
sofar |
28-30fps with bloom/tone/dof enabled, ~100 viewing range |
| 05:32 |
RealBadAngel |
it will be needed when i will go back to shaped halo |
| 05:32 |
kahrl |
and I'm not sure about its implementation anyway (adding 0.005 to the offset each box) |
| 05:33 |
kahrl |
that seems like it would lead to extremely huge boxes for detailed nodebox models |
| 05:33 |
RealBadAngel |
thats gonna be used by halo only |
| 05:34 |
kahrl |
I'd say leave it out for now and add it back in when it becomes necessary |
| 05:34 |
RealBadAngel |
and for that effect you would need 100 boxes to shift it by 1 pixel of 16x16 texture |
| 05:35 |
kahrl |
100 doesn't seem that much |
| 05:35 |
RealBadAngel |
and 0.005 is the minimum value to disable textures fighting on same or near planes |
| 05:37 |
RealBadAngel |
kahrl, the code is tested and works, i will need it anyway, why i should keep it in some branch (its just a few lines) and look for it god knows when? |
| 05:37 |
RealBadAngel |
but can remove it if you insist |
| 05:38 |
RealBadAngel |
100 nodeboxes in one node? that would be a killer node for rendering, doubt if there are such nodes out there |
| 05:39 |
kahrl |
I'm pretty sure there are |
| 05:39 |
RealBadAngel |
i can remind only famous round barrels from the past |
| 05:39 |
kahrl |
due to the transparency issues, is the shaped halo even something that's feasible to go back to? |
| 05:40 |
RealBadAngel |
yes definitely |
| 05:40 |
RealBadAngel |
also with fixed water transparency issues |
| 05:40 |
RealBadAngel |
i do know how to fix that easily |
| 05:40 |
kahrl |
good to hear :) |
| 05:41 |
RealBadAngel |
short version: skip transparent stuff on solid pass |
| 05:41 |
RealBadAngel |
project all the water onto screen plane |
| 05:41 |
RealBadAngel |
get 2d shape |
| 05:41 |
RealBadAngel |
put transparent 2d shape onto solid render |
| 05:42 |
RealBadAngel |
voila |
| 05:42 |
kahrl |
ah so you only see the nearest transparent thing if there are overlapping ones |
| 05:42 |
kahrl |
yeah that works, many games do it that way |
| 05:43 |
RealBadAngel |
that will work for any transparent surfaces |
| 05:43 |
RealBadAngel |
i will code that when get mrt in |
| 05:43 |
kahrl |
does that require shaders or can it be done with the fixed pipeline? |
| 05:43 |
RealBadAngel |
mrt doesnt require shaders to work |
| 05:44 |
kahrl |
nice |
| 05:44 |
RealBadAngel |
i will just render transparent stuff to another RTT |
| 05:44 |
RealBadAngel |
and blend in the final run |
| 05:45 |
kahrl |
isn't RTT very slow though? |
| 05:45 |
RealBadAngel |
no, cant see any slowdowns |
| 05:45 |
RealBadAngel |
sofar, is mrt_1 branch slow for you? |
| 05:46 |
RealBadAngel |
mrt_1 uses already up to 10 RTTs per single frame |
| 05:46 |
kahrl |
I guess the slowdowns with using RTT for inventory textures came from the fact that you had to make one RTT for each item rendered |
| 05:46 |
kahrl |
hmm, 10 |
| 05:46 |
RealBadAngel |
kahrl, that was even worse, that was whole scene |
| 05:47 |
RealBadAngel |
or more, and still 60fps :) |
| 05:47 |
kahrl |
that seems to be on the order of magnitude of # of items per creative inventory page, isn't it? |
| 05:48 |
RealBadAngel |
kahrl, just creating new scene, camera, set light, rtt and all the shit was taking long |
| 05:48 |
RealBadAngel |
now we just define single viewport on the current RTT |
| 05:48 |
kahrl |
I see |
| 05:49 |
RealBadAngel |
in fact rendering iventory item is not different from rendering it in world |
| 05:50 |
RealBadAngel |
just viewport is small window instead of whole screen |
| 05:51 |
RealBadAngel |
so if you are rendering shitload of meshes each frame, a few dozens more doesnt make any difference |
| 05:59 |
RealBadAngel |
so, bout this offset, can i leave it or trash it? |
| 06:03 |
kahrl |
eh I don't care enough about it to insist on leaving it out |
| 06:04 |
kahrl |
but ask the other devs if they are ok with adding it |
| 06:05 |
RealBadAngel |
then propably there will be 10 different opinions on that, i think i will just remember bout it and remove it now |
| 06:06 |
kahrl |
well, ask 1 other dev |
| 06:10 |
|
Obani joined #minetest-dev |
| 06:10 |
RealBadAngel |
nah, removed it, that may be in fact not needed when i code transparent render pass trick |
| 06:10 |
RealBadAngel |
that would be general fix for all transparent stuff not only halo |
| 06:12 |
RealBadAngel |
kahrl, since dump is approved by est31 and you, could you merge it? |
| 06:12 |
kahrl |
yes, will do |
| 06:12 |
RealBadAngel |
thx |
| 06:12 |
RealBadAngel |
i will make that version mismatch PR on top of it right now |
| 06:14 |
kahrl |
merged |
| 06:14 |
* kahrl |
brb |
| 06:15 |
RealBadAngel |
ok |
| 06:25 |
RealBadAngel |
kahrl, #3690 |
| 06:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/3690 -- Set proper GLSL pixel shader version by RealBadAngel |
| 06:25 |
|
Icedream- joined #minetest-dev |
| 06:30 |
|
Hunterz joined #minetest-dev |
| 06:47 |
kahrl |
RealBadAngel: commented there |
| 07:23 |
RealBadAngel |
kahrl, vertex shader version does not match pixel shader one |
| 07:24 |
RealBadAngel |
for opegl 2.1 vertex shader is 1.1 pixel one 1.2 |
| 07:24 |
RealBadAngel |
theres no even 1.2 version of vertex shaders |
| 07:25 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/namespaceirr_1_1video.html#a296c30d8c7591c4e083f7b7e2d4b35ad |
| 07:26 |
RealBadAngel |
and http://irrlicht.sourceforge.net/docu/namespaceirr_1_1video.html#a4a0a5ebb62ca1b59a6bfb8e9fe81b250 |
| 07:26 |
kahrl |
oh, ok |
| 07:27 |
RealBadAngel |
before opegl 3.0 there was a mess with versioning |
| 07:28 |
RealBadAngel |
since 3.0 all versions numbers are the same for GLSL, pixel and vertex |
| 07:44 |
|
paramat left #minetest-dev |
| 07:59 |
|
Alduin_ joined #minetest-dev |
| 08:05 |
RealBadAngel |
btw, why doors in minetest game have separate selection boxes for bottom and upper parts? |
| 08:06 |
RealBadAngel |
upper part shall have selection boxes empty, lower one should have extended one to cover whole doors |
| 08:08 |
RealBadAngel |
selection boxes are not limited to size of a node, can be extended |
| 08:14 |
|
blaze joined #minetest-dev |
| 08:49 |
|
evmzh joined #minetest-dev |
| 09:06 |
|
Calinou joined #minetest-dev |
| 09:24 |
|
nrzkt joined #minetest-dev |
| 09:44 |
RealBadAngel |
nrzkt, see 3689 again |
| 10:11 |
RealBadAngel |
nrzkt, also can you check 3678? |
| 10:15 |
|
Krock joined #minetest-dev |
| 10:39 |
|
Obani joined #minetest-dev |
| 10:44 |
nrzkt |
link ? :D |
| 10:44 |
nrzkt |
#3689 #3678 |
| 10:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3689 -- Use single box for halo mesh by RealBadAngel |
| 10:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3678 -- Formspec: recreate item_image_button pressed state for its image and … by RealBadAngel |
| 10:47 |
|
xeranas joined #minetest-dev |
| 11:10 |
nrzkt |
RealBadAngel, comments done, okay for 3689, but little adjustements on 3678 |
| 11:21 |
RealBadAngel |
nrzkt, updated 3678 |
| 11:32 |
|
xeranas joined #minetest-dev |
| 11:43 |
|
Fixer joined #minetest-dev |
| 11:48 |
RealBadAngel |
kahrl, box.repair() works fine, updated |
| 11:48 |
|
Calinou joined #minetest-dev |
| 11:58 |
|
proller joined #minetest-dev |
| 12:13 |
RealBadAngel |
btw, we have made introduced camera offset because rendering far areas was glitchy, but then we have to translate all the mapblock meshes when offset changes. |
| 12:13 |
RealBadAngel |
that sounds pretty costly |
| 12:14 |
RealBadAngel |
couldnt it be better to change BS instead? |
| 12:15 |
RealBadAngel |
BS = 10 means shitload of useless calculations all the time anyway |
| 12:15 |
|
proller joined #minetest-dev |
| 12:16 |
nore |
RealBadAngel: we can't change BS because the problem is with single precision floats, so it is relative precision |
| 12:16 |
RealBadAngel |
who said we cant change BS? |
| 12:17 |
RealBadAngel |
ive applied BS = 1 and only physics get fucked up |
| 12:17 |
|
dfelinto joined #minetest-dev |
| 12:17 |
nore |
I mean, changing BS wouldn't fix that problem |
| 12:18 |
RealBadAngel |
at what distance problems with rendering were starting to appear? |
| 12:18 |
nore |
We could change it though, except if someone else sees problems |
| 12:18 |
nore |
Near the edge, like 16k or 30 nodes |
| 12:19 |
RealBadAngel |
perfect |
| 12:19 |
nore |
With thin nodeboxes, signs, etc |
| 12:20 |
nrzkt |
nore => #3687 (trivial) |
| 12:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/3687 -- Drop luaentity_common.h which is not included anywhere by nerzhul |
| 12:20 |
nrzkt |
please :) |
| 12:20 |
nrzkt |
RealBadAngel, i agree this conversion of BS vs float is anoying and add many and many conversions |
| 12:21 |
nrzkt |
sfan5, can you look ^ too please ? |
| 12:21 |
nore |
nrzkt: I can't test it right now, but it looks good :) |
| 12:24 |
RealBadAngel |
dividing coords by 10 will solve the problem then |
| 12:24 |
RealBadAngel |
im doing mapblock_mesh cleanup atm, when im done with that i will remove camera offset and BS multiplications from whole engine |
| 12:24 |
RealBadAngel |
that should save lotsa time for us |
| 12:24 |
RealBadAngel |
with mapblock_mesh, btw, im coding using tangent vertices only when specific effects are used, so one could use shaders only for waving and other stuff without tangent space |
| 12:24 |
nrzkt |
nore, it was not included anywhere :p |
| 12:25 |
RealBadAngel |
that should speed up low end boxes same as without shaders at all |
| 12:25 |
nrzkt |
RealBadAngel, will you update your mapblock server side cleanup ? This optimization is quite interesting for end users (and bandwidth) |
| 12:25 |
|
Megaf joined #minetest-dev |
| 12:25 |
RealBadAngel |
nrzkt, you mean 3166? |
| 12:26 |
nore |
RealBadAngel: no, it won't, because floats are *relative* precision |
| 12:28 |
RealBadAngel |
nore, i will check it anyway |
| 12:28 |
nrzkt |
#3166 |
| 12:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/3166 -- Send to clients only changed node metadata instad of whole mapblock by RealBadAngel |
| 12:28 |
nrzkt |
yes :) |
| 12:29 |
RealBadAngel |
nrzkt, i started with it a few days ago again, but still havent finished it, put it away for a moment, waiting for some solutions to pop up in my mind ;) |
| 12:30 |
nrzkt |
RealBadAngel, no problem :) |
| 12:30 |
nrzkt |
kahrl okay for merging #3687 ? |
| 12:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/3687 -- Drop luaentity_common.h which is not included anywhere by nerzhul |
| 12:31 |
RealBadAngel |
nrzkt, ive fixed a few issues with it already, just grouping updates into single package left (thats a bit hard, because i do have put away changes that are too far and do that per each player connected) |
| 12:31 |
RealBadAngel |
current design isnt helping doing so |
| 12:32 |
RealBadAngel |
i think i will need to skip meta updates in current loop and make another one focused only on meta changes |
| 12:32 |
kahrl |
nrzkt: looks good to me |
| 12:33 |
kahrl |
RealBadAngel: changing BS will break existing maps |
| 12:34 |
RealBadAngel |
if the gain in speed will be significant imho it will be worth it |
| 12:34 |
kahrl |
coordinates including the BS factor are used at least in player coordinates and AFAIK a few things relating to objects |
| 12:35 |
kahrl |
I say spawning a player somewhere far away from where they last left (and possibly deep underground) is never worth it |
| 12:35 |
RealBadAngel |
if it will be only problem with incorrect spawn once that wouldnt be any problem at all |
| 12:36 |
kahrl |
uh |
| 12:37 |
kahrl |
having a completely black screen (because you're inside stone), not being able to do anything, and having to cheat (use /teleport) to fix it isn't "any problem at all"? |
| 12:38 |
kahrl |
if the player even figures out that the problem is that they have to teleport, and doesn't just quit such a broken game out of frustrating |
| 12:38 |
RealBadAngel |
"excuse me, mr moderator, could you teleport me back to spawn please?" |
| 12:38 |
kahrl |
frustration* |
| 12:39 |
kahrl |
I'm sure the moderators will be pleased with this work-creation program |
| 12:39 |
RealBadAngel |
kahrl, lets just check if the change is worth thinkin about possible problems |
| 12:39 |
kahrl |
and if there is no moderator? (singleplayer, or no one around) |
| 12:39 |
RealBadAngel |
if it will be significant gain then we can think what to do with it, ok? |
| 12:40 |
kahrl |
yeah, but like nore said, there won't be any |
| 12:40 |
kahrl |
since floating point precision is relative to the size of the number |
| 12:41 |
RealBadAngel |
if problem started with 16k or more and then max will be 3.2k ? |
| 12:42 |
RealBadAngel |
im going to do those two things at once, cut BS and trash camera offset |
| 12:44 |
nore |
RealBadAngel: no, it won't help, since all coordinates will be affected |
| 12:45 |
nore |
And about old maps, they should be properly converted |
| 12:50 |
RealBadAngel |
plants and leaves are waving funny way with BS=1 ;) (in shaders BS = 10 still) |
| 12:53 |
RealBadAngel |
nore, on which objects i could observe rendering glitches? |
| 12:53 |
RealBadAngel |
im in the world with BS=1 and camera_offset_step = 40000 |
| 12:53 |
nore |
RealBadAngel: signs, snow, and other thin nodeboxes |
| 12:54 |
nore |
anything with the signlike drawtype actually |
| 12:58 |
RealBadAngel |
nore, http://i.imgur.com/D9yXLvM.png |
| 12:58 |
RealBadAngel |
how about that? |
| 12:59 |
nore |
RealBadAngel: this one isn't signlike |
| 12:59 |
RealBadAngel |
you said snow |
| 12:59 |
RealBadAngel |
snow is nodebox |
| 13:00 |
nore |
Yeah, but I thought it was thinner |
| 13:00 |
kahrl |
don't you have to be farther away anyway |
| 13:00 |
nore |
and you have to move a bit away and look at it from above IIRC |
| 13:00 |
nore |
ah, I know |
| 13:01 |
nore |
go to coordinates like 30k, 30k, 30k too |
| 13:01 |
nore |
so all coordinates are big |
| 13:01 |
nore |
else, it will only show the effect in some directions |
| 13:01 |
RealBadAngel |
at y=30k i wont place anything |
| 13:04 |
RealBadAngel |
were at 30k,0,-30k, 30k,0,30k |
| 13:05 |
RealBadAngel |
still cant see any glitches |
| 13:06 |
RealBadAngel |
http://i.imgur.com/iCEuy0o.png |
| 13:06 |
RealBadAngel |
here also nothing |
| 13:07 |
nore |
hm.. |
| 13:07 |
nore |
still, it seems strange to me |
| 13:07 |
RealBadAngel |
nore, you can check it by yourself, set BS = 1, and camera_offset_step to 40k |
| 13:08 |
nore |
I'll try that when I will have some time |
| 13:08 |
RealBadAngel |
i will make BS = 10 again and compare |
| 13:10 |
RealBadAngel |
with offseting disabled ofc |
| 13:11 |
|
H-H-H joined #minetest-dev |
| 13:12 |
|
Player_2 joined #minetest-dev |
| 13:12 |
RealBadAngel |
nore, ok, glitches are back |
| 13:13 |
nore |
that *is* strange |
| 13:13 |
RealBadAngel |
i can see flickering textures |
| 13:14 |
RealBadAngel |
so, BS + camera_offset = BullShit. Q.E.D. |
| 13:24 |
RealBadAngel |
a conclusion, that would be an accurate reason to release .14 , dont you think so? :) |
| 13:27 |
RealBadAngel |
at 30k glitches are visible at almost everything, texures are fighting each other |
| 13:27 |
RealBadAngel |
selection boxes do disappear |
| 13:27 |
RealBadAngel |
nodeboxes are "shaking" when moving camera |
| 13:36 |
RealBadAngel |
kahrl, so, what do you think about it now? |
| 13:41 |
RealBadAngel |
do you know what happens when you cross the camera offset barrier ? |
| 13:41 |
RealBadAngel |
turn on profiler and look at this mess |
| 13:44 |
RealBadAngel |
folks are complainin about spikes and "stuttering", thats propably main reason |
| 13:45 |
RealBadAngel |
when some1 is walkin around 200,0,0 crossing the offset change line, all the meshes around are translated and refreshed all the time |
| 13:52 |
RealBadAngel |
also that would the reasons why VBO gets jerky from time to time |
| 13:52 |
RealBadAngel |
it means also reloading all the meshes into VRAM again |
| 13:54 |
RealBadAngel |
so,"Down with the bloody big head ;) |
| 14:36 |
|
STHGOM joined #minetest-dev |
| 14:38 |
nrzkt |
kahrl, nore #3692 ? :) |
| 14:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/3692 -- v2d & aabbox3d cleanups by nerzhul |
| 14:49 |
|
kaadmy joined #minetest-dev |
| 15:04 |
|
est31 joined #minetest-dev |
| 15:07 |
est31 |
nrzkt, sorry for the email spam |
| 15:09 |
RealBadAngel |
well, with completely no camera_offset code and BS = 1.0 glitches are in fact still here, harder to notice but not really gone |
| 15:10 |
|
enesbil joined #minetest-dev |
| 15:40 |
RealBadAngel |
est31, could you check 3678 too? kahrl and nrzkt already reviewed it |
| 15:42 |
|
Calinou joined #minetest-dev |
| 15:42 |
nrzkt |
est31: rebased :) |
| 15:43 |
est31 |
nrzkt, PR is fine with me |
| 15:45 |
nrzkt |
okay, i changed the commit message to be clear now |
| 15:47 |
|
Darcidride joined #minetest-dev |
| 15:48 |
est31 |
nrzkt, should I merge, or do you want to merge |
| 15:52 |
nrzkt |
if you want, go :) |
| 15:58 |
|
johnnyjoy joined #minetest-dev |
| 15:58 |
nrzkt |
thanks est31 |
| 16:01 |
|
hmmmm joined #minetest-dev |
| 16:09 |
|
book` joined #minetest-dev |
| 16:47 |
Fixer |
i'm complaining yes |
| 16:47 |
Fixer |
stutter is at least since 0.3.* |
| 16:51 |
|
jin_xi joined #minetest-dev |
| 16:53 |
jin_xi |
woah, RBA you talking about killing camera_offset? |
| 16:53 |
* jin_xi |
hopes |
| 16:54 |
|
Hunterz joined #minetest-dev |
| 16:57 |
RealBadAngel |
jin_xi, atm i can see slight glitches at 30k, but really cant see anything at 2k no matter how hard i try |
| 16:57 |
RealBadAngel |
why offset was set to 200? not 2k for example? |
| 16:58 |
jin_xi |
idk but crossing offset is way to visible to users when it should not be. it messes with some mods (attachment stuff if i remember right) |
| 16:59 |
RealBadAngel |
i will try to dig some more around it but maybe later |
| 16:59 |
RealBadAngel |
anyway results are promising |
| 17:01 |
|
Terusthebird joined #minetest-dev |
| 17:15 |
kaadmy |
wow the tonemapping is really obvious with pixture ;) |
| 17:16 |
kaadmy |
i have a problem regarding z-depth fighting with waving water too |
| 17:17 |
kaadmy |
Look at the water to the right of the waterfall area https://usercontent.irccloud-cdn.com/file/BAS9qPBk/zdepthfighting.png |
| 17:17 |
kaadmy |
and i get 4 fps with shaders :( |
| 17:17 |
kaadmy |
but i get about 20 with no shaders anyway ;) |
| 17:18 |
RealBadAngel |
i will speed up shaders without bump mapping and parallax too |
| 17:19 |
kaadmy |
i had shaders on with tonemapping and waving water and plants |
| 17:21 |
RealBadAngel |
but even if you are not using bumps or parallax tangent space vertices are used |
| 17:22 |
RealBadAngel |
and that seems to be a problem for slower boxes/gpus |
| 17:23 |
kaadmy |
and i noticed recently without shaders has gotten slower |
| 17:23 |
kaadmy |
5-6 fps slower with 30-node viewing range |
| 17:23 |
kaadmy |
while before in about the same area i got a good fps with 60+ viewing range |
| 17:27 |
RealBadAngel |
last change that could affect fps without shaders was about to speed it up |
| 17:27 |
RealBadAngel |
and it is confirmed by others that they have regained 20% more fps |
| 17:28 |
RealBadAngel |
change was pushed 4 days ago |
| 17:30 |
kaadmy |
i'm using git, updated yesterday |
| 17:32 |
RealBadAngel |
could you check which of latest changes from a few days is causing less fps for you? |
| 17:33 |
Fixer |
you mean tanget commit? |
| 17:33 |
Fixer |
i lost 0-2 FPS with it |
| 17:33 |
Fixer |
paramat on other hand gained +20% |
| 17:33 |
Fixer |
tangent* |
| 17:33 |
Obani |
I think I gained some FPSs too |
| 17:34 |
RealBadAngel |
the tangent commit was about non shaders only |
| 17:34 |
kaadmy |
my craptop barely has opengl in the first place |
| 17:34 |
kaadmy |
anyway halos work now |
| 17:35 |
kaadmy |
and the fps seems to be much better now with latest git... |
| 17:35 |
Fixer |
RealBadAngel, yes, compared to earlier build i lost 0-2 fps in no_shaders mode |
| 17:35 |
kaadmy |
still have the broken animations tho |
| 17:35 |
Fixer |
RealBadAngel, and gained that lag thing %) |
| 17:35 |
RealBadAngel |
kaadmy, broken animations of what? |
| 17:35 |
kaadmy |
the spinning items in inventory look neat ;) |
| 17:36 |
Fixer |
inventory looks nice, shading is cool |
| 17:36 |
kaadmy |
RealBadAngel: the player model animation only plays one frame before re-starting |
| 17:36 |
kaadmy |
i'll test with minetest_game, see if it's pixture's problem |
| 17:36 |
RealBadAngel |
kaadmy, you can blame for many things but not for players animation for sure ;) |
| 17:37 |
kaadmy |
yup, pixture's problem |
| 17:37 |
RealBadAngel |
Fixer, im working on mapblock mesh atm, im going to speed up things here a bit |
| 17:37 |
|
ud1 joined #minetest-dev |
| 17:38 |
Fixer |
RealBadAngel, nice, good luck with that! |
| 17:42 |
RealBadAngel |
well, atm is not any nice ;) http://i.imgur.com/3soR5n3.png |
| 17:42 |
RealBadAngel |
trying to find a damn bug lol |
| 17:42 |
kaadmy |
huh :) |
| 17:42 |
Fixer |
RealBadAngel, feels like my old home, with faulty Radeon 9600 memory |
| 17:42 |
Obani |
lol |
| 17:43 |
Obani |
Is this experimental art ? |
| 17:43 |
kaadmy |
nope, it's a buttload of $$$ if you put it on a canvas :D |
| 17:43 |
RealBadAngel |
i wouldnt call that damn bug an artist ;) |
| 17:43 |
Obani |
Well no, you are :p |
| 17:44 |
Obani |
You made this :p |
| 17:44 |
Krock |
Interesting art you made there |
| 17:45 |
RealBadAngel |
i got a better lookin bug with pp recently |
| 17:45 |
kaadmy |
would it be possible to have animated wield/inventory images? |
| 17:45 |
kaadmy |
like animated torches in your hand? |
| 17:46 |
RealBadAngel |
try this one: http://i.imgur.com/uBR8lTX.png |
| 17:46 |
RealBadAngel |
this is really an effect of bug |
| 17:47 |
Obani |
Nice one |
| 17:48 |
RealBadAngel |
kaadmy, why not, doable |
| 17:48 |
Obani |
include it in luaapi for we can make effects with it :p |
| 17:48 |
RealBadAngel |
and those are shaders for paramat: http://i.imgur.com/dToCnLw.png ;) |
| 18:30 |
|
linkedinyou joined #minetest-dev |
| 18:31 |
|
nrzkt joined #minetest-dev |
| 18:40 |
kaadmy |
another nice addition would be to have flat node drawtypes, like plantlike, signlike, torchlike and such to use extruded wield meshes |
| 18:46 |
kaadmy |
dang, the meshes for inventory items seems to have massive performance problems for me |
| 18:46 |
kaadmy |
i get 6 fps in the inventory |
| 18:47 |
kaadmy |
7 fps if i disable the item animations |
| 18:47 |
kaadmy |
wow |
| 18:47 |
kaadmy |
that's what causes the huge fps drops for me |
| 18:47 |
kaadmy |
disabling the hud goes from 25 to 50 fps |
| 18:48 |
kaadmy |
soo.. is there an option to disable the mesh items? |
| 18:55 |
kaadmy |
RealBadAngel: is it possible to disable the item meshes? |
| 18:55 |
sofar |
item animations can be disabled separately |
| 18:55 |
kaadmy |
not animations, the item meshes |
| 18:56 |
kaadmy |
this(https://github.com/minetest/minetest/commit/6cd2b3b445bf558fda1e5a7908adef8e3a45449a) |
| 18:56 |
sofar |
do you have animations enabled? |
| 18:56 |
kaadmy |
no |
| 18:56 |
kaadmy |
doesn't change anything |
| 18:56 |
kaadmy |
and disabling the hud with all 8 slots with items in them goes from 15-20 to 40 |
| 18:57 |
kaadmy |
fps* |
| 18:58 |
sofar |
pretty sure it can't be disabled just like that |
| 18:59 |
kaadmy |
i'm trying to find a way to revert back to images |
| 18:59 |
kaadmy |
seems like too much has been changed to allow that easily tho :( |
| 19:05 |
Fixer |
have no problem with 3d items in inv |
| 19:08 |
kaadmy |
<kaadmy> my craptop barely has opengl in the first place |
| 19:08 |
kaadmy |
^ most people won't have that problem |
| 19:31 |
|
kaeza joined #minetest-dev |
| 19:34 |
|
Terusthebird joined #minetest-dev |
| 19:35 |
|
Sokomine joined #minetest-dev |
| 19:51 |
Hijiri |
Does on_rightclick for items work even if the client is on stable? |
| 19:52 |
Hijiri |
since RMB state is sent |
| 19:53 |
Hijiri |
actually I can't find item on_rightclick in the lua doc on master, maybe I was mistaken |
| 19:53 |
|
Amaz joined #minetest-dev |
| 19:53 |
Hijiri |
oh, I see it |
| 19:53 |
Hijiri |
on_secondary_use |
| 19:55 |
|
blaze joined #minetest-dev |
| 19:55 |
Hijiri |
I would guess that it needs a newer client since the client has to send what it's pointing too I guess |
| 19:55 |
Hijiri |
ok yeah nevermind, I read the issue introducing it originally and it says old clients won't send the event |
| 20:02 |
|
kaeza joined #minetest-dev |
| 20:38 |
|
ssieb joined #minetest-dev |
| 20:51 |
|
Taoki joined #minetest-dev |
| 21:19 |
|
kaeza joined #minetest-dev |
| 21:49 |
|
turtleman joined #minetest-dev |
| 22:25 |
|
kaeza joined #minetest-dev |
| 22:43 |
|
Taoki joined #minetest-dev |
| 23:18 |
Taoki |
RealBadAngel: HDR seems to work nicely in latest master. Eagerly waiting for bloom and DoF to be there too :) |
| 23:19 |
Taoki |
Also, I'm not seeing items spin in the inventory, like in that video. Is there a setting for that? |
| 23:20 |
sofar |
yes, it's a hidden setting in minetest.conf |
| 23:21 |
sofar |
no wait |
| 23:21 |
sofar |
it's actually in the UI |
| 23:21 |
Taoki |
What's the name? |
| 23:22 |
sofar |
inventory_items_animations |
| 23:23 |
Taoki |
Thanks. Works for me, looks great! |
