peter_spy

An entire FM is probably a no-go, since my spare time is focused on something else these days, but I thought about doing a tiled material pack inspired by T3 textures. Will post it, if I come up with something worthwhile.

Shit, we're old. Too bad T3Ed and its workflows are way too unstable (at least for me, on win10) to even think about making something for it again.

Just change the key spawnClass from idMoveable to idStaticEntity.

It seems like it is impossible to kill an AI by dropping it. What I got initially was like some kind of physics glitch. It might be worth checking with more complex surfaces though, like rocks or some sharp spikes. With flat surfaces, the AI will pretty much land unconscious, even if dropped from an Angelwatch.

I just switched to this version from 2.something, and I must say the difference is amazing. The window snapping system, 3d view supporting specularity and basic shadows, it all looks and works great!

Because it's a visual tweak based on a personal preference that would actually make it harder to create maps and content for TDM. Once TDM has PBR support, such tweaks won't be necessary, as fresnel response will be calculated correctly at material level.

That would confirm my observations. I think that removing 1 & 2 might be beneficial as well... 1 – because it would give creators more of the specular texture color range to use. Currently, if I go above ~ RGB 190 intensity, the specular hotspot will look overblown (with no bloom applied)* 2 – because it increases the specular hotspot saturation at grazing angles, making it harder to control. You can compare that by using the dielectric specularity trick, where you invert the color of the diffuse texture to get white specular hotspot. This is how the result looks like: At straight angle in the center, everything looks correct: At grazing angle: I guess that you might want to apply that to cubemap reflections, not specular hotspot. *That said, this is my setup only, it's all relative to light intensity, radius, etc. Edit: would it be possible to toggle the two HDRLite features via cvar? I would be interesting to experiment with this and see how it affects making materials, for both flat surfaces and models.

In a long time, I don't think I've used photos for anything more than a source for a color picker, so I can get a gradient ramp, or a just a few colors to use for my base color texture. Photogrammetry is indeed useful, but in terms of capturing a photo-scanned 3d model and making it game-ready. Since most PBR materials are standardized and look similar, games tend to be slightly stylized anyway, as everyone wants to have some visual identity. Photorealism ceased to be a holy grail of games quite some time ago too, it's more of an arch viz thing (and maybe racing games, although that's mostly cars). Edit: Out of curiosity @OrbWeaver, how specularity works in this engine? Did TDM team use what was there by default with idtech4, or did you implement your own tweaks? From what I've been experimenting with, it's different than other non-PBR engines, as it's not just a straightforward add operation, am I right?

But in general, the big problem with photos is that you either have to have ideal conditions when capturing them, or you have to do tons of editing, like removing shadows, getting them to tile, etc. And you'll still end up with some sensor noise, and they will be in one resolution only. Procedural generators like Substance, or other counterparts, have the advantage of being resolution-independent, and all the components can contribute to generating proper height map, which in turn is used as displacement map for automatically subdivided mesh, which you can bake normals from. All this while being tileable at all times.

Jeez, that's awfully time-consuming. No wonder photosourced materials stopped being a thing for quite some time now.

Yup, there's something off with the normal map; I actually inverted at least one channel in order to get the chipped-off edges right. The normalmap looks like just generated from a grayscale diffuse, so the white edges were convex and dark bits were concave. Isolating the bright bits, copying them to a separate layer and inverting the color would do the trick, but I thought that might be a bit too much of manual work. Edit: I tried to do this^ quick and dirty way, https://we.tl/t-jNZdpmkJtF And this would be the result:

Now, that's a really nice floor! Here's how I'd do it: https://we.tl/t-clZCfdyxda I resized textures to 1024 for faster upload, I hope you don't mind. Tested the whole thing with both player lantern and strong lights, without bloom. \

Do you have a photo of that floor when lit, at an angle? I think the generated specular map is wrong: the raw stone bits should be more porous, while the orange bits should be smoother and more shiny.

Btw. unless you're working on glowy bits (light bulbs, etc.) I'd turn off the bloom entirely when testing a material. It's adjustable by players, so you have no control over it. IMO it's more important that your specular hotspot looks right without any bloom in the first place.

IMO this is fairly normal phenomenon in non-PBR engines. If you have bright diffuse texture, it will contribute to specularity. You check this with e.g. grey vs. full white diffuse, on the same plane and with the same light. You can counter this by keeping your diffuse texture outputs in certain range, but it will largely depend on how bright your lights are. In general, there is no way to make materials look good under all lighting conditions in a non-PBR engine.