DRD Team

Question about advanced lights and specular highlights:

If a material system is implemented... will it allow me to add models that have specular highlights?

My intended use case:
For my real-time weather system, I currently have it setup so that if it starts raining, there are certain sectors flagged as a "puddle" sector that will dynamically get more and more reflective using Sector_SetPlaneReflection... to simulate the idea of roads becoming "wet".

The problem with using SetPlaneReflection is that it's quite expensive if I'm going to have these littered all around the level.

What I was hoping with materials and specular highlights is if I could make flat plane models that have shiny materials that I could fade in and out in real-time. Then as part of level design, I would simply just scatter these so-called "puddle planes" about the level. I don't really care that level geometry and sprites etc aren't reflected by these high-spec-planes - even if merely only lighting is reflected off these planes, I'd settle.

Due to the simplistic nature of the light system in Doom, you can only really get specular highlights from dynamic light sources. As your sky has none of those, that option is unfortunately not there.

However, it might be possible down the road to do screen space reflections. For a technical description of how that works, see http://www.adriancourreges.com/blog/201 ... ics-study/ and scroll down to Screen Space Ambient Occlusion and Screen Space Reflections. Both those techniques should be doable in gzdoom.

One of the really cool things about this link is that both Doom 2016 and gzdoom are forward renderers. That means anything you read there could, theoretically, be implemented for gzdoom. One step at a time tho. First we need materials where we can declare normal and specular textures along with a few material wide properties such as whether they should reflect in a SSR pass. Until we have those materials, everything else is just dreaming.

That shouldn't be too hard to implement. Just as the TERRAIN code and ANIMDEFS code cues itself off of texture names, so too could specularity do so as well. This isn't too far off from how 3D programs do it, anyway.

I really would like to see a new file for this, though. GLDEFS is getting a bit jumbled. Maybe just extend the TERRAIN lump, or just make a new MATERIAL lump?

Yes, redefining texture names to actually be material names is probably a good way of doing it.

The logical separation between texture and material is already implemented, although at the moment its main use is the maintenance of brightmap textures. But all the basics, most importantly management of attached secondary textures already exists.

So it should not be a problem to build on this. Of course one thing should be clear: Let's not do step B before step A. The first thing to get out of the way is providing real normals. For world geometry, models and wall sprites this is relatively easy, the one thing where it may cause problems is voxels. I guess the current SSAO implementation will just butcher the look of any voxel because it's hard edges everywhere.

Hehe, good point about the SSAO and voxels. I wonder how they look like right now. If they look too bad, maybe we can render them after the SSAO pass just before the translucent stuff.

By the way, the SSAO pass should never use the smoothing group normals, even when we get those added. It is the light code that I have that needs to be changed to use them. This is because the SSAO math relies on the face shape for its ray tests.

Aren't those the same for any walls and flats? And for models, if it tries to guess actual face shape, won't that cause artifacts?

There are two kinds of normals: face normals and smoothing group normals. The first type is the normal of a triangle and is always cross(v2-v0, v1-v0). The second type is what is in model files and is often an average of several face normals, or may even be bumped slightly by normal maps. Sadly most stuff about 3D rarely distinguish between them, so the term 'smoothing group normal' is my term borrowed from 3ds Max where you control how they smooth by placing faces into distinctive groups.

The smoothed normal is excellent for light because it creates the illusion that the model has more faces than it really does, but for certain algorithms like SSAO it has to be the correct face normal. If the smoothed normal is used the SSAO pass will think a triangle is intersecting with itself, causing slight self-attenuation. How bad the effect is I don't know, but I read when implementing it that it was important to use the face normal there.

For Doom walls and flats you're right they are always one and the same. Unless someone adds support for placing linedefs into smoothing groups.

That's precisely how I read your post. But what does that mean for face edges in models that are supposed to be smooth? If I understand SSAO correctly it may also create artifacts there.

It might reveal the truth about the model's true shape, yes. It will only happen to edges that are close to other faces though.

... so there should be an option to disable SSAO on models I think... (and a flag in the modeldef would also be a good idea.

I'm not really that convinced yet that this is a real problem in practice, but adding support for it is probably easy enough if we are already flagging other walls/sectors for removal anyway.