Fully dynamic lighting actually uses less memory than static. Static lighting for big levels needs baked lightmap data for every surface and/or large grids of precomputed light probes. Fully dynamic lighting on the other hand only calculates the lighting for the currently visible viewport. The goal here is to only process things that affect the surfaces seen in the single image (since lighting is recalculated every frame). A good fully dynamic lighting solution thus doesn't want to generate/use huge data structures (and couldn't even afford spending clock cycles and memory bandwidth generating them over and over again every frame).
Better post effects and more transparencies are mainly consuming clock cycles and memory bandwidth. You don't need more memory for those. You need better performance.
I agree that less static environments would consume more memory. Especially if the environment changes are permanent, and especially if we have more fine grained control over the environment (can break/modify terrain/objects in various ways). Current gen games tend to remove all marks of destruction/bodies/shrapnel very fast. But the biggest thing that more memory brings is ease of development. With small memory you need to stream in/out everything rapidly (just in time). It's hard to create algorithms that predict things properly in all scenarios (since HDD data seeking is slow, and popping isn't desirable). Of course the bigger memory allows more variety in the game world (less copies of the same model/texture are required, more unique models/textures are possible).
Sebbi, It´s always good to hear you talk, but my case talks specifically about Rage, I know your engine uses both Virtual textures and fully real time lighting, but my point was specifically about Rage. Their baked Lighting and GI does not require an aditional lightmap, as the lighting is baked into the diffuse textures themselves, since with their tech even when repeating a texture it is stored as a duplicate in their Global Atlas, every texel is indeed unique, so there is no need to separate lighting from it. Regarding their lightprobes, if they are not too sparse, then they just must be very bad, because they just seem to be very low frequecy to me, and I see lighting on dynamic objects change very little as they move about in space. If they wanna have many shadowed lights for example, that does not require tons of memory, but if you don´t have to worry about it, there are many optimisations that can be done by reusing shadowmpas from the past frame that are impossible if you are reusing the same texture for all shadowmaps for example. If we are talking next gen, we could expect some sort of dynamic GI maybe, Precomputed or Voxel Based, both would take memory if they were to be chosen.
What I´m trying to say is Rage´s engine can do a lot of stuff with more memory. Not just better texel density, which is far from ideal at this point, but through more complex materials too. How about multi-layered stuff like wet surfaces or specular coating over glossy surfaces with two normal and specular maps per texel, or coloured RGB specular, heighmaps for POM or Tesselation, SSS maps, animated textures, and again, transparancies which are bottlenecked by fillrate and bandwith way before by memory, but sill, they destroy any constant texel/pixel ratio... Jeez there is a lot of places to spend those Gbs on. Good PostProcessing, although pushing processing time way more than memory, will still require aditional data in your G-buffer if you really wanna be fancy. That still won´t need Gigabytes worth of memory, but at 1080p, it can add up. Sure, all that could be sorted out with 4Gigs or less anyway, but it comes down to ease of implementation.
No need to chase after the median average of Steam users to justify development costs of the PC version.
