ZDoom

At the time I figured that the best mapping to Doom would be to assume that light level = classic ambient light = environmental light. This works okay the diffuse component of a material, but breaks down for specular.

What we maybe could do is to redefine what normal dynlights mean in PBR. Currently I'm treating them exactly as attenuated lights - that is, they are both physical point lights. But I could change it so that normal lights act as stand-in for the environmental light. I'm not too keen on applying the AO map on all light sources as then you might as well just remove the map and bake AO into the albedo texture.

Ok, that's the solution I'm used so far. Anyway even on this stage of design this is huge step forward for the engine. I know that all this hires pbr stuff stand off lowres sprites, but first - I don't care, second - as you mention before this is nice solution for peaple making total conversions.

Any idea if there will ever be support for fbx models to replace the outdated MD3 ones? Doomsday has it already so I assume it's possible.

hardcore_gamer wrote:Any idea if there will ever be support for fbx models to replace the outdated MD3 ones? Doomsday has it already so I assume it's possible.

Direct FBX support? No, that will never be supported. A few good reasons why:

1) It's a proprietary format that can only be read reliably via Autodesk's FBX SDK.
2) The FBX SDK is cussingly slow and templated to hell. It literally increased the executable size by several megabytes in the last project I used it in.
3) Autodesk is usually 6+ months behind Visual Studio on releases. If you rely on it, you can't switch compiler until they release new builds.
4) The FBX format is an exchange format, which means the vertices and such can't be loaded directly into OpenGL buffers. They need to be processed. For example, the normal smoothing groups require the application to analyze which vertices have to be split into multiples vertices before OpenGL can use them.

That said, GZDoom could use a good FBX import tool that converts such files to a format more suitable for engine consumption.

dpJudas wrote:

hardcore_gamer wrote:Any idea if there will ever be support for fbx models to replace the outdated MD3 ones? Doomsday has it already so I assume it's possible.

Direct FBX support? No, that will never be supported. A few good reasons why:

1) It's a proprietary format that can only be read reliably via Autodesk's FBX SDK.
2) The FBX SDK is cussingly slow and templated to hell. It literally increased the executable size by several megabytes in the last project I used it in.
3) Autodesk is usually 6+ months behind Visual Studio on releases. If you rely on it, you can't switch compiler until they release new builds.
4) The FBX format is an exchange format, which means the vertices and such can't be loaded directly into OpenGL buffers. They need to be processed. For example, the normal smoothing groups require the application to analyze which vertices have to be split into multiples vertices before OpenGL can use them.

That said, GZDoom could use a good FBX import tool that converts such files to a format more suitable for engine consumption.

Well having some kind of modern 3D model format would be nice. MD3 is too limited.

I recommend SMD format. It's an easily understandable text-based format, that's supported by a lot of major tools (3DS Max, Maya, Milkshape, Blender, XSI Mod Tool, etc), and is what GoldSRC and Source Engine use before compilation into .MDL. It's supported by Cube 2: Sauerbraten, so if you want to get an idea of how to implement it, there's a good place to look. SMDs are of two types, the "Reference", which is the model itself, and "Sequence" which holds the bone animations.

I see in the example map, that you used specularlevel for a material that uses metallic and roughness. By mistake or should that have an influence?

Than I don't really see any difference between glossiness 0, 0.1, 1.0, 10, 1000.... ?

Code: Select all • Expand view

material flat WOOD8
{
    roughness "materials/Grau90.png"
    metallic "materials/Grau50.png"
    glossiness 10
    specularlevel 10
}


(AO and normalmap are given with auto, which seems to work fine)

glossiness and specularlevel only has an effect on diffuse+specular materials. For PBR the specularity is indirectly specified via the roughness and metallic textures.

Is there any way to use pbr materials for texture which used "warp" argument in animdefs?

Not currently, no.

Ok, thanks.

By the way, any chance of getting my hands on those PBR textures for E1M1 you've been doing over at DW? I would like to do some tests with environment maps at some point and your textures are a lot better than the ones I currently use.

Of course, no problem - but all of them need some strong polishing (most of materials are on test stage).

You have blocked pm's

Oops, yes. Should be possible to pm me now.