the only visuals we had so far were not very impressive

Oleg keeps everything very close to his chest haltux but we can see where he may be heading. Remember how Oleg came up with a solution to large forests in Il-2 by stacking textures

No need for massive amounts of texture memory if you're using procedural shaders... cornfield shader one day

http://ati.amd.com/developer/SIGGRAPH07/Chapter5-Andersson-Terrain_Rendering_in_Frostbite.pdf

http://epubl.ltu.se/1404-5494/2007/12/LTU-HIP-EX-0712-SE.pdf

Ming

Thanks, Ming, now I know the depths of my ignorance has no bounds.





Lots of weird choices were made in RoF, some of them really good - like the speedtree(ish) fading in of trees to keep them all having to be rendered yet still be "solid" for collisions, and some kind of weird.

Errr, you clearly didn't read or understand the points Neoqb, Dart and I all made - which is that regardless of whether you're on x64 or 32-bit OS, the game can ONLY handle 2Gb of VIRTUAL memory usage.

It doesn't matter a jot that you've got a 1GB graphics card, 6 gigs of DDR3 in triple-channel mode. The game will still only use 2Gb of virtual (pagefile) memory, and when you overrun that you get the "out of memory" error.

I think ROF management needs to do some serious home work on this issue. Based on my experience the ROF designers have porked up the design if these restrictions are real.

I think what they may have done is given the implementation and the current performance testing then here are the best guess restrictions.

It may have been better to not post the restrictions until the rework was completed and new performance testing done unless they do not plan a good solution.

This reminds me similar discussion when FSX was first released. There were always people explaining that FSX was immensely more complex than any other video game (which could be partially true) and that this unavoidably makes the game immensely slower (which is nonsense).

When someone tells you that something that you don't see (like a plane 20km away) needs a lot of CPU time and that's why everything is necessarily so slow, it is either wrong or means that the game is badly designed. If you don't see it, if it does not interact with you, a realistic model is useless and therefore it should not require a lot of CPU time. This should be the basics of any simulation programming (or more generally any kind of "virtual world" programming).

No one requires that the bullet fired by a guy on another guy two kilometers from you on the battlefield is modelized in a realistic way. What people want is that their plane, their opponent's plane, their bullets and the bullet thrown at them are modelized in a realistic way. For the battle field, for ground units moving on the ground and fighting together, there is no reason to have more complexity than in Empire Total War (which is a recent game btw), so displaying a battlefield with thousands of units in RoF should not be more complex in RoF than in Empire Total War.

You are comparing a game that models very simplistic features for even the player controlled unit in front of him to an air combat simulator that is far more complex.

Just the processing power required for the planes in your vicinity is a huge hit. Have you tried a 20 vs 20 dogfight? It is modeling only what you see around you in your immediate vicinity. The computing power required to render an air battle is far more complex than a simple RTS, even a FPS, game.

But you're not talking about having a thousand units, only some of which are visible at any given point. You're talking about having a thousand units in use and visible - and unless you're using something like sprites that is always going to be a hell of a workload for either memory, CPU or GPU.

displaying a battlefield with thousands of units in RoF should not be more complex in RoF than in Empire Total War.

You'll need to study up a bit haltux (which will be enjoyable trust me) if you're interested in simulations generally, functions like geometry instancing mean that there may actually be only five or six soldiers on the table. The rest of the armies are smoke and mirrors

The computing power required to render an air battle is far more complex than a simple RTS, even a FPS, game

And then some Natty.

The soldiers are simple objects having no physics properties. No mass, no spring forces, no gravity

Faithfully modelling even a simple wing under the physics of gravity and wind, lift and drag, fluid dynamics etc needs far more CPU power than that needed to track hundreds of simple smoke-and-mirrors blocks around a tabletop

Physics is maths, maths is CPU. Simple maths, simple physics, simplistic simulation

Games v simulations it all boils down to.

Ming

Stop patronizing me. I know perfectly what you are talking about and you did not understand my point. I'll try to make it clearer.

It is a plane simulator. You have to make models of plane, physics of plane, AI, so on... This is complex, there is no such thing in games like Empire Total War.

Then you have to render the environment (like in ETW), and the ground units: soldiers, trains, tanks, so one. What you want from these ground units is that they behave in a way that looks good, in RoF or ETW (and honestly, even a fraction of the realism of ETW in terms of battlefield rendering quality would be great).

There is no reason why the physics of soldiers and tanks should be more accurate in RoF than in Empire Total War. The mirroring techniques used in ETW would be therefore perfectly suitable to render a battlefield in RoF. This is not more complex.

This is a plane simulator where a decent battlefield rendering would have been great. This is not a battlefield simulator where every moving object should be modelised and simulated in a realistic way.

I completely understand that:
- RoF has a much smaller budget than ETW
- Displaying massive amount of units was not the first priority for RoF

But arguments like "what you can do in a game cannot be done in RoF because it is a simulation" are nonsensical.

Hmmm, thinking of it ... remember the requirements are for multiplayer. Now, in multiplayer, the additional problem is that 'you' are not only in one place which should be modeled accurately, but also the other guys are in another places that should be modeled accurately, so this is what puts strain on the server. More players, more places, more computations for the objects on those places. Same for AI planes, even if they would fly based on a simple FM while you're not close to them, the chances to be close to them is higher in multiplayer. I'm not saying things cannot be optimized etc. but i think this is perhaps the bottleneck. If they want to present a *no-crash* solution, they would compute the worst-case scenario and base requirements on that. I don't think it really crashes everytime you don't respect the requirements, right?