Search the Community

Hello! I just joined the forums to report an annoying bug. I don't know if it's specific to this map or just a game bug but I have played most of the other missions and this is a first for me. Before i picked up the key to the junkroom i tried to open the door and i got the "needs junkroom key" message on my screen... but that message never went away. I had to complete the mission with that on my screen the entire time, overlaying all the other messages that appear. a reload/restart didnt do anything to solve the problem. A few of the on-screen messages at the beginning didn't make sense to me and were kind of cryptic, like a riddle i didn't get. one of them was something about an alarm? otherwise i liked the mission, pretty challenging and I know i missed some spots. cheers

I'm opening this topic to summarise the technical changes that have been made to DR's renderer and get some feedback from my fellow coders. I'd love to get a peer review on the code changes, but going through that by looking at a pull request of that renderer branch would be a terrible experience, I assume, so instead I'd like to give an overview over what is done differently now. General things to know about DR's renderer DarkRadiant needs to support three different render views or modes: orthographic view, editor preview (fullbright) and lighting preview. Each of them has very different needs, but the lit preview is the most complex one, since it ideally should resemble what the TDM engine is producing. Apart from the obvious things like brush faces and model geometry, it needs to support drawing editor-specific things like path connection lines, light volumes, manipulators (like the rotation widget) or patch vertices. Nodes can be selected, which makes them appear highlighted: they display a red overlay and a white outline in the camera preview, whereas the orthoview shows selected item using a thicker red dashed line to outline selected items. DarkRadiant cannot specialise its renderer on displaying triangles only. Path lines for instance are using GL_LINE_STRIPs, Single brush faces (windings) are using GL_POLYGON for their outline (triangulation of brush faces in the ortho view or the camera (when selected) introduce a lot of visual noise, we just want the outline), patches want to have their control mesh rendered using GL_QUADS. Model surfaces (like .ASE and .LWO models) on the other hand are using GL_TRIANGLES all the way. Almost every object in DarkRadiant is mutable and can change its appearance as authors are manipulating the scene. CPU-intensive optimisations like generating visportal areas is not a likely option for DR, the scene can fundamentally change between operations. The Renderer before the changes DR's rendering used to work like this: all the visible scene nodes (brushes, patches, entities, models, etc.) were collected. They have been visited and were asked to forward any Renderable object they'd like to display to a provided RenderableCollector. The collector class (as part of the frontend render pass) sorted these renderables into their shaders (materials). So at the end of the front end pass, every shader held a list of objects it needed to display. The back end renderer sorted all the material stages by priority and asked each of them to render the objects that have been collected, by calling their OpenGLRenderable::render() method. After all objects rendered their stuff, the shader objects were emptied for the next frame. Culling of invisible objects has been happening by sorting objects into an Octree (which is a good choice for ortho view culling), some culling has been done in the render methods themselves (both frontend and backend calls). The problems at hand Doing the same work over and over again: it's rare that all the objects in the scene change at once. Usually prefabs are moved around, faces are textured, brushes are clipped. When flying through a map using the camera view, or by shifting the ortho view around, the scene objects are unchanged for quite a number of frames. Separation of concerns: every renderable object in the scene has been implementing its own render() method that invoked the corresponding openGL calls. There were legacy-style glBegin/glEnd rendering (used for path nodes), glDrawElements, glCallList, including state changes like enabling arrays, setting up blend modes or colours. These are render calls that should rather be performed by the back end renderer, and should not be the responsibility of, let's say, a BrushNode. Draw Calls: Since every object has been submitting its own geometry, there has been no way to group the calls. A moderately sized map features more than 50k brush faces, and about half as many patch surfaces. Rendering the whole map can easily add up to about 100k draw calls, with each draw call submitting 4 vertices (using GL_POLYGON). Inconsistent Vertex Data: since each object was doing the rendering on its own, it has been free to choose what format to save its data in. Some stored just the vertex' 3D coordinate, some had been adding colour information, some were using full featured vertices including normal and tangents. State Changes: since every object was handled individually, the openGL state could change back and forth in between a few brush windings. The entity can be influencing the shader passes by altering e.g. the texture matrix, so each renderable of the same material triggered a re-evaluation of the material stage, leading to a massive amount of openGL state changes. Then again, a lot of brushes and patches are worldspawn, which never does anything like this, but optimisation was not possible since the backend knew nothing about that. Lighting mode rendering: Lighting mode had a hard time figuring out which object was actually hit by a single light entity. Also, the object-to-entity relationship was tough to handle by the back end. Seeing how idTech4 or the TDM engine is handling things, DR has been doing it reversed. Lighting mode rendering has been part of the "solid render" mode, which caused quite a few if/else branches in the back end render methods. Lighting mode and fullbright mode are fundamentally different, yet they're using the same frontend and backend methods. The Goals openGL calls moved to the backend: no (frontend) scene object should be bothered with how the object is going to be rendered. Everything in terms of openGL is handled by the back end. Reduced amount of draw calls: so many objects are using the same render setup, they're using the same material, are child of the same parent entity, are even in almost the same 3D location. Windings need to be grouped and submitted in a single draw call wherever possible. Same goes for other geometry. Vertex Data stored in a central memory chunk: provide an infrastructure to store all the objects in a single chunk of memory. This will enable us to transition to store all the render data in one or two large VBOs. Support Object Changes: if everything should be stored in a continuous memory block, how do we go about changing, adding and removing vertex data? Changes to geometry (and also material changes like when texturing brushes) is a common use-case and it must happen fast. Support Oriented Model Surfaces: many map objects are influenced by their parent node's orientation, like a torch model surface that is rotated by the "rotation" spawnarg of its parent entity. A map can feature a lot of instances of the same model, the renderer needs to support that use-case. On the other hand, brush windings and patches are never oriented, they are always using world coordinates. Unified vertex data format: everything that is submitted as renderable geometry to the back end must define its vertex data in the same format. The natural choice would be the ArbitraryMeshVertex type that has been around for a while. All in all, get closer to what the TDM engine is doing: by doing all of the above, we put ourselves in the position to port more engine render features over to DR, maybe even add a shadow implementation at some point.

DarkRadiant 2.13.0 is ready for download. A lot of fixes and improvements made it into this release. Several point files can be selected for display now. DarkRadiant is now capable of comparing maps, both in differential A vs. B comparisons as well as three-way merge scenarios (when both maps share the same ancestor). Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/2.13.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.12.0 Feature: Ability to choose from several different pointfiles Feature: Aspect ratio preserving Fit Texture option Feature: ModelSelector: add ability to rescan folders without having to reload all models Feature: Add "Show Material Definition" to ShaderSelector tree views Feature: Paste material-header to surface from clipboard with hotkey. Feature: A way to display editor_usage in the Entity Inspector window Feature: Selection by coords Feature: Three-Way and Differential Map Merge Feature: Map Comparison/Diffing Feature: Git Version Control Integration Plugin Improvement: Show axis when 'R'otating entities Improvement: Improve workflow for adjusting light brightnesses Improvement: Map Loading Performance Improvements Improvement: Refresh entity inspector when reloading defs Improvement: Increase maximum zoom level of 2D views Improvement: "Choose entity..." button for all def_ spawnargs Improvement: CTRL + MMB in orthoview: place camera at height of most recent selection Improvement: Added Documentation for Layer Script Interface Improvement: "Shift textures randomly" shifts all selected faces by the same amount Fixed: Problems with particle preview obstructing the view Fixed: Cannot view or copy from built-in Filters Fixed: Auto-save is slow when animation or particle viewer is playing Fixed: Non uniform light volume scaling not working Fixed: BC5 normal maps cannot be loaded Fixed: Copying a particle in the Particle Editor creates an ___editor list entry which can lead to crashes Fixed: Create Entity window no longer remembers the previous item Fixed: Model exporter: no model is exported if folder path doesn't exist yet Fixed: Non power of 2 textures show up black in Fixed: 'Change game/project' fails to save if a decent-sized .map was loaded Fixed: Reload Defs is messing up the entityDefs Fixed: Crash when using Reloading Defs after placing an Entity Fixed: Entity & Speaker windows don't remember their size Fixed: Restore non-uniform scaling for texture browser. Fixed: Some ASE models do not load Fixed: Prefabs importing miles away Fixed: Path entites rotate 15 degrees, each time when dragged. Fixed: Crash when activating GameConnection Feature "update entities on every change" Fixed: Model previewer not displaying ASE or LWO models Fixed: Crash when selecting an MD5 model in "Create Model..." menu Fixed: Crash when activating the Material Editor in Doom3 game config The list of changes can be found on the our bugtracker changelog. Have fun mapping!

Maybe everyone knew this already, but I just found out today that the player shadow can cause a major hit to FPS. That makes sense when you think about it, since the player is probably our most highpoly model and it's currently calculating the shadow for every single face of it. I tried this experiment: Go to torchtest.map, light three lights, move them close together. You now have three overlapping lights. Stand infront of them, with g_showplayershadow set to 0. I get 60 FPS. Then I turn g_showplayershadow on, and get 15-20 FPS! That makes quite a difference. Just to see what kind of hit we take for calculating the shadow from 3 lights on any item vs. no shadow casting items, I spawned a crate in the same place I was standing (with my own shadow off), and that didn't cause a noticeable drop. So I think we could really benefit from having a shadow mesh on the player, and all AI. It could make a huge difference in performance, since a lot of maps end up having a few shadow-casting lights overlapping, unavoidably.

[update] Spoke to Marcus @AMD UK on the phone and as it turns out a number of complaints have been made against "Spyre". My AMD forum account has been unbarred and my Ip address unblocked!!! Bought a new gfx card for xmas, been having issues with mainly the driver So I though a good place to look for support and polity vent etc - or so I thought My second post got flamed by some smart arse fanboy and then promptly locked, to which I reported the posted asking why it had been locked.. and then my account on there got deleted and my Ip blocked (untill the isp dhcp refreshed etc) so I cant login even with a different account name. I have emailed AMD directly about this as I did nothing wrong according the t&c's and I got no warning Pm or email from the forum mods. Now I've been over at the nVidia forums a long while back when I had the 8800GTX when I was equally frustrated when posting about the driver issue with thief etc, but at no point did a thread get locked or worse my account deleted. I don't have loyalty to AMD or nVidia but depending on the answer I get from AMD next week this card maybe going back and AMD will be added to the list of manufactures I will never buy anything from again. So whats the moral of this story, well take your pick.. [update] found cached copies of 1 of my posts Cached AMD frum link Cached AMD forum link2

It's not very complicated but a little tricky in places. First of all you need the md5 IO script for Blender... I believe the one I'm using is this: https://www.katsbits.com/smforum/index.php?topic=520.0 Setup: You must have one or more mesh objects rigged to an armature as usual. Each mesh object represents a different material, the name of the material on each object represents the texture that material will point to. Additionally every surface on the mesh must be UV unwrapped, whereas the bones must be on the armature layer where the script expects it (layer 5 by default I think). For the md5mesh: Just select both the mesh and the rig, and export to md5mesh. Disable reorient as this seems to mess up the rotation. For the md5anim: On the control armature, select the armature action of the animation you wish to export. Make sure to set the start frame of the scene to 1 and the end frame to the last frame of that animation! Then once again select both the mesh and rig, and export to md5anim. Again disable reorient as this seems to rotate it on its own. If you want an example setup, the ready blend sources of the bow and Xonotic characters are both included in the repository. You can find them here: https://gitlab.com/darkmodule/darkmodule/blob/master/tdmu_player01.pk4dir/source/md5/weapons/compoundbow/compoundbow.blend https://gitlab.com/darkmodule/darkmodule/blob/master/tdmu_ai_troopers01.pk4dir/source/md5/chars/troopers/troopers.blend

Can't use spoiler tags, so here's the file I'm using for beta4.

when i do a search, it give me some results, I click on a result and exspect to get taken to the post it specifies - but no..... I get taken to the first post of the bloody thread it is in..ggrrr

@Zerg Rush: Any further clues or suggestions or strategy should be wrapped in spoiler tags, please.

It's interesting because I recently read a thread on the Doomworld forums on people's opinions of single-segmenting maps in classic Doom/Doom 2. In other words, playing a map from start to finish without using saves - if you die, you have to replay the entire map. The general consensus was that saves are useful, however there was some merit in there being extra tension and challenge knowing that death couldn't be rewound easily by reloading a save. On the other hand (and speaking as an adult), people have to work and often have limited time for gaming. Having to replay a long map because you died can be quite off-putting and takes the joy out of a game if it happens often enough. Savegames keep the tempo going, keeps the feeling of progress going. Also someone pointed out that starting a map from scratch after a death is kinda like using saves anyway, just a single save at the beginning. You're just being tedious by denying the use of saves in this case. Dunno where I'm going with this. Trying to be diplomatic and say I can see all sides to the discussion.

Regarding the sound: Instead of creating a speaker via script, you could create the speaker in a seperate (e.g. where the start-weapons and items are stored) and move it to the player position, when you need the sound. When the sound should stop, you could move it back to its former location. That way, you can have the speaker on repeat all the time or you could handle it like you would any other speaker. Regarding the speed potion: By the way: If you are searching for somethin in the forums, I would recommend to use google with a "site:forums.thedarkomod.com" before the term you are searching for. This limits the google search to the forums and the google algorithm is way better than the search function of the forum itself. In this case it was the second hit of the search.

I only worked with skins briefly and that was some time ago, so my memory is rusty but afaik skins have nothing to do with multiple meshes, skins only replace a material name/link for another. About what i said about ASE, i pretty much only work with LWO and MD5 exclusively, so i could be indeed wrong about it, but i did made some ASE models in the past and unless idtech 4 treats 3DS Max ASE exported files differently, as the ones exported by my Modo ASE plugin (is possible), the ASE file should be a single model ingame and in DR, having said that, lwo and ASE indeed support multiple meshs/layers, but afaik idtech 4 does not, when you export your mesh for this engine, all of your geometry needs to be on a single layer, and i mean even if your model is made of separate objects, you need to put them all in a single layer, in blender parlor you need to combine them, for TDM for example this means, the visible object, the collision mesh hull and the shadow mesh, need to be grouped into a single layer/ object, you can only differentiate surfaces in the engine by material id's, this means a single model can have multiple different materials on it, but like Judith said be carefully with that. About UV's, idtech 4 require's a single non overlapping UV map per mesh, so no second UV layer, that doesn't mean you can't blend textures in a single mesh in idtech 4, for that you use vertex weight painting AND OR different material stages. I hope what i'm saying is clear.

You asked for Blender, so I can't say anything about that, but there aren't any problems with exporting multiple meshes as one .ase mesh (scene) in 3dsmax. Also, besides having one piece of mesh e.g. with custom collision or simplified shadow mesh, there's no advantage in either method in terms of materials. Every new (simple) material means more drawcalls + added triangle count. Every additional material stage other than diffuse, normal, and specular slot adds to it as well. Unless you have special-purpose elements like custom shadows or collision, you should strive for one mesh / one material ratio. Or even better, one material / several mesh variations, to save on texture memory.

So I'm kind of getting the desired result if I first convert my brushes to a func_static then change the classname to light. The problem is that this appears to cause bugs at least in the editor: You need to do this conversion at origin 0 0 0 otherwise the mesh will appear offset. Even if you do this however, the model won't move when you move the light in DarkRadiant, although its vertices appear in the correct position... looks like a bug to be honest. Update: I found a way around this particular problem! What I need to do is the following steps: Create my light brushes and convert them to a func_static. Separately create my light entity somewhere nearby and give it all the needed properties. Look at the model number in the name on my func_static entity. Then select the light entity and give it the property "model func_static_1". Now the light will use my brushes as a model without any glitches! Only problem is that this method raises a few questions: What happens if I delete the original func_static, can I do that or must I keep it somewhere on the map separately? In fact, what if I were to export this light as a prefab, without the original func_static entity included... would the brushes be exported accordingly with it and stick? Update 2: Just answered my own question. Unfortunately the original func_static must also be placed somewhere on the map, if I remove it the light's model turns into a black box. In this case: How can I make the func_static completely invisible and non-colliding, so that it's only there to be referenced but its mesh is only really used by the light entity?

In order to thank the team (and other mappers) for their relentless efforts in contributing, I hereby give the community.... Ulysses: Genesis A FM By Sotha Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraTlJ6ZHlYZ1pJRVE/edit?usp=sharing http://www4.zippysha...95436/file.html Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

Okay. So an update is in order. The server's disk was replaced on Tuesday and I am busy reinstalling everything. As I make progress, I will try to bring services back online as and when they are ready. As an interim measure, I have www.thedarkmod.com, forums.thedarkmod.com, and mirrors.thedarkmod.com up and running on one of my other servers. Are there any other services that are needed somewhat urgently? I suspect that we may want the missions list back for the in-game mission downloader. Thoughts? You will have noticed that the forums look rather different. I wasn't able to bring the forums over exactly as there were before due to incompatibilities with the newer versions of PHP and the old version of IP.Board that we were running. This will likely also be an issue when I setup the original server with updated OS and package versions. I've now upgraded the forums software from IP.Board 3.x to IP.Board 4.x and there are some significant changes that affect themes and other functionality. The new version doesn't seem to be as flexible in terms of configuration, so I'll have to figure out how to match the old setup as best I can. The theme and layout will need to be redone for IP.Board 4, but I won't have time for that this week. The default theme will just have to do for now. I'm not sure that everything is setup 100% correctly on the temp server, so expect some issues to crop up (e.g. URL rewriting currently isn't working properly). The forum software update was long overdue (old version went out of support months ago, meaning no security updates), so I will likely not attempt to get the old version working again. Please be patient while I try get the forums back to their former glory.

why are they so slow this evening..??

Hey @CrustyCircuits Welcome to the forums! I'm really glad you like the mission, thank you for playing Since other players have answered, I'll just say that it is definitely not a bug! Also, so other players don't accidentally get spoiled would you mind editing your post so that it uses spoiler tags. Thanks, hope you enjoy the rest of it!

I found the forum post I did about it here: https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=459121 I don't think I got a reply, and we were near release time so I just gave up on it. It worked at some point, so was probably something on my end. Regardless, having to use a Perl script hosted on some obscure server that nobody maintains anymore doesn't seem like a robust process. I think you can build the FM from the start to support i18N and not have to use that script. That's the approach that I think I will take for my next FM. Looking at the Wiki page, it's not that clear how to do it so that's what I'll aim to sort out. But then again, unless there are plenty of people waiting in the wings to perform translation work, not sure how motivated FM authors will be to support this.

The forums have been upgraded, please see this thread: http://forums.thedarkmod.com/topic/9845-forums-upgraded-to-ipb-3-0-3

Hey @MirceaKitsune, thank you so much for playing! As for the bracelet, there is no objective text that shows up specifically; it is just something you have to gleam for yourself. EDIT: Hmm, i can't seem to get spoiler tags to work right now. Will send a PM

I've been looking through that a couple times over already. The thing that's confusing me is how you swap several materials within the model? Like how to tell it which material is getting replaced with what? For instance I have three main materials defining the transformer. There is the primary material (covering the whole mesh) and the other two are for the lit gauge and needle. It's an odd gamble but I have the unlit gauge on the base diffuse and want to nodraw the needle and lit gauge for the non-active skin. What I'm having difficulty with is how to re-direct several materials within the same mesh. //----------------------- // arc_transformer skins - Epi //----------------------- // arc_transformer_001 // name of the alternative skin (included in the material file) skin arc_transformer_001_alternative { model models/darkmod/custom/arc_transformer_001.ase // default skin textures/custom/arc_transformer_001 // alternative skin textures/custom/arc_transformer_001_alternative } I have two more materials (minus the utility shadow and collision) transformer_needle and transformer_gauge that are being used in this mesh. I want one version for each skin variant to support on and off modes for the same mesh. Off mode would just nodraw out needle and gauge. I'm just not quite grasping how to tell the material something like, replace transformer_needle with nodraw? Because in this skin example it's only defining one material to switch rather than three. The only thing that's making sense to me is some kind of line that calls up the actual cluster on the mesh first. Such as the name I've given it within my modeling app and then listing the actual replacement material afterward... //arc_transformer_001_off { transformer_needle textures/common/nodraw transformer_gauge textures/common/nodraw arc_transformer_001 } ​//arc_transformer_001_on //Additional lines are absent, since the target material bears the same name as the mesh's cluster { transformer_needle transformer_gauge arc_transformer_001 } That's kinda the example as it goes in my head anyway. I need to specifically target certain parts of the mesh.

maskColor and maskAlpha are reasonably common when working with alpha masks: textures/darkmod/glass/clear for example. I've never seen a use for maskDepth though. Polygon offsets would probably be used more if they didn't break light interaction (one learns the hard way why setting DECAL_MACRO can be a bad idea); I basically associate privatePolygonOffset with D3-esque burnaway effects. Isn't the depth hack a particle thing from before sort particles? I have the impression that vertexColor is fairly rare because it needs a mesh with vertex colour data, and it's mainly used with inverseVertexColor for vertex blended meshes, although you can also use it for baked AO and the like. (The ET:QW wiki suggests using vertex colours to fade out the edges on water meshes, but I think https://forums.thedarkmod.com/index.php?/topic/18036-messing-with-sea-water/ has been the focus of TDM experiments on soft water edges...)