Material Maker is the first big FOSS project I contributed to and - while being very impressive and powerful - has a very sloppy code base. Diving into the source code was a pain in the ass (I actually was involved in some projects with questionable code quality, but none were that hard to get started). It could really use some documentation and refactoring. While improving heavily feature-wise at a really nice pace I'm a bit afraid of an unorganized growth potentially leading to abandonment due to too complicated code.
@@vojtastruhar8950 Well, I wouldn't say that. Key is to know the language and plan your software accordingly. Using type hints or strictly typed languages reduce the amount of documentation needed, but I would not say that dynamically typed languages tend to get unorganized. I think the problem with Material Maker is mostly the lack of code documentation as well as no strict style/design guide for new code.
@@vojtastruhar8950 var my_int : int = 0 or export(int, 1, 3) var my_int_again = 2 GDScript is not only a typed language. Like python, you can type cast.
Hmm Material Maker is not a big FOSS project, rather a tiny one. GDscript is definitely not a problem, it's very simple and clean. Godot, though, has lots of nice features (signals, groups...) that can lead to complex design. And Material Maker uses all of them. It's true it's not easy to dive into Material Maker's core, because it's inherently complex (basically generates shaders and renders them asynchronously). But the different components are well separated (and generally don't depend on each other more than necessary). Many contributors added nice features with success (sometimes without asking any question before creating a PR). I generally refactor and cleanup parts of it when (1) I have a good excuse that benefits users, and (2) I'm ready for it (i.e. I have a precise idea of what it should do and how it should work). I NEVER refactor for the sake of it, I'd rather release new stuff for users every 3 months (and so far kinda succeeded) and apply refactoring as a side effect of new features. So yes at some point everything will be refactored (should happen pretty soon since Godot4 migration will require major rewrites), and it's likely at some point I'll write a small documentation for contributors. Until then, you can contact me if you have questions (or at least join discord and chat with users and other contributors). Oh, and I have "bad" news for you: it's likely MM will also have C++ code in the future. :D BTW, you even don't have to dive into code to contribute. Adding new nodes or new export targets is done entirely in MM.
@@RodzLabs Don't be so modest @RodZilla. In the ocean of free software it might be tiny, but with 1.8k stars and the popularity it has for FOSS game devs I would consider your project big (not as in stats like Godot itself or Blender but in impact on the community). I never complain(ed) about complex code or even GDScript itself. My point was less about refactoring but more the fact that it grows without contributing guidelines and with very little documentation. Also, the code quality as in how it is written and how the software is designed is pretty okay. I wouldn't consider this sloppy at all. I was not talking about the code base being bad, I just think that all the little things I noticed while diving into MM bring the danger of getting so messy that it will be too hard to make anything productive. In my experience refactoring for the sake of it really helps decrease technical debt and reduces costs for implementing new features drastically in the future. Anyway, I managed to get familiar with the code and would consider my understanding of it good enough to implement what I have in mind. It was just relatively hard to get started as there is no obvious starting point on what is what and very little documentation leading to hard work of understanding the overall concept of MM's code. It lacks a bit in consistency. This, of course is my subjective perception. Maybe I'm totally alone with this and everyone else thinks exactly the opposite.
I love the idea of using a game engine to power the 3D rendering of some non-game software, like, think of how amazing it would be if, say Maya or Blender used Unreal for their real-time rendering, wouldn't their viewports look far better than they do today?
Did you know that Quixel Mixer still use Unity? Unreal asset pipeline is really restrict to do anything beside game. You have to modify the source code and they not allow mix up copyleft open source license (GPL) with UE license.
@@REOsama It is developed actively. It's basically one of their flagship features. It is not exactly like Unreal or so, but I don't get what the gain would be. EEVEE is very lightweight while Unreal uses a lot of resources. Their would be no gain since there already is a high performance rendering engine that is superior: Cycles.
This is a really cool tool to create materials, especially tileable. Since I currently have to create materials myself, I've been trying to do the same via Substance Painter by painting (since I don't want to give more money to Adobe), I'm going to try the procedural approach here. Thanks for introducing this application!
after playing around with the app, it's quite comparable to the early version of substance designer, not bad, i'm quite suprised actually, my substance designer skills transfered nicely. it only need a couple of polishing and performance optimization. i'm always love using substance designer, and knowing that there are an open source alternative version of it makes me happy. well done, good job for the dev
@@jensenraylight8011 Hi. I'm curious about what you said with it being comparable to the early version of substance designer. What features are missing that would make it comparable to the current version?
@@festerbutt I think what he means is that the files sizes can be pretty big due to having so many features that are rarely used. It's not spyware just an app thats bloated with features. used the substance suite for a few years now and haven't had any issues really.\\
GitHub recognizes GDScript quite a while already, thus it's not that new really. Though I don't know how long they can do that, could be 5-6 months, could be a year, I don't know. But yeah, generally that's really cool. 🤖
I have no idea why but YT just refuses to play this video for me, no issue with any other video just this one in particular, been trying to watch it the past 2 days
It just not out of box and maybe need modify the source code. (or may be not if it's pure math likes shader toy, Godot shader can do this already) Anyway, Godot 4 will remove OpenGL limitation with Vulkan.
Don't know why he would. That's an in game map editor that just looks like it allows a lot of control to the point where it's basically an official modding tool. This channel is about digital content creation tools.
@@larssonk22 I don't really know what to tell you other than it's simply not the same thing. I suppose if you want to split hairs, but it still wouldn't be considered a DCC tool. When someone is talking about a DCC tool, they're talking about software that allows them to model, sculpt, retopologise, unwrap geometry, write code, digital painting and image manipulation to create concept art, key art, etc. Game engines as a whole to create what ever game and mechanics they can imagine. Calling an in game map editor is like calling Audacity a DAW. Kinda correct if you split hairs, but fundamentally is not capable (nor designed) as tool for what people who are looking for a DAW. For example, if I want to make my take on a third person stealth espionage game akin to Splinter Cell or Metal Gear, or if I want to bring my epic, grand medieval fantasy world with my original religions, cutlures, creature/character designs, animations, etc. to life, an in game map editor with some degree of scripting tools in a sci-fi FPS that ultimately has you constrained to the assets that exist with that game itself is not going to help the people that watch this channel. There is definitely a difference between a DCC tool vs. a robust in game map editor. Not to mention that a lot of people who watch this channel are looking for alternative tools to save money (or perhaps out of principle to boycott certain companies) and ultimately want to make a game (or some other kind of product) that they can release and try to turn into a business. A tool specifically designed for making maps in an already existing game where that tool exists within that game itself, and is constrained to the assets in that game and can only be used to make content for that same game is not what we are interested in here. If you want someone to cover that sort of thing, you should be watching gaming news channels or something. Not a channel about dev tools. Because as cool as I think Infinite's Forge is, that's not going to serve us here.
@@brandonmcgregor9912 Valid points thanks for taking the time to share them so concisely. I do agree with your points I just thought it would bring some fun and something different to the community, who knows it might inspire other devs to create tools for devs but tools that don't have steep learning curves making it accessible to the masses. On a personal note, I find the whole concept of Forge fascinating not just from a gamer's perspective but as a developer myself, giving tools to a community to create and take your creation in directions I would never have thought of and even as business the man hours that took to create a tool that is free they must be thinking such tools will extend the life of the game through community sharing and attract other players who aren't necessarily interested in playing but in creation.
I don't know. Ask Epic, maybe. 😁 MM's core (i.e. shaders generation and rendering) could easily be reimplemented in another environment/engine (WebGL, Unreal, whatever...) and adapted to generate HLSL instead of GLSL. All nodes (predefined and custom) would be reusable.
Well it depends. When you want procedural texture generation I would consider this more engineering than art. And the only effective way to approach this non-destructively is using nodes.
Links:
gamefromscratch.com/material-maker-release-version-1-0/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
-----------------------------------------------------------------------------------------------------------
at my day job we use adobe but on my own ive been switching to all open source apps. they do improve very fast which is really amazing to me.
I just downloaded and gave it a shot.
This thing is very powerful! Thank you for reviewing it!!!
This is insane! Well done Material Maker!
Material Maker is the first big FOSS project I contributed to and - while being very impressive and powerful - has a very sloppy code base. Diving into the source code was a pain in the ass (I actually was involved in some projects with questionable code quality, but none were that hard to get started). It could really use some documentation and refactoring. While improving heavily feature-wise at a really nice pace I'm a bit afraid of an unorganized growth potentially leading to abandonment due to too complicated code.
Is it because gescript is hard to refactor and upkeep maybe? I feel like with a typed languages the codebases don't tend to degenerate as much..
@@vojtastruhar8950 Well, I wouldn't say that. Key is to know the language and plan your software accordingly. Using type hints or strictly typed languages reduce the amount of documentation needed, but I would not say that dynamically typed languages tend to get unorganized. I think the problem with Material Maker is mostly the lack of code documentation as well as no strict style/design guide for new code.
@@vojtastruhar8950 var my_int : int = 0 or export(int, 1, 3) var my_int_again = 2
GDScript is not only a typed language. Like python, you can type cast.
Hmm Material Maker is not a big FOSS project, rather a tiny one.
GDscript is definitely not a problem, it's very simple and clean. Godot, though, has lots of nice features (signals, groups...) that can lead to complex design. And Material Maker uses all of them.
It's true it's not easy to dive into Material Maker's core, because it's inherently complex (basically generates shaders and renders them asynchronously). But the different components are well separated (and generally don't depend on each other more than necessary). Many contributors added nice features with success (sometimes without asking any question before creating a PR).
I generally refactor and cleanup parts of it when (1) I have a good excuse that benefits users, and (2) I'm ready for it (i.e. I have a precise idea of what it should do and how it should work). I NEVER refactor for the sake of it, I'd rather release new stuff for users every 3 months (and so far kinda succeeded) and apply refactoring as a side effect of new features.
So yes at some point everything will be refactored (should happen pretty soon since Godot4 migration will require major rewrites), and it's likely at some point I'll write a small documentation for contributors. Until then, you can contact me if you have questions (or at least join discord and chat with users and other contributors).
Oh, and I have "bad" news for you: it's likely MM will also have C++ code in the future. :D
BTW, you even don't have to dive into code to contribute. Adding new nodes or new export targets is done entirely in MM.
@@RodzLabs Don't be so modest @RodZilla. In the ocean of free software it might be tiny, but with 1.8k stars and the popularity it has for FOSS game devs I would consider your project big (not as in stats like Godot itself or Blender but in impact on the community).
I never complain(ed) about complex code or even GDScript itself. My point was less about refactoring but more the fact that it grows without contributing guidelines and with very little documentation. Also, the code quality as in how it is written and how the software is designed is pretty okay. I wouldn't consider this sloppy at all.
I was not talking about the code base being bad, I just think that all the little things I noticed while diving into MM bring the danger of getting so messy that it will be too hard to make anything productive. In my experience refactoring for the sake of it really helps decrease technical debt and reduces costs for implementing new features drastically in the future.
Anyway, I managed to get familiar with the code and would consider my understanding of it good enough to implement what I have in mind. It was just relatively hard to get started as there is no obvious starting point on what is what and very little documentation leading to hard work of understanding the overall concept of MM's code. It lacks a bit in consistency. This, of course is my subjective perception. Maybe I'm totally alone with this and everyone else thinks exactly the opposite.
Thanks a lot for this excellent (as always) video!
Just added the download button. 😉
Nice
Congrats, you are a shader (and Godot) wizard!
I love the idea of using a game engine to power the 3D rendering of some non-game software, like, think of how amazing it would be if, say Maya or Blender used Unreal for their real-time rendering, wouldn't their viewports look far better than they do today?
Well, there's EEVEE in Blender for PBR real-time rendering.
@@comedyclub333 Yes but it isn’t being developed actively, also it’s not even close to something like unreal
@@REOsama eevee is actually really powerful and afaik they're still working and improving it to compete with their renderer cycles
Did you know that Quixel Mixer still use Unity? Unreal asset pipeline is really restrict to do anything beside game. You have to modify the source code and they not allow mix up copyleft open source license (GPL) with UE license.
@@REOsama It is developed actively. It's basically one of their flagship features. It is not exactly like Unreal or so, but I don't get what the gain would be. EEVEE is very lightweight while Unreal uses a lot of resources. Their would be no gain since there already is a high performance rendering engine that is superior: Cycles.
They must be paying close attention to your videos, they've already added a download link there!
Its make me feel like rendering a visuals from connecting electronic chips
and i like it! i will give it a shot.
This is a really cool tool to create materials, especially tileable. Since I currently have to create materials myself, I've been trying to do the same via Substance Painter by painting (since I don't want to give more money to Adobe), I'm going to try the procedural approach here. Thanks for introducing this application!
Great, now i can dump Substance designer and be free from the clutch of Adobe bloat
after playing around with the app, it's quite comparable to the early version of substance designer,
not bad, i'm quite suprised actually, my substance designer skills transfered nicely.
it only need a couple of polishing and performance optimization.
i'm always love using substance designer, and knowing that there are an open source alternative version of it makes me happy.
well done, good job for the dev
@@jensenraylight8011 Hi. I'm curious about what you said with it being comparable to the early version of substance designer. What features are missing that would make it comparable to the current version?
Can you explain more about the adobe bloat? Is it like spyware?
@@festerbutt I think what he means is that the files sizes can be pretty big due to having so many features that are rarely used. It's not spyware just an app thats bloated with features. used the substance suite for a few years now and haven't had any issues really.\\
@@oozly9291 thanks a lot for explaining
Just realized they essentially have the 3D Coat logo.
Wow, they’ve got nice documentation!
GitHub recognizes GDScript quite a while already, thus it's not that new really. Though I don't know how long they can do that, could be 5-6 months, could be a year, I don't know. But yeah, generally that's really cool. 🤖
It's been around for a few years now. I remember it was already recognized when I started using Godot 2-3 years ago when I remember correctly.
So cool that it is built on Godot.
It is really facinating what nice visual effects some mathematics can do.
Everything in computing is done with mathematics, you know that.
@@Zephyrus0 actully not exactly, though these bricks, wood etc. patterns are pure mathematics applications.
6:54 looks funn to adjust for clock on bilboard etc in shader but also baked for low settings annimated clock in game :D
How does this compare with the Unity asset "Seamless - Procedural Texture Builder"? Other than the obvious difference that one requires Unity.
Now if only I could understand how to actually do anything in this thing XD
This looks pretty cool, but am I limited in where I can use these textures? Is it possible to use them in Blender or something?
Took a look and it seems that they have a download option in the menu already.
This is absolutely amazing.
I have no idea why but YT just refuses to play this video for me, no issue with any other video just this one in particular, been trying to watch it the past 2 days
thanks for showing this!
Can this tool output texture images? Or is this all an in memory shader?
in the unity includes the URP option wean you create shaders ?
Is there something like this for 2d assets?
there is a binary available through the AUR for arch linux distros, there might be Ubuntu apt or other versions too but I haven't checked
It is also available as a Flatpak
GitHub has recognized GDScript for several years now, that's not anything new.
What about blender shader nodes vs this software
w8 for COPS revamp in H20
I wish them and armor paint would join forces.
There's also Texture Lab.
@@MrERJ1992 Oh yeah, that one was neat, I just wish all these programs were a little more updated; but I'll take what I can get.
question, if its made from godot, does it mean the materials made from it would be limited by godot's current tech/performance/look/visuals?
if the program's shaders allow math, then I doubt there's gonna be a limit
@@RenderingUser ow, cause it would be procedural at that point? thankyou for the answer ^_^
It just not out of box and maybe need modify the source code. (or may be not if it's pure math likes shader toy, Godot shader can do this already) Anyway, Godot 4 will remove OpenGL limitation with Vulkan.
How does this compare to armorlab?
Is that another texturing software?
This should be included in godot 4.x feature
They don't the main engine with every possible feature, so it might remain in its current form.
's lovely
Hi Gamefromscratch when Forge for Halo Infinite is released could you do a video review?
Don't know why he would. That's an in game map editor that just looks like it allows a lot of control to the point where it's basically an official modding tool. This channel is about digital content creation tools.
@@brandonmcgregor9912 it's still a digital content creation tool just enveloped inside of a videogame.
@@larssonk22 I don't really know what to tell you other than it's simply not the same thing. I suppose if you want to split hairs, but it still wouldn't be considered a DCC tool. When someone is talking about a DCC tool, they're talking about software that allows them to model, sculpt, retopologise, unwrap geometry, write code, digital painting and image manipulation to create concept art, key art, etc. Game engines as a whole to create what ever game and mechanics they can imagine. Calling an in game map editor is like calling Audacity a DAW. Kinda correct if you split hairs, but fundamentally is not capable (nor designed) as tool for what people who are looking for a DAW.
For example, if I want to make my take on a third person stealth espionage game akin to Splinter Cell or Metal Gear, or if I want to bring my epic, grand medieval fantasy world with my original religions, cutlures, creature/character designs, animations, etc. to life, an in game map editor with some degree of scripting tools in a sci-fi FPS that ultimately has you constrained to the assets that exist with that game itself is not going to help the people that watch this channel.
There is definitely a difference between a DCC tool vs. a robust in game map editor.
Not to mention that a lot of people who watch this channel are looking for alternative tools to save money (or perhaps out of principle to boycott certain companies) and ultimately want to make a game (or some other kind of product) that they can release and try to turn into a business. A tool specifically designed for making maps in an already existing game where that tool exists within that game itself, and is constrained to the assets in that game and can only be used to make content for that same game is not what we are interested in here.
If you want someone to cover that sort of thing, you should be watching gaming news channels or something. Not a channel about dev tools. Because as cool as I think Infinite's Forge is, that's not going to serve us here.
@@brandonmcgregor9912 Valid points thanks for taking the time to share them so concisely. I do agree with your points I just thought it would bring some fun and something different to the community, who knows it might inspire other devs to create tools for devs but tools that don't have steep learning curves making it accessible to the masses.
On a personal note, I find the whole concept of Forge fascinating not just from a gamer's perspective but as a developer myself, giving tools to a community to create and take your creation in directions I would never have thought of and even as business the man hours that took to create a tool that is free they must be thinking such tools will extend the life of the game through community sharing and attract other players who aren't necessarily interested in playing but in creation.
Why something like this is not implement in unreal?
I don't know. Ask Epic, maybe. 😁
MM's core (i.e. shaders generation and rendering) could easily be reimplemented in another environment/engine (WebGL, Unreal, whatever...) and adapted to generate HLSL instead of GLSL. All nodes (predefined and custom) would be reusable.
Usual node crap that requires you to be an engineer over an artist. Substance remains supreme.
Yeah, but you still have to pay money for it.
@@MrERJ1992 That's why torrents exist.
@@Valk-Kilmer Well, yeah, but this software does have some potential.
Well it depends. When you want procedural texture generation I would consider this more engineering than art. And the only effective way to approach this non-destructively is using nodes.
What do you mean? Substance Designer is also using nodes to create materials and those graphs can become quite complex.
𝐩𝐫𝐨𝐦𝐨𝐬𝐦 🤷