Godot Live Q&A with engine developers – August 2020

let's see so hi everyone i think we are now live so welcome to this uh q a of the go to engine developers we're starting a bit late because we've been struggling getting the video feeds to work and it's not working for everyone but we'll we'll work with that so i will be moderating today and we have juan the lead developer of kudo engine we have fabio who works on the networking and html5 stack we have george which you cannot see but who works on gd script and we have jill who we just announced is our next full-time hire who is going to work on uh general usability of the editor and a lot of other things that i intend to show his way to offload a bit my own uh amount of tasks it's what's good with having some versatile profiles so we have some questions prepared that we got from patreons and we will also be taking questions from the chat for the questions in the chat it's quite important we have a bot that is monetary more knitter in the chat and you should use exclamation mark question to ask questions so that we get them filtered by the bots so like i don't i do an example in the chat so you should see i just posted the question started with an exclamation mark question so you ask questions this way and we will get them filtered and we can then uh see them more easily in the huge stream of chats that is usually happening so do ask your questions we get them and then we will answer hopefully the ones that we find the most interesting for the stream right so let's get started i just wanted so before we start asking um some of the team members to just very quickly uh brief you on what they've been working lately and what's coming up in the coming months so that you kind of if you're not you've not followed followed everything on twitter or github so that you get a bit up to speed and know what you can ask them about in your questions so maybe juan you can start hello everybody uh i'm juan i'm the lead technical developer of the project uh i'm leaving the rewrite of the rendering code for good.4 mostly done with the new features which is pretty cool i only missing the the particle system uh the new particle system which i'm working on right now hope to finish next week uh and then a few minor features remaining but very few and then will be very fun because we switch the optimization phase i will create a lot of scenes for optimizations and for testing and regression testing and all the nice optimization will come with a lot including technic plugs like lod occlusion cooling this kind of thing will be very fun that's what i'm working on right now thanks so maybe george you can tell us a bit about what you've been doing okay so i'm working on gd script i did a big refactor of the code to like add a new features and fix a lot of old brick old stuff that were weird about javascript and you start working on optimizing the vm real soon nice what about you fabio ah you're muted i'm fabio or phallus as my handle in github i mostly do as you mentioned as i can mention networking and html5 right now so right now specifically i'm working to get the html5 export better with more functionalities and trying to part the editor to the web as much as possible it could be really cool for small projects and school and stuff like that and the next focus like the current focus is on getting gd native to work there on html5 export and kind of better mobile support as much as possible and as i mentioned the editor possibly is finished in a few months okay and i am jill also known as g root on the the internet uh i'm going to be as remi said i'm going to be the next hire uh so i'll start to work on november and probably on the editor side so my first task is going like is likely going to be uh reworking the time map and tileset editor since there are a lot of there is a lot of demand for it uh but generally i'll probably work mainly on the editor and also help remy reviewing prs and organizing the the community i'm muted and i for myself yes so i'm remy the product manager and i haven't been working on much lately since i have been taking some holidays but google 323 is going to be released soon so i've been working on that lately i will talk about it some more later on so i suggest we start with the questions that we have listed so the first let's start with one so rendering question we got a question about the custom sky shaders feature which has been merged in godot 4 developed by clayjon and one of the patrons is asking how useful will this feature be to implement source engine style 3d skybox and maybe will it allow to implement it yourself so the new feature for sky shaders is super interesting i'm very happy that we could finally add this feature to a dot this is quite unique it allows making uh any kind of shader based sky if you want to uh do procedurally for example if you want to make procedural clouds procedural like ocean pressure water uh like all the scattering for the for the atmosphere everything you you can do shaders uh of any kind it's pretty cool uh you can do like day night cycles make stars appear you can just do anything with a very simple shader and you can also use the the visual shaders for this which is it's really nice once code 4 is out i'm pretty sure that a lot of you will be sharing sky shaders that you can use in your games and modifying them that's going to be very cool uh regarding to source style uh source engine just to clarify uh source engines uh i think that's kind of an old technique uh probably more geared to older hardware usually when you would do uh skies and backgrounds in older world like you have to think of like half life and or have even have like two style hardware which is quite old at this time usually what they did is uh since you have had really low uh texture memory in general uh having like a high resolution detail skybox was kind of slow uh plus you have the problem if you wanted to draw very far away uh that the buffers were usually just 16 bits at the time for performance uh but nowadays this is not really a problem not even a mobile so uh what source used to do is let you like re-render a scene that you would use as a background and paste it in the background of the of the frame and then let you render your regular frame i don't think it's worth implementing something like that because nowadays you use 32 bits for for the buffer so you're not going to have much c fighting just put use a higher draw distance and put whatever you want in there and it's going to be fine plus you can use high resolution uh sky boxes uh or panoramas or whatever so there's not much of a new a need for something like that nowadays uh you will still probably be able to do it if you want using the the render pass system uh so yeah you can kind of probably do it in other form but probably not very worth it that's my my take on it thanks let's follow up with a question for jill we were asked about it's pretty specific but it's still interesting maybe to spawn some ideas xavier asked if in the 2d editor currently there are small crosshairs to locate nodes and they can be a bit hard to see if you have lots of nodes or so can they be made bigger configurable or can we have options to show the labels of the node so that it's easier to locate the things you're looking for in the 2d editor uh that might work uh one solution indeed like we could have bigger crosser in general for and make this configurable especially for accessibility reason and like if people are have difficulties selecting such a small thing uh it's something we understand so probably i would make this configurable uh regarding the other parts if like we want to display labels for nodes uh the problem is like in a lot of uh situation when you're making a 2d scene uh you have a lot of 2d nodes that are more or less stacked to do together so if we display labels on them uh they are going to level up quite often and you're going to end up with like unreadable text so solution might be too like an of labels that are kind of motivating automatically but i mean it might still make things complex to you to know where are your nodes are because the globals are going to be moved around so there's not a lot of solutions so basically right now we have the least selection you know when you alt click or i think it's i'll click the shortcut for it when you all click on a node you have a selection [Music] a drop down list where you can select what not you actually want so yeah at least we can make the courser uh size configurable for the party needs a little bit of syncing and likely uh a proper proposal setup syncs yeah thanks so next i have a question for george um which should be easy to answer because it has actually been implemented already which is would it be possible to add some sort of token into the script and maybe an attribute for c-sharp to add a description directly to an exported value so that it shows up in the pop-up yes so there is a project in this google summer of code where a student implemented the documentation for gdscript so you can add a documentation comments and it generates uh the documentation page automatically and you can also hover your mouse over the names on the editor and it shows on a pop-up and that can be i'm not sure if he implemented yet but this can also be expanded to be used in the export in the inspector panel when you export something the same way that the engine internal properties already have the documentation with the tooltip could be like the same thing so yes that's gonna be done i'm not sure if it's done yet but it's gonna be done anyway so yes it's possible and it's going to be done yeah and for c-sharp i think there might be a way to expose this same kind of functionality i think there might already be a feature like that in c-sharp but then we still need to to link it in the editor so that you can also expose this c-sharp dot strings directly yeah i'm not familiar with c-sharp should ask ignacio about that but i don't think it's a big deal to do so there was a question that i will answer which is from jasper about the c-sharp integration and asking if we have plans for having um like a better c-sharp integration inside the good editor itself so that you could like edit c-sharp in the script editor have like built-in documentation in c-sharp style instead of gd script and also if there are plans for more c-sharp tutorials so for that i can say briefly the current focus on c sharp is to make it all like feature complete and usable and then the next step is kind of focus on better usability and implementing support for editing chap inside the godo editor it's kind of one of the last priorities because the main interest of c sharp for most c-sharp users is that they want to use the usual c-sharp ecosystem with their usual c-sharp ide so there's a lot more demand for being having good support for visual studio visual studio code and this kind of editors than being able to type c-sharp in the google script editor which is very well suited for gd script but maybe a bit lacking if you really need a full-blown development environment for a language like csharp on the other hand eventually further down the road we can have some decent support for like quick edits of your c sharp uh in the golden editor it's already possible but it uses the same um the same mechanism as gd script so it can be a bit unwieldy about the documentation there has been a change merged in master i think not sure i should check but which will also probably trickle down to the 3.2 branch which auto converts all the properties and variables like you can choose if you want to see the documentation in the normal gd script api or if you want to have them converted to what they look like in c sharp so it's something that we are working on some contributors are working on that so that in the editor you can have c-sharp friendly documentation but again the normal c-sharp workflow is that all this documentation you get it through your ide where the google editor already provides all this documentation out of the box in your ide so that's the best way to consume c-sharp specific information and for tutorials uh currently we've tried to keep everything like language agnostic on the documentation website but we're also trying to make it we have more and more uh examples of c sharp code and not just gd scripts but eventually i think we will also have like full tutorials made for c-sharp because instead of just translated part by parts and keeping the same structure when using a different language sometimes you want to use a different kind of organization for your code so it might make sense to have for some very specific tutorials different uh like have one version in gd script one version in c-sharp or two different tutorials maybe so there's definitely more love coming for c-sharp and ignacio and the community are doing a lot of good work so a quick question that i handed over to fabio even though that's not his area but is um will there be jason editing support in the editor that was asked by sergey okay so i i i see how jason like some form of json support is helpful it's like an ambiguous way of saving data and transferring data from one system to another um i would say like the idea is that you should be able to do something like that as a plugin in the asset library i'm not sure what we want is actually to have something like that integrated in the editor especially when it comes to having a graphical interface to json but again we definitely want that to be available on the asset library so maybe we can do it as the google developer so the community can do it what we could try to do slightly better maybe is to have some form of better completion when it comes to when you edit the file as a text file so to automatically get the closing of the parenthesis and signalize the signal when it's missing or when you're missing a comma there is probably something that doesn't require too much code and could be done in google but again for a more graphical interface like for example when editing uh dictionaries in the inspector then it's probably better to have something like that as a plugin if the user wants it and to avoid bloating too much the engine basically yeah that makes sense and i'm going to take a few questions from the chat already we still have some more from patreon but so that we can kind of process questions as they come so there is one about whether there will be any batching support for gles3 so in google 3.2 so i can answer that so lon julie who has been working on the batching support for gds2 has also started working on the same for g83 so i think he has pretty advanced implementation already but it's going to be for the not for good or three to three it's probably going to be finished and merged for three to four or later depending on his own timetable but that's something that has been worked on and that we intend to include in the 3.2 branch eventually on that while i'm talking i can also answer when will be the three two three release so uh currently we have the fourth release candidate so it's almost there but there was some late big changes to mono support which i will talk about some more to answer other questions which added some instability in some things so a few more fix fixes were needed so i had some fixes during the weekend from ignacio so i'm going to try to make a release candidate five tomorrow and then we'll see how that goes so the 3.323 release is incoming like maybe this week maybe early next week but basically as soon as it's ready another question i guess maybe for one so that i'm not the one talking all the time is uh since we talked about it today any news about wayland support oh that's a really good question uh so for golot4 uh we basically reroute how uh how you how the engine interfaces with the windowing system uh we used to have the os class which would do basically everything but this was a problem because uh there was like for example maybe in windows it wouldn't make so much sense but if you run on on on on unix's like if you wanted to be able to choose between uh like x11 or ylan or even just use the frame buffer or egl like for the raspy it was very difficult to do with just one binary because the whole engine expects to have one os instance so this was modified and now we separated os into os and display server display server is like the windowing driver so right now we are working on having the x11 display server working as best as possible once it's done the idea is to to maybe work on a while and to be completely honest i was expecting violent to become more of a standard nowadays but it's taking a long time so that makes it like less of a hurry for us so ideas to get x11 like perfectly working with uh with with four and then probably just implement it uh but there's a lot of contributors who want to do that the back end so it's going to be probably done sooner than later uh so yeah that's that's what i can think of i guess thanks um one question for fabio uh is there will there be any major networking updates soon okay that's the that's a very good question um so i know audino andrea is working on a very cool module for making it easier for you to synchronize scene it's a very interesting module and i've been waiting for him to penalize his request so i can review it and i think it's a great update and there is also some plan i've been writing a proposal and a document about it to make the server export of godot better so you can make your game server with godot engine without needing for a gpu like you can already do but like with better performances and giving you um more possibilities on that side i also have a few things planned for the future but it's like i've been counting it in my spare time for now so i prefer not to talk too much about it to not probably something that i don't know if i can deliver but it's like trying to improve a little bit the net uh the net interface and yeah i think that's mostly it uh at least for 4.0 um i i've been also working on a way to like to make a proposal to for node replication or actually scene replication so the idea is that uh when you instance a scene you can tell the system to replicate it on other players the problem with this uh form of simply simplification of the multiplayer is that it's really cool and like it makes you prototyping really fast and it allows you to part the game to multiplayer even if the game wasn't really designed for multiplayer but if you are planning to do a like fully multiplayer game like a multiplayer center game most of the time you want to do a lot of the stuff manually simply because networking is mostly a matter of optimization and you cannot optimize too much if you don't know what are the game rules but of course like our idea is to try and make something that can be usable by everyone and the most common scenarios and then if you have like this really multiplayer centric uh competitive game that you are designing then you you'll know what you're doing and you try to change it a little bit and you know do something on your own on that side simply because that's not really possible to do at its best for every possible game but again it's something we work on and we keep iterating on and we keep thinking about it there's like ongoing discussion even on irc about how we can improve that so uh it's definitely something we we value uh and again there will be news uh soon soonish and there will be something better for for 4.0 nice and while you're talking i have at least three questions about when can we expect fixes for the stuttering web audio oh yeah that's i mean like that that's a bit like that's not super easy to do uh mostly because the the the web api for audio is pretty limited in the sense that it it requires you to do a lot of things to make it fast so the original implementation in the original api like the original standard and it's running on the main trade which is what you are doing now and it's very inefficient because if you have high cpu usage then you got stuttering so for example what i've done in the last last few months is to allow the developer to set how big the buffer is so the developer can try to find the balance for this game based on how much cpu intensive is this game uh to how much delay there is where when audio is played and how likely how much the how powerful it must be your pc's or your device so it doesn't stutter uh the only way to improve this further is to move it on a zipper like move audio processing on a separate on a separate treat which is possible with the newer audio api but it comes with limitation so you can only serve your game through an https website which is okay but you also have to write your own javascript file that do the processing and like we do the processing in the c code of godot so we will need to expose some of those functionalities and then this the idea is that we don't have control over the thread that does the mixing so like it's a bit complex because we have to create a way to bridge uh what we like our functions to this treat that is generated by the api when we ask it to do so and it requires a separate javascript file and it requires some communication and sharing of some like of some memory uh which again will only work on https website and it's also not supported by most browsers yet firefox is enabling it probably in the next version uh chrome supports it i'm not sure chroma mobile supports it or only the newest maybe safari doesn't support it i don't think internet explorer supports or edge supports it so like even when it arrives uh even if it's there tomorrow you probably will only be able to use it on a few browsers uh but it's planned and it's something i really want to do and probably going to be do for 4.0 um and i'll even try to backport it if i can like succeed in it um but i moved it down a bit on the priority list because it's really hard it takes time and there's other stuff in the html5 export that needs to be fixed earlier and faster but it's something we want so i don't want to tell you something that i cannot respect but maybe by december maybe we'll see how it goes um that that's as much as i can tell thanks so let's go back to some of the patreon questions and just a reminder for those who join the stream later on if you want to ask questions in the chat use exclamation mark question as a prefix so that it gets filtered in our system so that we can see them easily you can see that others are doing it so you can do the same so i have a question for juan which is will you be continuing your series on godot's source code for new engine developers yeah that's a uh the problem is that for good for a lot of changes in the core of the engine are happening including a lot of renames uh a lot of ways on how the lower level systems are being uh managed to they are all being made a lot more optimized 4.4 so because they are changing so much i i thought it may be better to wait until the api stylizes again so if i do this now then they will be out of outdated in a few months so probably better to wait a few months until the engine is more stable and then go back to doing those uh tutorials about uh how the the engine works at the source code level yeah and in the meantime there's a new series by a contributor will nations that you can find on youtube who is basically taking on from what what one started and make doing his own dive into the engine source code and explaining a bit how it's organized so if you're interested in like having an introduction to how godot is built you can check out uh will nations on youtube so read the chat i have a question which i think could be for jill because i remember we talked about this kind of things maybe george or so to some extent which is um so the project.goodall file often has merged conflicts which are simple to fix do you think it is possible to add an automated feature to fix the merge conflicts in project.goto um that's possible i i mean this is those are the kind of things that are uh likely part of the vcs integration work we're doing right now we have a gsoc student who is working on integrating the vcs's version control system so we can have for now there's only git which is working but the plan is to be able to support other kind of uh version control system for now kind of have basic functionalities and it shows you some the diffs between the files but it doesn't provide uh more features on merging the conflicts but by the time we work on that we the plan is to have uh the possibility to merge uh to to solve conflicts uh both inside the script editor uh but also i'd like at some point uh to have also a tool in the inspect or to choose like uh when you have conflicts the version you want to keep and kind of solve everything directly inside the editor but that's a lot of work so probably the project settings are not going to be the first thing to be implemented but yeah it could end up being part of the the work someday but it's not planned like right now we have limited resources but yeah it's true that specifically for the project.file i mean i don't experience a lot of conflicts on it myself because don't change the settings too often but if your workflow implies changing them often maybe some plug-in could be made to like because it's very a very simple format to pass basically just a list of section values so uh it's easy to merge two versions of that provided you use a text file so tscn uh at least four scenes but it's the same from the project settings you can like basically edit the the the well solve the conflict directly inside the text editor most of the formats are really easy to to parse and like you you read the file it looks like an ini file i think it looks something like that so yeah most of the time it's easy to sort the conflicts but uh i mean that's why i mentioned the scenes because usually it's a little bit harder to to to solve the conflicts is that kind of kind of file so that's where the editor would be really useful to to solve the problems thanks so a question for juan about the navigation server so has any work been done recently on the navigation server since the last update and can we see any of it how performant do we expect it to be compared to uh yeah gd squares steering behavior framework i don't know if you're familiar with that yes the for code for the navigation classes and notes have been moved to a navigation server uh this work has been done with the audino andrea catania and i think he did a couple of improvements like for example he had a collision avoidance and a few other things and also the possibility to do 3d based queries so you can't just do a lot of queries on the thread and improve performance that way so i think you also don't need any longer the navigation node since now it's part of the world but i haven't tested it myself uh i think once we make an alpha or our avita of course four is going to get a lot of feedback but yeah the idea is that he's going many improvements also i think one thing he did is uh adding uh with this we lost george welcome back george uh one thing with it is i think properly adding uh the recast support and other stuff so in general it is it's it's much better for good.4 but i don't know exactly what improvements are i don't remember like on the top of my head so once the alpha comes out make sure to test it and give some feedback on it another question for well there are two questions which are kind of linked but let's start with um the one on for one maybe i can also add something what would you say are the areas of the engine that will change the most over the next two years and this is being asked in the context of someone making a game now and are the areas where they should not bother polishing things too much because it's going to be completely changed or like what are the most changing areas i guess comparing 3.2 and what like 4.1 or 4.2 would be okay here we go uh so the idea is that code 4 is going to be a major release with a lot of compatibility breaking we will still make tools to migrate easier so you your game can be made to work from three to four without as much as for as it was migrating from two to three but i think the idea is once god4 is out uh all the all the new features will be like more minor features are a lot more focused on polish also because uh i think most of the changes are going to be more stable i mean it's been a lot of work to get something that that just uh is what it's supposed to do uh so yeah that's i think it's going to be mostly polish and more smaller incremental updates nothing really big breaking or something like that maybe in rendering we will eventually add ray tracing support and these kind of things but that's not going to change uh most of how you do your stuff your stuff right and maybe on that topic of like compatibility breaking there's the question uh that but will there be migration specific docs from google 3.x to 4.0 and or helper tools to convert large projects for example gd script conversion skeletons particle systems and so on so to this i can say of course we will write some documentation about like what are the major changes and how you should um prepare for like parting over there will be several like we are not sure yet what kind of we plan to work on some tools to like simplify the parting work we don't know yet exactly what but basically one thing which is already implemented in the engine is that there's a compatibility alias for all the node names which have been renamed so godot 4 is still able to open your scenes from google 3 and it will automatically convert all the nodes which have changed names when when they are compatible so that's already working yeah i also added a lot of uh stuff so your your scenes just load i mean if you uh the idea is that if if you open ago.3 uh scene in four it should open it should be there with most of your data some things are different like for example the environment has a few different things like the skies work different uh but we added some tools that will automatically convert uh your stuff uh so the idea is if you of course you need to test the alpha and give feedback because we may be forgetting to add some options uh when eventually alpha comes out but it is it's going to just work it will be different with gd script so i guess george will be able to give you more detail on this because gd skip is going to become incompatible from three to four but i think you have been thinking about having a tool to convert so up to you george i guess we can have something in the editor maybe or maybe an external tool for converting i haven't thought about the details yet but the idea is yes to have some sort of tool that will parse the old script and it knows what's changed in generation new script stuff like the exports that are now annotations and like yields that become await and stuff like that and some of the renames is possible as well uh i haven't thought about the details yes the details yet but the idea is to have such do available to help people migrate as well and uh what else will there be to migrate this yeah there will be things probably where an automatic conversion will not be possible so probably particle system it's likely going to change again well juan is working on it right now it's going to work i i am making it compatible with the previous one so it should work that's nice so yeah for the things which cannot be converted automatically then we will try to write some documentation explaining like how best to reproduce what you add in google three in goto four but yeah it's it's going to be a big uh like a significant amount of sporting work but it should not be as bad as it was to pot from gold two to go to three um so i think we are aiming so that like medium-sized projects could pot in one or two days of work uh over to the new version i think that's a real realistic estimate for how much work it will require and for simple project it might be much simpler than that if we have tools to convert the gd script easily and stuff like that and so that's it for the questions we got from patreons so let's go back to check what we got from the chat so uh maybe i can talk a bit i'm not an expert on that but i feel in for ignacio about uh what are the plansfor.net like mono c-sharp support so some users are asking what's the progress of moving towards using.net 5 or net core or whatever it changes name every six months so i'm a bit lost myself in what's the proper name of the dot something but it's actually implemented already in the master branch ignacio did some changes recently so i think the master branch already uses the net five the new name right so i think in the master branch well it's like so the godo4 is already tracking.net five and using like the.net cli application command line tool to [Music] to instead of ms build like to communicate with the with the.net sdk and for google three two three now the same changes have been backported in a like more compatible way so that's why it's delaying the release a bit because it adds some quirks that need to be ironed ironed out now but basically we are using the new cs brush file format and currently it still tracks like dot net framework 4.7 as it used to or 4.7.2 i don't remember and but you can change it so it does like this for compatibility reason so that your project still work but for new projects i think or for your current product if you want to port them you can probably already change it to use.net 5. to be checked with ignacio because as i said i'm not an expert on that but there is like the modern.net things are coming and are already partially supported so that might require some documentation to explain exactly how do you get like uh what to change in the cs file in google 323 to get the latest.net and to get c-sharp 8's support and so on so yeah that's all that's cool stuff that is coming from [Music] ignacio um for jill maybe will tile sets be updated in 4.0 yes [Laughter] we're going to rework all of this it's um so as i say that the introduction of the stream uh this is most likely the first thing i'm going to do when i uh start working in november uh so maybe to detail the plan a little bit the idea is to likely to merge the tile set in the tile map editor as a first step so instead of having a panel on the right where you have your tiles and the panel on the bottom where you edit your tile set both of them will be merged together and you would have like an edit mode to edit the tile set or like the paint mode where you would have the toolbar to to paint and eventually feel that kind of thing a lot more operations uh so the plan is to make a proposal at the start of november or put it on github i probably talk a little bit about it on my twitter account when i'm done with the proposal so that people can come and give feedback and the goal is to have a great proposal so that i don't start working on something that big without being clear on what we're going to implement but yeah the the goal is to improve a lot the the the yours the user experience uh we know it's a problem we've seen the the video from i don't remember his name sorry but uh yeah emilio exactly uh so yeah so we know it's it's it's a priority and we're going to deal with the problem it has and try to solve everything at once as much as we can at least so there's a good uh simple question but which uh involves a lot of things which is will the minimum request requirements be updated for good of four like in terms of hardware drivers and so on so that's maybe for one to detail the current plan yeah if you're using if you're going to be using the vulcan backend then you need a hardware which is vulcan compatible which is i think directx 12 level hardware nowadays i think this hardware is quite commonplace so if you by default want to use the high i mean if you want to use high and 3d or make sure to use 2d in a way that is super optimized like the woocon backend is going to be i'm pretty sure that uh most computers are going to be able to run it if you even want to publish something like on steam or on mobile uh well mobile not so much uh but uh on desktop if you check steam survey the hardware survey like pretty much everything supports woocommerce so it should be okay if you want to publish a game for desktop uh for mobile it's going to be more like high-end mobile which means ios and higher and android which is what supports woolcan if you want to make something that works everywhere like on every single platform you will still have a gles3 renderer that will support most of what you do with vulcan that's going to just support it's going to be uh like a mix of rgl es2 and gls renderers in godot 3 because it's going to be able to be more compatible than our current glds3 renderer on godot 3. and eventually we've been discussing keeping a g alias to render but it's going to be more limited or maybe to the only still not completely sure about that we need to keep discussing that with the contributor so that's kind of the the goals right now uh regarding minimal requirements for the rest of things nothing else is going to change i think so yeah follow-up is um what version of vulcan will go to four targets 1.0 1.1 or while 1.2 now just 1.1 1.0 the newer ones are mostly focused on being more compatible with directx mostly because some game companies that have games made in directx want to port woocon or because you see like the proton emulator that valve is making for for steam requires very compatibility for the wrapper but in general with 1.0 maybe one or two extensions or something like that that will be still used uh it's not going to need a more modern versions of vulcan than that at least for now maybe when we are retracing uh in some time in the future that will require a more modern version or maybe just use the extension i'm not sure about it 1.0 should be why i would for a while but i think it will be much easier than with opengl to add like conditional support for features from higher versions yeah yeah the extensions are fine in bootcamp yeah and especially i think we will target white 1.0 for like maximum compatibility especially on android where the drivers might not get updated because the oem just does not update the android version anymore android is a nightmare but on the other end on desktop like for the engine developers themselves we might want to use like some features debugging features from 1.2 so while debugging the engine but still then use 1.0 for exporting so that's done uh for her for george we'll go to four support threat debugging for gd scripts i'm not sure so we do have an idea how to support threats in the debugger and one idea is to just simply like stop the only only the thread that's debugging that's probably the simplest way but you can probably figure out a way to stop outreads when use when you pause the debugger and yeah like fabio did a lot of work on the debugger so that part is probably already done so what's missing is having i stacked per thread in the gd scripts side so i'm not sure if i'm going to be able to do that on 4.0 or later but yeah that's like in the planes zoom ish yeah and uh if you cannot yeah something we can also like either only stop the tree that you're currently debugging or we could also since the main thread is also pulled on every frame we could also implement it that the next frame it will stop if it's not stopped already because it's waiting for the trade to finish of course in busy weight so we we can also have that option um i guess that could even be a debugging option yeah originally i think the problem is that when i wrote jesus creep a long time ago uh it doesn't really use like uh uh if you look like other scripting language like uh the javascript interpreters or lua or squirrel usually they have like a custom stack uh that they use but i didn't use that because uh the problem with that is that it's very difficult to get into work with multiple threads so gd script actually uses the operating system stack directly uh which is much faster and unfriendlier for this the problem is that when you want to show a stack trace you don't really have the information of the stack so we have to fake uh this a stack with a linked list or something like that when you run in the back mode and it gets complicated to do this with multiple threads so i think what we discussed with george is using something with credit local storage and we can probably just stop the trade that is being having the problem and let the others continue running and i think it should be okay for now it's just to catch crashes and eventually with more time george can find a better solution for this that makes more sense all right a question about shaders for juan will we have multi-pass shaders defined in the same shader not in multiple separate shaders in four point x no you're going to still need to do one material per shader don't make me do that it's much easier this way so just you just create a material and set the next pass and it's going to work what's going to change is that multiple passes are going to work also in 2d which don't work right now but it is to keep using them separate it makes everything much simpler and you can still do everything you need with multiple materials i mean it's less less hacky and just works on gdscript there's a question will signals support will signals support static typing in the same way as functions do in gd script that's for george i would say i think you're muted george sorry i missed the question yeah will signals support static typing in the same way as functions do ah that's complicated because the engine itself doesn't validate any typing for signals so we could use two like generation generate error messages in the editor but in the end you can pass any type and the engine will not complain but so i i'm still like and i don't know exactly if i want that to happen it should be like a compile-time validation you wouldn't affect like the runtime annually so that's probably like it's on my list but it's not like super priority for now i'm doing the others and so yeah this one is maybe a bit tricky i don't know who we want to answer but it's from will nations asking there's a there are many old issues which exist for discussing updates to the plug-in system like adding dependency management or sub-projects and so on and he's asking if there's been any concrete decision or what's like what's the feeling uh regarding this we discussed this a lot of times even during the godot sprint and there's kind of two two different uh postures about it uh one is going uh full modular package system like you try to replicate like debian packages and dependencies within the engine and the other is to just keep it simple because for most users the way it is works fine so right now i think keeping it simple is winning uh we actually discussed a lot of ways to do it i i can't even remember we discussed this with budget i think during our ago sprints not this one the previous one uh and in the end everything ends up being too complicated and we realized i mean when you're working with software like this uh if you make something complicated it has to be really worth it because otherwise it's a lot of code you have to maintain uh and this to it completely honest i mean it would be nice to have plug-in dependencies but we we found that it it can fail in so many ways uh like it already facing on distrust like uh having like you update one plug-in you can't probably see this happening a lot with npn and this kind of thing you are something breaks and then everything changes up break breakage uh and it's kind of a mess and probably not it's not going to be so much used in something like godot to be completely honest uh so probably for now it is to not do it uh but if a good way to do it that is simply not comes up or a scenario where it makes it worth it to do something like this also comes up then yes maybe but right now is more leaning on the way of keeping it simple so will there be any improvements on improve on importing 3d models and scenes sometimes specific kind of texture painting does not seem to be well imported uh the one working with this is gordon uh we should probably ask gordon about that or also i think the one also working on this is uh i fire i know that there's a new fbx importer in the work that has been almost made from scratch uh this was financed by imvu they are donating this importer so it's a new fbx importer that is super tested so uh i think if you're using blender probably you don't care so much since the glc f2 uh importer is working really well now uh and there's also probably the talk there's a talk we have with the blender people about making sure we can export more stuff from blender to a dot and for this we are using uh we had a go dot exporter for blender but maybe it could be better to define extensions than gltf2 which is very extensible so this is a discussion that we need to have eventually uh but other than that yeah the texture importer is being improved there's a lot of improvements on on the importing processes for there's also betsy coming up which is a a library that matthias from august 3d made that we are financing from godot which is for importing textures using the gpu doing all the texture compression and gpu this can accelerate significantly if you have a good gpu it's going to accelerate a lot and if you don't have a good gpu then at least it's going to let you scale up and do half on gpu and half on cpu so you can import textures faster uh so yeah there's a lot of improvements coming for good.4 so when the alpha comes up make sure to test it and see if if it covers what you need so there's a question about will we be able to export user-defined resources in goto four so that's for george so probably yes there are some people working on this i think he juan was working this uh the there's will nations did the previous work and then it was changed but i think it was only for 3.2 so we need to part that shortcut master and it should be easier to do at least from from the gdescript side should be easier to do that but you need a few changes in the editor to make sure it works so probably yes it's gonna be done just not yet but soon so sorry i'm lost in the questions i'm trying to figure out which one's next um okay this one are there plants to make i don't know for whom but for anyone who feels interested are there plans to make it easier to make add-ons that modify the editor layout i think that's for you jealous that's a good question we probably need to first to resync the editor itself so before adding any other way to like make things more flexible than kind of thing the editor is already quite flexible now you can look at dogs and that kind of thing so i'm not pretty sure where the limitations are whether or not it's like the interface the api which is not simple enough maybe or but well the goal in the end is likely to rework a little bit the editor first uh and if we later on want to improve things a little bit for plugins and make it easier to integrate editors yeah that's the plans after i'd say but i think if the question is like whether godot will eventually become like blender where you can really create your own dashboards with all the elements the way you want i would say that's probably not the goal no that's probably not worth it that's something we discuss with uh juan a lot and it's not that we disagree i i'd say personally i would like a little bit more flexibility in the way elements are organized especially since now we have the possibility to undock uh tabs and that kind of thing so there might be some work to do to make the enterprise in general more flexible but it needs some thinking because one thing we don't want to lose at all is how like easy in godot when you click on something the correct editor opens uh and then you click on something else and everything opens uh on what you need when you want to edit a specific resource and this is something we don't want to lose because i uh yeah in other editor you might have like to go into the let's say uh the into workspace and build your own workspaces that kind of thing it might be interesting but i mean this is not the most user-friendly way to present an interface in my opinion so yeah and it's thinking and that's likely going to happen someday but uh we did as usual we need a proper proposal before doing that but yes yeah my way of seeing this is that what blender does with the workspaces is more like a workaround to the limitations of the way the interface is because you can just it's very flexible but then you need something to work at one situation and the other and then changing things around takes a lot of time so i think that's a workaround for a limitation in the design rather than a feature uh in the case of godotties as shields says uh ingot is more designed so the correct editor pop-ups at the right time you want to do something and this is something that i think in my personal opinion works better than just letting you just adjust everything freely and then because it's a mess have to put workspaces and the idea is to just go further in the direction of automatizing how things pop up and and work for you rather than just letting you just do whatever you want and then have to fix it yourself in the end that's kind of the idea that's completely agree so there's a question which is whether we have any plans for blend file format compatibility so i think this was partially an answered yet i can also say like importing blend files as a format is not going to happen because that doesn't make any sense for us to re-implement an importer for a gpl file format where we could not even look at the source code to implement it but what we could do if there was really a lot of interest is do the hacky unity way to just like you want to import a blend then we call blender and we ask blender to export gltf with all the extensions that we need and then it loads in godot as the ltf but it looks like you imported the blend file but so far we don't have a plug-and-play workflow that would make it meaningful to do it this way so for now it's better that you just export yourself from blender and configure things properly but maybe further down the line we can do something like that so a question for george you talked about native compilation in gd script but only for functions for debugging for a pose could you talk a bit about that and is it possible to compile all during the export sorry yes so the idea is not to really for debugging purposes it's more like if you compile your native you cannot really debug anymore because it's not chinese script so it's not running through the interpreter so we cannot like we don't know what's going on so we need to use like gdb or something to debug it so it's kind of complicated so the ideas should be like only when you really need this function how it runs every frame and have like doubly nested for loops or something like that niche you run fast then you can add an annotation for this function and you it will be would be compiled to native and then just call the the native function you know but the the sda from more from juan like he come up with this the situation with this proposal but they think it would it wouldn't be worth it to just like compile everything because most of the thing wouldn't make a lot of difference anyways it is theoretically possible but it wouldn't be worth it to compile everything on export so it would be wrong for functions that really should be really fast we discussed this with a lot with george and the problem is that first of all the gd script is a dynamically typed language uh so if you are using a dynamically date code compiling the code to native it's not going to make any difference uh because it's still it's going to be native because you don't really know the types you can infer some of the types but not going to make a lot of difference to you uh so that's the difference with something like c sharp or c plus plus which is mainly intended to be statically typed on g script uh we discuss a lot and the priority is going to still be that it's a dynamically typed language and you have static types in case you want to have like i don't know better completion or maybe just more optimizations because you can go via the type if you know the type you can just use type of codes and it's going to be faster so it is that you first anyway like imagine the workflow you're going to be making a game and you probably want to make some function faster uh then now the the editor will show you when you're using typed instructions like george made it so it shows you perfectly that your code is typed so if you want to optimize a function that's slow you will make sure to make all of it typed you can see the lines clicking when they are typed just say they are safe once they are typed george is going to add now the type interpreter which uses typed instructions these are always going to optimize a lot the runtime because if you know like for example uh the actual uh right now if you want to call a function and you don't know the types going to go through a few hash maps and different things but if you know what the function is when you compile you just can't keep the pointer to the function and code much more efficiently so even if it doesn't compile the native having typed instructions going to improve the performance a lot so what we discussed with george is that we can go this a bit further if you wanted to have native so native speed so if you create your function and you put all the types and it can probably get a bit more boost instead of using type instructions just go totally native and you kind of optimize this function a bit more but the idea is that you still need to make yourself all the work to write all the functions typed uh in order to get some performance boost uh so compiling everything doesn't really make sense and also if you make a game you don't benefit from compiling everything plus you lose the device the ability to debug so it doesn't make any so so what what george says is kind of what we're going to do just choose whatever you want to optimize uh make it typed it's going to be faster just because it's fully typed with the new vm and if you need a bit more performance then you can compile that to native and get the extra boost but it's kind of like the last resource if everything else fades not really what's going to do by by default so we have some core developers that use the q a to ask some questions about development so let's go so gordon is asking if we want to deprecate the kolada importer i don't know let's talk about it i haven't is is anybody still using the colada importer i i don't really know uh if you want to deprecate i mean if it still works i don't really see much of a reason to deprecate it especially if people has projects that have been working for a while because at some point it was the best importer so we may not want to replicate it now maybe in the future if nobody's using it anymore but i don't know let's see if somebody's using it first and see if it can be improved or something like that i guess because yeah it's not a lot of code and it's still useful to import like simple scenes or models or stuff like that it doesn't need to support all the features that we might get through gltf or even through extensions to gltf to import like materials and complex stuff but that's not what it's being used for so far anyway so it doesn't hurt to keep it around as a limited order uh one question uh where i know we don't have a clear answer but we can try do we plan any improvements to video playback so i can say we plan to remove the video playback modules that we currently have and instead we would like we already have a g native interface for video decoding so we'd like to continue in that direction and have an official plugin for decoding more video formats using julie native so that it's not included for everyone you include it if you need it and you have access to more formats that's kind of the plan but there's no clear direction right now for when to do that yeah the problem is that the video codecs are huge there are a lot of code and they contribute a lot to the binary size and if you ask around there's only very few users who are doing video playback in their games like it became it used to be more common before but nowadays everybody does this all the in-game cinematics using animations and this kind of thing is it's a bit rare to see actual video playback in a game nowadays so given there's not a lot of demand for it and that it takes a lot of the binary size that it is to just move it out and if you really need it you just get from the asset library uh the gd native models for it and use it but that's the plan mainly so there's a question about is there any interest in supporting javascript or quickjs so there's a contributor who implemented support for it um g cooling and it's already working i can link it in the chat maybe [Music] i think a model right now you have to compile the engine with it uh with this cut uh the thing is the following we don't really know how much real demand for javascript support within the engine there is so what we suggested to him is to change the model to use a cheaty native model so you can just like download it and add the javascript support to the engine uh and if it really proves to be popular we can maybe make it official but that to be honest i'm not really sure how uh how much people are actually using i know javascript is super popular but for making games is like not so common unless you make games for the web uh so i don't know we let's see how much popular it is and how much people relax it before deciding on something like that yeah but what i can say is that we're always open to having more like community maintained uh plugins language support plugins which you can install if you want but we don't really see any needs for adding like building support for more languages in the engine right now than gd script c sharp and visual script because it kind of covers already a lot of the different use cases that one might have for a visual language and very easy scripting language and a more full-featured compiled language so adding javascript would kind of be the same as using gdscript the performance is the same and the syntax is quite similar so it's it's more like if you really love javascript then yes you can use the module or hopefully in the future gd native integration so that it's just plug and play because it's also important to know that anytime we add a new like officially supported language that means we need to duplicate all the documentation for it uh we it it adds a lot it's not just like oh it's implemented it works let's go with it it's like each time you add a language you double the amount or like you adds 100 for each language of amount of work on everything which is around it so it's better if this is maintained by community members there's a question about will we get the an editor for android and yes uh there's work uh being done on it uh right now uh so there's already a working work in progress for the three point i don't remember it started for the 3.2 branch then it was spotted to master i think because we always want to merge new features in the development branch first and not like much work in progress stuff in the stable branch and break everything for your games but there's promising support already for running the good editor on android so it still uses the same kind of input workflow as on desktop so you it's like it's good on an android tablet if you can plug in a keyboard and a mouse but eventually once this is working we can start thinking a bit about how to implement some kind of touch-based support for using the editor so that should be quite interesting uh in the future oh by the way you can actually use it already for android if you use fabio's work on the web app i think i tried and it seems to work fine or android maybe not the most optimized thing but it works so you can experiment with that if you want and or you need something urgently that works on android so well i think we're closing in on one and a half hour so probably check if there's one or two interesting question and then we can wrap up um there's a question for juan uh is it true that juan worked on argentum online uh no i didn't work on argentum online i'm sorry uh that's a very weird very old argentinian game mmo or something like that from the 2000 i think it was a really weird game it was very uh weird it was really argentinian i think it was so so strange so i think i composed some music for them i composed the intro song this this is like the year 2000 so you make an idea i'm i'm 40 so i am pretty old uh and i think i was going to make the second part of that game uh but then it became another thing called regnum online which is still you can still play that game uh it's champions of ragnum or something like that i started working on that one uh but no i didn't work on the actual argentine lime sorry i'm sorry to disappoint you i think the question comes because i saw there's a godo made mmorpg which has just been published which is inspired by argentum online so i guess it's in the same argentinian based mmo vibe all right do we have a last question well that's a bit of a tautological question but there's uh mario's asking if there are any plans to fix some editor bugs on the 4.0 branch so i can say yes we do fix bugs when we get to it but yeah for those who try the current development branch you might find that there are a lot of issues uh like on x11 not everything works as you expect it or but it's been a big refactoring effort tons of new features implemented so it takes a while to go back to something stable with the new feature set once we reach something where we consider that it's like usable for like all users who are eager to be like early testers we will have an official alpha build but as long as we don't have an alpha build you can expect that it's very unstable and it might just it currently godo on some configurations can crash your system because some drivers just explode when they try to do something that kodo is asking so it's not for the faint of heart currently the master branch yeah it's much easier to first add the features and then fix the box because the features are never stable and until everything is done changing so uh going to fix box right now is like maybe we fix a few of them and we merge requests with bug fixes but uh the full focus is on adding features as i said before the the idea is to uh complete maybe in two months or three months to have like an alpha or something like that after the optimization work is done and then it's going to be fixing issues until we make the stable version like nothing new uh we still have the we are still discussing like for example if you're going to uh support opengl in 4.0 because it's not completely certain yet because there's so much new code that needs to be tested and bug fixed that would be nice to have something stable using bulk and first so maybe we can make like we did with 3.1 and add it later i'm not sure yet depending on what contributors can do and if we have enough contributors to have time to do the porting of opengl uh so still everything is very much in the air right now uh we will have more idea about this and in two or three months i guess great so i think we'll stop here for the questions um thanks to all of you for the answers and thanks to everyone for watching uh it has been a nice uh nice interaction with the community so i hope it was good for you uh if you have feedback uh feel free to to write it in the chat i will have a look and see if there's anything we should try to improve for next time so we are still oh hi jill scott the beauty that's perfect ending your livestream that's uh 1 000 more views just yes for it's a reward for all of you who stayed till the end so thanks everyone and see you next month yes oh

Channel: Godot Engine

Views: 6,918

Keywords:

Id: 0zsgT9Gi_4o

Length: 86min 10sec (5170 seconds)

Published: Mon Aug 31 2020

Reddit Comments

[u/HaveToExplainSarcasm]

These Q&A sessions are very welcome. Thank you for doing them.

Here's a few ideas to consider;

Please output to 1080p video and if possible buy better quality cameras. Also, the Jitsi watermark in the corner of the screen looks a bit amateurish and distracting.

Rather than 5 people having an 85 minute presentation, consider 2-3 people talking about about their domain for 20-25 minutes. This is more digestible, and means you have content for more frequent presentations.

A short summary of interesting PR merges since the last video gets people up to date.

Blender Today is very slick, it's worth looking at. A few extra elements like an opening title screen, and intro music improve the production value. Could you reach out to the Blender team for some suggestions about software and equipment.

Please put the livestream date and time on the Godot homepage. Not everyone follows Twitter. Include a YouTube link on the homepage too.

Presentations for Spanish, French, Russian and Portuguese speakers would be popular too.