And that helps exactly what if the CPU is limiting?

Right, absolutely nothing.

As for who is buying a racing sim for a console without analog triggers and steering wheel (accurate steering wheel not fumbling with the gamepad gyro)?

Likely almost nobody. The lack of analog triggers was the main reason i never intended to buy the Wii U version in the first place.

Since Occlussion Culling and Frutrum were made for saving draw calls its obvious that this will save CPU resources as well as GPU, and using compute shaders so that part of the physiscs will be handled on GPU instead of cpu can also help

https://software.intel.com/en-us/articles/how-to-plan-optimizations-with-unity

"

Occlusion Culling

Occlusion Culling disables object rendering not only outside of the camera’s clipping plane, but for objects hidden behind other objects as well. This is very beneficial for performance because it cuts back on the amount of information the computer needs to process, but setting up occlusion culling is not straightforward. Before you set up a scene for occlusion culling, you need to understand the terminology.

    Occluder – An object marked as an occluder acts as a barrier that prevents objects marked as occludees from being rendered.

    Occludee – Marking a game object as an occludee will tell Unity not to render the game object if blocked by an occluder.

For example, all of the objects inside a house could be tagged as occludees and the house could be tagged as an occluder. If a player stands outside of that house, all the objects inside marked as occludees will not be rendered. This saves CPU and GPU processing time.

Unity documents Occlusion Culling and its setup. You can find the link for setup information in the references section.

To show the performance gains from using Occlusion Culling, I set up a scene that had a single wall with highly complex meshed objects hidden behind. I took FPS captures of the scene while using Occlusion Culling and then without it. Figure 17 shows the scene with the different frame rates.

Figure 17. The image on the left has no Occlusion Culling so the scene takes extra time to render all the objects behind the wall resulting in an FPS of 31. The image on the right takes advantage of Occlusion Culling so the objects hidden behind the wall will be rendered resulting in an FPS of 126.

Occlusion culling requires developers to do a lot of manual setup. They need to also consider occlusion culling during game design as to make the game’s configuration easier and performance gains greater.

"

Here is another example using culling for objects taht are distant to us

http://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html

"

LOD and Per-Layer Cull Distances

In some games, it may be appropriate to cull small objects more aggressively than large ones, in order to reduce both the CPU and GPU load. For example, small rocks and debris could be made invisible at long distances while large buildings would still be visible.

This can be either achieved by Level Of Detail system, or by setting manual per-layer culling distances on the camera. You could put small objects into a separate layer and setup per-layer cull distances using the Camera.layerCullDistances script function.

"

You can find other solutions in this page that developers of Project cars can use, in fact i forgot to mention and even better solution if the game is cpu bound

"

Batching

Having numerous draws calls can cause overhead on the CPU and slow performance. The more objects on the screen, the more draw calls to be made. Unity has a feature called Batching that combines game objects in to a single draw call. Static Batching affects static objects, and Dynamic Batching is for those that move. Dynamic Batching happens automatically, if all requirements are met (see batching documentation), whereas Static Batching needs to be created.

There are some requirements for getting the objects to draw together for both Dynamic and Static Batching, all of which are covered in Unity’s Batching document listed in the references section.

To test the performance gains of Static Batching, I set up a scene with complex airplane game objects (Figure 21) and took FPS captures of the airplanes both with batching and without batching (Table 8).

"

Have you actually read about the SETA tire model and other stuff?

That is the actual problem. It's not the renderer. Maling a smart guess SMS uses a lot of that stuff. AA is basically optional. Well, for PC. So again a guess, they only use post processing AA for Wii U already.

Those Batching and and Occlusion Culling benchmarks where under perfect conditions by the way.

That still doesnt help with to demanding physics and stuff like that. SETA uses a FEM simulation for the tire carcass as well as two other parts. For every tire. That is quite demanding.

Yes, I have read about it, thats why i am proposing solutions to reduce stress on the cpu and gpu as much as possible sand make the 30fps possible despite the strain cuased by the physics

Of course that the only way to know which solutions are they already trying is to see the source code of the game. but occlusion culling is is not that widely used as frustrum culling, and maybe they could have missed batching as the game is a port from pc and we know that optimizations from pc are oftenly skipped(expecting pc gamers to solve it by buying powerful harwdare). And again, they mentioned that they could reach stable 30fps with some effort, not that it was impossible.

Yea, probably the benchmarks were done on perfect conditions but look at the numbers, even in the worst conditions do you think is impossibel to get 7fps to reach the 30fps?

And i am not making assumptions, there is already a developer who used occlusion culling to keep the 60fps on a game

Do you want to know who?

here

@HylianCIA Yes, without Occlusion Culling 60fps would be impossible in dense areas. It also takes a lot of strain from the CPU.

— Shin'en Multimedia (@ShinenGames) July 3, 2014

Of course that the easiest solution is dynamic frame buffer so that resolution will change instead of the frame rate durign gameplay like what sony did on Wipe Out HD to keep stable 60fps at variable 1080p(resolution could go as down as 1280x1080), from what eurogamer says the chnage is not that noticeable due to the nature of the game

http://www.eurogamer.net/articles/wipeout-hds-1080p-sleight-of-hand

"

Sony Liverpool's WipEout HD is the first big game for a while to be touting true 1080p credentials and regardless of its technical prowess, it's stupidly good value at GBP 11.99. It's also a superb technical effort, great to play and accessible to a level that recent releases in the series have failed to achieve.

And 1080p? True 1080p? Well yes. And no. OK, most of the time, it is. I mean look at these shots... scrutinised and measured by the ever-reliable 'Quaz51' who cast his expert eye over a number of Digital Foundry TrueHD 1080p captures:

There's still something about Ridge Racer 7 that makes it a phenomenal 1080p game, but there's no doubt that WipEout HD is the better-looking 1920×1080 effort with some beautiful shader effects and excellent art direction. But what's going on the two shots below?

They're not 1080p in the sense that the resolution is no longer 1920×1080. WipEout HD is now rendering at 1280×1080 (with some screen tear to boot), which I'm fairly sure is the game's lowest resolution - but still a 50% resolution increase over 720p. So what's happening? Basically WipEout HD is the first game I've come across that seems to be operating with a dynamic framebuffer.Resolution can alter on a frame-by-frame basis. Rather than introduce dropped frames, slow down or other unsavoury effects, the number of pixels being rendered drops and the PS3's horizontal hardware scaler is invoked to make up the difference. It's an intriguing solution that works with limited impact on the overall look of the game (the tearing has far more of an impact on image quality - I'm assuming that kicks in when the framebuffer can't scale any lower).

The actual amount of horizontal resolution being dropped can change on a frame by frame basis: 1728×1080, 1645×1080, 1600×1080, 1440×1080. All have been seen in the Digital Foundry TrueHD captures. The shots above appear to be 1500×1080. The dynamic framebuffer is really quite an innovative solution to the perennial 1080p problem. Even though we're seeing major differences in resolution, the human eye really will have trouble realising the difference when the detail level is changing so rapidly in such a fast moving game.

"

Of course that a variable resolution would be the last option i would like them to take, i hope they try occlusion culling and batching

Games like Mario Kart & Smash Bros are still showing legs and getting a lot of play time, especially since both have just recently received DLC. Don't forget that Wii U does get a lot of indie games along with constantly adding games to the Virtual Console and people who have bought a Wii U recently may be buying previously released games so it's not like there's nothing to play.

Right now I'm playing on my One most of the time. Basically played through my Wii U backlog, don't like Smash Bros so WiiU is for occasional MK8 online.

I wont buy Splatoon for some time if at all. Not yet sure. So the next two games will be Yoshi and Star Fox. FAST Racing Neo if I'm lucky and it comes out some time soon.

That isn't that much. It's actually very few.

@megafenix: SMS has enough console experience. And the PC version isn't that demanding. At least without AMD GPU. That's a problem with the driver though which causes massive overhead. The existing console versions don't have that problem and AMDs DX11 drivers are known for that problem.

So once again just a guess but I think their engine supports all those features. And the engine itself already ran fine with 360 and PS3 as well as low end PCs years ago.
Problem is the tire simulation itself is resource hungry and there are other things ad well. There's a lot to read about that at WMD. So it really seems they'd have to charge so many things aWiiU version wouldn't be the same.

Dont forget, you are also guessing, and even if the engine supports the features doenst mean they are using them(is like you are suggesting the engine can even create characters on its own) and my guessings are based in experience and common knowledge, well, at least for programmers. If project cars developers prefer to squeeze the wii u specific features to alliviate the cpu and gpu strain then its their choice, but wouldnt hurt to use these other options, specially if they missed things like occlussion culling or batching; of course that the dynamic framebuffer is almost sure they havent even cosnider it

As for the engine running fine on ps3 and 360, why do you think the versions were cancelled?

Arent we being anti nintendo putting wii u on the same league as the older cp¿onsoles that are limited to DX9 capabilities?

http://playeressence.com/ps3-and-x360-versions-of-project-cars-cancelled-coming-to-wii-u-ps4-xbox-one-and-pc-in-fall-2014/

"

PS3 and X360 Versions of Project Cars Cancelled – Coming to Wii U, PS4, Xbox One, and Steam OS in Fall 2014

Slightly Mad Studios has made the big announcement that Project Cars cancelled the PS3 and Xbox 360 versions of Project Cars. And will opt for Wii U, Xbox One, PS4, Steam OS, and PC versions only. The firm has stated that they have set the new standard for simulation racing with Project Cars.  

Studio lead Ian Bell made a short statement on the Project Cars.

“Project CARS has always led the pack in terms of insane detail. Whether that’s graphically in the craftsmanship of our cars and tracks, technically in the way we’ve approached weather and time of day, or emotionally in how each car feels and responds to your touch. These powerful new platforms allow us therefore to not compromise on the quality of our vision and ultimately that means players are going to experience something truly breathtaking when they get behind the wheel.”

"

One of the reasons the ps3 and 360 is that besides lacking new graphical features found on dx11 and opengl 4 is that they didnt support multi threading rendering(wii u supports it and was confirmed in one of the project cars wii u version builds) which is imprtant for framerate, meaning that 360 and ps3 would perform even worse than wii u due to this hardwrae limitation

Is not that Wii u cannot run it with the physics enabled, its that they are facing problems to reach the 30fps and by now they have reached 23fps, in other words, they need 7 more frames, and achiving it with occlussion culling(for shinen fast racing neo game it worked) or batching or any other method is possible. I would understand if the wii u wouldnt be able to even run the game, but if they have managed 23 fps of the 30fps then there isnt that much left to reach the goal, may be difficult but thats why there are tool options like the ones mentioned

The engine is the same Madness engine already used for SHIFT, Test Drive Ferrari and SHIFT 2.

Occlusion culling is really nothing new. It was in the early 2000's. AFAIK most (bigger) PC games use it.
Hell, Cry Engine uses multiple culling techniques by default, though some have to be optimiesed at hand for the best performance.
So i'd basically bet they have culling techniques. Without reading through their tech docs in the WMD forum.

For the fps side, you are missing something. They actually need more than 7 fps. Which would be a 30% increase.
They have an average 23fps. With much lower framerates as well. They'll need to not drop under 30fps for a at least good playable racing game.

That might look as good or better than SHIFT 2. But it still wouldn't work with SETA and other demanding stuff.

So no leaderboards for Wii U. Probably no weather or at least no dynamic weather. Less cars offline and probably online. This is a real current gen game and though Wii U has a current gen feature set it has far less power than the other devices.
Then there's still the question who would really buy that.

Batching isnt actually new either.

and fixed shaders are new?

How many people still use them?

If there is something we have learned this generation is that companies wnat to laucnh a game as fast as possible without doing to many optimizations to earn the best profit possible(look at all those games with bug, even the acclaimed witcher 3 is facing many troubles). Even if the engine supports it developers still have to do tests and improve the occlussion culling in certain areas, not everything is automatic, and if its is normally is inefficient compared to doing manual adjustments. The concept is the same as low level programming vs high level programming, the first giving best performance possible and the other making life easier for the developers in exchange for performance.

And is not 30% increase, its 23.33%

look

30fps = 100%

7fps= x

x= 7fps*100 / 30fps

x= 23.33%

By looking at the benchmarks(even with worse escenarios than the examples) we can see that some optimizations with the occlusion culling here and there and some batching then they could indeed reach the 30fps, and if they are in a hurry they can always mix these solutions with the last one i mentiond, the variable resolution used in Wipe Out HD, that way even if there are occassion with bad framerate the resolution will be the one that would drop instead

percent calculation my friend.

It's 23% less than 30fps. So 23fps is a 23% decrease over 30fps.

At the same time 30fps is 30/23*100%=130.43%
130.43%-100%=30.43% increase.

Or 7/23*100%=30.43%, again.

It's like Xbox One having 29% shader power less than PS4 but PS4 having 43% more than Xbox One.

No offense, but i've seen a load of poeple with problems in percent calculation.

Now for the other stuff.

Pretty much every major title uses some kind of culling today. That was an issue in pre-DX8 days when routines for such things wheren't supported in hardware usually and had to be written by hand.
ST Kyro (Power VR based) was well kbnown back then for very efficient hidden surface removal because of it's then new tile based renderer. Without hardware T&L it could be faster in many games than a Geforce with higher fillrate and hardware T&L.

Draw call batching is commonly used by game engines, often by default. It's optional in Unity though. There is no perfect batching. Seems like batching for Anvil was changed multiple times which is one of the reasons why later entries had less issues where AC1 and to a lesser degree AC2 had framerate drops.
CryEngine uses batching by default. AFAIR all the planes in the Unity scenario would be rendered in one batch automatically because they use the same materials.

Now for Anti Aliasing:
pCARS (PC) uses selectable FXAA, SMAA, MSAA and downsampling. Console versions use EQAA, but with the slightly older Wii U GPU and less power i am pretty sure they went for either FXAA or SMAA only already.

You are making the guess that they don't use draw call batching at all because of Unity. That is without reading documentation of other game engines i'd guess.
Same for culling.
I'd recommend you to at least read the CryEngine and Unreal engine docs.