duzenko

Problem: idRenderSystemLocal.renderCrops not thread safe. Both frontend and backend may want to change it. Frontend uses it for scissoring, etc. Backend sets it to FBO internal resolution and then back to window size.

Thanks The problem that I can see with your map is no smooth-normal objects. The way it works now: each object normal serves as cubemap tex coord. So it you have a single normal across entire wall it will be lit with a single cubemap texel (effectively single color) See the attached screenshot with a smooth-normal bust (light material uses source cubemap, not irradiance in this example) No idea why the light is being clipped when looking from spawn point - I don't think it related to cubic lights. If you want reflections, try the lightFalloffCubeMap keyword.

Fixed in svn

Please post your test map in the cubemap thread

For that and for me to better understand the area.

@Spooks I dropped r_fboSharedDepth cvar because I think it's has no issues. Where can I test the warp material? Does r_useglsl 0 fix any of those?

Do you have a test map for this?

Does the cubemap reflection work at all now?

Umm... Is there any bug or feature request I can be useful here? Or is this more like a general discussion?

Now I think we're on the same page in terms of point/projected lights. Now looking in the backend render code I can see that arb2 path uses separate GPU programs for point and projection, but cubic only. GLSL path makes no distinction at all. Are we talking about cubic projected or "regular" projected lights? Also how do we call the "regular" lights (e.g. not cubic)?

I think that's the async sound thread... So about the FBO resolution and SMP - that should be in next beta.

Whip up a test a map and create a new forum thread with a feature request

When was the latest beta released?

No, DR is all Chinese to me. I mean the result flags in the material file.

How do you set a light to be Omni or Projected? From my point of view, there are two light shaders: ambient and point. Point shader takes has a position and can cast shadows. Ambient does not. Each of the two can be cubic or "2d". The latter one takes two 2d textures for falloff and projection. I still don't see where Projected fits here.

Tell you the truth I am looking for opportunities to lose as many textures as possible for performance reason. What do you think about having a formula falloff instead of texture. E.g. falloff = 1/(1+distance^2);

Good to know that I'm not the only one running TDM on Intel Do you have r_usefbo 1 and if so do you often see depth fighting?

7281

minimum system requirements should be OpenGL 2.1, but the new GLSL was not tested on anything older that 3.1 yet

Yes, use SMP and fbo resolution at the same time.

I'm confused if we're talking about ambient or interaction lights here. We have separate GPU programs for these: interaction and ambientInteraction. I assume it's interaction light? It sounds like you want a falloff texture on your cubic light with a project-like cubemap. I can add that but can you provide a test map and assets for testing?

Does it still happen after r_usefbo 1 and restart?

Does not have to be an integer. Values like 1.5 are accepted too. Fixed in svn trunk, @grayman should include this in next release.

Anyone having problems with r_fboResolution: try com_smp 0 or r_useScissor 0

interaction VWARNING:shaderCompileFromFile(glprogs/interaction.vs) validation ERROR: 0:40: 'var_WorldPos' : undeclared identifier ERROR: 0:40: 'u_modelMatrix' : undeclared identifier ERROR: 0:40: 'u_lightOrigin2' : undeclared identifier ERROR: 0:40: 'assign' : cannot convert from '3-component vector of highp float ' to 'highp float' F WARNING:Program linking failed Fragment shader contains a user varying, but is linked without a vertex shader. Out of resource error. Unfortunately @grayman branched the beta on the day glprocs were broken on nVidia Try the glprogs from @nbohre1more's post above