News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

RBDoom 3 engine (shader programs)

Started by argoon, March 28, 2015, 06:07:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

nbohr1more

So here's what's happening:

1) Doom3 BFG has two shader interfaces: one is hard coded and the other acquires shaders from materials (non-lit post process blends only)
2) For hard coded shaders, BFG translates Cg to GLSL at the start then sends GLSL to the driver (the driver does convert the GLSL to ARB) on render
3) For materials, the shader file location in glprogs is parsed and converted from Cg to GLSL during map load then
the renderer will again send GLSL to the driver on render (which is internally converted to ARB)

The setup is designed so that you can write your shaders in Cg then send them to the backend as either GLSL or
HLSL, etc. Anything the target OS platform (or game console) can run.

BielBdeLuna

ok, but what do you reefer as hardcoded?

let me see, the material defined as *.material are transformed to cg? but the materials define the lit interactions (albeit with tokens) of a surface.

and the hardcoded are those *.pixel and *.vertex files are already cg? why do you say they are hardcoded, maybe because their filename and path is hardcoded in the c++ code ?

if so, why not implement a parser from *.material tokenized definitions to GLSL directly? or even instead of writing *.material tokenized definitions write directly GLSL shaders per surface?

argoon

#17
Quote from: trebor on March 30, 2015, 06:56:32 AM
Look at the base/renderprogs/  shaders. GLSL is not supported. You need to write your custom shader in Cg like heatHaze.vertex heatHaze.pixel.
It is automatically translated to GLSL/HLSL and whatever renderer backend is used.

And yes dmap is fully functional. I compiled all D3 maps with it on another branch.

Oh did knew that, about glsl not being directly supported that explains alot, i don't know if theres cg shaders readily available on the net for free, because i really don't know how to write them. :( And a fresnel shader is always nice to have.

About dmap i need to explain what i'm doing, i made a folder inside RBDoom3 BFG and copied almost all assets from old doom3 (i didn't extracted BFG assets) to that folder, then i made a shortcut and used on it the cvar's commands that you recommended, all works i can start my mod, i then copied DarkRadiant to the RBDoom3 BFG folder and pointed the options to the RBDoom3BFG.exe and to my mod folder, DarkRadiant was able to see all the assets on my mod folder and use them.
I made a test map, then i tried to dmap it, i really don't know if the dmap process ends well, i see no error on the console only a bunch of warnings about materials (maybe is this the cause of the crash?), and on last, info about no entities in map that use aas stuff, and on the BFG main menu i see "A sign-in change occurred. You have been returned to the title screen."

Edit: It seems the old ARB programs are indeed included with BFG assets I extracted them and all ARB (.vfp) programs are there on a folder called "gl" next to the cg and glsl/hlsl programs, can someone experienced explain if they are used or are just there for compatibility purposes? Can i put the old fresnel.vfp on the gl folder and the materials calling it would work on BFG?

trebor

There is a list of builtin shaders that are required to run the renderer. For the example renderprogs/interaction*, environment* or gui*.
There also shaders that are optional and not required by the renderer and called by the materials like heatHaze* or bloodorb*.

The BFG resources shipped with the .vfp programs but the renderer didn't use them at all. Those are relicts from an ealier version of the BFG renderer.

If you have problems with dmap then it is probably due to material problems. I've experienced BSP leaks when I had missing material definitions for some test maps.

bitterman

A question:

Wouldn't it custom Cg-shader which placed in BFG/base/renderprogs be automatically converted into GLSL-shader and writed in My Documents/../base/renderprogs/glsl (or /../../glsl-1_50 in RBDOOM) if the loadable map don't contain any link to material with "vertexProgram"/"fragmentProgram" keywords?

In other words, are custom shaders converted by engine (from CG to GLSL) only when the map is loaded and this map uses these shaders?

trebor

If the .vertex/.pixel shaders are not directly loaded by the renderer and not loaded by a used material in a level then they are not translated to GLSL.

bitterman

#21
Ok, as I see /base/renderprogs into RBDOOM source code contains an improved set of shaders (instead identical folder into D3BFG source code).

It was a cause for few funny errors in work with resources.
For example I get an error with linking 'interactionSM' shader but can't find this shader into D3BFG/base/renderprogs.

Is there any information about these additional shaders (examples of decls/material, how to work with etc.)?
By the names they looks like very interesting stuff.

And optional question:

In the common examples Cg-shaders are presents in a single file (.cg), that is not divided into two (fragment and vertex) files (.vertex/.pixel). But as I think this division is neccesery for engine. Or not?

How to divide .cg -> .vertex/.pixel the correct way?

Thanks.


bitterman

#22
Ok, I belive:

1. CG -> .mtr -> ARB

uniform float4 rpUser0 : register(c128) -> vertexParm 0 -> program.local
  • [/b]

    uniform sampler2D samp0 : register(s0) -> fragmentMap 0 -> texture[0]


    2. main VS_IN/VS_OUT for .vertex, main PS_IN/PS_OUT for .pixel.

    **********************

    ************************

    All ARB fragment programs contained this code:


    # env[0] is the 1.0 to _currentRender conversion
    # env[1] is the fragment.position to 0.0 - 1.0 conversion

    # calculate the screen texcoord in the 0.0 to 1.0 range
    MUL R0, fragment.position, program.env[1];

    # scale by the screen non-power-of-two-adjust
    MUL R0, R0, program.env[0];


    Is it unnecessary in new Cg/GLSL code?

bitterman

#23
Of course screen texcoord conversion was changed. Something like this:

float2 screenTexCoord = vposToScreenPosTexCoord( fragment.position.xy );

There is differences between how shader works in D3BFG and RBDOOM. I think the same Cg code can't used in both without minor but non-obvious changes.

And why RBDoom looks like RB-darkplaces? :)

****************** upd *********

There is a deal with YCoCg compression in BFG.
Really don't understand how to work with it (e.g. in D3 to works with textures was enough GIMP + DDS plug-in).


// Since all interaction shaders now assume YCoCG diffuse textures.  We replace all entries for the intrinsic
// _black texture to the black texture on disk.  Doing this will cause a YCoCG compliant texture to be generated.
// Without a YCoCG compliant black texture we will get color artifacts for any interaction
// material that specifies the _black texture.


Should I use RGB to YCoCg conversion for custom  TGA textures or it's will be done by engine?

bitterman

#24
Ok, found a Waveren's info about YCoCg compression and code wich working with it.

What is mean "all interaction shaders"?

If I plan to blend some texture with currentRender is this means this texture must be YCoCg compressed manually?

Also I found code to convert TGA to DDS with YCoCg-DXT5 compression, but as I know BFG not work with DDS.

And motorsep's info from related thread:

QuoteNote that all diffuse is encoded with YCoCg DXT5, which isn't supported by Doom 3 anyway.

http://idtechforums.fuzzylogicinc.com/index.php?topic=211.msg1814#msg1814

But now I use simple TGA in BFG without any compression.

Is anyone know how to prepare (or was prepared) textures for BFG/RB?

trebor

You can either use .tga, .jpg or .png with RBDOOM. Those textures are compressed automatically to .bimage resources if they are newer than the .bimage files.
The .bimage format is similar to .dds so you don't need .dds and the engine decides wether it is compressed to YCoCg-DXT5 or another format.
It depends on the usage in the material files. Other textures like the _currentRender are internal textures that are copied from the RGBA framebuffer.
They usually remain uncompressed for performance reasons. You can see all texture formats that are used by the console command "listImages".

bitterman

#26
Thanks for the reply.