Ohohoho! Is it possible to get a quick summary of these tricks (or a url link that explains them)? I'd imagine that it's some sort of trick where you render all the objects, take the depth data, and perform trigonometry-based pixel lighting on the UV Maps of the mesh, and somehow superimpose that on the buffers?
On a different subject, I did a bit of talking with Zilav and Sheson, about batching static objects (e.g, a boulder, a house, the rock objects used to make a mountain, etc.) that aren't referenced by scripts and aren't linked to any enable/disable functions, so as to reduce draw calls and increase performance, when used in conjunction with TES5LOD's atlas code.
I'll copy paste what I sent to Sheson. Basically explains, in detail, how the batching would work:
Essentially, it would go as follows, using the information and pre-existing code used by LODGen:
Make a list of all object references in the game, sans the directly interactable objects. For example, the model of a house, a road sign, the cobbled roads, Whiterun's walls, etc., would make it into the list. This list would be organized by the objects in a cell (or make a new list per cell?).
What wouldn't make it into the list, would be things such as a bottle of mead (an item the player will "remove" from the game world when picking it up), a door to a house (since it's animated), a movable static skull (responds to player interaction), that sort of thing.
Then the objects in the list are scanned, to see if they are "used" in any shape or form, so as to prevent things such as a house object being batched, when that house is disabled/enabled by a script, since that'd royally mess things up.
Once those are expunged, the final list will be processed. The objects in a cell would have a mesh instance arranged from the center point of the cell being 0x 0y and 0z. The mesh instances will have copy the position of the original object reference, with the positions changed to accommodate the center point in the new batched mesh; exactly the same way that the LOD meshes are generated.
Then the textures are atlases, again, exactly in the same way that the LOD textures are atlased. Perhaps, rather than having a unique texture atlas for each cell, several master texture atlases are generated, that the batched meshes will use? Might be of benefit in terms of GPU "device changes", as well as RAM/VRAM usage.
Once that's done, the batched mesh is placed in the appropriate cell, and the original objects are moved to a dummy cell, to prevent them from being rendered along with the new, batched mesh, as to have them being rendered would defeat the whole purpose of this.
The main roadblock, is that an object can only have four lights affecting it. Here's what he had to say on the matter:
The question would be if Boris or anyone else could fix the lighting engine limitation of 4 lights per shape. Without that, lights shining on these large meshes will flicker if there is more than 4 per shape - the larger they are the more likely that will happen.
Any insight on whether or not that can be resolved? Or is it too ingrained to be patched?