HMart

My thoughts about this is that, even tho is a free game, where the original intention was to make a open tool set for people to make missions, and even tho everyone's map file, is open to everyone to mess with, this kind of practice shouldn't not be condoned, and basic guidelines should be followed, by everyone, no matter how respected within the community you are. This would be my personal guidelines: No copy/pasting of other people sections with minimal change, if you do so ask permission, if permission is giving, still try to change it enough that no big similarities can be discerned, this is so gamers don't feel they are playing the same mission all over again. If you do it without permission (if you are a ass and imo a criminal) at least have the decency to change it enough, so the original author doesn't know, ignorance in this case is bliss, is best to be oblivious then to feel robbed and stop making missions because someone else lacks creativity. Without express permission from the autor, no rework/change, big or small, of other people missions, at least for public release. Even tho they don't own TDM assets, the author spent a large amount of time arranging them on that particular way, and for them that ends felling like their "baby", no matter your opinion that should be respected period. If this means that in the case the author is unreachable, some old mission will stop working, because a TDM engine update needs missions to be reworked, so be it, remove it from the list and wait for the author to complain, small inconvenience to save from dramas like this one.

Just a update on my case, VanishedOne you were right the burn away effect was handled by the script code. On c++ was only the case of using SetShaderParm(parm7, gameLocal.time * 0.001 ); It should have been obvious but I didn't saw it, gameLocal.time changes each frame, i was using a fixed value expecting the material keyword "time" to do the rest but it didn't. Btw the * 0.001 is there to convert milliseconds to seconds, the engine Macro MS2SEC() does the same. This tho don't explain how to get the alphaTest value from the material using other than GetShaderParm...more study for me.

To me that part was ~50fps with single pass on a AMD Ryzen 1800X CPU, didn't tried with single pass off but i assume would be 6 fps or so faster. Btw a got a warning about aas96 or something being out of date when starting that mission.

I'm not sure but is not that expected? Afaik shadow maps are more GPU heavy by design they are just textures after all.

Hum yes that maybe it, i forgot about that, will analyze that script code and see what i can get of it, thanks for the hint.

That is strange, i'm on a AMD GPU?! To be exact i'm on a entirely AMD PC. Ok after testing this more, it seems duzenco is right, I went to a place that brought fps down enough from constant 60fps so i could see well the difference, with single pass off fps were ~56, with single pass on, it was constant 50fps with some occasional deeps to 48/9fps, but one really strange thing happens, even tho the fps's are lower, it feels smoother! That was what made me think the performance was better even tho it was not really... Reminds me of this: https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92

Tested the new 15 update and i most say in my case the shadow map performance with that has improved leaps and bounds and they look very good, now I don't see any reason for me to play with stencil shadows on. my settings: r_shadows 2 r_shadowMapSinglePass 1 r_softShadowsQuality 24 r_softShadowsRadius -0.65 r_shadowMapSize 1024

Sorry if this is not really about TDM but i'm trying to do the same thing on my custom fhdoom engine and not having any success, I can't even make the Doom 3 burn away effect to work on my case, what it does is make the object instantly invisible, I blame that on my lack on knowledge on the subject of material shading. This is the burn away material stage (modified slightly from Doom 3) but it doesn't do what i expected... { // blend away effect if (parm7 > 0) // only when dead // make a burned away alpha test for the normal skin blend gl_zero, gl_one // don't draw anything map textures/nature/red_strange_plant_blend.tga // replace this with a monster-specific texture alphaTest 0.05 + 1.5 * (time - parm7) } Also how can you access the alpha value from the c++ code? I know about SetShaderParm(Flag, value); But this only changes values based on the materials "parmx" material key what i want is to access the value defined in front of the key "alphaTest" keyword; I came up with the code below but the most impart part, getting the alpha value and changing it, is something that i don't know how to do. renderEntity_t *renderEnt; idRenderModel *renderModel; const modelSurface_t *surf; const idMaterial *shader; const shaderStage_t *sstage; f32 alphaTest = 0; renderEnt = GetRenderEntity(); renderModel = renderEnt->hModel; if (renderModel == NULL) return; for (int i = 0; i < renderModel->NumSurfaces(); ++i) { surf = renderModel->Surface(i); if (surf == NULL) continue; shader = surf->shader; if (shader == NULL) continue; for (int i = 0; i < shader->GetNumStages(); ++i) { sstage = shader->GetStage(i); if (sstage->hasAlphaTest) { // get current alpha test value // new alpha test value break; } continue; } the sstage has the following member variable "sstage->alphaTestRegister" but instead of getting the 0.5 value of the alphaTest key i get the value 22. What are stage registers and how I retrive the real alpha value? Can anyone help me?

IMO you are more or less right, your method is map based scripting but his method is not wrong, is what's called object based scripting, more times than not you will run both in unison and call from within map scripts functions of object scripts, like so $object.function_name(), on object scripts you can call functions directly, just using function_name() (behind the scenes it is doing: this.function_name()). In map scripts you initialize (call initial functions) everything on the main() function, on object scripts you initialize (call initial functions) everything from Spawn() or Init(), plus other differences. Both are valid ways to make scripts work on a map, but yours is indeed the prefered option (and the one id software used the most) to do scripting for a entire map, in this way you have all the code on a single file instead of on multiple files attached to multiple objects. In map scripting to prevent naming conflicts and make functions unique to the mission you're making, wrap all of them around a namespace, that is not needed for object scripts. like so: namespace map_name { void main(){ otherfunction(); } void otherfunction(){ $object_name.show(); } } In both ways you need to #include "path to the script" on the main script file (in TDM you can do it in tdm_custom_scripts.script) for the game to see it. Map scripting Object scripting

No doubt about it, but like I said there's no harm to look at the source and see how they connected the pieces, that way you don't need to start from total darkness. Writing a GUI editor (or others) will indeed be laborious. Have you written a editor before?

You have a very ambitious list there! Good luck! TDM would benefit immensely with improved tools. Btw idtech 4 already has a gui editor (and a material editor for that matter) made by Raven Software, you could look at the source. Is a little buggy and only supports basic gui functionality, you can't animate inside it for example, only put images in and transform them. TDM engine seems to miss it tho, so if you want to study those you need Doom 3 version of the engine.

This, but was replying about the fake water reflection, for fake interiors is overkill, is a bunch of work to make different cubmaps for all windows and think of all the different states the rooms could be in. For a single pool of water is fine tho.

Yes that would be a nice trick, I assume the image would be mapped on the inside of the dome? Btw wouldn't be very heavy, but is labor intensive and perhaps requires a script that detects the player and makes the half dome look always at the him when he moves, like the flares on lights. Yes Oh I saw that before I totally forgot. Btw about that wiki tut even tho I didn't tested it, I think there's a way to solve the problem referred on that wiki page, the one about the light being off on the world and not on the cube map reflection, this if you want to make that trick more dynamic but is labor intensive... first make cube maps for all light states that you can have on that room (to save work don't use many lights ), then make a material like so for the water: material name { qer_editorimage ..... { if ( parm7 == 0 ) // default cubemap all lights on blend gl_dst_alpha, gl_one maskalpha cubeMap env/env1 texgen reflect } { if ( parm7 == 1 ) // cubemap light 1 off blend gl_dst_alpha, gl_one maskalpha cubeMap env/env2 texgen reflect } etc... } then make a script where you set the parm7 value depending on the light being off, to turn on/off the material stages, if you (the one reading this) don't know how to script you can do the same on the editor with the "target_setshaderparm", like so, target one light at one "target_setshaderparm" entity and in it, set the desired value for the shaderParm7 key, then target that "target_setshaderparm"at the water surface entity, do this for all lights. Btw this also doesn't solve the problem of movables not being updated on the cube map, so only put static objects near the water. Again i didn't tested this so if it doesn't work don't blame me. (but it should work...)

One and two was something that EAX had the ability to solve, I remember Creative demos showcasing those and plenty of other effects like sound reflecting on surfaces and changing sound depending on what material they were made, wood, rock, etc, so EFX should have those has well but EAX 4 was implemented (by Creative) in Doom 3 in a hurry and so they only implemented the basic stuff. Also is good to mention for those that don't know, this stuff runs on the CPU, is not accelerated by sound cards like in the old days, so the more advanced the sound system is, the more heavy it will be, unless the team makes this stuff run on a separate CPU core, then is better to be conservative on EFX, TDM is still very CPU dependent and i don't know how good is its multicore support.

So we have ghosts that make sounds and we have a ghost that needs to eat. Do you guys stop to think how is that even possible? Do you know how sound itself is made? What is necessary for something to able to touch something? If a ghost has the ability to make sound and touch a physical item in the world, made of atoms like you and me, then he must be made of the same stuff as you and me, what prevents us from detecting it? We can detect invisible radiations like wifi and see it using special apparel, even tho it is totally invisible, goes right through you and anything around you (minus lead) and makes no sound, even after that we can detect it and see it but no one as been able to photograph or film a ghost, using visible light or any other type of electromagnetic radiation, or detector even tho by what is claimed above, they can make sound and they can pick up physical objects in the world.

To display that on a map just use cameraCubeMap. { blend add cameraCubeMap env/cloudy texgen skybox rgb .6 } I'm not sure but logically texgen skybox should be better because simulating a interior is not different from simulating a skybox. edit: hum a skybox expects the player to be inside it, in this case is more the player looking from the outside in.

Yes Brandon lee ( Bruce Lee son ) died in a freak gun accident while participating on a scene of the Crow, he died before finishing the movie so they add to use a double in the last scenes. Because of his death gun laws changed in the movie industry and all dangerous guns in the set have the nozzle covered before shooting. And btw contrary to popular belief his father didn't died while making a movie but died from a brain aneurysm caused by a unfortunate bad mixture of headache pills given by a friend while visiting her and his pills for the back pain, this was said by Chuck Norris in a interview.

Never ever seen any ghost, never ever experienced any paranormal situation that couldn't be explained by logical means and not a single person has shown me irrefutable evidence that they exist. Anyone claiming to see ghosts every week is anything but a "normal, high functioning person".

That is a nice trick i didn't knew about it, thanks for the video. About if TDM engine supports parallax maps, i don't think so, there's no cvar to control parallax maps like you have on fhdoom, but i also seem to vaguely remember someone showing parallax occlusion mapped materials in here but i'm not sure, if it does and it works like fhdoom then is just a matter of putting the bump map in the alpha channel of the specular map. About that bump offset shader i don't think that is done with a normal parallax map, you can see the texture is a colored one ( object space normal map? ) not a grayscale bump map? I'm sure this would need for someone that knows GLSL to write a bump offset shader and without knowing how the UE4 one is done, i'm sure is not easy. Also http://www.humus.name/index.php?page=3D&ID=80 And for OpenGL https://www.opengl.org/discussion_boards/showthread.php/165407-Interior-Mapping-%28Humus-demo%29

I'm also of the opinion shadow meshes should still be included, they are a performance trick even for shadow maps and yes, not all alpha materials should cast shadows but that is obvious. The ability to control shadow mapping on/of per material and or entity should also be a most. Btw i'm almost afraid to say it, because this is really a radical suggestion... but what would solve many of the problems i'm seeing coming up is...removing stencil shadows all together. Wait! Don't come with the pitchforks right away! Hear me out ;P ...By doing that, you can then remove noshadow from the materials with no fear of breaking what is not there, and imo logically, removing shadows or not from a object, should be in the hands of the mission maker, not TDM forcing everyone that uses the oficial materials to not have shadows (apart from the obvious ones that should never cast shadows), this way there's no need for a extra keyword either. Anyone wanting to control the shadows, for existing materials per mission, just use a material skin override with noshadow on it, like always, missions where shadow anomalies are detected, because someone faked shadows, should be updated by the mission makers or by a third party if the author is nowhere to be found. Yes this is a radical change indeed but would save many headaches and pretty much all engines i know, use one or the other, supporting two radically different shadow systems in the same game is not easy. If this is still not the time to think of that then, i may suggest not removing noshadows, let that keyword control only stencil shadows, make another to control shadow maps, that way you don't mess with stencil, for shadow maps, editing the missions at least to remove faked shadows wouldn't be necessary (nor do you want that if playing with stencil shadows), why, because you would only need to stop those particular materials from casting shadow maps and this could be done like i already said, by implementing that new "noshadowmap" keyword on a skin and then just make a script that at map/mission start time would detect the materials you want and swap them. I can't think of anything better unfortunately. Yes shadow maps are just textures they do not create extra geometry like stencil does.

Hum unless i'm not understanding what you are saying (is possible) i don't think that solves the problem of past missions faking shadows on alpha materials (don't think this is solvable unless the mission is edited) nor it solves the problem of people playing with stencil shadows on, if you play with stencil noshadows keyword should be there. About a example Trees should be a obvious candidate. Btw i thought of a little contrived way to solve the stencil shadow problem, make a copy of the alpha material you want to cast alpha shadows, remove the noshadows from that material, make a skin and on a script detect when the cvar r_shadows is 2 and if so change the necessary entities to the skin permitting alpha shadows...

Man that is very nice work the shots look impressive indeed!

We know that Judith, the problem is if the team ignores the noshadows keyword , like fhdoom does, to force alpha shadows on past missions, in that case shadow maps will not be able to be turned off using noshadows, that is why i was suggesting a different keyword for shadow maps.

I assume idsoftware removed it because, one they used a extra tool to compile the maps for BFG so no need to include the older engine dmap, two they thought no one would want to mod BFG has it was very hard to mod, this before RBDoom3BFG came into the scene.

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.