motorsep

Right. When I press the button, it jumps instantaneously into another "room", just like the one spawn in. The idea is that I can put a trigger into the tunnel connecting the "rooms" and as I pass through, sun jumps and it would feel like I have one massive sunlight that covers both "rooms". One of the reason I did that is that I am working on dynamic day/night system, and the whole system will be bound to a root entity that will jump between areas (having parallel light per area will make it too complicated and I don't really want to make pipes :/ ) No, dmap has nothing to do with it. If light is static, it's flow is restricted by portals, to my understanding. As soon as light moves, portals stop blocking the flow. So I am thinking that due to visportals, that are on the open, static lighting breaks. I can manually delete shadow model from the .proc file and the same issue will still be present on the map, meaning with dynamic shadows light flow will be limited. We have both shadow volumes and shadow mapping, but they are mutually exclusive. So when I run with shadow maps, all shadows are fully dynamic. Prelit shadows aren't used/rendered. I forgot to test it with shadow volumes, but I have a feeling no one will run the game with them

Bam! Solved! All I had to do was making light dynamic. So what I came up with, empirically, is this - apparently there is a limit on how many interactions/interactive surfaces can be per leaf. If there are too many surfaces (tris) per leaf, only certain number of surfaces (or even tris) get lit. Maybe that's why dmap merges inlined meshes into one surface (based on material). A leaf can be huge and has only few surfaces and it will work well. It can be small and choke full of tris - corrupted surfaces will show anyway. So I am basically chopping tree into more leafs, distributing surfaces between them. Each leaf gets only so many interaction surfaces and as a result it works well.

Now that is true - compiling Linux-based apps on Windows is a bigger horror than building so-so made Linux apps on Linux. That comes down to using too much of the 3rd party libs. If DR would only use Qt/wxWidgets, compiling on any OS would be a breeze. But it uses Boost and some other stuff, so it's makes it really hard to be friendly to Windows. For example, Darkplaces engine and RBDoom 3 BFG and Dhewm3 were made to use almost no 3rd party libs, and cmake, and they compile easily anywhere. GIMP migrated to Windows from Linux, and it's royal pita to build it on Windows. Same goes for Blender. Now Blender is moving to cmake, so it should make it a bit better/easier. Note I had issues building newer GIMP and Blender on Linux, since they used libs that don't come with my Ubuntu install.

I used Linux (Ubuntu) and Windows. I am currently on Windows 7 Pro 64bit 99% of the time and I prefer Windows to Linux any day. Both OS have their bright sides. However on Windows I simply work and do my thing, while on Linux it's always struggle to build stuff making sure all dependencies are updated. Some of those need to be build and that requires more dependencies to be installed/built. That's the part I can't stand about Linux. There are apps that designed properly and they just compile, but most of the apps are horrible on Linux. It requires too much effort to get working. On Windows it just works. Never had any issues with video drivers, after I removed that Noveau crap and installed manually Nvidia blobs. As a matter of fact, video games run 10% faster on Linux (idTech based games at least). Note that gaming market share for Linux is tiny and doesn't grow. Valve's SteamOS might be just a PR move, since it hasn't been advanced in a while, plus Steam Box hasn't even materialized yet. Stability wise I'd say Ubuntu and Windows 7 are equal.

A small breakthrough - apparently number of interaction surfaces / tris is limited per area. I split each of the "rooms" with 3 visportals ( ||| - in such manner) and I no longer have corrupted model surfaces on my 3k+ of entities . However, the issue with light not passing through those portals persists (and solution with tubes isn't acceptable as areas get connected as if there are no portals, and I am back to square one with corrupted mesh surfaces). I wonder if there is a way to keep portals closed when the maps is being loaded, and then "open" them so that the light floods the map (this way interactions are created without corrupting meshes).

You (or someone else?) said SEED is _slow_ Did you implement actual instancing to clone models? Supposedly RAGE does it the same way, but on a separate thread. The issue that I have with this is that the engine culls on per surface basis. So if you have one massive surface and part of it is in the view - it won't be culled. So it will be drawn even if you don't see most of it. That's why I question the need to merge surfaces into one. My test case with ~13M tris shows that LOD is twice as fast than no LOD. And I am not doing any merging. It would be nice to investigate what's really happening with culling and batching in idTech 4 :/

ETQW engine was a significant step ahead of idTech 4 in Doom 3. That's why I was in line to be released next as GPL. Maps are still not big there. Even RAGE had maps which had walkable surface withing +/-32k (or that's what I was told by ID). Moving world's origin at player's coordinate won't fix any issues. Player needs to be always at 0 0 0 and the world needs to "scroll" under. Or the world needs double float, which is not trivial to implement in idTech 4, and not only because everything uses common matrices (rendering and physics and coordinate system do at least). Anyhow, rendering was improved, megatextures were improved, networking, multithreading got better, AAS was reworked, etc.

Well, there are two issues happening - interactions with brushes (culling of lights at the visportal boundaries), and interactions with meshes (partially lit triangles, non-lit triangles). So, there aren't conflicting results per se I also tried the same cases using RBDoom 3 BFG before shadow mapping was added, and after. Same issues. So that ruled out us potentially messing up renderer with our implementations. 1. I tried it and had same issues. I might have forgotten to reset light center, so I will try again. Shadow mapping supports point lights well and I still have shadow volumes working, so I usually test both ways, and the results are identical. 2. It's actually other way around - origin needs to be inside, otherwise map leaks. Light center can be outside, and here is the result: I think that zfighting is the result of my ceiling skybrush casting shadow, since the light direction goes from light center to the origin. 3. That looks interesting and as I dig into it I will definitely have a lot of questions I am testing that new visportal setup you recommended ( |||| a la slices of bread). Will report as soon as I have it compiled. EDIT: It seems that there can only be one parallel light per map. Although I might be wrong. @SteveL: I see you are using portal sky in the Moonlight map. What if I don't use portalsky at all? Will it make any difference ? (not to mention portalsky in idTech 4 is massive hack that chops down performance)

Is fog lamp being blendlight as good as normal fog lamp, but with less performance overhead?

Found interesting detail - if I keep only one parallel light, I don't have the issue with brushes not being lit. The problem is that I can't stretch one sunlight to light up both areas. Might have to use a hack - script that moves sun light to a new outdoor area :/ Blocking tunnel with brush doesn't help at all - one room becomes pitch black.

Is there a way to supply config with hotkeys for DR along with .game file, so that end-user launches DR having not the default setup, but customized one?

In the light of recent events unveiled while testing LOD system, it seems that after all, having massive open levels in not possible with neither idTech 4 nor modified BFG engine. It could be some limits set in some tricky manner or ultimate flaw in the rendering engine design (even Darkplaces engine can draw so many triangles over massive outdoor levels without having artifacts). I still do need "big open" level for the game. So I was thinking that having hub structured levels would be a good solution. That would allow me to split my "open world" into smaller hubs, and player would be crossing over (that's to short map loading times in BFG engine it shouldn't be too horrible). Is it easy to implement hub structure with idTech 4 ? How would I go about implementing it ? Thanks!

Here is my top-down layout: I'll try blocking tunnel with solid brushes, and also will try moving lights so they won't overlap. Fun fact - I tried my 1 room test with RBDoom 3 BFG build without shadow maps and with shadow maps and it has exactly the same issue (although a bit worse than our engine).

Yes, the sharp boundaries on the floor are exactly where visportal planes are. My lighting setup is simple - one large ambient light, and slightly offset from it one parallel light. 2 lights per "room", so to speak. Moving parallel light doesn't change the issue at all, unfortunately. Despite how it seems to be in theory, visportals cutting up map was advised by Brian, nontheless. Empirically, having no visportals on the open map vs having them reduces map compiling time significantly. It also doesn't cause any artifacts or issues or performance effect with regular polycounts. The only reason I am having this issue is due to massive amount of tris and surfaces in the scene. Note that the first level shown on the video is exactly the same setup as the second level. The only difference is that instead of 1 room, there are 2 rooms (I copied original room with the same setup, including visportals, and connected the rooms). So to summarize, there is no performance hit at all whether I have visportals or not. Shadows have no effect on artifacts - I can load map with shadow volumes, or without shadows at all - it will still be corrupted / half-lit. Shadow maps, just like shadow volumes, are created for LOD1 iteration and don't change when LOD iterations are switched. Shadow mapping has its own LOD system. I also tried having noSelfShadow flag, and that didn't do anything either. As a matter of fact, if I replace LOD entities with standard func_statics, I will have exactly the same issues. The only way to remove artifacts is to reduce total polycount of the scene. Even if I have small rooms cut off from each other with vis portals (with doors or S-tunnels), there issue is still the same - total polycount / surface number matters. func_portals? Doom 3 doesn't have that as I recall. However, in S-shaped tunnel you don't need func_portals (whatever they do). I can see with r_showPortals 1 that the corridor between 2 rooms is shut closed as portals are drawn red. The video I linked in the first post shows layouts for both maps, one- and two-room setup. I can upload map too, just it won't have any textures / models.

There aren't really any idTech 4+ resources left where knowledgeable people hangout, so I am asking in TDM Support forum, sorry (and maybe in the future TDM would migrate to Storm Engine 2 anyway ) I have two rooms, ~56k x 42k units, with ~3200 func_statics (each has 4 LOD meshes, the lod1 is ~2.5k tris, lod2 is ~1.2k tris, lod3 is ~800 tris and lod4 is ~80 tris) both rooms. I also split the room with visportals so it's faster to compile. 2 lights - ambient and parallel (in each room). Rooms are connected with a zigzag tunnel with visportals inside. If I have it as-is, I get what you see on the screenshot - the sharp boundaries of the light is where visportal planes are. The bright green surfaces are fine, the dark green are corrupted ones. If I have only one room (same setup, just twice less entities), I get no issues at all. If I have two room, but replace func_statics with regular non-LOD models, I get no corrupted surfaces on meshes and more area on the map lit. As if there is some limit on total polycount and/or on number of surfaces per map. Does anyone (most likely SteveL, greebo, OrbWeaver, Tels and revelator; sorry if I missed someone - just have't seen anyone else deeply discussing / digging the rendering engine) know why is this happening and how to fix that ? EDIT: video

Looks like shaders magic

Ok, apparently there is some tricky hardcoded total polycount limit in BFG engine. Instead of going all crazy with 13M tris, I reduced polycount per entity (highest LOD iteration) to ~2900 (since it's just suppose to be rocks and foliage) and now I have no issues. Having LOD is still twice faster than bruteforce rendering, so I assume engine still batches surfaces in runtime based on matching materials. The sad truth that idTech 4 / BFG is definitely not an outdoor engines. I tested my massive outdoor map with LOD entities and issue with corrupted surfaces popped up again. Maybe splitting terrain into smaller enclosed sections, connected with tunnels and having vizportals should do the trick.

Not that I remember.

Not sure if you saw this already, but (TAB related): http://goo.gl/zUnzDW http://msdn.microsoft.com/en-us/library/system.windows.forms.control.keydown%28v=vs.110%29.aspx

Apparently it works for GUI surfaces. I have 2 of func_statics made with GUI surface and regular brush for each, and dmap writes them as separate "models" into .proc file (2 "models", each contains brush surface and gui surface), while the rest is shoved into another "model" (even though there are discrete surfaces there). I am thinking maybe our dmap port for BFG engine is lacking something. I would have to test it with stock idTech 4 dmap to confirm.

So, modifying how dmap sorts out surfaces and saves them per "area" is how it should be done. I did that manually and it worked like a charm. Did some performance testing last night with LOD. 24k x 24k (or something like that) flat open level with models totaling 13M tris. Only tested with LOD meshes so far and got pretty descent performance (55 fps w/ 12ms on GPU with distance of 1024 to the first high poly LOD; shorter distance results in 60 fps and ~8ms on GPU). Next step is to replace all LOD entities with regular func_statics containing mesh with LOD1 polycount. The goal is to see whether performance is comparable or if LOD approach still fares better. The question is if the engine still batches meshes based on material on runtime, and even if it doesn't (as I was told it merges surfaces on map load time) I gotta see whether LOD is still a better approach than bruteforce rendering of high poly meshes.

I see, now I get the issue. Didn't have such case yet myself.

Oook, "discrete" doesn't do anything with .proc - it seems that it only works for rendering. So, no matter what I do (and I bet I do it wrong), dmap gets all the surfaces and saved them as one.

Got it. Sounds like inlining and current limits are the only solution for variety / performance, until someone comes up with implementation of entities that are treated as geometry and nothing more.

I would think we aren't in 2004 anymore.. How much RAM would 1,000,000 entity array would "eat" ?