Hello guys
Now that dmap is supported on this engine ( thank's trebor !!! ) I'm trying to convert a glsl fresnel to it (because i also don't know how to convert the one made in ARB code) below is the fresnel code, i'm also trying to convert a ice/snow opengl shaders, but everytime i try to dmap a map with the fresnel_vertex.glsl and fresnel_fragment.glsl i get a "warning bad vertexParm number" error.
fresnel_vertex
const float Eta = 0.67; // Ratio of indices of refraction (air -> glass)
const float FresnelPower = 10.0; // Controls degree of reflectivity at grazing angles
const float F = ((1.0 - Eta) * (1.0 - Eta)) / ((1.0 + Eta) * (1.0 + Eta));
varying vec3 Reflect;
varying vec3 Refract;
varying float Ratio;
attribute vec3 normal;
uniform vec3 viewer;
void main( void )
{
vec4 worldPosition = calcWorldPos( gl_Vertex );
vec3 ecPosition3 = worldPosition.xyz - viewer;
vec3 i = normalize(ecPosition3);
vec3 n = normalize( calcWorldVec(normal) );
Ratio = F + (1.0 - F) * pow((1.0 - dot(-i, n)), FresnelPower);
//Ratio = 1.0 - Ratio; // Add this line if your cube map is not based on the right side
Refract = refract(i, n, Eta);
Refract = vec3(gl_TextureMatrix[0] * vec4(Refract, 1.0));
Reflect = reflect(i, n);
Reflect = vec3(gl_TextureMatrix[0] * vec4(Reflect, 1.0));
gl_Position = gl_ModelViewProjectionMatrix * worldPosition;
}
fresnel_fragment
varying vec3 Reflect;
varying vec3 Refract;
varying float Ratio;
uniform samplerCube tex0;
void main(void)
{
vec3 refractColor = vec3 (textureCube(tex0, Refract));
vec3 reflectColor = vec3 (textureCube(tex0, Reflect));
vec3 color = mix(refractColor, reflectColor, Ratio);
gl_FragColor = vec4(color, 1.0);
}
material calling the fresnel shader
textures/bod/rock/shiny_mot088
{
surftype10 //tile
qer_editorimage textures/bod/rock/mot088_ed.jpg
{
blend bumpmap
map textures/bod/rock/mot088_local.tga
}
diffusemap textures/bod/rock/mot088.tga
specularmap textures/bod/rock/mot088_s.tga
{
blend blend
mirrorRenderMap 128 128
translate 0.5, 0.5
scale 0.5, 0.5
vertexProgram fresnel_vertex.glsl
vertexParm Eta 0.67 // Ratio of indices of refraction (air -> glass)
vertexParm FresnelPower 10.0 // Controls degree of reflectivity at grazing angles
fragmentProgram fresnel_fragment.glsl
fragmentMap tex0 _scratch
alpha 0.6
}
I'm a total noob at this shader thing so please be easy with me. :P
this material doesn't seem to call any shader
Isn't this parts on the material "vertexProgram fresnel_vertex.glsl" and "fragmentProgram fresnel_fragment.glsl" used to call the glsl shader? Isn't that how vanilla doom 3 does it also?
Question for trevor - Is dmap fully functional?
I'm asking because i tried to dmap a simple map using RBDoom3 and it didn't worked.
d3map is functional I've compiled several maps of mine and all worked fine. take a look tough to the launch options recommended in the modding section of the readme (12th section) you have to use several cvar in order for the engine to recognize your new content in the mod folder
on the vertex/fragment program issue, I've never tried to use a fragment in the bfg but maybe you can try to call an in-existing vfp program that bears the same name as your glsl (sort of how the textures with heat-haze do it in the game) and then the engine will use the heat-haze
take a look in inolen water mod (you can see it in the section of "making water" in the darkmodwiki there is Vertex's or Inolen's water shader material which calls a fresnel vfp), try to make it call your program to see if it works ( sort of how d3bfg didn't contain the old vfp files but still they where called whithin the materials, and yet you could see heat-haze effects in d3 bfg)
Quote from: argoon on March 28, 2015, 07:23:48 PM
I'm asking because i tried to dmap a simple map using RBDoom3 and it didn't worked.
Can you please elaborate ? I looked into RBDoom 3's dmap port, and while I haven't tried it, it looks like a lot of stuff is missing.
Quote from: BielBdeLuna on March 28, 2015, 09:01:30 PM
d3map is functional I've compiled several maps of mine and all worked fine. take a look tough to the launch options recommended in the modding section of the readme (12th section) you have to use several cvar in order for the engine to recognize your new content in the mod folder
Hum strange, about the cvar's i did that from the beginning.
Quote from: BielBdeLuna
on the vertex/fragment program issue, I've never tried to use a fragment in the bfg but maybe you can try to call an in-existing vfp program that bears the same name as your glsl (sort of how the textures with heat-haze do it in the game) and then the engine will use the heat-haze take a look in inolen water mod (you can see it in the section of "making water" in the darkmodwiki there is Vertex's or Inolen's water shader material which calls a fresnel vfp), try to make it call your program to see if it works ( sort of how d3bfg didn't contain the old vfp files but still they where called whithin the materials, and yet you could see heat-haze effects in d3 bfg)
Didn't worked "ERROR: While linking GLSL program 41 with vertexShader fresnel.vfp and fragmentShader fresnel.vfp" but i suspect that is because my fresnel glsl is not really made for Doom3.
Quote from: motorsep on March 28, 2015, 09:22:35 PM
Can you please elaborate ? I looked into RBDoom 3's dmap port, and while I haven't tried it, it looks like a lot of stuff is missing.
A simple box map with a player start and a single light doesn't work on my end, this using RBDoom3 BFG dmap, when i start the map it just crashes the engine.
if you try to dmap the map, and then after finished compiling you restart the engine, does then opening the map crash the engine?
Quote from: BielBdeLuna on March 29, 2015, 05:17:50 AM
if you try to dmap the map, and then after finished compiling you restart the engine, does then opening the map crash the engine?
Yes, tried it right now. On the maps that work for you, are you also using doom 3 assets or only custom assets? Be it textures and models.
btw i used Darkradiant to make the map.
well most of the code and enemies and models I used are d3 elements, but even if you set up a box map with a "info_player_start" this is already a d3 element.
I did my maps with Darkradiant like you. what does the compiling process say? what are the process of opening the map say?
Try replacing "fragmentProgram fresnel_fragment.glsl" with "fragmentProgram fresnel_fragment"
I believe the material parser adds the extension. That said, the shipping programs with BFG are labeled
*.vp and *.fp so you'd probably want to break your program into fragment and vertex programs and
use that naming convention.
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.
what? I don't get it, RBDoom3 doesn't use GLSL?
Ah, I thought something like that might be the case.
You can hard code GLSL calls in the source of course but to define shaders in materials you need to use Cg unless someone
adds a GLSL parser in the material system. The whole point of the Cg to GLSL system being a system to ease cross-platform
targets (and apparently native GLSL is a bugaboo of undefined performance cliffs so Cg does a better job of choosing
optimized paths for recompile... if you trust nvidia of course...)
but, apparently Nvidia recommends to no longer use CG but GLSL because "future hardware features might not be supported", the material system parses the definitions to a shader language? I didn't know that, I always though it was a fixed point system where specific definitions did that and only that, in a defined c++ part of de renderer code.
I always thought it was work of the drivers to convert the GLSL (or whatever is the shader language the application is using) to whatever the hardware needed in order to render the scene
does the d3bfg engine transcode the material definition tokens to CG in the loading of the level? and then the engine also transcodes it to GLSL in order to use it with OpenGL commands? how much shaders does the engine use, because per level the engine could be using a lot of material definition commands, if so why not dump the material definitions and code every "texture needs" directly with GLSL (it would be less transcode work to the engine) or transcode the material definitions in the start of the game (all of them, at least once, and then you're always using GLSL
please tell me if I'm getting this wrong because I feel I'm getting it quite wrong.
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.
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?
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?
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.
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?
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.
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.
Ok, I belive:
1. CG -> .mtr -> ARB
uniform float4 rpUser0 : register(c128) -> vertexParm 0 -> program.local[0]
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?
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?
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 (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?
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".
Thanks for the reply.