00:33:14 Hmm.. ive written a few small gdnative plugins and didnt really have any problems after reading the getting started tutorial. It works rather intuitively to me, already being familiar with both c++ and godot scripting 00:33:58 But im all for "more docs" in general 00:34:47 Speaking of gdnative specifically though, are there ideas of how the docs would ideally look? 00:35:19 well, API is similar, unless there's something different, then you are on your own 00:35:29 Im also not really sure what nathan invisions when he says "reference style" docs 00:35:32 like anything from @GDScript 00:35:40 it's not available in obvious way 00:35:59 To me, having worked in software a long time, "reference" docs means like class references. Which i dont think is what he means 00:36:19 But so far, i havent seen an actual description of intent here 00:36:37 Which is why i have mostly stayed away from docs contributing 00:43:02 reduz disabling script editor will disallow attaching scripts (#32636) 00:43:04 is this intended? 00:43:15 #32636 00:43:16 #32636: Disabling Script Editor removes the attach scripts option from contextual menu when right clicking nodes | https://git.io/JTPpu 01:30:20 Hmm is it possible to merge two collision meshes at run time? 01:30:24 collision shapes* 01:31:21 Like if I have two scenes, each with a self contained collision mesh, and I want to put those two scenes next to eachother so that they look joined, can I join those collision meshes? 01:32:05 I guess for collision it probably doesn't matter though, maybe. If the two scenes are touching eachother then there shouldn't be any gaps in collision anyway, assuming the two collision meshes already cover the whole area. 01:32:11 🤔 01:32:29 This would likely be a problem still for NavMeshses though, but afaik that won't be possible until 4.0 07:59:25 Hello 08:00:19 Heyo 08:09:17 morning 08:18:09 Morning! 08:24:49 morning 08:32:25 Just a heads up for anyone it concerns I'll be away till sat, but should be able to access github but not IRC or PRs. 08:50:13 lawnjelly: thanks for letting me know :) I just merged your two fvf bugfix PRs 09:04:51 Akien: ah fantastic. 09:05:09 Am off, catch you all later :) 12:15:33 ello gonna continue with the refactor and get it done for the fbx pr 14:15:55 reduz: to prevent unneeded proposals, consider documenting the development philosophy behind Godot development, please read https://github.com/godotengine/godot-proposals/issues/575, thank you. 14:16:43 Xrayez[m]: https://docs.godotengine.org/en/stable/community/contributing/best_practices_for_engine_contributors.html 14:16:58 I think what we have right now is sufficient, which boils down to "Only work on what people actually need, ease of use over performance" 14:17:26 As I said the proposal text, Best practices is not sufficient for this purpose. 14:17:57 I'm referring to thing like https://github.com/godotengine/godot-proposals/issues/1741#issuecomment-717944646 14:17:59 also, I think it's fairly obvious by now that Godot doesn't attempt to cater to AAA use cases, but I'm not sure if writing this down explicitly would do any good 14:18:04 > I stated several times that I don't care about purism in Godot APIs. 14:18:47 Xrayez[m]: its the same in my opinoin, this does not solve a problem, this is just something we think it could be nice 14:18:47 It's the first time I read this. :D 14:19:49 I mean, out of the ~1.3k open proposals we have, there are a lot of them which are about actual problems users have faced 14:19:57 it would be better to look into fixing them first 14:20:22 I dunno, I rarely find those existing proposals useful for myself. 14:20:38 And those are mostly editor features. 14:20:50 Or GDscript features. 14:20:55 I have a dumb question, do I need any special arguments to run clang format on a folder? 14:21:17 I want to reformat our parser with clang format basically 14:21:21 without re-opening those files 14:21:30 RevoluPowered: I think you have to run the command recursively AFAIK. 14:21:46 ok so it's a per file tool basically 14:21:56 so I could maybe do clang-format * 14:22:03 clang-format *.cpp maybe? 14:22:17 I don't really use it low level so this makes sense ty 14:22:20 RevoluPowered: see git hooks https://github.com/godotengine/godot/blob/master/misc/hooks/pre-commit-clang-format 14:22:47 https://github.com/godotengine/godot/tree/master/misc/hooks 14:23:14 is it just me or is shell script so fucking unreadable 14:23:15 xD 14:23:19 I love it 14:23:22 but still 14:23:40 I prefer Python for this tbh ::D 14:23:50 haha I understand completely 14:23:56 I wonder if clang-format is written in python 14:24:00 it's C++ 14:24:05 for i in **/*.cpp; do clang-format -i $i; done 14:24:11 (stage your changes before trying, just in case) 14:24:21 ** only works if you enable "shopt -s globstar" 14:24:30 (it's enabled by default in many Zsh configs, but not in vanilla Bash) 14:24:36 ok I uses zsh 14:24:39 so should be on 14:24:54 for i in **/*.{cpp,h} actually, so headers are also formatted 14:25:33 I wonder what's the powershell version of this. :O 14:25:49 Because that's painful to do in Windows. 14:26:26 ty Calinou: I must admit I don't do shell script that often to fully remember the syntaxes 14:26:39 will try it right now 14:26:40 sec 14:27:33 I often ended up becoming the resident shell script expert in my previous workplaces. :P 14:28:04 RevoluPowered: also it might be slow, look into installing and using parallel 14:28:11 parallel clang-format -i ::: **/*.{cpp,h} 14:28:22 it should be available in your distribution's repositories 14:28:34 parallel is a bit nicer to write *and* runs in parallel as its name implies 14:35:16 great 14:35:27 I am still moving stuff around 14:35:27 :) 14:35:36 its time consuming updating includes /./ 14:35:52 I think it would be nice if C/C++ had a better way like c# has 14:35:57 like using 14:36:01 using SomeModule 14:36:16 to me the include header guard should be included by default 14:36:23 its fucking dumb we need to put it in when its required 14:36:47 excuse my swearing :P 14:37:58 it's fine 14:38:11 #pragma once would make it easier to include but we decided against it 14:38:45 yeah it seems like the language should do this for us automatically 14:38:47 its 2020 14:38:55 the ifndef and pragma seems so 80's 14:38:57 don't C++20 modules do that? 14:39:03 Probably 14:39:07 but C++ engineers complain about them 14:39:17 I haven't followed C++20 changes too much (I read about them, but didn't necessarily understand them all) 14:39:22 me neither to be honest 14:39:29 I think this was introduced in C++17 actually 14:39:33 and revised in 20 14:39:42 it'll be a while before we can use C++20 anyway :P 14:39:50 Yeah I don't believe we should use it 14:39:55 maybe for Godot 25.0 14:40:00 but we'll rewrite that version in Rust anyway 14:40:15 I just get annoyed with C++ it has some archaic constructs which are left around which I think it will reach a point where we don't use it and use Rust 14:40:18 ;) 14:40:30 I don't think rust will the successor 14:40:34 to C++ 14:40:36 I could be wrong 14:40:46 it seems very well headed to be the C++ successor, many new projects have already switched 14:41:02 its amazing 14:41:21 I just don't know for certain it would be nice to try it out in some of the modules 14:41:30 maybe that is a good approach for testing rust out 14:41:31 xD 14:43:32 I don'r think that's a good idea due to the buildsystem overhead, see https://github.com/godotengine/godot-proposals/issues/1330 14:43:40 it'd make Godot a lot more difficult to build for newcomers 14:44:03 good point 14:45:46 I thought they can work synonymously in the same system 14:46:14 just like we have .c files sometimes 14:46:56 I know the comments in the proposal say otherwise 14:47:02 but I believe it can work that way 14:47:07 C and C++ use the same compiler 14:47:39 clang can do what I have said 14:47:44 but gcc can't yet properly 14:47:57 its all LLVM IR to clang 14:48:02 so it does just drop in 14:48:10 so yeah 14:48:13 not worth it 14:48:16 maybe in 2030 xD 14:49:26 We'll be using a different engine in 2030. :P 14:55:00 heh, who knows 14:55:36 Rustdot 14:55:37 I think most game engines never really die, some people are still releasing commercial games based on Doom and Quake engines today after all 14:55:54 I don't think godot will die 14:56:12 because its backed by contributors who won't forget about it 14:56:26 so even if it stagnates like springrts it will still be used in games 14:56:47 I even think that would be unlikely to happen 14:57:11 I'm not saying that it will die, but we may just move on at some point. 14:58:46 reduz: what do you think about https://github.com/godotengine/godot-proposals/issues/1725#issuecomment-717983764 ? Do you think it's worth the effort considering this is only for the 3.2 branch? 14:59:18 (sorry for pinging you directly, but I'm not sure if anyone else could reply here since this is low-level rendering stuff) 14:59:18 ok so refactoring is done now to mass clang format 14:59:51 Calinou: I don't think this makes sense for Vulkan, since on Vulkan you literally choose the GPU and use it 15:00:06 indeed, on Vulkan this makes no sense. OP only asked for OpenGL 15:00:12 Calinou: also if this is an nvidia problem, sounds like nvidia should fix it 15:00:22 yeah, but I doubt it will happen, Optimus is barely getting any changes these days 15:00:35 Optimus still makes for a huge portion of gaming laptops nowadays, since AMD barely does anything there 15:01:26 also are we not using exclusive fullscreen btw? 15:01:44 apparently, no, not even on Windows 15:01:57 bruvzg made a WIP branch for that a few months ago 15:01:58 we might need to check this then 15:02:17 https://github.com/godotengine/godot/pull/41746#issuecomment-686729881 15:02:30 akien: problem with redoing the fbx parser folder need some help 15:02:57 akien: CREDITS and LICENSE being kept in modules/fbx/fbx_parser/ is causing file_format.sh to fail 15:03:04 where should i keep these files? 15:03:16 https://github.com/godotengine/godot/pull/42941/checks?check_run_id=1321382002 15:03:18 more info 15:03:20 IDK what to do 15:03:29 Calinou: oh but we dont need to change video mode 15:03:36 selecting video mode nowadays is pointless 15:03:53 exclusive fullscreen can work with the native desktop video mode 15:03:57 indeed 15:04:12 changing resolution is useful on 4K laptops with slow graphics cards, but most people don't use that kind of laptop to game in the first place 15:04:25 (and you can do it manually, since it's an edge case) 15:04:34 even so you can still render to lower resolution and scale using the GPU at literally no cost, so this is not a problem 15:05:08 it does have a pretty significant cost according to some issue I've seen on GitHub 15:05:21 https://github.com/godotengine/godot/issues/36507 15:05:38 still waiting for people with slow graphics cards to do benchmarks, though 15:05:54 I'm not sure if we're doing something wrong or this is just a fillrate limitation on IGPs 15:07:02 > I tested the sponza demo with a viewport size of 1280 x 720 pixels, on a 4k screen. This scales perfectly to 4k with a 300% hi dpi scaling in windows. Fps drops from ~150 FPS to ~100 FPS, when enabling the "Allow HiDPI". Not as dramatic change as my simple test project. However, I still think this is a significant FPS drop, when the visual result is identical. 15:07:02 > Edit: setting the windows 10 OS resolution to 1280 x 720 increases the FPS further to ~170 FPS. 15:07:36 Sponza is still pretty simple in the grand scheme of things 15:08:32 it's worth trying again in `master` with the new renderer, I can dig out my laptop and try 15:08:46 (it's on Windows so I can test with the scaling routines) 15:09:25 Calinou: kinda seems like a non-issue to me, its still way above the refresh rate 15:09:44 and if you have a high refresh rate monitor with an IGP well, whathever 15:09:49 it can affect heat development and battery life on laptops, so it's not ideal 15:10:31 Calinou: no one games on battery on gaming laptops :P 15:10:45 I don't think it's as critical as some people might think, but it's still worth documenting at the very least 15:11:01 and someone should write a Windows app that changes screen resolution based on running processes… :) 15:11:08 (I'm still surprised that doesn't exist in 2020) 15:19:52 seems clang format either is broken on my local machine or is not running and IDK why 15:20:09 or maybe its already formatted correctly 15:24:01 Calinou: agreed re parallel. gnu parallel is my go-to tool for any sort of batch processing from the shell. +1 First tool I install on a new development machine. 15:33:56 seriously /./ file_format.sh is pissing me off 15:34:07 its checking files which do not have formatting 15:34:27 i even have git hooks enabled 15:34:28 check for missing newlines at end of files and trailing whitespace in your files 15:34:32 done already 15:34:36 but why is this not done via clang format 15:34:42 also why is this even a thing? 15:34:47 file_format.sh does what clang-formatdon't 15:34:54 (it also works on non-C++ files) 15:35:01 we do this because it allows for better Git diffs :) 15:35:15 a newline at the end of the file gives better git diffs how? 15:35:20 it's not critical, but it always irks me when I see a PR adding trailing whitespace :P 15:35:29 well yeah, you don't want to accidentally remove the trailing newline (or have more than one) 15:35:47 Git warns you when a file doesn't have a newline at the end of file for this reason 15:35:57 (also because it can break things unexpectedly, some poorly written programs will trip up on such files) 15:37:13 I use https://pre-commit.com/ in my personal projects with this configuration: https://hastebin.com/tagupoloxa.yml 15:37:13 file_format.sh is just a shell script that achieves a similar thing 15:37:49 OK but formatting a credits file is silly 15:37:59 it's trying to reformat a license 15:38:03 and a credits file 15:38:07 this is why its dumb 15:38:27 there is no exclusion 15:38:44 https://github.com/godotengine/godot/pull/42941/checks?check_run_id=1321570778 15:39:14 nd because it's just a shell script it wont format it correctly 15:39:51 so maybe we should get rid of it and put something in there which has that features like clang format but for the newlines etc 15:40:02 or just extend it 15:40:08 to make it apply a patch 15:41:34 so right now it literally wont work for fbx 15:43:04 easy to add a newline to a file, but not to do the changes its trying to make me do 15:45:03 https://usercontent.irccloud-cdn.com/file/HlkTZrzC/image.png 15:45:15 take care 15:46:09 im fine just annoyed with it :P 15:53:17 for example 15:53:18 - Zhao Lei 15:53:18 -Contributed several bugfixes fixing memory leaks and improving float parsing 15:53:18 +Contributed several bugfixes fixing memory leaks and improving float parsing 15:53:30 I don't see a difference 16:04:42 here are the top-voted proposals on a single page: https://0x0.st/ik3w.html 16:04:55 (static output from my Godot proposals viewer, I'll make a version hosted on GitHub Pages eventually) 16:07:57 i guess dumb question, how do you vote a proposal? 16:08:28 use a +1 (thumbs up) or -1 (thumbs down) reaction on the first post 16:08:34 ahh cool 16:08:45 other reactions are currently not taken into account, since I can't deduplicate those using the GitHub API 16:08:53 very cool 16:08:54 (someone who uses both "thumbs up" and "heart" should only count once, for instance) 16:09:23 maybe sort by thumbs up and show the other emoticons in a list on the table? 16:09:39 I could do that, but I'd show them only on hover since they're fairly secondary 16:09:45 makes sense 16:09:51 it really is a cool page btw 16:09:53 https://github.com/Calinou/godot-proposals-viewer 16:09:59 sorry for ranting about the file format 16:10:07 it uses Alpine.js + pre-fetched JSON files 16:10:09 no worries :) 16:10:23 the thing I think which is a problem for me was it was showing git diff and i confused the git diff with the required changes 16:10:32 so i mixed the two up 16:37:47 Akien: okay swearing session is over 16:37:50 #42941 16:37:53 #42941: [3.2] FBX importer rewrite | https://git.io/JT0tP 16:38:15 I didn't remove Assimp::FBX:: namespace 16:38:17 lmk if you want me to 16:38:39 I would probably like to rename from Assimp::FBX to FBXParser 16:39:18 hmm nvm FBXParser is already a thing 16:46:42 ifire: will do some bugfixes for sensei 16:57:12 I deployed the proposals viewer to https://calinou.github.io/godot-proposals-viewer/. Note that since it does everything using client-side JavaScript, it may take a while to load 16:57:24 on the bright side, you can Ctrl + F on that page to find any open proposal 17:03:30 reduz: reminder about #42361 ;) 17:03:30 #42361: Vulkan: Make validation layers optional | https://git.io/JUKJp 17:03:55 Calinou: can you add godot editor theme to the css? :D 17:04:09 I thought it would be funny xD 17:27:46 you could put a button at the bottom [reimport] to refresh xD 17:48:00 Can we please review #35012 or do I have to create a proposal first? 17:48:01 #35012: Add Input `is_anything_pressed` method | https://git.io/Jvf3C 18:04:21 RevoluPowered: that's what I did for the HTML5 editor (it's not online yet) 18:04:42 https://i.imgur.com/340ahJQ.png 18:04:59 (I made buttons larger so they're easier to click, especially on mobile as some people will likely try the HTML5 editor there) 18:21:34 is anyone here bruvzg ? I'm digging into the Vulkan display server in display_server_osx.mm. Is vsync even implemented on this driver/platform? 18:29:45 There's no vsync implementation in the any of "DisplayServer"s, it's probably controlled by VK_PRESENT_MODE_FIFO_KHR in the Vulkan driver (drivers/vulkan/vulkan_context.cpp), if it is implemented at all. 18:30:59 hmmmm, CADisplayLink drives for iOS so I guess i expected to find CVDisplayLink driving OSX 18:32:24 latest 4.0 on my machine (macOS) just maxes FPS regardless of any vsync settings. Tried laptop display, external monitor, 120hz, 60hz, 144 etc. Will continue to investigate i suppose 18:37:22 hmmmm, at least reduz has some good comments here: 18:38:12 "It should be noted that Vulkan 1.0 doesn't provide a method for synchronizing rendering with the presentation engine's display. There is a method provided for throttling rendering with the display, but there are some presentation engines for which this method will not work. If an application doesn't throttle its rendering, and if it renders much faster than the refresh rate of the display, this can waste power on mobile devices. That is 18:38:12 because power is being spent rendering images that may never be seen." 18:54:57 Calinou: this means I can use godot in my car 18:54:59 this is hilarious 18:55:01 :D 18:55:25 hmm? 18:55:45 I forgot about the web version of godot 18:55:55 ah, yes 18:56:00 but the screen res of the car display is like 1280x720p 18:56:09 your car will need to support WASM and WebGL 18:56:10 so you making that change means I can use it in the car properly :P 18:56:15 It does 18:56:26 and maybe WASM threads, not sure if they're a requirement for using the editor 18:56:29 RK3399 I think has webgl 18:56:34 I might be wrong 18:57:35 I'll use the panfrost driver 18:57:40 and it should just work ™️ 19:10:20 unrelated, but did you see the AMD 6800/6900 announcements? 19:10:51 Yes! Its gonna be my birthday present for the 31st to myself :) 19:19:00 OK so I did an optimisation the import time for bistro was SOOO slow with fbx 19:19:04 it was like 10 minutes 19:19:07 now its like 30 seconds 19:19:29 I made some cache to make a single lookup really quick for the vertex id's 19:19:46 so when it converts the fbx faces to godot it does it faster 19:19:51 a lot faster 19:33:56 RevoluPowered: amazing! 19:40:00 RevoluPowered: Happy Birthday soon! 19:53:56 Happy bday! 19:54:22 Haloween bday 19:54:26 Spoopy baby 20:07:37 ok so question regarding main::iteration... Maybe for reduz or Aikien... Main ticks are computed based off cpu sample and then compared with last sample time 20:07:42 'uint64_t ticks = OS::get_singleton()->get_ticks_usec();' 20:10:20 I'm asking because on iOS, this resolution ends up being pretty steady and accurate relative to the frame display time. ( coinceidently due to Main::iteration being called almost immediately within the CADisplayLink's frame displayed callback). 20:11:36 but on other platforms (well at least on macOS), the delta tick computation is VERY jittery due to aliasing introduced by OS scheduling among a lot of other things. 20:13:39 RevoluPowered: the 6900XT looks interesting to me since I was eyeing a RTX 3090 for my next build 20:13:55 if AMD holds up their promises and doesn't screw up Linux support, that is 20:15:42 If I drive the Main::iteration with a CVDisplayLinkCallback (called with frame display Timestamp), and pass in ticks_elapsed from these delta display times, I get a ROCK solid 8.3333 ms per frame. Instead of of being widely variable due to cpu sampling. This aliasing artifact ends up making everything jittery due to using a cpu sampler instead of frame display times. 20:17:17 Also also leads to hacks trying to figure out 'how many physics ticks' should the engine process in this particular main loop iteration (using averages and other stuff thats generally not great) 20:27:07 Mux213 may also know a thing or two about CVDisplayLink 20:28:50 Ya, I mean i just implemented driving Main::iteration from CVDisplayLink and using frame display times instead of get_ticks_usec(). Its not really that complicated as CVDisplayLink just callsback when a frame is displayed, and also gives the presentation timestamp. 20:30:22 but now i'm actually more curious why cpu get_ticks_usec() is driving delta ticks in the first place. I know you can run godot headless, as I'm eventually planning to, but in the headless scenario I would imagine the tick rate is explicit and then throttled with nanosleep or something. 20:46:52 I've noticed high CPU usage when running a headless Godot 3.2.3 server 20:47:01 I haven't tried setting target_fps in headless yet 20:47:16 this is the project if anyone wants to test it, https://github.com/Calinou/platshoot. You can find dedicated server binaries in the Actions tab's artifacts 20:47:30 it uses 50% of a CPU core on my VPS when no players are connected 20:48:42 MoltenVK demos do use CVDisplayLink callback for the rendering loop, it was not necessary for OpenGL, but if VK_PRESENT_MODE_FIFO_KHR do not do the job (it sets displaySyncEnabled of the Metal layer to YES which should enable vsync without any extra steps), maybe we'll need to reintroduce it (we were using CVDisplayLink cb for some time, when OpenGL vsync was broken in 10.14). 20:56:14 hey lawnjelly, are you around? 21:05:33 hmm how does godot decide if a variable is const or not? in shaders 21:06:58 qbieshay: it looks for the const keyword. 21:07:21 ty 21:07:24 bruvzg[m] OK, well I guess I may just fix the entire jitter in the engine... Even if VK_PRESENT_MODE_FIFO_KHR ends up blocking on the call to sync() in rendering_cevice_vulkan, that wont help with timing artifacts introduced by using a cpu sampler for frame times 21:07:41 I'm experiencing some funny stuff with modulate color at the moment 21:08:30 I'm NOT a unity guy by any means, but its kind of coincidental Unity FINALLY seems to be attempting to fix their jitter: 21:08:30 https://blogs.unity3d.com/2020/10/01/fixing-time-deltatime-in-unity-2020-2-for-smoother-gameplay-what-did-it-take/ 21:12:00 clayjohn can i bother you for 5 minutes? I'm getting very confused, I'd like to PR something but I'm not sure where to go with this 21:12:23 probably a bit more than 5 minutes 21:13:24 qbieshay: sure! 21:13:58 If it's a modulate color issue, it may be caused by batching. So it's worth checking if the issue persists when you turn batching off in ProjectSettings. 21:14:09 It kind of is, but also not 21:14:22 Alpha1088: a lot of the jitter currently visible in Godot is due to the lack of physics interpolation, at least in my experience 21:14:55 first, i noticed that setting modulate to vec4(1.0) in the vertex shader makes some objects disappear 21:15:12 well, actually, from what I see, the root cause is actually this timing artifact 21:15:28 without batching too 21:15:54 (I am altering modulate because I don't want it to be applied to my sprite at the end, but i want to use it to carry information) 21:16:13 actually, you only need to interpolate physics frame If and only If the physics tick rate differs from the display rate. 21:16:17 qbieshay: oh! So you are setting it in the shader? 21:16:25 yes 21:16:29 if you tick physics at 60 fps, and you draw at 60 fps, theres no need to interpolate anything 21:17:32 ok so i guess that this is a separate bug 21:17:37 lol 21:17:40 maybe, but with so many different refresh rates existing on the market, you either need interpolation or adjusting the physics tick rate to match the monitor refresh rate 21:17:53 https://irc.poto.cafe/uploads/6f44f317aed8a0ad/modulate-repro.tscn 21:17:56 these days in gaming, we have 60 Hz, 75 Hz, 90 Hz, 100 Hz, 120 Hz, 144 Hz, 200 Hz, 240 Hz and 360 Hz 21:18:02 oh, and 165 Hz 21:18:13 yes I know, i was just using 60 and 60 as an example. 21:18:13 this is the scene if you want to take a look now clayjohn, but I will also open a proper bug report later 21:18:19 the gcd of these refresh rates would be pretty low ::-) 21:18:38 i tick my game at 120, and render at a variable rate 21:18:43 144 or whatever really 21:18:47 what is puzzling me the most is that i have the same fragment shader in 2 different shaders, one behaves like this: 21:18:52 https://irc.poto.cafe/uploads/89b4bf4e131d2b3f/simplescreenrecorder-2020-10-28_21.19.23.mp4 21:18:58 when these number differ, is only when interpolation is necessary. 21:18:59 in my game, I use 60 Hz + interpolation via the smoothing add-on, it looks butter smooth on my 144 Hz monitor 21:19:04 while the other one applies the modulate color instead of using it for the gradient 21:19:49 Calinou heehee but if you timing was more precise you would have an even more smoother simulation! 21:19:59 all of this happens also with batching disabled 21:22:05 no, sorry, the behaviour in the video happens only with batching on 21:22:18 with batching off, it multiplies by modulate and fades out 21:23:07 batching off: 21:23:10 https://irc.poto.cafe/uploads/c91e57ac8a00af4c/simplescreenrecorder-2020-10-28_22.20.30.mp4 21:23:14 bathing on: 21:23:18 https://irc.poto.cafe/uploads/04f68df1cb2722e0/simplescreenrecorder-2020-10-28_22.22.26.mp4 21:23:24 well, batching not bathing 21:23:34 Who needs bathing anyway 21:23:49 ahah 21:24:22 clayjohn all of this is because i really want to draw these sprites with a single material, they are going to be a lot 21:24:41 qbieshay: batching off looks correct to me. 21:24:43 i recalled that modulate would be baked in vertex color so that's why I'm using color 21:25:13 When batching, modulate gets baked into color. But you can also access it with MODULATE. 21:25:29 is there a way to know in a shader if batching is happening? 21:25:49 In which case it won't get baked into color but will be baked into its own attribute (I think, it might also just break batching. :P) 21:26:00 qbieshay: yes. Turn on debug batching in ProjectSettings 21:27:14 clayjohn i can't find it 21:28:07 https://irc.poto.cafe/uploads/9f100bdcf84fa8d1/Screenshot_2020-10-28_22-27-53.png 21:28:18 qbieshay: ah, sorry. It's called diagnose frame. https://docs.godotengine.org/en/stable/classes/class_projectsettings.html#class-projectsettings-property-rendering-batching-debug-diagnose-frame 21:28:47 huh, it didn't mention anything about having a bool in the shader 21:29:00 qbieshay: also see https://docs.godotengine.org/en/stable/tutorials/optimization/batching.html#diagnostics 21:29:47 qbieshay: oh sorry, I thought you said "if a shader is batching" not "in a shader if it's batching" 21:30:06 I don't think there is any way to tell in a shader if it's batching. 21:30:16 I think i will need different shader code if the canvas item is batched 21:30:56 Can I add the keyword in the shader? 21:31:02 would that be desirable? 21:31:40 qbieshay: you mean like a builtin that tells you that batching is used? 21:31:48 yes 21:31:59 because for my case I'd need to either check the vertex color, or modulate 21:32:07 It could be helpful for debug. But in the long run we should just fix the bugs in batching which would make it unnecessary. 21:32:34 qbieshay: well, you should check MODULATE either way. 21:32:48 I think what you are seeing is a bug that should be fixed. 21:33:01 If i have a shader that wants to get color info, it needs to read from modulate if the sprite isn't batched, or for color if the sprite is batched 21:33:34 so i think in the end I'd need it anyway? 21:33:43 Unless I'm missing something 21:34:38 So ideally what I'd like to do 3 things 21:34:45 1. fix things disappearing when modulate is set 21:34:51 qbieshay: https://github.com/godotengine/godot/pull/38694 looks like reading either one breaks batching :/ 21:36:19 2. have batching info in the shader (built-in bool) 21:36:29 3. being able to write to modulate in the fragment shader 21:36:44 Does this list sound sane clayjohn? 21:39:17 qbieshay: yes. But I think once we do 1. We won't need 2 or 3. 21:39:41 is there an occasion where color will differ from modulate? 21:40:02 yes, meshinstances2D, i suppose 21:40:12 Yes. And polygon2D. 21:40:19 hmm 21:40:33 why will 3 not be needed? 21:40:44 I think there are still cases where you want to reset the modulate after reading from it 21:40:49 (namely mine cough cough) 21:40:54 What version of the engine are you on btw? 21:41:03