[FTEQW]Fake reflections via cubemaps

[toneddu2000]

Is it possible to use cubemaps in FTEQW? How? What kind of extension should have cubemap textures? Which is the shader property should I use?
Thanks guys

[Spike]

map $cube:foo

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.

[toneddu2000]

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?

[toneddu2000]

[Spike]

[toneddu2000]

[Spike]

http://sourceforge.net/p/fteqw/code/HEA ... er.c#l2107

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

[toneddu2000]

[Spike]

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.

[toneddu2000]

[toneddu2000]

A simple test showing cubemaps in FTEQW. Model "BMW M6 2006" courtesy by Fred C. M'ule jr. ('tyrant monkey') on BlendSwap. Floor is realtime reflection, car is cubemapped. Every glsl used is available below.

[toneddu2000]

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

[Spike]

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).

[toneddu2000]

[xaGe]

Nice!