duzenko

If it's using static vertex data then I think yes. In fact, I would like to work on that demo for TDM as a proof of concept and an engine capability check. Can you insert a translucent cone in the skybox area? It might look like that.

A first step could be copying the stats info to the windows clipboard for easy forum posting

Can you attach a build log with warnings about curlies or size_t to int? This is very intriguing.

How do you get a warning about that? I'm using vs 2017 and there's nothing like it.

I would be happy with an eye pictogram below the door handle, maybe shining or pulsating color.

The important thing is to give mappers the choice and the tool. Now when someone needs this they can use it instantly, without waiting a year till the next version.

Did we talk before about formatting-only changes? Rev 7709, draw_glsl.cpp, RB_GLSL_DrawInteractions_MultiLight. 4 changes and all of them formatting only. Please don't do formatting-only changes on functions.

You can feed the input data through vertexParms. All actual operation is done inside the shader and you (mapper) have full control on what happens there.

Umm Do you guys confuse materials with textures? The fragmentMap keyword takes a name of a texture (i.e. a .tga, .jpg, .dds, etc). Not a material name. fragmentMap 0 textures/darkmod/nature/skybox/starry1_clouds The starry1_clouds here is an actual .tga. So the shader can't be "calling many materials". Exactly. What some mappers did with ARB shaders before.

@all What is the referenceBounds on entity and how different is it e.g. to the bounds of the entity's md5 model snapshot? This is related to the bug that @nbohr1more noticed with dynamic models sometimes being scissored on the edges because the model does not fit its referenceBounds on some of its animation frames.

Try r_fboresolution 0.1 and see if the picture on the screen becomes pixelated.

Sorry, I didn't understand some parts of your post. The material load errors in the console aren't related or caused by custom GLSL, no? The vertex parm there passes current time to shader that it uses for scrolling. You can pass anything else, as long as it's supported by the material parser. Texture limit is 8. You can use the material with interactions if you want. But any light interaction goes out of scope of this thread. You can pass any texture to the shader, including normal maps. What the shader does with it, simulating interactions or whatever, is the mapper's choice. You can control opacity and everything else a shader can do. You would have to elaborate on the last paragraph, I totally don't get it.

Please test and advise https://drive.google.com/file/d/1ezaziu8U6k05aWfMA610wXrWo4jlpbzy/view?usp=sharing Please note the spectrum keyword. It totally disables interactions with whatever lights are in the skybox, as they aren't welcome here.

Does not work at all. width = &renderWidth; height =&renderHeight; in FB_Resize() does not even generate any machine code in release. If you want to discuss the depth check revert please PM.

Re your recent post. I agree that dozens of "if (r_shadows.getInteger() == N)" conditions are annoying. Do you think you could add a flag to renderlights (none, stencil, depth ) to be used in the backend instead? Not sure if it's better in the lightDef because of added code (vLight->lightDef->shadows is more typing than simply vLight->shadows). E.g. bool doShadows = !vLight->lightDef->parms.noShadows && vLight->lightShader->LightCastsShadows(); if ( doShadows && r_shadows.GetInteger() == 2 ) // FIXME shadowmap only valid when globalInteractions not empty, otherwise garbage doShadows = vLight->globalInteractions != NULL; if ( doShadows ) { if(r_shadows.GetInteger() == 2 && vLight->tooBigForShadowMaps ) qglUniform1f( shadows, 1 ); else qglUniform1f( shadows, r_shadows.GetInteger() ); //qglUniform1i( shadowMipMap, ShadowMipMap[0] ); // don't delete - disabled temporarily qglUniform1i( shadowMipMap, 0 ); } else qglUniform1f( shadows, 0 ); would end up like bool doShadows = vLight->shadows != LIGHT_SHADOWS_NONE; if ( doShadows ) { if(vLight->shadows == LIGHT_SHADOWS_STENCIL ) qglUniform1f( shadows, 1 ); else qglUniform1f( shadows, 2 ); qglUniform1i( shadowMipMap, 0 ); } else qglUniform1f( shadows, 0 ); Or even qglUniform1f( shadows, (int)vLight->shadows ); qglUniform1i( shadowMipMap, 0 ); I imagine you would have to set the shadows flag where the tooBigForShadpowMaps is set now. It should include lightDef->parms.noShadows, lightShader->LightCastsShadows(), r_maxShadowMapLight, r_shadows. (probably globalInteractions check as well)

That's on my short list too.

Duly noted. Not that I upload binaries to svn, ever. There's nothing to test yet, just beeping progress to outer space hehe.

WIP. Svn rev 7702. textures/darkmod/nature/skybox/glsl_shader_demo { translucent diffusemap textures/darkmod/nature/skybox/starry1_stars { blend add program skybox fragmentMap 0 textures/darkmod/nature/skybox/starry1_clouds fragmentMap 1 textures/darkmod/nature/skybox/starry1_stars fragmentMap 2 textures/darkmod/nature/skybox/thunderclouds } }

I'm starting with this and will try a simple shader next textures/darkmod/nature/skybox/glsl_shader_demo { translucent diffusemap textures/darkmod/nature/skybox/starry1_stars { blend add program skybox_glsl fragmentMap 0 textures/darkmod/nature/skybox/starry1_clouds fragmentMap 1 textures/darkmod/nature/skybox/starry1_stars fragmentMap 2 textures/darkmod/nature/skybox/thunderclouds } }

Can you move the visportal further out so it does not intersect anything?

Would you upload or attach a simple .map and an .mtr where the material is defined. Then I add a shader and link it to the material.

Getting the source code and do a debugging session is what I'd do.

I want 2.07 to support custom GLSL shaders, even if experimental. For now it will be of limited use due to interaction shaders being locked to standard only (for reasons of compatibility with existing missions). One particular place where we could apply a custom shader could be the skybox. We have standard sky materials with multiple stages, that cause massive fillrate overdraw. If we could reduce those to a single material, the performance be could significantly improved. Another possible application is complex water surface, but that's more complicated to achieve. I am looking for a mapper who will be working on a test/demo map with a skybox material that combines multiple translucent textures. The old-fashioned way would be to split each texture in a separate material stage while this time they will be all fed to a customer shader in one material stage. Ideas on going beyond the simple blending are welcome. Any volunteers?

It's been dragging for long enough, so I just went ahead and fixed it in svn 7703. I have a task that might be more in your style. There is a certain r_fboResolution cvar. It's a backend-only thing, that should never be used anywhere else. Now the problem is that at some point I made a mistake and used it in front renderer (idRenderSystemLocal::BeginFrame). Can you please see if you can refactor that code so that the frontend operates in window coordinates, and the conversion to FBO coordinates is done on the backend side, ideally in FrameBuffer.cpp. I have more exciting tasks for you coming!

The problem is line 956 Interaction.cpp You can see it with this additional check if ( shader->ReceivesLighting() || r_shadows.GetInteger() == 2 && (shader->SurfaceCastsShadow() || r_ignore.GetBool())) { Then do r_skipparticles 1, r_ignore 1 and reload. Nothing to do with far Z plane, depth transparency, or vis portals. And you can't just remove shader->SurfaceCastsShadow() check otherwise all surfaces start casting shadows, including street wall decals in Lockdown