Search the Community

Probably not. In case you didn't notice, game industry played with POM for a short while, and then mostly ditched it, because it's too performance-heavy. POM uses either path or raytracing, and it needs quite a few steps to make the shapes look good and not like a jelly or something. It requires quite a bit of optimisation to reduce tracing steps to be mostly nearby the player and nowhere else. Besides, as GPUs went more and more powerful, and hi-poly to low-poly model workflows were already in use, it was much much cheaper to just add more geo to existing models and use LOD.

Just realized something: The new parallax effect would be a great way to get model-less building modules, for creators who'd rather try those over the model panels! They provide enough depth to realistically simulate bricks and beams and even windows, enough to look as good as sets like "models/darkmod/architecture/modules/exteriors/ext_timber01" and the others: You'd only need to create some extra geometry for corner pillars to hide the geometry edge effect in parallax, otherwise it should offer the needed depth to have detailed 3D building walls directly on brushes

It is caused by trying to convert render model into collision model for these two models: models/darkmod/nature/skybox/starry2/moon_full.ase models/darkmod/nature/skybox/starry2/moon_full_glow.ase I guess the models are just planar grids. The engine tries to merge all the incident planar quads, and suddenly gets more than 64 edges in total. And there is no protection against it. Windows build is lucky to have some extra space, but Linux build dies. I fixed it in svn rev 10916. Meahwhile, I think you can mark the skyboxes as non-colliding?...

I started typing this on Discord but will move it here. I'd simply love for this to be added to vanilla TDM: The change is a wonderful Christmas gift for the next release. To make this more likely I wish to offer a few points and observations from my perspective, anyone feel free to add to this or correct if I'm wrong. For the record I'm not an official TDM developer though I spend most of my days modding / mapping or playing every FM as it comes out. First of all TDM has a culture of being careful with retroactive changes: If anything modifies the experience too much (especially for existing missions) we usually want it to be an option. I suggest designing your patch with a main menu setting; I'd add it to either "Settings - Gameplay - General" or "Settings - Video - General" whichever makes more sense. I propose giving it the following 4 options: Disabled: Never show POV hands even for weapons. If someone wants this for any reason we're also giving players an option to disable them entirely. Weapons: Only Blackjack / Sword / Arrows. Current functionality and can remain default. Weapons & Items: Also see your hands holding any selected item (lantern, compass, key, readable, etc) but hide them otherwise. I'm in favor of this being the new default if no one finds it too disruptive. Always: Show even the empty hands when nothing is selected, in which case you see the mantling / leaning movements. Likely too disruptive to default but I see myself using even that. I was excited to hear you plan to add them for individual items, that's something I've been dreaming to see years ago but lost hope we ever would. When it comes to items we'll likely need special animations for the default ones as they have specific purposes. Here's a list of the the important items... especially at this stage I don't want to suggest too much and overwhelm, I'll only add essential ones the player is almost always guaranteed to use: Lantern: Hand dangling the item down. Only the skin needs to change between lit and unlit lantern, all light entities have skins and it's easy to setup. This will look awesome with glow and fireflies Spyglass: Hand brings it toward the face when using and back down when unusing. Compass: Hand facing up holds the item in its palm. Wonder if the handheld compass can actually work and point in the right direction, wouldn't bother with it now but since we got it working for the inventory icon this should be easy to do later and will look really neat Lockpick & Keys: Poke the item toward the crosshair to look like picking the lock or inserting the key. It doesn't need to go toward the keyhole or anything, seems perfectly fine the way this was done in DeusEx where you'd see the hand flailing it in front of the door wherever you pointed. Health Potion: Move the hand toward the face and back down to appear like quickly drinking. Careful not to bring it too close to the camera as the minimum clip distance may cut off the mesh and let you see into it. Everything else: Generic hold animation with a basic jolt when using. This should fit most things: Not sure how items with different sizes will look and if we'll need different grips for each one, a book isn't held the same way as a sheet of paper, but especially right now I wouldn't worry about that. Remember that TDM allows mappers to define their own items. This includes builtin ones: You can make custom lanterns, lockpicks, spyglass, etc. The best solution seems like letting each item specify the hold & use animation it wants for the hands via spawnargs, matching the best grip and use animations the author thinks looks best. We'll also need spawnargs for the origin and rotation offset for the entity attached to the hand, each item's model is bound to appear in a different place and will need to be configured by trial and error.

The question then becomes: Which is the model's intended area and which is the pierced area? The existing AreaLock lets you determine using either the model's origin or the center of its bounding box. In my tests I found both may fail at detecting the intended area in a few cases. One reason is the answer to the second question: Most modules are walls, but others are corner pillars which are even more problematic. On the outside you need to line them up so the edges of two wall panels don't show up, which almost always requires pushing them inside a room. This image shows it clearly if I hide the interior walls... note how the pillar's origin also falls inside the room in this case. The wall brush is 4 units thin which is very small but what I found works; Some would ask why I don't just make the walls thicker which would technically solve the problem. The issue then is you can't get the exterior modules to line up with the interior ones, they're meant to be placed back-to-back. Only way is to make unrealistically thick walls so you skip an entire panel, meaning a wall would have 5 panels on the outside but 4 on the inside positioned midway: One panel is usually is 128 units long, for modules that offer a half-wall 64... for them to line up you need your walls to be 64 or at best 32 units thick which looks like it's over 1 / 0.5 meters, that's a lot of space to waste and only makes sense for something like a castle or giant cathedral. Even then it won't work as the door frame of an interior module needs to poke through the exterior so you don't see a gap: The modules include their own door frames and expect you to use those instead of adding your own. The interior and exterior door panels need to slide into each other perfectly like a socket in a power outlet; If the door panel of the outside isn't glued to the one of the inside just right, you'll get an empty space in which you see caulk where the door sits in the door frame. The second image also shows the problem with center detection: The door frame that must poke out belongs to the indoor panel, and it's long enough to cause its bounding box to be present outside the room more than it is inside. If I use the model's origin then it works, but for a few modules the origin of an interior panel may be flipped and lands outside. Modules with door and window frames are the only ones that need to render both inside and out, everything else should be restricted to its intended area.

Nice mission overall. It even has some nice dialog in it. Edit: The Revenant spirit model textures seem incomplete. some of the texture images seem present, though. Trying to cobble something together doesn't yet give a proper result.

Maybe we can try what I proposed in the other thread: a flag which says "this model is continuous and cannot pierce area boundaries". Anyway, I don't really know how the modules are organized. Is every module a wall which is only visible on one side?

Sure, I'm open for the best solution of course. I suggested an upgrade to AreaLock as it's the only system we already have that culls models based on visleaf: A solution would likely have similar results though it doesn't need to be implemented the same way. Merely binding to a location info seems like the simplest way. Though we should probably use a separate ID not the location info directly, that way entities aren't restricted to one outdoor area else you can't have location separators in between buildings: The "info_location" would have a spawnarg of the form "show_area the_outside" then any entity can also be given "show_area the_outside" to bind it to that zone. An alternative would be to trace the path taken by the origin / center through open portals touching the bounding box, similar to how lights are optimized as to not needlessly calculate surfaces from rooms they intersect but can't shine in. An "areaLock center_trace" or "areaLock origin_trace" would allow the model to be rendered only in visleafs the origin / center can travel to through open doors. The advantage is we can probably reuse the same code as light optimization, also the mapper doesn't need to define areas manually... the disadvantage is this offers less control, the origin of a model or the center of its bounding box may fall in the visleaf you want to hide.

I think we should first decide what do we want TOS for: To protect TDM from legal issues? To protect TDM team from angry mappers in case of conflicts? To guide mission authors in their work? In my opinion TOS should only cover legal issues, and wiki articles about making/releasing missions should cover author guidance. The chance of getting malware in a mission only increases after we write this publicly. Better don't even mention it, we are completely unprotected against this case. By the way, isn't it covered by "illegal" clause? I'm not sure this is worth mentioning, but I guess @demagogue knows better. By the way, which jurisdiction defines what is legal and what is not? Isn't it enough to mention that we will remove a mission from the database if legal issues are discovered? I think this is worth mentioning simply because mappers can easily do it without any malicious intent. We already had cases of problematic assets, so better include a point on license compatibility. It is a good idea to remind every mapper that this is a serious issue. I also recall some rule like "a mission of too low quality might be rejected". In my opinion, it is enough. You will never be able to pinpoint all possible cases why you might consider a mission too bad in terms of quality. And even the specifics mentioned here already raise questions. Having such a rule is already politics. I feel it does not save us from political issues but entangles us into them. If there is a mission which contains something really nasty, it will cause outrage among the community (I believe our most of active forum members are good people). If people are angry, they will tell the mission author all they think about it. And if the author won't change his mind, he will eventually leave TDM community. Then the mission can be removed from the database, perhaps with a poll about the removal. But it sounds like an exceptional case, it is hard to predict exceptional cases in advance. This is not even terms of service, but a technical detail about submissions. The mission should be accompanied by 800 x 600 screenshots. Or we can make them ourselves if you are OK with it. This is again purely technical, and I'm not even sure why it is needed. Isn't it how TDM works? If mapper does not override loading gui file, then default one is taken from core? Is it even worth mentioning? I think we should discuss mission updates by other people in general. This is worth mentioning so that mappers don't feel deceived. The generic rule is that we don't change missions without author's consent. But it is unclear how exactly we should try to reach the author if we need his consent. PM on TDM forums? Some email address? However, sometimes I do technical changes to ensure compatibility of missions with new versions of TDM. Especially since the new missions database has made it rather easy to do. Luckily, I'm not a mapper/artist, so I never fell an urge to replace model/texture or remap something. But still, it is gray zone. On the other hand, I think the truth is: we can remove a mission from database without anyone's consent. I hope it has never happened and will not happen, but I think this is the ultimate truth, and mentioning this sad fact might cover a lot of the other points automatically.

areaLock should definitely not be used on anything that moves, unless it's something like a func_bobbing or func_rotating that never exits its visleaf: On things like AI it would cause them to get cut off whenever they cross through a visportal, since the model will only show in the vis area its center is located in at that moment. From what I'm seeing you only need to use it if you have a model / light / particle poking through a wall and know you don't need it to show on the other side of that wall. It's why I want it for building modules: As my thread explains they often poke through structural walls and you have exterior panels rendering from an enclosed room or vice-versa, however using the current implementation causes exterior panels to also not render outside if they cross a visportal between two buildings, hence my suggestion to allow area-locking based on location info too.

Yeah I'm aware of the use cases - I mainly used it for particles and preventing models from showing up through walls. The point of the thread was to reveal why it was even created, as the thread I linked contains advice from @stgatilov to NOT use it at all: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/page/10/#findComment-490707 If that's the advice, an explanation is needed and the Wiki updated.

Seems no one's answered this yet. There's a section about it on the wiki page: https://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows#AreaLock_(New_in_2.08) Essentially it makes a model only render in the visleaf (visportal area) its origin or bounding box center is located in. This is an useful tool to improve performance, by ensuring a model or a light doesn't render through a wall when you don't want it to. I was trying to use it on building modules to improve FPS which is how I found this thread. Sadly there are some limitations that don't allow customizing it as needed currently. I made a thread explaining the problem here:

Felt I should post this here before the bug tracker so I can properly explain the limitation and the solution I'm suggesting. I'd love to hear what @stgatilov @Dragofer @nbohr1more and other developers experienced with the graphics system think about this. I'm making extensive use of the building modules since they look amazing, but they can also be quite a drain on performance even when using their LOD models. I noticed a reason for wasted FPS is that often times interior modules will poke into exterior areas, likewise exterior walls may still be rendered out of sight when the player is inside a building. This happens because with their intended alignment the bounding boxes of some models may poke through the brush wall: The rule is that if an entity's bounding box touches a visleaf open to the player it will be rendered, which in this case causes walls and pillars the player can't see to still be processed by the GPU. The screenshot below is from a camera position that's inside the building and past the (shadow)caulk wall but just behind the interior panel, as can be seen the module of the exterior wall is still being rendered from the visleaf of the enclosed room. I asked if there's a way to solve this and was reminded of the areaLock spawnarg which is a powerful concept: It allows restricting an entity so it only renders in the visleaf its center or origin is located in. I gave it a try on the FM I'm working on: Using "areaLock center" or "areaLock origin" on the exterior modules will prevent them from being rendered inside as intended, the outer wall in the above image no longer shows up when peeking behind the inner panel. The problem then becomes that if a module touches more than one visleaf, it will be cut off and disappear from any area its center isn't located in. To resolve this I'd like to suggest a new option for AreaLock or a new spawnarg to complement it: Allow specifying a list of areas defined by their location info, meaning an entity will only be rendered inside every visleaf that's part of that location but nowhere else. This should allow binding exterior walls to the outside and interior walls to the inside, without relying on random chance based on where the bounding box or origin of each particular model falls. Mappers should then be encouraged to use them for all building modules, given there's no way to prevent some of them from poking through solid walls and being rendered on the other side, this can result in a significant performance loss in open areas with many lights and lots of module walls seen at once. Eager to hear what others think and if this solution is possible or maybe there's an even better way.

Just uploaded version 4 of this FM: Primarily this is a bug fix update, using TDM's many new diagnostic tools to fix issues like non-functioning visportals, dead-end GUI elements and sounds not playing due to a wrong sampling rate. The console now posts no warnings about FM-specific assets. Added subtitles provided by datiswous. Adjusted the river forest skybox to look more like it did when I originally released the FM, counteracting subtle, but significant changes to how transparent (leafy) surfaces are rendered in fog. Added a black fog to make the ravine scene look more bottomless. Also, wisps no longer leave behind black boxes at their starting positions. The AI in the bunk cabin of the starting ship should no longer be able to see the player through the corner of the bunks model (all nonsolid items should have visual-clip now). Cleaned up obsolete clutter from old-era material shaders. As a side effect, Linux users should now be able to start up the FM. Switched moonlights in certain outdoor scenes to the new parallelSky system. Got completely rid of the rotation hack for scaling models. Recompiled the maps using the newest version of TDM's compiler, benefitting from a lot of things that stgatilov changed over the years.

Finished it. This was so much more incredible than anything I expected! Especially the last level, that was something else. As a final idea: Think we could put that radio model in vanilla TDM? It fits perfectly and could definitely be used in other FM's. Maybe have some fitting ambient songs that can be looped with it?

A Winter's Tale By: Bikerdude "One of the few pleasures I have as a man of the thieving profession is to return to my old home town for the holidays and relax in the company of friends and relatives. But a local lord has been going out of his way to making the lives of the locals a miserable." Notes: - TDM 2.12 or later is REQUIRED to play this mission. - This is my entry for the speedbuilding jam. - This FM should play on the vast majority of systems. I have perf tweaked this map with low end players in-mind. And have moved the globale fog/moon lights to the ‘ better’ LOD level. - min recommended spec (as per beta testing) Intel Core i7(3rd gen), nvidia 1030 4gb (GDDR5), will get you 60fps inside and 45fps outside. - Various areas will look better with shadow maps enabled (SoftShadows set to medium/high, Shadows Softness set to zero and LOD set to 'better'), at the possible expense of performance depending on your system specs. - this mission continues the imperial theme, with this being a border town slightly further out from the main imperial lands than Brouften. - build time roughly 130hrs. Download Link: - (v1.4) - https://discord.com/channels/679083115519410186/1310012992867405855/1310022631415746632 v1.4 changes: I have been tweaking the LOD levels through-out the map - - Snow fall has been moved to LOD low/normal. - world fog moved to LOD better. - fireplace grills to LOD better. - world moonlight moved to LOD high. Other tweaks - - reduced light counts in all the fireplaces. - reduced the length of the looping menu video background. - Some new assets Gameplay: - added more ways for the player to get around. - tweaked existing routes to make some easier or more of a challenge. - and added an additional option objective. Credits: Special thanks go to - - Nbhor1more, flashing out the briefing and creation of readables. - Amadeus, Help w/custom objectives, script work, proof reading, mission design & testing. - Dragofer, for custom scripts and script work for the main objective. - Baal, for additional tweaking of the main objective and script work,. - Beta testers: Amadeus, Nbhor1more, Mat99, DavyJones, S1lverwolf, Baal & Dragofer. - Freesound.org, for ambient tracks, further details in sndshd file. Speed Jam Thread: - https://www.ttlg.com/forums/showthread.php?t=152747

Armor rusts, and the more you ignore the rust the faster the rust spreads. (Corrosion reactions scale with surface area, which is increased by rust flakes and scratches. A mirror polish minimizes surface area.) So if you neglected your armor so that it looked like those Fromsoft references, you would be buying a new suit of armor within a few years, and suddenly that captain-of-the-guard salary would be stretched pretty thin. Plus your employer would probably fire you for making him look like some pitiful hobo who hired a bandit to guard his house instead of a proper man-at-arms! So yes, in a realistic setting, an elite guard like that would probably have armor that is polished to a mirror finish, because part of his job is in fact to care for his armor. That would include making sure that it is immaculately oiled and polished before putting it on. That said, TDM is a fantasy game, and it's important to have a cohesive aesthetic to communicate the themes of the setting. One of the most common of those themes is the depravity and corruption of elites, and an easy way to communicate that visually is to put a thick layer of tarnish and grime on all their shiny trinkets. In contrast, to modern eyes mirror polished armor communicates vanity, grandiosity, and egomania, but not necessarily depravity. In that sense I agree that the new model should be a separate variant rather than replacing the default, so that FM authors can be intentional about how they use it.

Pretty subjective. Looking at things like the rough details in the normal map, I don’t think that’s what the original model is intended to convey, but I guess I don’t know either. It’s all subjective, but if that is what you are going for you are operating more in the territory of making a skin variant and the base material should remain intact, as I would consider yours to be more of an exception in terms of depictions of armor, which even when ornate, tend to have a more diffuse reflection: Personally given the darker setting I would prefer to use the original.

That should be fairly straightforward to implement; it sounds rather like what DR was doing before the change to treat bumpmaps as implicit separators. Are we certain that there are no materials using [B,D,D] to share a single bumpmap between two blended diffusemaps, since it looks like they might be handled differently now? This might have been something that only vanilla D3 used, perhaps to share a model's renderBump bumpmap with blended/painted diffusemaps.

Why? When I make assets I always use default values, and I think it's pretty much the only way to ensure everything looks the same on all players' computers. Obviously they can set it up as they like, but they have an easy reference point, in case they want to return to intended look. Besides, in order to get consistent results, you have to at least try to assume a model, something that will return somewhat logical results. Since this is non-PBR, it's hard to do; you don't even have any consistency in how models, materials or other declarations were made, nor how mappers use lights in maps.

r_bloom_weight is set to "0.7" both in my 2.12 installation and in main repository. I never touched those values which means the default must be 0.7. Troy Sobotka is the original creator of AgX. He was active on Blender forums where he had long philosophical arguments about color with people. Also on Blender developer forums. I don't know if there's much more beyond those and his github page: https://github.com/sobotka Edit @stgatilov AgX however is a direct continuation of Sobotka's earlier 'Filmic', so there may be more about that: https://github.com/sobotka/filmic-blender https://blender.stackexchange.com/questions/164991/are-the-technical-details-of-filmic-available

Yes, it's entity.setSkin("your_skin_here") if you're using scripting. There's also a way without scripts: Place two entities with the same model at the same location and rotation, give one the initial skin and the other one the new skin, give the first entity spawnarg "hide 0" and the second one "hide 1", trigger them both to make the switch. The downside is this requires placing two entities on the map, the upside is the new skin is then precached which may be faster and avoids stuttering when changing them.

I want to be able to change the skin of a model from a switch, and I don't know how. Tried target_setkeyval with no succes, then tried to make a custom trigger/target using setSkin, with no succes .. and now I don't know anymore. It has been so long that I don't even know how things work : P edit: setSkin works using a callscriptfunction, that is something, but too lame XD edit2: I am too lame XD It was merely a syntaxerror afterall : ) This works: #ifndef __STR_CHANGE_SKIN__ #define __STR_CHANGE_SKIN__ object str_change_skin { string skin; entity target; void init(); void main(); }; void str_change_skin::init() { target = getEntityKey("target0"); skin = getKey("newskin"); } void str_change_skin::main() { target.setSkin(skin); } #endif __STR_CHANGE_SKIN__ entityDef str_change_skin { "editor_color" "1 1 1" "editor_mins" "-8 -8 -8" "editor_maxs" "8 8 8" "inherit" "atdm:entity_base" "spawnclass" "idTarget" "editor_displayFolder" "Targets" "editor_usage" "Change the targets skin" "editor_var scriptobject" "Scriptobject this entity uses. Don't change" "editor_var newskin" "Give target this skin" "scriptobject" "str_change_skin" "frob_action_script" "main" "newskin" "newskin" //Stim/Response to call the frob_action_script when triggered. "sr_class_1" "S" "sr_type_1" "STIM_TRIGGER" "sr_state_1" "1" "sr_class_2" "R" "sr_type_2" "STIM_TRIGGER" "sr_state_2" "1" "sr_effect_2_1" "effect_frob" "sr_effect_2_1_arg1" "_SELF" }

Neon Builder sign. Looks pretty good with the bright orange, kinda like molten iron which gets the point across. decorative/signs/sign_hanging_builder_symbol_neon_lit { model "models/darkmod/decorative/signs/hanging_builder_symbol.lwo" "tdm_hammer_small_bronze1" "textures/darkmod/window/lamp_glass_lit_opaque_colorme" } decorative/signs/sign_hanging_builder_symbol_neon_unlit { model "models/darkmod/decorative/signs/hanging_builder_symbol.lwo" "tdm_hammer_small_bronze1" "textures/darkmod/window/lamp_glass_unlit_opaque_shadowcasting" } atdm:hanging_builder_symbol { "inherit" "atdm:static_electric_light_lit_base" "editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Signs" "editor_usage" "Neon sign, hanging builder symbol." "model" "models/darkmod/decorative/signs/hanging_builder_symbol.lwo" "skin" "decorative/signs/sign_hanging_builder_symbol_neon_lit" "skin_lit" "decorative/signs/sign_hanging_builder_symbol_neon_lit" "skin_unlit" "decorative/signs/sign_hanging_builder_symbol_neon_unlit" "_color" "1 0.5 0" "texture" "lights/biground1_squarelamp_snd" "s_shader" "light_flicker_104" "light_center" "12 0 -32" "light_radius" "128 128 128" "noshadows_lit" "1" }

Don't know if it's a dumb idea or not, but I for one kinda like my steampunk neon signs. I'll probably mention them in the shop keeper's book, how neon signs are all the rage and everyone's buying them. Wish I could reskin more of the default models to get even more designs, was lucky it happened to work out with this one, even if the chain shining is a little meh. No custom assets needed, just the def and skin. If anyone else wants them here's the one for the sheep logo, easy to produce and customize the rest of them from there. decorative/signs/sign_half_round_neon_sheep_lit { model "models/darkmod/decorative/signs/sign_half_round_01.ase" "textures/darkmod/metal/flat/iron_rough_ns" "textures/darkmod/window/lamp_glass_lit_opaque_colorme" "sign_half_round_wine" "tdm_sign_shield_sheep" } decorative/signs/sign_half_round_neon_sheep_unlit { model "models/darkmod/decorative/signs/sign_half_round_01.ase" "textures/darkmod/metal/flat/iron_rough_ns" "textures/darkmod/window/lamp_glass_unlit_opaque_shadowcasting" "sign_half_round_wine" "tdm_sign_shield_sheep" } atdm:sign_neon_sheep { "inherit" "atdm:static_electric_light_lit_base" "editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Signs" "editor_usage" "Neon sign, sheep." "model" "models/darkmod/decorative/signs/sign_half_round_01.ase" "skin" "decorative/signs/sign_half_round_neon_sheep_lit" "skin_lit" "decorative/signs/sign_half_round_neon_sheep_lit" "skin_unlit" "decorative/signs/sign_half_round_neon_sheep_unlit" "_color" "0.5 0.5 0.5" "texture" "lights/biground1_squarelamp_snd" "s_shader" "light_flicker_104" "light_center" "0 0 -24" "light_radius" "128 128 128" "noshadows_lit" "1" }