| Time |
Nick |
Message |
| 01:08 |
|
olliy joined #minetest-dev |
| 01:33 |
|
Foz joined #minetest-dev |
| 01:33 |
|
oiaohm joined #minetest-dev |
| 02:57 |
|
el joined #minetest-dev |
| 04:56 |
|
Icedream joined #minetest-dev |
| 05:15 |
|
DI3HARD139 joined #minetest-dev |
| 06:15 |
|
fluxflux joined #minetest-dev |
| 06:24 |
|
calcul0n joined #minetest-dev |
| 06:26 |
|
RichardTheTurd joined #minetest-dev |
| 06:52 |
|
skyliner_369 joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:28 |
|
oil_boi joined #minetest-dev |
| 08:30 |
|
NetherEran joined #minetest-dev |
| 09:52 |
|
Amaz joined #minetest-dev |
| 10:25 |
|
erlehmann joined #minetest-dev |
| 10:42 |
|
absurb joined #minetest-dev |
| 11:10 |
|
Fixer joined #minetest-dev |
| 11:38 |
|
erlehmann joined #minetest-dev |
| 11:49 |
|
Beton joined #minetest-dev |
| 13:23 |
|
jonadab joined #minetest-dev |
| 14:35 |
|
olliy joined #minetest-dev |
| 14:39 |
|
Taoki joined #minetest-dev |
| 14:43 |
|
calcul0n_ joined #minetest-dev |
| 15:42 |
|
hecks joined #minetest-dev |
| 15:43 |
hecks |
hi, what does m_ stand for in class fields? |
| 15:43 |
sfan5 |
member |
| 15:44 |
hecks |
so this just means "not a local or outside variable"? |
| 15:45 |
sfan5 |
yes |
| 15:45 |
sfan5 |
it's not supposed to be used for new classes though, just for consistency with old code |
| 15:46 |
hecks |
hm, okay, I actually like the distinction, but I'll keep that in mind |
| 15:47 |
hecks |
while you're here, could you please roughly explain to me the path that a mapblock takes from a network message to the mesh displayed in clientmap.cpp, if you're any familiar with this code? |
| 15:49 |
hecks |
I'm trying to understand this stuff in order to do something about the performance, I know how they're being drawn so far |
| 15:50 |
sfan5 |
not familiar with it but I imagine it's somewhat like this: "packet handler deserializes and puts it into local map; client requests a mesh and doesn't find it in cache; mesh generator thread takes it from local map and generates the mesh, putting it in cache; at next frame(?) the mesh is rendered too" |
| 15:51 |
hecks |
right, the cache, I forgot about that |
| 15:51 |
hecks |
is there anyone still active who knows more about this area? |
| 15:53 |
sfan5 |
unfortunately not, your best bet is to look at the code until it makes sense |
| 15:53 |
sfan5 |
the performance of what exactly did you want to look at? |
| 15:53 |
hecks |
I want to reduce drawcalls, possibly by merging block meshes or straight up decoupling drawing from the mapblock structure |
| 15:54 |
hecks |
the problem is that minetest mapblocks are tiny and the chatter between the game and the graphics driver is killing it |
| 15:54 |
hecks |
I've already eliminated geometry counts, fragment fill and other causes |
| 15:55 |
hecks |
meanwhile batches are an obvious hog, starting in the hundreds at low draw distances and getting into thousands with more than that |
| 15:55 |
hecks |
also getting worse the more diverse a mapblock is |
| 15:56 |
hecks |
materials are already batched but this is not enough, a block-layer can contain as little as one face if we're unlucky |
| 15:57 |
sfan5 |
I have nothing useful to comment about that, good luck |
| 15:57 |
hecks |
binding and drawing buffers with these ancient GL methods is not cheap sadly |
| 16:13 |
oil_boi |
So you're finally gonna defragment the opengl implementation to speed up new graphics cards hecks? |
| 16:13 |
hecks |
no, just the meshes |
| 16:14 |
oil_boi |
That's still super noice, there's no reason my rx580 black edition should only be getting 350fps on view distance 20 |
| 16:14 |
hecks |
there's something up with that actually |
| 16:14 |
hecks |
I get 240 fps just looking at the sky, 4ms are being eaten for *nothing* |
| 16:15 |
oil_boi |
Yes, especially when gta v runs 120fps on ultimate, what are those 4ms even been doing, I'm going to check right now |
| 16:15 |
oil_boi |
draw meshes is taking 0.05555 ms |
| 16:15 |
hecks |
check it; fly high up, look at the skybox |
| 16:15 |
hecks |
drawtime will still somehow be 4ms |
| 16:16 |
oil_boi |
for some reason only getting 220fps on superflat |
| 16:16 |
hecks |
maybe less for you but something noticeable for sure |
| 16:16 |
hecks |
but anyway, upgrading GL would take a new irrlicht video driver implementation, and dramatically different ways of doing things |
| 16:16 |
hecks |
instancing sure would solve this issue elegantly |
| 16:16 |
hecks |
but it wouldn't be compatible and batching is kinda easier to do |
| 16:17 |
hecks |
I'll just merge things into mega-blocks or something |
| 16:17 |
oil_boi |
sky rendering 0.00015 fps at y 350, I'm an fps snob so this is still irritating |
| 16:17 |
hecks |
sure is; "empty scene" is generally 2000+ fps stuff |
| 16:17 |
Krock |
will merge #10143 in 15 minutes |
| 16:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/10143 -- FormSpec: Don't stop style parsing on unknown property by v-rob |
| 16:17 |
hecks |
even irrlicht itself renders its demos this fast, with things being drawn and all |
| 16:18 |
hecks |
also who the hell draws the skybox before the world? should fix this if possible |
| 16:18 |
oil_boi |
That is an old technique |
| 16:19 |
hecks |
for... what exactly? don't you draw it last to cull as many fragments as you can? |
| 16:19 |
oil_boi |
it is easier to draw geometry on top of an existing background elements, it's the lazy way to do it, that's why the skybox is the "background" |
| 16:19 |
hecks |
only in a really bad software renderer |
| 16:20 |
oil_boi |
Welcome to irrlicht m8 |
| 16:20 |
hecks |
:] |
| 16:20 |
hecks |
ah yes, that wonderful soft driver |
| 16:20 |
hecks |
try switching that on sometime for a laugh |
| 16:20 |
oil_boi |
One thing I'm having an interesting time with is dynamic map updates with pistons, causing some interesting fps mesh rebuilding problems |
| 16:21 |
hecks |
every time a mapblock is touched, it's being remeshed |
| 16:21 |
oil_boi |
Oi, you're going to give me a hernia talking like that one, I'm gonna pretend I'm just a bad programmer |
| 16:21 |
oil_boi |
Oh wait |
| 16:21 |
hecks |
I hope that doesn't ruin my idea of merging blocks |
| 16:22 |
oil_boi |
Do it and create something with mesecons or redstone with pistons as a test and see how it goes |
| 16:22 |
hecks |
a frameship |
| 16:22 |
hecks |
no better way to kill a server than a frameship |
| 16:23 |
hecks |
and it's also a full remesh |
| 16:23 |
oil_boi |
Is that's what is happening now? |
| 16:23 |
hecks |
hm? no, I'm getting thousands of drawcalls on static scenes |
| 16:23 |
hecks |
that's my problem |
| 16:24 |
hecks |
there's also one funny thing about irrlicht here |
| 16:24 |
hecks |
it has... a minimum vertex count for VBOs (?????) |
| 16:24 |
hecks |
500 by default |
| 16:25 |
oil_boi |
https://i.imgur.com/XkJyaEL.png there are no animated meshes in this scene |
| 16:25 |
hecks |
there is in fact a line somewhere in minetest that disables that madness, but someone commented it out a very long time ago |
| 16:25 |
hecks |
so you're getting 3ms with nothing; but keep in mind that the hud and text also eat a lot |
| 16:26 |
|
fluxflux joined #minetest-dev |
| 16:26 |
hecks |
text rendering is pretty crap |
| 16:27 |
oil_boi |
Ah there's my fps https://i.imgur.com/LhfU16R.png |
| 16:27 |
oil_boi |
You're right, 800 with no text at all |
| 16:27 |
oil_boi |
When I build the game on windows I get like 50 errors about the font rendering engine |
| 16:27 |
hecks |
still crap; also even the debug display counts as text |
| 16:28 |
hecks |
see how it very briefly lerps down from a higher fps when you enable it |
| 16:28 |
oil_boi |
Warning! Unsafe mix of BOOL and INT! |
| 16:28 |
oil_boi |
Oh of course |
| 16:28 |
hecks |
text rendering might also be having batching issues |
| 16:29 |
oil_boi |
I bet it's also a cause of the memory leak |
| 16:29 |
hecks |
crap, what memory leak... do you too get an "out of memory" after leaving and entering the game a few times? |
| 16:30 |
oil_boi |
No, I have 16 gb of memory, but I can make it reach 12GB at the main menu |
| 16:30 |
hecks |
ahahahahaha what |
| 16:30 |
hecks |
just by generating strings? |
| 16:30 |
Krock |
old news. it was already like this in 0.4.7-dev |
| 16:30 |
oil_boi |
Ah I have some free time, let me show you, I'll be back in a little while |
| 16:30 |
Krock |
media not fully unloading after game leave |
| 16:31 |
hecks |
all media? |
| 16:32 |
Krock |
cannot tell anything more precise - it's the only thing in Minetest that consumes this much RAM and varies per server |
| 16:32 |
hecks |
and is vorbis decoded to a wave in ram instead of being streamed, by any chance? |
| 16:32 |
Krock |
not all media - since the RAM usage decreases after leaving |
| 16:32 |
Krock |
merging trivial PR.... |
| 16:32 |
hecks |
cause I've been getting this a lot since adding audio |
| 16:41 |
|
Lone_Wolf joined #minetest-dev |
| 16:44 |
sfan5 |
pretty sure it's decoded entirely in ram yes |
| 16:45 |
oil_boi |
I finally caught this bug during my endeavor https://youtu.be/7HNBXRKnkas |
| 16:47 |
hecks |
have you ever been so angry that you just vibrated your feet in place at 60hz |
| 16:50 |
sfan5 |
literally never seen that bug |
| 16:51 |
sfan5 |
did you compile the engine yourself? using msvc? |
| 16:52 |
hecks |
closest I've ever seen to that was when setting jump force to 0 |
| 17:01 |
oil_boi |
Yes and visual studio everything's stock, only happens in MTG |
| 17:04 |
hecks |
wait, is that snow full nodes or those tiny slabs on top? |
| 17:06 |
oil_boi |
I have no idea, it happens on anything randomly |
| 17:06 |
hecks |
oh okay |
| 17:06 |
oil_boi |
Sometimes I don't even have to look down and it blows my ears up |
| 17:06 |
hecks |
but... only mtg? curious |
| 17:07 |
oil_boi |
Yep |
| 17:07 |
oil_boi |
Also the game hit 7 gb and reset somehow, it went to 0MB and froze |
| 17:07 |
hecks |
what if you transplanted some of the sounds to devtest and tried to repro it |
| 17:07 |
oil_boi |
But here, I did a little more and https://i.imgur.com/IZILm7i.png oof oof oof |
| 17:08 |
oil_boi |
I just realized the main menu is using 50% of my gpu there, WAT |
| 17:13 |
oil_boi |
I forgot I had the game open oh my god |
| 17:14 |
oil_boi |
My cpu went from 70C to 28C |
| 17:15 |
oil_boi |
It's water cooled |
| 17:17 |
hecks |
oh yeah, this is the primary reason I'm looking into map drawing perf |
| 17:18 |
hecks |
I just want to have minetest open without being cooked alive |
| 17:21 |
oil_boi |
This was left open at the main menu man |
| 17:22 |
hecks |
but I thought the main menu was capped at 30 fps? |
| 17:22 |
hecks |
it sure feels that way |
| 17:22 |
oil_boi |
It's linked to the in game pause menu apparently, 2000fps at the main menu |
| 17:23 |
hecks |
oh so you have it unlimited in the config? |
| 17:23 |
oil_boi |
Yep, the pause menu in game basically stutters if I have it below 250 |
| 17:24 |
oil_boi |
It's really, really annoying |
| 17:24 |
hecks |
well, it's either vsync or weld a refrigerator to your GPU |
| 17:25 |
oil_boi |
The real question is, why is the pause menu fps linked to the main menu fps? |
| 17:27 |
|
lisac joined #minetest-dev |
| 17:28 |
oil_boi |
vsync with 60fps limit at main menu is using 5% gpu and only rendering at 37 fps |
| 17:28 |
oil_boi |
What even is life |
| 17:28 |
Krock |
oil_boi: sleep_ms(25); in the code. this has already been reported |
| 17:29 |
hecks |
oh wow |
| 17:29 |
oil_boi |
What else is sleeping during the main client loop? |
| 17:30 |
Krock |
in-game it sleeps when vsync does not do the frame capping |
| 17:30 |
Krock |
game.cpp IIRC |
| 17:31 |
Krock |
oil_boi: regarding your "empty" world rendering: I suppose the GPU is not fully under load, but rather the CPU trying to render the text |
| 17:33 |
Krock |
TTF rendering can be quite slow, especially because it's rendering the text twice per frame (shadow and white surface text) |
| 17:34 |
hecks |
could probably do that with a shader instead |
| 17:34 |
Krock |
that would be lovely, yes. I have zero clue about GPU stuff |
| 17:34 |
oil_boi |
meshupdatethread is sleeping |
| 17:34 |
Krock |
oil_boi: separate thread. does not matter. |
| 17:35 |
hecks |
I wonder if it's something as bad as a draw per character, or even glBegin |
| 17:35 |
Krock |
hecks: it "plots" all same colored characters at the same time |
| 17:35 |
Krock |
FYI. dunno how important that is |
| 17:35 |
hecks |
but does it cache the text mesh? |
| 17:36 |
Krock |
mesh? All I can see are 2D image batch draws; https://github.com/minetest/minetest/blob/master/src/irrlicht_changes/CGUITTFont.cpp#L554-L566 |
| 17:37 |
hecks |
uh oh |
| 17:37 |
hecks |
that's glBegin |
| 17:37 |
hecks |
per character |
| 17:37 |
hecks |
this is what kills statbars too |
| 17:37 |
Krock |
so glBegin is slow? |
| 17:37 |
hecks |
definitely more than a cached VBO |
| 17:38 |
hecks |
maybe the "batch" part here does something to make it faster but I know that text in minetest is atrociously slow so I wouldn't be surprised |
| 17:38 |
oil_boi |
client\fontengine.h(51,1): warning C4805: '|': unsafe mix of type |
| 17:38 |
oil_boi |
55 times |
| 17:38 |
hecks |
that ain't it, the font engine only makes the sprites out of TTFs, right? |
| 17:38 |
Krock |
unsafe but works just fine |
| 17:38 |
hecks |
bools *are* ints :] |
| 17:39 |
oil_boi |
Also, with the mesh generation thread disabled, I am now getting 350-430 fps vs 200 |
| 17:39 |
oil_boi |
mesh generation sleep* |
| 17:39 |
Krock |
hecks: found this in my history: https://github.com/minetest/irrlicht/blob/6fe86df4b37db76bf9d17f515b704de3cc5e1a68/source/Irrlicht/COpenGLDriver.cpp#L2140-L2174 |
| 17:39 |
hecks |
hmmmmmm |
| 17:40 |
Krock |
oil_boi: please point out the line you changed |
| 17:40 |
Krock |
this could mean there's an unopened lock |
| 17:41 |
oil_boi |
I went crazy so I will pastebin |
| 17:41 |
hecks |
yup, literally draws a quad by feeding it to the driver vert by vert, this is slow |
| 17:41 |
hecks |
the proper way to do text is to make an atlas out of the font, then make and cache meshes for strings since strings do not change often |
| 17:42 |
hecks |
but this is a can of worms and it's hard to do right |
| 17:42 |
hecks |
when you add unicode and especially CJK chars into the mix, it's a world of pain |
| 17:43 |
Krock |
if it were at least possible to cache it |
| 17:43 |
Krock |
render once to a texture, and then draw that |
| 17:43 |
hecks |
that too is possible |
| 17:43 |
hecks |
but the atlas approach lets you change it faster if the character set doesn't change |
| 17:43 |
Krock |
freetype should already do the rendering for us |
| 17:44 |
hecks |
but freetype only gives you bitmaps from ttf, doesn't it |
| 17:44 |
hecks |
it's a game engine's job to make the atlases for GPU friendly rendering |
| 17:44 |
Krock |
looks like that... yes. |
| 17:44 |
hecks |
anyway if you're using an atlas and someone is typing ansi only, you don't have to reupload any textures and it's fast |
| 17:45 |
oil_boi |
https://pastebin.com/raw/M49LY7hX |
| 17:45 |
oil_boi |
Oh by the way, you guys know that weird like pause you get when you load into singleplayer? It's instant now |
| 17:45 |
oil_boi |
There is no delay entering a world after hitting play |
| 17:45 |
hecks |
so you just commented out all the sleeps and the game is smoother? |
| 17:45 |
hecks |
madman |
| 17:45 |
hecks |
I'm gonna try this |
| 17:45 |
Krock |
oil_boi: you set the network throughput to may speed |
| 17:46 |
Krock |
*max |
| 17:46 |
hecks |
whoops, so which sleep should be left alone? |
| 17:46 |
hecks |
then again it's okay to do this in singleplayer |
| 17:46 |
oil_boi |
If you think that's bad, this is with unlimited viewing range https://i.imgur.com/1LjNKwP.png, 320 fps while taking a screenshot with no weird stutter glitch happening |
| 17:47 |
hecks |
aaaaaaaa |
| 17:47 |
oil_boi |
With unlimited viewing range |
| 17:48 |
Krock |
oh no |
| 17:48 |
Krock |
QueuedMeshUpdate *MeshUpdateQueue::pop() holds a lock |
| 17:48 |
Krock |
though only during pop... not after |
| 17:48 |
oil_boi |
Time to comment that out too |
| 17:49 |
Krock |
dno't |
| 17:49 |
Krock |
it won't change anything and make the rendering instable |
| 17:49 |
Krock |
*unstable |
| 17:49 |
oil_boi |
*breaking news today, a local man makes the entire local area internet go down as the server room catches fire, we'll be back with more at 11* |
| 17:50 |
Krock |
you cannot simply remove locks and expect it to work better. they're there to avoid concurrency issues |
| 17:51 |
Krock |
I don't understand how the FPS is higher with sleep_ms(m_generation_interval); commented out. are you sure about that? |
| 17:51 |
hecks |
but you're not supposed to sleep while locking something either, in case that's happening |
| 17:51 |
Krock |
hecks: well, that's what I thought. It doesn't happen. |
| 17:51 |
Krock |
*But that doesn't happen |
| 17:53 |
|
Seirdy joined #minetest-dev |
| 17:53 |
oil_boi |
Hahahaha I changed while to an if statement and it's crazy |
| 17:53 |
hecks |
what happened |
| 17:54 |
Krock |
I'd expect Minetest to completely stall due to held locks |
| 17:54 |
hecks |
hey, the block stutter is gone |
| 17:56 |
oil_boi |
hecks https://youtu.be/anfC9SMvseM |
| 17:57 |
sfan5 |
sounds like you've reinvented this https://github.com/minetest/minetest/blob/master/minetest.conf.example#L894 |
| 17:57 |
oil_boi |
hecks, what did you do to make the block stutter go away? |
| 17:58 |
hecks |
just killed the sleeps where you did |
| 17:58 |
oil_boi |
Amazing |
| 17:58 |
hecks |
I mean the stutter that happens when loading blocks, I guess there's a config var for that |
| 17:58 |
Krock |
that's what F4 did until the "Disable camera update" key was removed |
| 17:58 |
hecks |
but that makes sleeping in the first place questionable |
| 17:59 |
oil_boi |
q->crack_pos = m_client->getCrackPos(); smuggling drugs through code are we? |
| 17:59 |
hecks |
for the cracko.png obviously |
| 18:00 |
hecks |
but I was meaning to ask this actually, what is the crack visual doing in meshing |
| 18:00 |
hecks |
does the whole block get remeshed when someone just starts scraping a node? |
| 18:00 |
sfan5 |
the answer may surprise you and I think yes |
| 18:00 |
Krock |
hecks: yes, also animated nodes |
| 18:00 |
hecks |
and couldn't it just be... drawn separately? |
| 18:00 |
hecks |
well animations I can understand |
| 18:00 |
Krock |
perhaps |
| 18:01 |
oil_boi |
hecks which line is rebuilding on scraping a node? |
| 18:01 |
sfan5 |
pretty sure animations are a thing not affected by this |
| 18:01 |
sfan5 |
since it just swaps the texture |
| 18:01 |
sfan5 |
(each frame is in fact stores a separate texture) |
| 18:01 |
hecks |
animations don't scroll texcoords? |
| 18:01 |
hecks |
oh well this works too |
| 18:01 |
sfan5 |
it's terrible |
| 18:01 |
oil_boi |
std::time_t t_now = std::time(0); what the, 0 just works too?? |
| 18:01 |
sfan5 |
it should just use texcoords |
| 18:01 |
hecks |
no wait |
| 18:01 |
hecks |
if it uses texcoords, you'll have to touch the vbo |
| 18:01 |
hecks |
if you swap the texture, it's better |
| 18:02 |
hecks |
you just bind a different texture but the vbo is intact |
| 18:02 |
sfan5 |
hm yes that just crossed my mind |
| 18:02 |
|
Seirdy joined #minetest-dev |
| 18:02 |
hecks |
am I understanding this right? |
| 18:02 |
sfan5 |
changing the texcoords requires uploading the mesh again, doesn't it? |
| 18:02 |
hecks |
yup, at least the texcoords buffer on GL's side |
| 18:02 |
hecks |
but irrlicht might not give you this luxury |
| 18:02 |
hecks |
and just happily upload the whole mesh again, which would suck |
| 18:03 |
sfan5 |
then it's not so bad I guess |
| 18:03 |
hecks |
if you had GL level control over this, it would be acceptable |
| 18:03 |
sfan5 |
..and I can cross looking into that off my todo list |
| 18:03 |
|
NetherEran joined #minetest-dev |
| 18:03 |
oil_boi |
So you're telling me that every time I start digging a node it's doing a full rebuild of the mesh |
| 18:04 |
sfan5 |
perhaps |
| 18:04 |
oil_boi |
I thought I was a madman |
| 18:04 |
hecks |
what would it take to link to GL on windows with mingw? |
| 18:04 |
sfan5 |
honestly I'm not sure, it also creates an extra texture for default_dirt.png^[crack:1:0 |
| 18:04 |
sfan5 |
so maybe it's just a swap and I was wrong |
| 18:04 |
hecks |
and yes, we need to take crack off the streets... I mean, the mapblocks |
| 18:05 |
sfan5 |
hecks: what's special about linking to GL on mingw? |
| 18:05 |
oil_boi |
Also I can't believe the digging microstutter is gone with that sleep removed |
| 18:05 |
hecks |
someone said that windows builds fail if GL is used directly, in that uh alpha test discard PR |
| 18:05 |
sfan5 |
oh that was me |
| 18:06 |
hecks |
I'd be happier if that was sorted out because talking to GL directly would let me bypass irrlicht's brain damage when needed |
| 18:06 |
sfan5 |
ah yes, the engine does not directly link to OpenGL |
| 18:06 |
hecks |
also if cracko is applied to default_dirt then wouldn't it be also applied to every other texture in existence? and since it's a different texture, it still needs a remesh because of greedy meshing |
| 18:06 |
sfan5 |
just transitively because Irrlicht sits in the middle |
| 18:06 |
oil_boi |
Yo why is the smooth lighting calculated in the mesh rebuild thread? https://i.imgur.com/GH2nDxX.png |
| 18:07 |
sfan5 |
so you can't just include gl.h and use those functions (with the current windows setup) |
| 18:07 |
sfan5 |
hecks: it creates a copy |
| 18:07 |
oil_boi |
That's why we have chunk border smooth lighting errors |
| 18:07 |
hecks |
this still poses a problem for my batching idea |
| 18:08 |
hecks |
suddenly temp copying one mapblock isn't viable |
| 18:08 |
oil_boi |
And that's why punching a node fixes this |
| 18:08 |
hecks |
punching a node also fixes physics errors, I wonder why |
| 18:08 |
sfan5 |
oil_boi: the reason there are smooth lighting errors is https://github.com/minetest/minetest/pull/6765 |
| 18:08 |
oil_boi |
Nah, you're just pulling my leg man |
| 18:09 |
hecks |
punching a node will fix the bug where entities cannot enter a mapblock and raycasts in that mapblock fail |
| 18:10 |
oil_boi |
If smooth lighting is disabled globally why is the update still attempted on cache fill? |
| 18:32 |
|
LoneWolfHT joined #minetest-dev |
| 18:40 |
hecks |
so I'm experimenting with a bigger blocksize globally at first, it sure is slow to generate |
| 18:40 |
hecks |
but the framerate sure is promising, even though culling sucks |
| 18:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 18:47 |
* oil_boi |
explores v3s64 |
| 19:15 |
oil_boi |
Max mapblock size 512 gets me over 1000fps |
| 19:15 |
|
oil_boi joined #minetest-dev |
| 19:21 |
oil_boi |
Yep any higher that crashes the entire computer |
| 19:21 |
hecks |
but man, do higher block sizes render well! |
| 19:21 |
hecks |
meshblocks are officially on the table |
| 19:40 |
pgimeno |
[0703 20:02:25] <sfan5> changing the texcoords requires uploading the mesh again, doesn't it? |
| 19:41 |
pgimeno |
not if the meshcoord change happens in the shader |
| 19:41 |
pgimeno |
texcoord* not meshcoord |
| 19:42 |
hecks |
true, but then again it's not a good idea anyway because that would require you to tessellate geometry to tile the texture |
| 19:46 |
pgimeno |
what do you mean with tessellate geometry? |
| 19:47 |
pgimeno |
you would have the animation in a texture atlas |
| 19:47 |
hecks |
but how would you tile a single frame of the texture itself? you'd have to disable greedy meshing just for this |
| 19:48 |
hecks |
and it would not work on things like meshes that use UVs outside the 0-1 range |
| 19:48 |
hecks |
binding a different texture is more sane actually |
| 20:15 |
|
jomat joined #minetest-dev |
| 20:15 |
|
jomat joined #minetest-dev |
| 20:24 |
|
jomat joined #minetest-dev |
| 20:24 |
|
jomat joined #minetest-dev |
| 20:28 |
hecks |
finishGenOOM environment_OnGenerated(): not enough memory, what the hell |
| 20:28 |
hecks |
the program's working set was barely above 1 GB, VRAM barely above 100 MB |
| 20:28 |
hecks |
lua memory at 16 megs |
| 20:28 |
sfan5 |
luajit memory limit? |
| 20:30 |
hecks |
but... how, all I did was bump the block size |
| 20:30 |
hecks |
also this wasn't happening at first |
| 20:31 |
hecks |
not that I want to keep a large block size, but it's a mystery |
| 21:01 |
|
appguru joined #minetest-dev |
| 21:30 |
hecks |
so guess I can confirm that cracko does not affect meshing, thank goodness |
| 21:37 |
|
Zughy joined #minetest-dev |
| 21:43 |
Zughy |
hey there guys. Is there any way to remove the shadow bg of a text? (ie for a nametag) |
| 21:43 |
Zughy |
in C++ ofc |
| 21:46 |
Calinou |
it's applied on the client side with the `font_shadow` minetest.conf setting, I don't think you can control it |
| 21:57 |
Zughy |
ty |
| 22:16 |
|
LoneWolfHT joined #minetest-dev |
| 22:43 |
|
LoneWolfHT joined #minetest-dev |
