then write some glsl with samplerCube s_t0 (or 1 etc according to which 'pass' you listed it as) + textureCube function to read it.there's meant to be some 'tcgen reflect' to go with cubemaps, but it never got implemented. fixed-function stuff sucks anyway.

sorry Spike but I didn't understand a word! Do you mean there's not a cook&eat method, ready to use like map $normalmap in shader, right? Because I can't write glsl code and probably I'll never be proficient to There's some code I can use somewhere?

and finally created a cubes texture folder with 6 .tgas: skynx.tga, skyny.tga, skynz.tga, skypx.tga, skypy.tga, skypz.tgaNow it shows a cubemap on the walls BUT:1)diffuse and normal maps are hidden now and the only texture that it's visible is the cubemap one2)a giant wireframe cube appears in the middle of the world

I've updated fte's built-in defaultwall+rtlight programs to sample from 'reflectcube' and 'reflectmask' textures to provide cubemap reflections over a masked area (additive with diffuse+specular, and scaled by lightmaps/rtlights).The following shader should generally do what you would expect (hopefully). Set up the textures as you see fit.

textures/world/wall_foobar2000{ program defaultwall //diffusemap $blackimage //default is textures/world/wall_foobar2000.tga of course normalmap $identitynormal //identity ensures that we get a perfect reflection for this example (otherwise it'll default to something based upon the shader name, or possibly even generate one from the 8bit data in a q1bsp). //specularmap $blackimage //fullbrightmap $blackimage reflectcube textures/cubes/sky //your cubemap image(s) to display reflectmask $whiteimage //texture that says which parts of the texture should show the reflection. white for on, black for off. tint for various types of metal.}

you can find the official version of the built-in glsl code here: http://sourceforge.net/p/fteqw/code/HEA ... ders/glsl/the reflectcube term just provides the glsl with an s_reflectcube texture, and causes s_reflectmask is normally automatically loaded from a foo_reflect.tga file but can be specified explicitly as in my example above.

ok, first of all: THANKS a lot Spike for your help!FTE crashes when loading your defaultwall.glsl. I tried loading also old defaultwall, eg_defaultwall, and eg_drawflat_wall and they all crash. The others work.Now, after a lot of study, thanks to your files, I understood (hopefully!) how passes work in GLSL and FTEwhen you declare a texture 2d

The only thing I don't understand it's why earlier you wrote this shader like this

program defaultwall //diffusemap $blackimage //default is textures/world/wall_foobar2000.tga of course normalmap $identitynormal //identity ensures that we get a perfect reflection for this example (otherwise it'll default to something based upon the shader name, or possibly even generate one from the 8bit data in a q1bsp). //specularmap $blackimage //fullbrightmap $blackimage reflectcube textures/cubes/sky //your cubemap image(s) to display reflectmask $whiteimage //texture that says which parts of the texture should show the reflection. white for on, black for off. tint for various types of metal.

"normalmap" for example, doesn't not exist in FTE source code, "reflectcube" neither. In your defaultwall.glsl there were s_reflectcube and s_normalmap. Are they related to those directive you wrote in the shader?Thanks again for your huge help!

side note: using the word shader for both materials and glsl code is stupid. oh well.

the s_normalmap stuff comes from a reworking I made 1-2 months ago. the engine automatically inserts the map lines/blocks into your shader based upon the specially-named textures in your glsl. this means you don't need map $diffuse, map $normalmap, map $deluxemap, map $lightmap, map $fullbright, map $upper, map $lower... you get the idea. this separates the shader from the glsl a little more which can only be a good thing (the worst part was that the order needed to match).

internally the engine has a shader override system, this includes stuff like the rtlight shader. these shaders 'inherit' their named s_diffuse/$diffuse etc textures from the original shader that they are replacing, which is how fte uses one rtlight shader (with permutations based upon texture availability) for pretty much everything.naturally you can use 'bemode rtlight othershader' to specify a different override for the rtlight passes. there's a few other backend modes that you can provide alternative shaders for like that. the terrain system does this too, of course (which uses the lightmap to mix 4 underlying textures, which means it can't use the regular rtlight logic as that assumes there is only a single diffusemap).

unfortunately not all surfaces define all texture maps (or might define them but fail to load them perhaps). unspecified texture maps often have some awkward default of 0,0,0,1 (which is why s_lightmap is meant to end up as 1,1,1,1).note that certain bsp formats(rbsp+fbsp, but not q3bsp) have multiple lightmaps per face (now introducing the LIGHTSTYLED permutation!)You should probably figure out the various permutations in order to avoid this from being an issue (as well as to avoid wasting gpu time on logic that just isn't relevant).e_lmscale can end up as 0 if r_shadow_realtime_world_lightmap is 0.v_lmcoord is a vertex attribute and is thus only valid in the vertex shader. e_lmscale is a uniform and should be usable in either (but usefully the fragment shader). both should be included in the "sys/defs.h" header

It renders beautifully! The only (very subtle) problem is that, when player view changes pitch orientation, illumination changes abruptly. Don't know why but I'll study it

Justy few more question now that I'm starting understand something 1)You said in this post that "the !!permu thing at the start is another fteism. Each glsl file/block can optionally define multiple permutations, which means that certain steps can be skipped to avoid unneeded work. The shader knows which permutation it is based on #defines that the engine sets up before compiling the glsl."So, basically, I could create anothere glsl file, copy the !!permu at the start of the rtlight.glsl (for example) to inherit all the properties of that shader without rewrite them, but just writing into the shader block #REFLECTCUBEMASK or #BUMP after glsl file?

2)what is r_glsl_pcf cvar? The engine doesn't say anything about that. Is it related to realtime shadows?

#EDIT 3) There'a way to "render" cubemaps inside the engine?

Thanks A LOT for your explanations, I'm learning so much thanks to you!

the rtlight glsl code assumes that there is an active rtlight. which can be stale if not used within the rtlight backend mode. as you look at different parts of the map, a different rtlight will be left selected, hence the illumination changes.use defaultwall for a lightmapped wall. if its a q3bsp, you will likely need to include a {map $lightmap} block in order to get q3map2 to actually generate a lightmap for that surface.

rtlight glsl works great for static meshes but look what happens when it's applied to a skeletal mesh.The model is duplicated: one silhouette T-pose model is static and the animated cubemapped model is like 50% transparent. Why?Thanks in advance Spike for any clarification

static world lighting and depth comes from the glsl code specified directly in the shader.rtlights are an additive pass applied per-light, specified within a 'bemode rtlight' block. if omitted, the engine will use its own rtlight fallback (note that the default rtlight glsl code has lots of extra light uniforms to determine those per-light contributions, including shadowmapping logic).