HMart

That is exactly what i thought has well. About decals this is not a silver bullet, but for example fhdoom shadow maps just ignore any material using textures from the decal folder to prevent them from casting shadows. if( coverage == MC_PERFORATED ) { //WARNING(johl): this is kind of hacky but is necessary to get the // original Doom3 materials to work at a decent perf. // Decals don't cast a shadow, unfortunately there is no // flag indicating whether a material is decal or not. // Decals usually are alpha tested and have the 'noshadows' // flag set, but 'noshadows' is ignored by fhDOOM on alphatested // surfaces to enable alphatested shadows. // Current solution: Just assume all materials starting with // 'textures/decals/' are decals and dont cast a shadows. static const char* const decalsPrefix = "textures/decals/"; static const int decalsPrefixLen = strlen(decalsPrefix); if ( cullType != CT_TWO_SIDED && (strncmp( GetName(), decalsPrefix, decalsPrefixLen ) == 0)) { return false; } return true; } Appart from decals, the sky and particles IMO all alpha materials should cast shadows by default, but of course mission makers could want to disable shadow maps, and this is where problems arise. I'm certainly not thinking about everything right now, but I would suggest making a entity keyword (defined in the editor or def file) called no_shadowmap or something, why a entity keyword and not a material keyword like we currently have? It would certainly be easier to apply to many objects at the same time, yes true, but a material keyword, unless implemented in totally new materials, will mess with already made missions, where's a new entity keyword defined in the editor just affects the mission if the author wants it. This of course do not solves the problem with past missions, forcing alpha shadows for them is not desirable, like Springheel explained and unless their makers update them, with the keyword above or similar, then is best to continue playing with alpha shadow off, that means we will have no alpha shadows at all in plenty of missions, and to me at least, that defeats the purpose of playing with them on, imo the only benefit of SM was alpha shadows, especially when in my case soft stencil shadows look very good and perform better than shadow mapping. Afaik Is not a easy problem to solve and that is why I pushed for talking about it, final TDM 2.07 is still far away but is better to solve this sooner than later, just my two cents.

I'm not seeing shadow mapped shadows for alpha materials in any mission besides the Judith test map for the volumetrics, i assume that is because past missions disable those shadows with the no_shadow material keyword, so my doubt is how will you force shadows on past maps. Will you like fhdoom just ignore the "no_shadow" keyword in alpha materials?

Not necessarily, func_statics should be used only for static models (to save performance), any model that moves should be a func_mover (controlled through scripts) or a idMoveable (defined in def files, is a rigid body physics enabled object), you also need to know that AI path calculation (AAS) only works on world brushes, AI walks fine on func_static floor but you need to put a brush under it, btw no need for the AI to touch the brush, so you can have a func_static floor and a brush under it some units down and it still works fine.

With total respect to the missions authors, that's what happens when you have people of varying degrees of knowledge and skill working on missions, some will know how to make good soundscapes (for example not rely only on default TDM sounds), others will be better at lighting their missions, others at gameplay/story, others at level design/geometry, etc, no mission will be perfect in all aspects, especially when a single person is working on them, that is life and like others have said if something really bothers you open the pk4 (is just a zip file) and change it. Personally i've yet to edit any mission and just play it has is, some things i don't like but I just accept it.

Yes sometimes some decisions are bad decisions but at the time they seemed to be the best ones, unfortunately we don't have the ability to predict what the future brings. Fortunately in this case no one removed md3 support but even if they did, this ability could be made by other means, for example using vertex shaders.

Hey guys just curious, have you discussed internally how to best support shadow maps for alpha mapped surfaces?

Aldo very nice work, just a suggestion on the second picture you can break those visual straight lines, for example in the right, where the wall meets the ground, with some rocks or some plants or even making the terrain more uneven (using patch's). Btw are those trees in the second image using the 2.07 shadow maps or you faked the shadow with texture projection?

That last pic shows that dmap created a n-gon (geometry with more than 3 edges). Everything should be triangles (geometry with 3 sides) showing that you need to cut that stairs manually until that doesn't happen (or someone on the engine team finds why dmap breaks down on that). Not saying that it doesn't but why converting to a func_static would solve bad dmap triangulation?

That looks to me like dmap causing a bad cut in the geometry at compile time, perhaps if you manually cut the last big steep at the top level of the smaller one touching it? Something like: ___________ ____|___________| | | | | | | | | | |___| ___________|

Looking at the post office website sending to canada to me is not a problem, the problem maybe you having to pay additional taxes to pick up the package in your country, you need to inform yourself on that.

I'm from Portugal, i can send to anywhere in the world but would be better if you lived within europe of course because of customs.

I've seen this idclass on fhDoom before but it was totally commented out! Like the md3 loader i never thought this would work so i personally let it pass, what more is hidden on this engine!

I agree with duzenko, my two AMD HD 5770 on my old PC are dx11 (OGL 4.4) cards and those are now 9 years old. Having said that, New Horizon if you want to get one of my used HD 5770 only by the postal expenses just send me a PM, there's no reason for you to be stuck on dx10 when i have two dx11 cards here getting dust.

Normal maps are tied to each material yes. Btw just so you know, if you don't use a normal map, the engine will automatically use a flat normal map in all your materials, regardless if you write it on the material or not. So not putting detail on a normal map, is a waste of opportunity imo. If you don't want to bake a high poly to low poly, you can just paint a normal map on photoshop, GIMP, etc.

Ok i see that on my PC but i assume you want me to delete the data on GLCache not on DxCache? TDM is a GL based game after all.

I don't know how to do that. Do i just delete the shaders folder? No it still works.

The ones you posted above. r_shadows = 2 r_testARBProgram = 1 r_softShadowsRadius = -0.65 r_shadowMapSize = 1024 r_softShadowsQuality = 24 r_softShadowsRadius is a negative number? Btw i installed duzenko latest volumetric test shaders and exe and shadow maps started working...

If i use the exes from update 14 shadow maps get all burked if i use your exe shadow maps (and the volumetric lights) work very well !? Now i used the exes from the update 14 and the shadow maps worked?! This is very odd.

In the new 14 update shadow maps to me became totally burked, i tried both 32 and 64 bits exes. https://drive.google.com/file/d/1EF6JMkOOAFx906Lmi3TGxXPQV98uJvcb/view?usp=sharing My GPU is a AMD RX 570 8GB

Hello Petike the Taffer, your logo is very nice but I studied graphic design (not that i'm claiming to be a master), so sorry if i'm going to critique your work a little. Ok the logo is fine but imo is too illustrative, with to much unnecessary information, simplicity is the key, for example there's to much shards, the detail in the eye will be totally lost if you shrink the logo, making it only good for certain sizes,etc. Btw this is why, flat design, is so prevalent now imo to much so, but liking flat design or not, one of the new "rules" is that a logo must be simple enough and and at the same time transmite the desired idea. I made two (fast) simplified examples of your design but they are just pointers not trying to say this is what TDM should use. In this one the eye could be simplified even more to its essential features https://drive.google.com/file/d/10KH-QhE6gegmkK7FSnYRgNlPG0Yp734d/view?usp=sharing Or a even simple one https://drive.google.com/file/d/12jS0BhE2m7RWbjAM-H51TMmqCWg4zlua/view?usp=sharing

Yes a static LOD seems to be a logic thing to have.

Is technically possible but IMO very very hard, id script language lacks some important things that C/C++ have, arrays is a big one, and those are pretty much required to make any game, technically the vector class (idVec3 in c++) could be thought as a array with three indexes, but you can't do much with it in id script but save 3 float values on it, you can't for example make a vector of 3 objects/entities, pointers is another thing that id script lacks, the $entityname is technically a "pointer to a entity" but its single use is to get entities already spawned in the game nothing else.

That really looks awesome, btw i don't know how heavy on performance MD3's really are, compared to bone animation but if they are heavy, then IMO is somethings that would benefit immensely from a LOD system, for example at longer distances instead of always showing 275 frames you could bring them way down, the animation will not be that smooth but at the distance i bet is almost unnoticeable. Cobwebs is not something that you will use very often so perhaps the work of making a LOD system just for this is not worth it, but with LOD you could have a room full of cobwebs, for a big spider lair or something and potentially have better performance.

scripts use a very simple custom OOP (object oriented programing), c/c++ like, language made by idsoftware called, id script, even tho is a very simple language, is also very powerful, anyone with basic knowledge of OOP and programing can do immense stuff in TDM with it. https://modwiki.xnet.fi/Scripting

Afaik you can't change the console keybinds, they are hardcoded, unless of course you change them in the engine source code and that IMO is not desirable because would affect everyone else using the console. And IMO deleting a \ is a small inconvenience.