Search the Community

This is an experimental GUI app for managing and packing Dark Mod missions. It's a successor to FM Packer but with a GUI, that I've been working on for some time. It's now at a stage where I feel somewhat comfortable sharing. Having a GUI unlocks potential for more in depth management of fms, which I intend to explore in the future. You can download the binaries here: https://github.com/Skaruts/tdm_packer_2/releases Currently: it can pack your selected mission into the pk4 at a click of a button you can specify which files to exclude from the pk4, by editing the .pkignore file (Package -> Pack) you can edit the mission's files with syntax highlighting (xdata, scripts, skins, definitions, etc) you can view both the included and excluded files in a handy tree list (you can Shift+LMB to fully expand/contract branches) it can launch TDM or DarkRadiant for the selected mission, or run a second installation of TDM to test your pk4 in isolation (see the menu Settings->Paths) it automatically puts your map sequence into the appropriate file all maps, except the ones in the map sequence, are auto excluded from the pk4 Important: This is still an experimental alpha version, so backup your missions before using it. Note: For now I provided binaries for Windows and Linux. I don't have a Linux system to test the binaries yet, though, so they may or may not work properly. As a last resort, one can still run this app from the source code by running the Godot Engine itself from the terminal with the "--path path/to/project" argument. (Godot itself is just a simple executable and requires no installation.)

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

ThiefGuild has some tags: https://www.thiefguild.com/fanmissions/?advanced_search=&series=&collection=&table=&page=&works=&work_lists=&sort_by=newest&search=&games=5&released_from=all&released_to=all&genre=all&original_games=fms Not sure how complete or accurate those are, after all either the author or users add the tags to the missions.

Revelator, Zerush: I remeber when Mircea Kitsune was banned. I saved the Xonotic vote page to the internet archive, but can't remeber the URL: What I do remeber is this: 1) First Havok (AKA: Forest Hale, IIRC) from Darkplaces banned Mircea because of some twitter opinion Mircea wrote three years prior. This is after Mircea work on code for Darkplaces for many years (for free). Havok then made an explicit rule in the opensource project banning everyone who expressed such views anywhere on the internet: they were banned from development and not wanted. It had to do with who one likes. Mircea was not allowed to like why they liked. Verboten in America. Mircea had programmed C for a Decade + for darkplaces. 2) Then Mircea fell back on Xonotic: and wrote about this on the blog. The feeling was "atleast I have this community that will not betray my kindness". He had programmed QuakeC for Xonotic/etc/whateveritusedtocallitself for a Decade; including great additions such as the code that makes better damage effects clientside. He also made 3d models to be used with Xonotic/etc and textures and everything else. Within a week, the head of that project: Divverent (AKA: Rudolf Polzer, IIRC) voted to ban Mircea because of his twitter opinion expressed 3 years prior: about who was liked/loved by Mircea. Verboten in America (and Germany (but less so)). The rest of the "heads" of that project also gleefully voted to ban and they happily stand by this decision to this day on their discord. 3) That crushed Mircea (according to the blog written) and this is the eventual result. In the past developers were never banned from opensource projects. I think that banning people who have contributed to an opensource project; directly their time, effort, and code; whereby the original understanding was "show us your code" "only code matters" etc; is a violation of a implicit agreement. I also think that banning them based off of speech they made; is an attempt to quell their speech; and a violation of their Federal Civil Rights. But that's just a theory. I also think the parents of Mircea Kitsune, in Romania, should be informed about the people who banned their child. It feels like a wrongful death to me.

yeah its the same for me basically i have a hard time wrapping my head around interactions between the renderer and the shader code. this is mostly because im from a time where all render code was fixed function and the apperant mechanism opengl / directx uses to handle converting the shader code to engine code is not readily appearant. i can do some simple shaders but that is mostly because i memorized the effects. still not understanding it fully .

For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts

Darkmod underutilizes, in my opinion, capabilities for procedural animation. We already do some, like the random head and torso turns that are added on top of existing animations. There's also possibility for separate animation for top and bottom of the character as well as head. There's a missing opportunity for varied facial expressions. I talked about animation blending in this thread. Here's something that for example Thief: Deadly Shadows did. It's swaying side to side while turning. I used Gemini to add code to the tdm_ai_base.script. I don't know if this is the most efficient way of doing it, probably not. Here are the parts added: Gemini came up with the term "banking" which is used in car racing. I don't know if that's what it's called in animation or games. There's a lot of variables that can be tweaked. You can rotate this way any bone you wish. I use 'Origin', 'Spine_Dummy' and 'Neck' bones: You can tweak amount of rotation for each bone. setJointAngle(m_bankingJointHandle, 1, jointRotation * 1); setJointAngle(m_bankingJointHandle1, 1, jointRotation * 0.6); setJointAngle(m_bankingJointHandle2, 1, jointRotation * -1.5); There's also global intensity: (targetBanking = deltaYaw * 1.4;) and attenuation: m_bankingCurrentValue = (m_bankingCurrentValue * 0.95) + (targetBanking * 0.05); modifiers. Gemini also proposed to add an LOD system, which I thought was a great idea. So currently at a distance of 1500 from player the swaying will be disabled. Here are examples, each with slightly different values: And here's comically exaggerated one:

Here are some screenshots of Mircea Kitsune's code being used on weapons (counters on weapons) The code was great and something when I beheld it I thought "so elegant; simple; and yet I could have never thought of it". Nor did anyone else in the 20 or so years that Nexuiz/Darkplaces/and-it's-forkXonotuc has been around. They savagely and with malicious aforethought: threw him away. This code was ported just a few months ago, maybe 6 or 7 or 8.

Nice work! Is there a build/code that other users can download and try? Please merge back the code with TDM VR, see topic: https://forums.thedarkmod.com/index.php?/topic/20468-the-dark-mod-vr-210-alpha-is-now-available/ === Reddit topic: link Video of JAKE's work:

In a broad sense, yes. This is how interface boundaries work. Mappers have freedom to totally override most of the files. This locks up extensibility pretty quickly. Normally, there should be boundaries, like e.g. we say that base AI scripts and defs are only for the core to maintain, while some derived classes can be customized by missions. This is how e.g. GUI code works (you can override this / you can't override this). Interaction between C++ and scripts works in the similar way. So the answer is different in every specific case.

For more info, read this topic: https://forums.thedarkmod.com/index.php?/topic/23261-i-made-full-vr-support-for-the-dark-mod-new-bow-climbing-mechanics-and-more/ He based his code of TDM VR, so I referred him to this topic.

I don't know who has what skillset, as I am still pretty green on the forums. However, I do know that shader development does require some voodoo black magic! I understand the fundamentals of shaders, but understanding the basic how and why is very, very different from creating them.

So there's no way we can add this code to the game without having to modify any old missions that have custom .script or .def files?

If mission overrides some base AI scripts, you can't add it without conflicts. Otherwise, what kind of conflicts do you mean? Script data is stored in savegames as raw binary, so any change in scripts may break it. That's why the engine writes checksum of script code: if it is different on load, then savegame refuses to load. It does not matter where you put the code, checksum will be different in any case. In a campaign, it should be okay to replay one mission, or just load the "end mission" save. It does not work right now?

Thanks for the feedback! There are still junky parts to fix and things to do before i can confidently put it out for people to experience, AI is doing the coding but quite often the code needs direction and fixing after it does it This was built upon fholger's extensions, the one you linked, so i will merge with it when im confident with it or at least fork it. I am looking for ideas and feedback if anybody wants to test the current version, I've always wanted this VR support and Thief community having their say in it is the importance for me rather than having me and AI put something together people will get frustrated over

I wanted to ask him about his code that allowed one to pick both nexuiz and xonotic servers to play on. I guess I'll never get to do that now

the shader based versions might be better nowadays but im from a time before they became the mainstay so im really bad at them . though the members who can do those might also be interested in this discussion. the old version works quite well though so it depends on the need. currently cleaning up the code a bit and looking into what needs changing for idtech4. ill use doom3 to check for oddities and if it works ill post the code changes needed.

void R_HardwareOcclusion (void) { int i; entity_t *ent; int numOccluded = 0; float mins[3]; float maxs[3]; byte boxindexes[] = { 0, 1, 2, 3, 4, 5, 1, 0, 3, 2, 6, 7, 5, 4, 7, 6, 1, 5, 6, 2, 4, 0, 3, 7 }; float boxverts[24]; // disable texturing glDisable (GL_TEXTURE_2D); // because we don;t know the orientation of the bbox in advance... glDisable (GL_CULL_FACE); // disable framebuffer and depthbuffer writes glColorMask (GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE); glDepthMask (GL_FALSE); glEnableClientState (GL_VERTEX_ARRAY); glVertexPointer (3, GL_FLOAT, 0, boxverts); for (i = 0; i < cl_numvisedicts; i++) { ent = cl_visedicts[i]; // don;t bother with these are they're included with the world if (ent->model->name[0] == '*') continue; // get mins and maxs points VectorAdd (ent->origin, ent->model->mins, mins); VectorAdd (ent->origin, ent->model->maxs, maxs); // CPU grunt to the rescue!!! boxverts[0] = boxverts[9] = boxverts[12] = boxverts[21] = mins[0]; boxverts[3] = boxverts[6] = boxverts[15] = boxverts[18] = maxs[0]; boxverts[1] = boxverts[4] = boxverts[13] = boxverts[16] = maxs[1]; boxverts[7] = boxverts[10] = boxverts[19] = boxverts[22] = mins[1]; boxverts[2] = boxverts[5] = boxverts[8] = boxverts[11] = maxs[2]; boxverts[14] = boxverts[17] = boxverts[20] = boxverts[23] = mins[2]; // begin the occlusion query glBeginQuery (GL_SAMPLES_PASSED, OcQueries[i]); // draw as indexed varray glDrawElements (GL_QUADS, 24, GL_UNSIGNED_BYTE, boxindexes); // end the query // don;t read back immediately so that we give the query time to be ready glEndQuery (GL_SAMPLES_PASSED); } glDisableClientState (GL_VERTEX_ARRAY); // restore basic state glEnable (GL_TEXTURE_2D); glEnable (GL_CULL_FACE); // enable framebuffer and depthbuffer writes glColorMask (GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); glDepthMask (GL_TRUE); // some implementations don't reset the primary colour properly after restoring the colormask glColor4f (1, 1, 1, 1); // now we read back for (i = 0; i < cl_numvisedicts; i++) { ent = cl_visedicts[i]; // don;t bother with these are they're included with the world if (ent->model->name[0] == '*') continue; // get the object and store it in the occlusion bits for the ent glGetQueryObjectiv (OcQueries[i], GL_QUERY_RESULT, &ent->OcclusionBits); if (!ent->OcclusionBits) numOccluded++; } // testing // Con_Printf ("Occluded %i Entities\n", numOccluded); } this code was made for quake so there are a few things that needs changing. feks. if (ent->model->name[0] == '*') continue; this tests against quake's transparent models (water / slime / teleports) and skips occlusion tests for those but idtech4 uses something different. or these cl_numvisedicts / cl_visedicts which are used to make a list of visible entities in quake but idtech4 uses a different approach on these as well. so quite a lot of changes nessesary before it can be used. the occlusion queries are actually generated in another piece of code in the check for OpenGL capabilities. that code is this -> // occlusion queries if (glGenQueries && glDeleteQueries && glIsQuery && glBeginQuery && glEndQuery && glGetQueryiv && glGetQueryObjectiv && glGetQueryObjectuiv) { // get number of query bits // an implementation is allowed to support occlusion queries but have no bits available!!! // therefore we only store query bits as a cap and test against that glGetQueryiv (GL_SAMPLES_PASSED, GL_QUERY_COUNTER_BITS, &GL_Caps.GL_QueryBits); Con_Printf ("%i Occlusion Query Bits\n", GL_Caps.GL_QueryBits); if (GL_Caps.GL_QueryBits) { // generate occlusion query objects extern int OcQueries[MAX_VISEDICTS]; glGenQueries (MAX_VISEDICTS, OcQueries); Con_Printf ("Generated Occlusion Query Objects\n"); } else Con_Printf ("Did not Generate Occlusion Query Objects\n"); } else GL_Caps.GL_QueryBits = 0; the renderer in quake uses it like this -> // occluded if (!cl_visedicts[i]->OcclusionBits) continue; which just skips over drawing anything that is occluded. for lights / shadows we are not actually drawing an object so the method would also have to be changed for this purpose. there is also the problem with hardware occlusion queries that they tend to lag 1 frame behind which would cause otherwise occluded objects to shine through for a split second before it catches up.

the code is actually compatible with other culling standards so i would wager it could be used for specific in game purposes. a lot of what you mention is pretty much what it does . it prerenders a small quad representing the game world entities then it tests for occlusion between this prerender and the game itself. transparent entities are not tested as they would not occlude anything anyway. the code is pretty old (2007) and more fine grained methods have since popped up so there is room for improvement (masked occlusion culling etc). a distance cull is actually pretty easy to pull off but it rarely looks good because of pop ins. a better method would be to fade it in when close enough (we used a rather nasty hack in quake with fog density to make objects appear slowly the closer you got. but this still renders it so it is not real culling). hardware occlusion culling can even be done with shaders

Can I have something added to the source code? file game\Player.cpp function HandleSingleGuiCommand() if ( token.Icmp( "toggleObjectives" ) == 0 ) { ToggleObjectivesGUI(); return true; } Like this: bool idPlayer::HandleSingleGuiCommand( idEntity *entityGui, idLexer *src ) { idToken token; if ( !src->ReadToken( &token ) ) { return false; } if ( token == ";" ) { return false; } if ( token.Icmp( "addhealth" ) == 0 ) { if ( entityGui && health < 100 ) { int _health = entityGui->spawnArgs.GetInt( "gui_parm1" ); int amt = ( _health >= HEALTH_PER_DOSE ) ? HEALTH_PER_DOSE : _health; _health -= amt; entityGui->spawnArgs.SetInt( "gui_parm1", _health ); if ( entityGui->GetRenderEntity() && entityGui->GetRenderEntity()->gui[ 0 ] ) { entityGui->GetRenderEntity()->gui[ 0 ]->SetStateInt( "gui_parm1", _health ); } health += amt; if ( health > 100 ) { health = 100; } } return true; } if ( token.Icmp( "ready" ) == 0 ) { PerformImpulse( IMPULSE_READY ); return true; } if ( token.Icmp( "toggleObjectives" ) == 0 ) { ToggleObjectivesGUI(); return true; } if ( token.Icmp( "updateObjectives" ) == 0 ) // Durandall #4286 { UpdateObjectivesGUI(); return true; } if ( token.Icmp( "updateInventoryGrid" ) == 0 ) // Durandall #4286 { UpdateInventoryGridGUI(); return true; } src->UnreadToken( &token ); return false; } This change has zero impact on anything. I would like to do without the "Objectives" hotkey and alternatively access the Objectives directly from the Inventory Grid: Thank you.

Hey Greebo Thought you might appreciate this -

@stgatilov, here is a release of the generated .po files with the *existing* translations for every TDM language in all.lang Generated_po_files_Oct_14_2026.zip The zip file has this content: [from_all_lang_to_po_v0.12] all.lang input file [with_chunking] tdm_main.pot, *.po, comand_line_output.txt [with_long_lines] tdm_main.pot, *.po, comand_line_output.txt [poedit_3.10_resave_with_po_tweaks_&_mo_gen] [from_chunking_with_poedit_wrap_on] tdm_main.pot, *.po, *.mo [with_long_lines_with_poedit_wrap_off] tdm_main.pot, *.po, *.mo [draft doc] Generating POT & PO Files and their Headers.docx The data for chunking and long-lines is equivalent; just the internal file structure differs. When opened in PoEdit, the .po files generally exhibited some problematic rows, which PoEdit moves to the top. Typically, there were a handful of warnings (in yellow) and 1 or 2 severe errors (in red). On purpose, these are not corrected in this release. Each .po file was saved, which can alter the internal file structure & header (i.e. "PO tweaks") but not what is shown visually. The saving also generated a .mo binary file. For files with red errors, during save you get a warning that the "MO file probably won't work". Many of the red errors were due to strings that had printf format specifiers (e.g., "%i"), and where the number of spec fields in English differed from that of the translation. Since the same culprits turned up across languages, perhaps the translations were right at one time, but now stale after code revisions. Only languages without red errors at moment are: russian, turkish, and the overwhelmingly-incomplete dutch & swedish. The draft Word doc supplements (i.e., not an update) the draft doc in my earlier release above.

This is likely in part due to the bannings by Darkplaces and Xonotic concurrently some years ago. That hit Mircea very hard: having put much of their life into _programming_ for BOTH of those projects, as well as alot of 3d work etc. For free. I, to this day, use Mircea's work: the extra hit effects client side. More recently was ported over the digital-read-out-on-weapons-models (like UT 1999) code that Mircea created for their fun vore-tournament mod. Mircea was visciouly rejected by the (so-called) Darkplaces and Xonotic communities after working for _YEARS_ for them: they decided they did not like something Mircea tweeted years before. Those people are the true enemy. To this day they make fun of Mircea and say "it was no loss" and they're glad Mircea is not working for them any longer. >was banned by unanimous vote from both the darkplaces and xonotic communities >behavior post-ban affirms our decision. i'm not a fan of cancel culture myself, but we just... don't associate with those kind of people, for reasons i sincerely hope you can appreciate... They laugh and mock Mircea to this very day. A person who did so much ACTUAL WORK for these people. >go ahead and google mircea kitsune and >there is a lot of negativity that comes up. theres your reasons for bans etc

Hmm i do have code for hardware occlusion culling but it would need to be converted from C to C++. This should help somewhat i guess ?. Distance culling could also be interresting. Perhaps the cvar could be set via a material flag.

I do have some thoughts. My original idea was to implement a simple renderer culling distance as a CVar and intercept the rendering process, but that raises a whole set of questions I can't answer, yet. For example, take a large building where part of it falls inside the culled distance, but part of it is outside that distance? What do you do? Do you render the whole thing? If so, it would most likely be the only thing projected beyond the cutoff point, and it would look weird. If you don't render it, a large structure would just disappear when it should be visible. Without a serious amount of dev kungfu to rendering process itself, a hard render distance is probably going to be a non starter, at least for me. There are, however, a couple of other interesting ideas I am playing with. One is the light/entity interaction system. During play, the renderer maintains "idInteraction" objects representing the relationships between a particular light source and the surfaces it affects. For example: Street Lamp -> Wall Street Lamp -> Road Street Lamp -> Wooden Cart Street Lamp -> Barrel Street Lamp -> NPC A single light source will make multiple idInteraction objects, each of which must be evaluated separately. If an object falls into the radius of multiple light sources, then an idInteraction object is created for *each* one. Just having the interaction defined isn't that big of a deal, other taking up some RAM. It is the evaluation of that interaction that costs alot from a CPU/GPU standpoint. As the amount of lights and the amount of surfaces in an area increase, so do the computations for that area. Hence, a large open area with lots of lights and things usually brings the system down to 10-15 frames per second unless the mapper does some design magic to control things. Shadows also play into this, which complicates it further. Since there is no distance culling, the bigger the area, the more likely of a performance drag. But with respect to this, there is an interesting possibility. Within the idInteraction class are a couple of functions to add an interaction and to create one as a deferred action. By implementing a new CVAR like "r_lightInteractionCullDistance", a very fast and quick check can be made from the camera to the closest part of that interaction. If it is outside that distance, don't activate it. If it isn't activated, it isn't calculated or rendered. This could add in a simple distance culling mechanism and I think it could be huge in performance. As I stated, shadows are an extra wrinkle here. The engine keeps some things around which are not directly visible because their shadows may project across the camera, even though the light source causing the shadow is not visible. This can have added ovehead, and again, this increases with the amount of lights in an area. There is also another option I have been looking into that could actually be better. That is calculating how much of the screen is being occupied by the object. A relevance factor, if you will. An example is a large building, say a Templar church, and it is 8000 units away. Maybe there is something needing to be frobbed on the ground about 3000 units away, like a potion. With pure distance calculation, the church would disappear even though it can be plainly seen, but potion wouldn't even though it is most likely not visible or very, very small. As part of the calculations, the screen projection sizes are already computed by the engine. It would be fairly academic to query the engine for the onscreen rectangle size and cull it based on if it is too small. I have been leaning toward this idea more and more as I run scenarios through my head. Things usually don't work out the way they are intended to in the first pass with stuff like this, but as I dissect the source more, it is what I think the better solution. In a similar way, portal traversal can follow the same idea - if the visible projection of a portal on screen is below a certain threshold, do not go through it. Basically, when the map is created, the compiler breaks up the map into areas, separated by visportals. This is actually a super important function because it provides hard separation between to disparate locations on the map. A closed visportal prevents the engine from searching through it for things that are beyond that "could" visually affect the current view from the camera. Much of the time, things behind visportals do not affect the current view in the camera at all, but if the portal is open, the engine will search through it every time, regardless. Good map makers (ahem...JackFarmer?) know how to use all the tricks in the book to force occlusion - doors, 90 degree turns, short alleys, tall structures that obscure, and visportals. Closing a door/portal immediately halts the search for anything past it from an engine standoint. But an open portal beyond an open portal causes searching into a third area which most certainly won't have any relevance to the current view. It can cascade from there because the engine will continue through all open portals it finds during that rendering pass. So, this is great for interiors, closely confined towns, etc. But a large outdoor space is harder. Breaking up a large area with multiple visportals is worthless since they would all have to be open to see the area in the first place. Interestingly, the engine does clip out the stuff that can't be seen behind a portal. But the problem is that it has to search through it at all to figure out if it needs to clip it. So, I am thinking another CVAR for portalScreenSize or something like that. If the portal occupies less space on screen than the size specified in the CVAR, then don't traverse it. As an example, assume the map is a long alleyway. At the far end is a portal that is only showing on screen as a 2x2 pixel square after it is rendered. That is something you wouldn't even really see, but the engine sure can. Because the engine can see it, the renderer goes through the opening to find a bunch of stuff behind it - lights, surfaces, etc. It then has to compute all of that stuff it finds through that little tiny opening because it "may" affect the current screen view. After everything has been calculated, it then just simply clips it out anyway because all of that stuff isn't visible through the portal or the 4 pixels it takes up don't change. All that work for literally no reason. I don't want to sound like I am putting down the engine - quite the contrary. I am amazed that anyone could come up with this at all. For it's time, this thing is a marvel to be sure. The renderer does do plenty of screen culling, to be sure. The engine could never achieve real playability if it didn't. It just doesn't do anything that is *distance* related, or screen size tested to determine that culling, and that is why large open areas die horribly: too many lights and surfaces to compute because it doesn't know not to. The last thing I have found, I am not sure how to handle/fix. In any area (as defined by visportals), walls and other things are not actually doing occlusion from a calculation standpoint. They block things visually on screen, sure, and this does go a long way in performance. It is also the expected behavior. I mean, lights shining through walls is a bit silly. But if you place a large wall in front of a light source, and stand on the other side where you can't see the light, the engine still has to check the idInteraction objects that the light it connected with to see if it is interacting with the viewscreen. Of course, it isn't, but the calculations take place because from the engine's viewpoint, it could. So those are my ideas for now. Finding the engine really fascinating. In many ways, it is much easier to understnad than the beast that is Unreal Engine. Obviously, it isn't nearly as mature and developed as Unreal but it wouldn't be realistic to expect it to be. In reality though, knowing what I know about UE has really made me appreciate it that much more. Bottom line is that all of these guys were geniuses. Incidentally, there are lots of good comments througout the source code - big time kudos to whoever did that. It would be very, very hard to digest this if they hadn't documented it.