duzenko

So what are the rules for going beyond? Radius, opacity, etc. And why the multiply? What is multiplied to what?

Umm So how is it different to e.g. regular material with the same "rgb 7"?

I have no experience with UDK or other engines. Can you tell me more about the desired effect? What gets multiplied by what?

Look what render crops are used for on the front end and where they are used on the backend.

I would suggest creating a separate forum thread with a feature request for emissive materials/volumetric lights.

So what are your plans with r_fboResolution? Have you given up? Do you need some advice to go through?

idRenderSystemLocal::BeginFrame was using r_fboResolution in 7704 last time. Are you saying that 7707 also had r_fboResolution in idRenderSystemLocal::BeginFrame?? Do you know how to use svn log? What is the accumulate effect of your commits 7705 and 7712? Did you complete the r_fboResolution refactoring task? Or are we on the reformat/revert/re-revert loop again? Do you understand why you should have done the r_fboResolution changes in svn commits separate to the unrelated stuff you did, like the depth color, type casts, or reformatting?

What did you do exactly? Reverted back to 7704?

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.