Substance painter might be using the heightmap to hold the data needed before baking the normal.
Yeah I was about to say that, these softwares use both the height information and normal information in the final normal map(if you choose to) So I guess it doesnāt matter in that sense if you modify the normal map or the height map in the process, as the final normal map will be of the same quality regardless. I didnāt formulate it that well, but this was what I meant. So you could just choose to modify the height info in the process.
Yeah the hieghtmap is more a shortcut is what Iād guess. I mean it might wind up looking a bit different.
Just gotta test them out in engine.
The limit of normal maps is that they are actually flat.
________ /\/\/\/\
If you compare these cross sections⦠The actual surface is larger on the second one. If it were made geometrically itād be about twice as long when unfolded. So a normal map can capture the illusion of those ridges to an extent⦠But the available surface area is less than what it is trying to represent.
Or to further the notion. Imagine the difference of a regular texture on both the objects⦠Your either using a larger texture for the second or if using the same texture on both the second will look all stretched out.
So its a limit on how much normal maps should be expected to do⦠Cause they canāt compensate for that..
I might be preaching to the quior. I find all of this stuff interesting⦠Fun to think about.
If you get them loaded into the engine put up a screenshot. Iām curious
I used AI to write me a shader script in Godot to get a toony look where handpainted textures shines (no normal map, no roughness etc, only color). It did a good job, got a WoW feel to it.
The code didnāt seem complicated at all, there werent many lines, I think Iām going to learn some GDshader scripting to understand it better.
Iām kind of a sucker for normal maps though. Even with a stylized look, I think good normal maps can make things look cool and interesting. Not that 100% handpainted isnāt cool, it is.
Yeah godot makes things as accesible as possible⦠The later versions are better but thats mostly just renaming methods to make more sense.
They had a visual scripting shader thing for a while that was cool.
Shaders are pretty strict with their syntax.. But that is was grants them the efficiency.
Got sidetracked with video games yesterday⦠At work now. My program is still in a state of being pretty far from where it needs to be.
At the point where making the editor co-exist with the real time environment⦠Is basically what needs to happen. So packaging all that to play nicely is a jigsaw puzzle. Itāll prolly work pretty quickly⦠But⦠Prolly also be a buggy mess.
Really? Like node-based? Why did they remove it?
Quoting an AI:
VisualScript (a node-based coding language for game logic like GDScript) was removed from the core engine in Godot 4.0 due to low adoption and lack of traction.
I think it fell to lower priority in the face of the rest of complexity of the game engine.
Iām still using 3.5⦠As thats what the Vita build was compiled to. Iāll have to look and see if its there.
I did use 4.0+ for a good while⦠It is a lot more straight forward than 3.x⦠But its mainly just renaming things at least from the scripting perspective I really dont use anything else.
Iām curious what the framerate difference would be between Godot and Unity if you were to build the exact same game. Say youāre targeting fairly high end graphics, lots of polygons, textures, and effects.
Thatās a fun question. But I canāt really say for certain.
Sort of gonna talk off the top of my head here⦠But unity has better support for c# c++ even programming Iād assume. I know you can get godot working with c# but it takes using .Net framework⦠That might just be the editor side not the compiled program.
I mean for what godot is its pretty neat. One sandbox environment with its own scripting language that compiles to pretty any platform. And its all integrated one small app ~100 megs prolly a bit more. I remember it being 40 megabytes and that was it.
Unity is more sprawling and Iād imagine more or less paired with Visual Studio of some kind. I donāt have much experience with it. The extent you can optimize goes a lot furtherā¦
But unity is pretty jank and bloated. That optimization bit is probably crucial.
Baseline Godot with nothing but scripts⦠All in its own IDE⦠Definitely canāt be optimized as much as Iād like⦠Not without editing the engine source code itself⦠Which is an option it is all open. I think Sonic Heros was made from godots source code.
I donāt think the assets used have as much of an impact. Rendering is all hardware⦠Either opengl directx vulkan⦠Those bits would all wind up looking the same.
Really its resource management and cpu tasks⦠Memory constraints. And I have no idea which would be better for that. For small projects Iād bet on godot. For bigger projects Unity has a lot larger set of resources to draw from so that might pay off as all the niche circumstances might have been considered.
I feel like Unity keeps a lot in the dark⦠You can get by without being super technical⦠Or really even coding that much at all. Thatās not gonna be optimal by any means.
With godot there is a lot more of being stuck with what you got and having to make it work. It takes a lot of troubleshooting for basic stuff sometimes⦠But if you are scripting the whole engine is pretty much right there with you its ins and outs are spelled out. The documentation has some holes⦠But its pretty well structured.
Itād be interesting to see duplicate projects running to compare for sure.
Anyone have any updates on their work? Iām just playing around with shaders and stuff in Godot. It was weird cause the standard material shader had a section called ādetailā, where you can use a mask to blend in another texture, which is all fine and good, but it didnāt work, it wouldnāt detect my second UV map which I had painted this mask. So I made a custom shader, or rather AI did, and then it suddenly worked.
Sometimes Iām not sure if I encounter bugs in Godot or if it is that I have done something wrong. Know the engine pretty good now, but Iāve used Unity a lot more.
Things I like about Godot:
- The coding language, GDScript, is very fun and easy to use. I think I prefer it over C# in Unity.
- Itās pretty straight forward which rendering pipeline to use, with good descriptions. In Unity I always got a headache of trying to understand what the purpose were of the different pipelines, and I always forgot. Pretty confusing
- Itās very easy and fast to set up visual effects like ambient occlusion, different GI lighting methods, volumetric fog, etc. Itās not so bad in Unity either though
- You donāt need to compile your code before testing a game, youāre pretty much instantly good to go the moment you press play, because the code is interpreted on runtime. (i think I got that right)
- The signal system between nodes is good, especially when you set up a singleton to route them through.
Things I donāt like that much about Godot:
- The node system takes getting used to, and I think when it comes down to it, I prefer Unityās GameObjects with components system. Not that the node system is bad
- Getting into User Interface is pretty confusing at first, because you got like a hundred different UI nodes, and I have no idea whatās for what at first. I need to watch tutorials on that. Iāve heard itās good though, once you grasp it fully.
- Making a build of your game seems confusing at first, as there are fields you need to fill out that arenāt obvious what it means at first
Some of the negative things I guess is just me not being used to Godot and having used Unity for many more years in comparison.
Starting work on the 2d side of my editorā¦
One big plus of Godot is that is FOSS. Unityās license signs you up for to pay them a percentage of any commercial sale.
I havenāt used unity⦠But I could see building a similar system in godot pretty easily.
You make a custom node that is more or less an array of generic nodes. Then you design your components as nodes listed in that array. Itās more work more a choice if you need it that way.
The way I see godotās nodes are more just templates. You can easily take make a new node and include an āExtends Textboxā or whatever your trying to use and tack on any new functions your write while maintaining the same integration and functionality of the out-of-the-box version.
Also godots nodes are all in a tree structure of inheritance. So learning how they all sit together sort of teaches you how these engine and game entities are built and specialized. I think itās a well structured environment for learning game systems on a deeper level.
Iām being defensive⦠But really you gotta remember Godot is free and not for profit. In that itās in a league of its own.

Random pixel shifts.
Gonna try to build some āGame of Lifeā style algorithms to try to get some rule base height maps generated
I donāt have many updates, been struggling with psychosis so havenāt felt like doing anything. I did switch from Ubuntu to Xubuntu which has been great. Kubuntu 26.04 had some issues on my machine so I might switch to that later. Xubuntu runs on X11 still which is way better than Wayland when having multiple monitors. Wayland slows to a crawl with two displays for some reason. Do the distro makers even test their distros? The new oxygen theme in KDE is broken. The icons it shows are dark partially and light partially. Weird. One of the flagship features of Kubuntu was bringing back to the Oxygen theme but itās broken. The wobbly windows do work which is a nice blast from the past.
Xubuntu is really quality though. You click a menu and it opens instantly without slow animations.
I have been reading books though. Iām studying Common Lisp, game physics, compilers (dragon book), and AI programming (building models). Also got a book on making Gameboy ROMs from scratch. Just expanding my knowledge out of graphics. Lisp finally āclickedā for me and Iām enjoying it.
Yeah arch linux is particularly bad about breaking dependencies. I switched to the Long term service version of manjaro its not as bad⦠basically gotta use flatpak for anything that isnāt in the main repo. They integrated flatpak into their package manager so it all worked out. Sort of prefer it this way but it did take a while to become user friendly.
Different way of doing things⦠Sort of opens up Arch even further. Itās AUR or community maintained package repo was itās killer feature for a long time⦠but then it basically became a front-end for github⦠and most of it fell into dependency hell.
I donāt do front-end stuff so Iām not sure what the appeal of Qt is supposed to be outside of replacing the old GTK and all itās dependencies⦠but every time Qt updates⦠it breaks everything⦠like literally everything. Canāt have Qt5 installed alongside Qt6, new OS update depends on Qt6⦠old software⦠out of luck. venv venv venv⦠annoying. Flatpak is the real hero. What a mess all around. Whatās the point of having system wide package management any more? Might as well flatpak the distro⦠flatpaks on flatpaks on flatpaks⦠Sorry Iām being stupid.
@mars waiting on wayland to mature is taking too long thatās for sure.
