So, I have a wall with a PBR texture I downloaded and tweaked. Next to it, the cracked orb that ships with GG.



It's not as noticeable in this snapshot as it is when moving about the test game (though I still think it's pretty noticeable!), but the cracked orb looks flat compared to the wall I set up. So, this is an issue with the actual PBR materials used on them. Perhaps the normal map is not strong enough. In any case, these orbs don't appear to be good examples of PBR.

@Argent Arts:

Here are the listing for how the PBR textures are in Game Guru.
This may explain some of the differences you are seeing from the textures in other engines, verses Game Guru.

Metalness - black is dialectric, White is metal

Gloss - Black is shiney, white is rough

Roughness - Black is Rough, White is shiny - We dont use this

Displacement - White is height, black is lows

Normal direction +X -Y +Z

Illumination and detail can not be in the same model, The shader has not split them out yet.

Thanks, Pirate Myke. I had followed this thread:

https://forum.game-guru.com/thread/219411

... before creating any PBR materials.

In the above image, the PBR materials I applied to my wall look right to me. It's the cracked orb, an example that came with GG, that looks bad, especially in-game.

@Argent Arts
It is easy to complain. Maybe you should do it yourself and point out what is really needed!
Personal I find the "bump" factor in the shader very low, but it is what it is for a reason, so I increase the normal map.

Yes I created the ORB's and the above video is the exact same model and textures I just loaded it into Toolbag3 and rendered it, PBR will render differently in any package GG's shaders are very good might not be perfect but we can tweak them and yes normal maps are very subtle in gg you need to emphasise them quite a bit.


The ORB's are not perfect they were just created to show GG's PBR shaders and I personally think they do a good job

Uhm ... I just did that. Thus, the screen shot with an explanation of what was going on, comparing my PRB material to one of the ones that ships with GG. I did look into it and the normal map on the cracked orb is weak. The UV mapping is terrible on the orb as well. And there are all sorts of artifacts on the ambient occlusion map, too. The point to my "complaining" here is that, if you're going to showcase PBR materials, then showcase them properly. With the poor UV mapping (or at least the way the textures are applied, showing seams everywhere), the weak normal map, and artifacts on some of the others, this does not make the orbs look good ... certainly not a showcase for what GG is actually capable of (which is quite a lot, actually). If you load the orbs in and keep the animation script so they spin in the test game, then you can see texture popping as they move. This is especially apparent on the wood and cracked versions (well, any of the orbs with some detail going on). That's not good and I have no idea why that is happening.

So, see me as "complaining", but don't forget that I keep saying, throughout this thread, that I see GG as having a ton of potential. So, this "complaining" (more of a critique, if you will, as I pointed out earlier) is expressing what I am finding as a new user diving in so I can develop with GG. If I was actually "complaining" (or if GG made me actually "complain") then I would simply go elsewhere. It's not like there aren't a ton of game engines to choose from these days.

That's not what I am finding out. I took one of my own created normal maps and it rendered in GG just as I expected it to (after people here helped me set up the .ini files and all). I took another that I downloaded from a PBR website and it worked just as expected without having to increase the strength of the normal. If you look at the rough rock wall in my screen shot, that was made with a standard normal and that wall looks about like that in each engine I put it in.

BTW - I'm not purposefully dissing your work. I didn't know you had created these orbs. But they still need a bit of work due to the seams. You've got a tiling image that fills the texture area, but doesn't take into account the model's UV seams. And the artifacts on the AO are causing some artifacts on your glossy orbs (like chome, etc.). With just a bit of work, the orbs could be really good.

I am sorry they are not up to your standards maybe a more seasoned artist can do them cya!

Sigh. It's not about my standards. Sorry that you see it that way. Just ask yourself a simple question - should there be unintended visible seams on textured models? If the answer is "no" and the seams are there (and they are), then it's not about my standards ... especially when the models ship with GG as an example.

There was no real effort made to properly map the texture to these orbs. You took a tiling texture and applied it without regard to the UV mapping of the orb. There's more to texturing a 3D model than just dumping a texture on a model with UVs.

I'm not trying to be pissy or argumentative. I just think these orbs could be better. A lot better. And, thus, help showcase a bit more of what GG can do.

What's interesting and a lot of people may not know this but Fallout 3 and Fallout New Vegas ran off 512x512 textures. While not modern in quality, they both still visually look decent and proper. Additionally when Skyrim first released, most of the scenery textures were also 512x512 and that game looked spectacular. All 3 of these games were 32-bit on launch and did not have PBR textures. A few of them had some supporting shader based textures but there was a lot of optimization involved here.

Skyrim will crash at or around a reported 3.1 gigabytes of RAM usage, which is fairly widely known. Skyrim mirrors its active textures in memory, and since it is a 32-bit application with a 4GB memory limit this constrains the total size of modded textures that are viably usable,” the post says. “The exact VRAM:RAM ratio is not known, but one metric reported was a texture pack taking up ~500MB VRAM would consume approximately 430MB physical RAM.”

The authors of the post said that they hadn't been able to come up with any memory management solution that could “reliably mitigate” the problem, and worse, said “it is unlikely that any could be developed.” Even Bethesda described the 4GB ceiling as “a fundamental problem of 32-bit applications,” and said it had no plans to address the matter further.


Bethesa's ultimate solution was to launch a 64-bit version of Skyrim and provide it free to PC users that could transfer their saves to it. Skyrim Special Edition is 64-bit and supports higher texture resolution and better lighting.

If anyone is interested, you can read more on the topic of Skyrim's limitations and moving towards 64-bit from 32 bit here:
https://www.pcgamer.com/skyrim-special-edition-will-be-64-bit-promising-big-things-for-modders/

That guide is correct (although the version i posted on steam guides is more up to date) as confirmed by Lee both on the forum and via email.

Thanks for that, Belidos! I appreciate it.

@Teabone I love your insight knowledge of the bethesda games, very interesting
Ive done mods myself but not as seriously as you do.

don't take it personally, we see a lot of new users come in all guns blazing and then just as quickly leave, it's a slow process around here but things are always moving... and it is nice to see GG from a fresh users perspective, some of us have been here since before GG/FPSC-R existed and so we all have our own requests but trust me, lighting and shadows have been on that list since day 1 :p

for now keep the constructive criticism coming and remember GG is still very much an infant - it might be "officially released" but it is by no means complete... even Lee admits you may want to look elsewhere to make a proper indie game - though GG is somewhat capable, there are some great examples around, it certainly makes you work for it.


Real time shadows... about time!
joke
awesome work as always, expecting to see a million and one horror games in GG now :p

@smallg - Thanks. I appreciate your words. And I am not planning to go anywhere. I am very interested to see what becomes of GG. There are a lot of things to like about it, a lot of things that are quite strange to me, and quite a few things to gripe about (obviously). I think the "likes" outweigh the "gripes", though. So, yeah, I'll see where GG goes.

One of the things that gets me with GG is the editor, to be frank. It's strange, especially coming from a 3D modeling background ... and even having worked in other game engines a bit. The top-down view is not orthogonal, so precise placement of items, like lights, can be difficult. And pressing "F" doesn't always make it any easier. For me, this means I will make most of my level as parts/pieces in my modeling package, import it into GG, and piece it together there.

Speaking of the editor, is there a way to stop it from zooming in on an item when you access it's properties? Zooming in on it doesn't seem to help since I am not going to work on the item itself, but change settings (like the color of a light). And since I was able to select it to begin with, then obviously I could see it. Why have me zoom in on it just because I've pressed Preferences?

Why is "B" the key for toggling snapping? Just curious.

And speaking of snapping, is there a way to adjust the grid size or are we locked to just the one? And what is that grid size anyway?

I would really like lights to show their radius the entire time they are selected, especially when I am in Properties. When I change the range of the light, I'd like the radius to be seen so I don't have to guess if I've plugged in the right number. In fact, it would be great if scale would actually scale the light's radius. It's also important to see the light's radius when moving the light. I don't like having to grab the light to move it (making the radius ring disappear), move the light, release, deselect, and then mouse over so I can see the radius ring.

GG is a different beast, to be sure. It's fun, it has a ton of potential, but it's going to take a lot of getting used to.

Here is the github link where you can put all your improvement suggestions: https://github.com/TheGameCreators/GameGuruRepo/issues

Make for every improvement an issue(no ultimate issues with a lot of tasks) and we will add it sooner or later.(please search for equal issues first before you make a new one)

Hi Argent Arts - Welcome to Game Guru land



B 1,2,3 = snap, grid, none
Page controls = up\down

That's it no other options.

Grid size in Game Guru is same a 100 units in Blender. So you can use 100x100 or 200x200 etc and they will snap together nicely in GG
You can use page up\page down when in grid mode to move model parts up or down.

Reliquia....

Thanks, Corno_1. Made my first submission.

@reliquia - Thanks! I appreciate it.

Before I report this, in the EBE, is there a way to make the texture display (lower-right corner) larger for those of use developing on 4K monitors? It's so small on my screen that I have difficulty seeing the textures well enough.

Bugsy

While I don't think I'm going to change your mind in terms of the overall decision to pursue PBR - I get the arguments for sure, and they make sense - I feel like it is a bit of a myth that PBR requires twice as much texture usage as DNS, ESPECIALLY if you don't want it to. For example:

* For PBR we have the following texture types 1- color 2-roughness 3-metalness 4-normal 5-ambient occlusion 6-height

On the face of it, this is indeed twice as many textures. However:

* Height: GameGuru does not even support this at the moment, so we can eliminate it right off the bat. Even in engines that do support it, most models do not use it. This is used sparingly in Unity and Unreal too if one does not want to create a resource monster.

* Ambient Occlusion: I see this one often talked about as if it is mandatory but it isn't. You can (and should) eliminate it entirely on many models that don't have a lot of important shadow areas or crevices that really benefit from it. Even on models that do benefit from it, in my experience you can typically cut down the resolution size on this texture by half if not more (in comparison to the other textures) without the user noticing.

So now we are down to using only one additional texture. But I would also advocate that the roughness texture can frequently (not always) be cut in half compared the color and normal maps without causing noticeable visual impact. So now we are down to .5 of a single texture extra memory space.

FINALLY, if you really wanted to, you could use only the color, normal and roughness textures, and have a tiny 256x256 solid color texture for your metal channel, and this would do a decent job of emulating the DNS information and look for basically the same amount of texture information.

To add to lorddweeb comments, Preben is looking to combine the textures within the engine to save memory.

In other engines the PBR information is often combined in the different channels of a texture, so a normal map may also have the height map in the alpha channel of the normal, and metalness and gloss/roughness are combined into one texture using different rgba channels. This makes it more tricky for the artist but saves memory in engine.

However I think Preben is aiming to do the best of both worlds and let the artist keep discrete textures for each purpose (as now), but combine them in the engine for storage on loading - pretty clever idea of his.

So in terms of texture memory, we may well get PBR for the same as DINS soon.

Cheers.

One of the modeling programs I use, when setting up a material, allows you to declare the specific channel that texture is assigned to. So, if I need the specular map to be on the red channel for some reason, I can. This allows me to set up a material to be used in the specific way a game engine or a specific format requires it. As long as I know what is needed (what channel to set the texture to) this makes it pretty simple. I just bring in the normal, AO, etc., and set the channel for each.

Welcome Argent Arts.

You guys know whats so awesome about this forum and GG,
Guys like me that have a dream to make a cool game and that do not know a lot about game making , and all the things around it , like light mapping , and words things like uv , normals and roughness textures , can sit in the back of the room near the coffee machine and listen to you guys talking about all the issues , and not speak until ask to . ( lol ) we listen and do catch some helpful stuff wile listening .

Thank you very much.

@lorddweeb

right... OR, we couldve just kept using DNSI, which would provide effectively the same results when not using any of the other textures PBR materials have to offer.....

I have done a short GG x11 lighting test and will be posting my findings. If anyone likes the thread i'll continue with other tests.

Bugsy: We did preserve that option , just set "pbroverride=0" in setup.ini to use the old DNSI. but baking PBR is the future

I will have to try another version of the lighting test with that setting used. I believe I did for my first test a while ago to some abysmal results, but we'll see how it's coming along.

pbroverride=0 seems to give me lots of problems …
Tab makes the floor vanish in the editor when looking from top down …
lights vanish and cant be selected … Its kind of all over the place for me ?