looks like lee is working hard on another update.
https://forum.game-guru.com/thread/217811

I did see in one of the threads that lee done a whisper of 64 bit.
to come, mabie soon, looks like the new update he is working on now
is quite a big update,

Yes, 64 bit.

yes please 64bit will be amazing

Wait - are there still gamers and game devs using 32 bit?

Lol - yeah bring on 64 bit.

Reliquia....

You'd be surprised how many gamers are still using 32bit, 64bit has been around for quite a while now, but games have only been utilizing it for a short while now because of the amount of people that won't move on from 32bit. It's a topic i see on almost every MMO forum, people asking why there's no 64bit client, and devs explaining there are too many 32bit users around still to warrant it.

I severely doubt that GG can be "converted partially" to 64 Bit.
Maybe, it is possible to have the editor or the lightmapper in 64 bit , if it is external, (oh, great!),
but almost certainly not the engine)

And converting a nontrivial program to 64 bit is a meanie in itself. Look at other forums of well known engines for reports from those who tried (and initially thought: Oh, it's just the 64bit switch I have to thow).

I also doubt that TGC has the capacity to maintain a 64Bit version alongside the 32 Bit version.
Not sure how many users TGC would have to drop to "go 64".

At best, Lee could probably create a "Fin de siécle" 32-Bit version, "largely free" of all errors known to the GG community.
I guess, the latter would practically be a precondition for a move to 64 Bit, anyway, to have a starting point not already loaded with hereditary problems.
Just my 2 cents

There are not many 32-bit ONLY users left out there in Steam land. I had considered dropping 32-bit altogether should I embark on converting the engine to 64-bit. I have already removed XP and Vista from the minimum specifications of GameGuru as they represented less than 2% of all Steam users, and represented a great deal more queries than 2% I figured a similar ratio with 32-bit operating systems. I can say the conversion is possible, but it will probably not result in more performance or better-looking games. It will result in LARGER games and larger levels, more stability and less crashing. It will also have a good marketing point as it's felt that 64 bit is better than 32 bit, just in general non-specific terms. Curious to know if anyone here relies on 32-bit only hardware right now? For obvious reasons, you can appreciate why I would not want to run two parallel developments for 32 and 64

The last report i read that Microsoft issued (just after release of Windows 10), they stated there were still in the region of 70 million 32 bit users. Granted a good chunk of them are IT departments in companies that refuse to change. Which is why they launched a 32bit SKU for Windows 10.

I imagine the extra memory alone would transform how varied and hence better looking a map can be. Probably not a massive performance boost if any though as you say, but more memory is always useful probably not a priority but always good to look to the future.

I second that, DVader, the most interesting feature is the larger memory space to work with., followed by the marketing aspect for GG.

Although I recently noticed that my own little pet project's map had to be reduced a lot to cram an innocently small looking part of the real world into GGs map space, I would be wary to ask for much larger maps or even advertise that GG64Bit can create "real big worlds now".

Such worlds need to be populated to make sense to the player, which in turn means more .... attention to performance problems.
I remember a discussion from another forum where one participant firmly requested that the limits be raised to "what he needed"; a quick calculation check revealed a size into which either the whole of real Cambodia or Korea (don't quite remember which) on the basis of 16 by 16 meters tilesize could have fitted; we others all would have liked to see the PC he was working on, then (that was 8 or 10 years ago)

I guess a somewhat better use of the memory were to be able to preload additional levels / maps as a background task while one level is being played. And with really large levels, precision limitations may kick in especially for the remotest objects. Maybe, with huge memory areas, terrain paging can be implemented more easily ?

I don't think 64 bit needs a vote, for GG it is a must to move forward
into a new modern and powerful engine, tempting other software
users over to GG, I believe 64 bit would solve a lot of issues with GG
larger levels more content , and none lagging A.I , all in all a faster engine
capable of outlasting other TGC game engine releases, with new shaders
being developed in GG multi textures all uses more processes, mabie
pbr to come in the future, done by TGC or a third party, I also think
TGC should put the price of the engine to a real price tag for what it is,
selling an game engine to cheap puts most people of purchasing
in fear of whats wrong with it or is it dead software, ease of use and
new update to 64 bit should reflect in the price of the engine,
we see some of the old artist returning to GG, this is a big plus for content
being created for GG, and will create attention to GG.

If I was Lee I would be looking to the future and 64bit is it for now.

I would also be looking to implement version or renewable licensing.
Lets face it all these improvements cost time and effort, sleep deprivation all at no extra cost to us.
This is Lees living and a different licensing structure could give him a more predictable income stream.

Better-looking yes, as in "I could use all the quixel megascan assets without running oom". Of course, it would be a trade-off against longer loadign times, I suppose?

I would like to see an option to do away with the terrain ,
and be able to lock the camera to side scroll ,
enabling more options, and more fun gaming,
people are getting more fed up with AAA games
same old same all over again. platformers are or can be
more fun and challenging , and fun to develop,
and has a massive user base, untapped in a 3d environment
with TGC, and would be welcome from many users here,
yes using mega scans and other media would probably
slow loading time for now, but compression could be worked on
to eliminate the process of loading times, look at the work and
option preben has already added to GG, and GG loader some of these
options could be ported into GG for platform games.

You know AAA is a mark of quality, mainly due to being a big publisher, not a genre right? Any game can be a AAA game if it's done well enough and has the backing, even a platformer.

Yes I do know the difference ,
but GG is indie game software and you can never
develop what the big studios could do,
but GG can develop some great games compared
to most other engines in its class, yes some users have
created some stunning work here, but given the right
choices or say options would allow us lesser mortals
a chance to put new and exiting ideas out there,
giving us a much bigger user base, and drawing
attention to GG and the possibilities it has to offer.
don't loose track of what GG is all about, and its end
user base.

Yeah I know all that, I was just asking because the way you worded it sounded like you thought AAA was a type of game, like fps, third person, platform, etc. now I know you don't think that

To be honest the term AAA is thrown around a lot now days, and really it doesn't mean anything anymore, indie developers can produce just as good games as big publishing houses, it just takes them longer because they have less resources, but with a bit of time, dedication, and some good creativity an indie developer can make a game that rivals the big guys in the business.

At the moment with GameGuru I personally believe we can get it close, but not quite close enough. As it stands, there's only really a few things that absolutely need to be added to GameGuru for the most creative, and dedicated of us to create a blockbuster, one of which is as people have stated in this thread, performance, that's the biggest thing holding us back at the moment, and it's definitely something that shouldn't be on the voting boards, it should be being worked on alongside the current task at all times.

It would be nice to have better graphics, or better AI, water at multiple heights, and so forth, but to be honest much of that, as has been shown by some of the better WIP projects here, can be "faked" by the game designers, we already have people creating near professional projects, but they're being held back because there's only so much you can "fake" before the engine starts grinding to a halt.

Lee has done some great things with performance lately, things are improving at an increased rate for sure, but we still have a long way to go before performance is at a level where we can say "yeah it's great at the moment, you can switch performance to a secondary need and just tweak whenever you find something", it's something that needs constant attention.

Yes I agree,
but 64 bit might not give us better graphics or A.I.
but would be better performance overall .
there is only so much you can do with a limited 32 bit
and a memory bottleneck, I have no doubt that when
GG is 64 bit users will still want or expect more.
and no offence taken in your message at all.
I agree about the fake idea but all developers use it
for say certain things performance or memory usage
if it works don't fix it attitude, we see many bugs and flaws
in AA games people come to expect it , or even find them.
I do have 30 years + of gaming experience, and enjoy the
fun of development at an indie level, that's why I chose TGC
for my choice of engine or say engines, been good fun and
some frustration, but still here from 2006, because it has become
a second home like many others here. but all in all fun with a great
community forum. I do not want to be in a position of using unity
or unreal or other engines , because you just get swallowed up in
the mass user base, GG gives us more than just an engine it gives
a community who share the same goals that let us challenge us
at our own level or skill set that we want or choose, that's what
makes it work, it would be interesting to see why other members
or users stay here and there reasons, and a good insight to what
they want in the future, yes the voting board is good , and the reset
every so often is a great idea, be interesting what the list unveils ,

I would imagine better thread support would be the best route for a real performance boost in game and possibly also for loading levels. I'm not sure if moving to 64 bit would give more options in this regard, but for sheer performance having the engine utilise as many cores as possible would certainly boost performance for many users with 4 or more cores.

We have to remember Lee only mentioned 64 bit in relation to tidying up work he is doing, removing old legacy stuff from the engine. I imagine it would be easier to convert if it doesn't depend on any 32 bit libraries anywhere, but I'm not a C++ coder so could be wrong. 64-bit will not speed up the engine just because it's 64-bit though. It sounds like it should be twice as fast, but that is not the case by any means. Memory advantages are the big thing, 64bit would allow you bigger better textures, more objects and variations of objects. You would basically be able to use as much memory as you have available. I agree it would probably help with a huge map as well as that would be a big issue with memory at the moment.

For me performance is still the issue, loading times are a big thing as well in general. I'm finding the editor to be very slow in the current preview version when you start getting a decent map put together, similar to how it used to be slow when in entity mode. It moves okay if you highlight an object, but move off it and the frame rate drops to the floor. It's quite the task on my benchmark level for instance to place an object down at all. I have to hold the mouse button for a second or two.

I still wonder how much difference it would make going to DX11 as well. I'm sure modern video cards would get a boost from some of it's features. It must be more multi-core friendly as well I would hope.

If I were Lee, I would consider sparing myself the chore to implement DirectX11, and rather target either Vulcan or DX12, because by the time he will have finished a proper conversion to DX11, again, DX11 itself will be outdated.

The conceptual changes between DX9 and DX11 are quite big, and between 11 and 12, there is just another gap to bridge, but -so to speak - on the same road, so, why not go the full distance and be up to date with the rest of the competition when he can put GG_DX12_x64 or GG_Vulcan_x64 out to production, thus breaking the circle of "why are you still on ...." for this component and then that and then a third, for a very long time, giving him the air to breathe to really think about great gaming engine features ?

This might even mean an apparent step back in terms of looks for the first versions, but I for one could live with that since I would assume that GG is then on firm, stable and extensible basis, so, improvements WILL then come back in "rather" quickly. And with that basis, Lee would have a much better argument at his hands to establish better licencing models for GG.

Surely DX12 would be a new engine? if you think about how long it has took to get the DX9 version to its current state it would probably take 10 years plus to get it to DX12 unless I'm missing something, Lee is just one guy.

I'm no programmer but I do know the current engine is from DBpro which is 32bit, the conversion to C++ has that took away the DBPro code or added to it?

Graphix, Going to DX 11 would only take 9 years, I'll give you that.

For anyone interested this is quite the read, maybe it is possible to convert to DirectX 12 with visual studio 2015
https://software.intel.com/en-us/articles/tutorial-migrating-your-apps-to-directx-12-part-1

I'm no programmer but its still interesting

If you checked out Lee's blogs you would have seen the ones where he had a look at DX11. He was fairly outspoken in his tests with it and actually said DX11 would be added this year or was it last year now? Time flies. However that seemed to take a backseat in reality. I think it would have taken too long and GG was getting bad reviews. So, I think DX11 is likely in the future and isn't as hard to convert as you imagine. I just think for speeds sake he's trying to polish what is there at the moment. DX12 though (I think) probably has a license fee which would stop Lee using it as it messes up the free to release stuff option.

Interesting, maybe we could have clarification that DX12 indeed would cause licensing issues, currently rendering engine overall is top of the community vote if it is the next thing Lee does work on the time scale is 6 months plus so a total conversion to either DX11 or 12 maybe worth looking into, that would certainly be a overall lol

Sorry but I need to ask:

What changes will happen when gameguru becomes 64bit?

Guess this is a noob question, but I really don't know.

DK

https://www.digitaltrends.com/computing/32-bit-64-bit-operating-systems/

Windows 10 64-bit is now the most-used OS by Steam PC gamers.

http://store.steampowered.com/hwsurvey

Duchenkuke, the address space will extend a LOT. GG seems to be VERY hungry for memory; If we assume that Lee is already using tricks to avoid as many memory problems as possible to not have people crash against the current 32Bit 4GB addressing limits, it is obvious that Lee can drop these tricks and can just move into the greater space.

One problem is that windows has a nasty habit to arbitrarily limit the use of the technical address space with the windows license you have.

I myself had to acquire a win7 Pro license for a notebook fitted with 24 GB Ram, since the home version only allowed 16 GB.
The limits have been lifted with ensuing win versions, but they are still in place.

Nevertheless, being able to use at least 3-4 times the current ram certainly would allow Lee to drop the tricky programming and give us the option to create larger levels, finer detailed textures etc. - partly in theory, because the larger levels will need to be populated, requiring more processing power in general. But if we don't overdo it, we would all profit from the option to make levels visibly larger without necessarily checking the limits.

On the other hand, one cannot mix 32bit and 64bit dlls in the same program, so EVERYTHING in the engine has to be converted to 64bit. If 3rd party stuff should be in use, it also the needs to be available in 64 bit versions.

Again, theoretically, more bits can be moved at the same time with certain CPU Instructions, but one has to take care which data is moved where to, to avoid memory segmentation faults and the likes.
It is possible, it is useful in some cases, but one has to take a lot of care - it usually cannot be done by just selecting the 64bit compile option in complex applications like game engines.

Sometimes, even the names of 64bit functions corresponding to their 32bit counterparts are changed.

And so on and so forth....

I have no idea how many lines of code the engine og GG is comprised of, but I wouldn't be surprised if it took 8-15 months for one man to take on the task - which means : no or very few improvements to the current engine, no or few error corrections ....

And because it is a deep dive into the code, it could be best to combine this task with the upping of DX, because so much has to be touched anyway.

Thus, we shouldn't harass Lee to take this on, since it also means re--thinking certain hereditary concepts to get it right.

If there are licensing issues with the latest version of directx maybe Lee should look at going opengl he could then leverage the work done by the AGK team.
Also Ive read reports that opengl is faster than directx and it sopen??

On this subject I found this interesting.


It was written in 2010 so its well out of date but still worth a read.

link to full article.
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX

I could not find any reference on the internet that DX12 carries licence fee burdens with it.

The nearest thing to cost aspects was that the non-free visual studio versions raise a bit of cost, and on a recurring scheme at that,
but that is largely due to support you'll get and which you'll need as a professional working developer. And that's ok.

The move to OpenGL should rather be a move to "Vulcan", because Vulcan has similar advanced features as DX12,
surpassing DX11 especially in terms of multithreading etc. (from which GG may or may not profit on larger scale, currently, my impression is that multitasking would do more in the non-graphical layers of GG).
Vulcan could be a must if GG was to become open for Linux, Android, OS X as a platform, just like AGK2. True OpenGL may be looked upon as (almost) "outdated", in comparison to that.
But that is even a more radical overhaul than going DX12.

A few by the sounds

Ah well, I did say I thought there was a license, not that there was.

Also, for any reading through this thread I will remind you this is all speculation, there's no official word on either 64-bit or DX11 etc as yet. This is all based on an off the cuff comment from Lee on his update thread.


As I have said above DX11 has been mentioned by Lee before in his blog and nothing has ever come of it, so don't expect the comment from his update thread to be any different. He can sometimes get over enthusiastic and say things that don't actually come to pass.

That said...


Something is in the works, at least it would seem

My main reason for suggesting openGL is that Lee could build on the work done by AGK team and it must make sense from the workload prospective for all TGC products to use one graphics api rather than 2.

Anyway its all speculation, no doubt what ever Lee decides will bring big improvements and that will make people a bit happier(for a little while at least).

Engine overall still top vote, I hope those that have voted realise it could take at least 6 months before completion and nothing else can be done until it is finished (except the bugs and performance bits Lee wants to do)

After researching the subject all weekend here is my personal conclusion on porting to a updated DirectX API ( I am no programmer so I may have things wrong),

Purely in itself, moving from DX9 to DX11 will have basically zero effect on the look of the game, or its performance. Each version of DX is a superset of the previous one - it just adds new options and capabilities. In fact DX11 will still run on DX9 GPUs, as long as you don't use any of the new features. The API changed significantly from DX9 to 10 (and a little from 10 to 11), so DX9 titles need major rewrites of their graphics code to move to DX11, which takes time. At the end you'll have a DX11 title that takes no advantage of the new features, but after that you can start to make improvements.

For a flavour of what could be improved, some of the headline features of DX11 over DX9 are instancing, tessellation and compute shaders plus a bunch of other smaller things I don't really understand.

'Instancing' means drawing multiple copies of objects in one go. In DX9 if you want to draw e.g. ten buildings, you set up the position/rotation of a building and draw it, and repeat this ten times. In DX11 you can set up an array of transforms for each building and draw ten at once, potentially saving a load of CPU time (each draw call is expensive). This may well be of use in GameGuru.

'Tessellation' can be used to dynamically generating new vertices depending on where the camera is. It's useful for height-mapped ground terrains to generate the optimum number of vertices for the given camera angle, and avoid copying so much data to the GPU (again slow). I don't know if this is applicable at the moment with all the shader work Preben is doing , but it's pretty much a requirement for doing good looking dynamic water.

'Compute shaders' are for doing general purpose (not necessarily graphics) parallelisable work on the GPU. It's still mainly used to do graphics effects though and is great for doing super-quick particle systems, hundreds of dynamic lights, post-processing effects, stuff like that. Again would be very useful for GameGuru.

So, DX12. From what I have researched the main advantage of DX12 is that it can be much more efficient on the CPU, by stripping away most of the driver and giving direct access to the hardware. It's Windows 10[u] only though, so most (or all?) existing titles add DX12 in addition to DX11 support, as otherwise you're cutting your customer base. That doubles up your work though each time you add a new graphics feature, so personally I think DX11-only is the way to go for now.
[b]

At the end of the day though I don't even know if graphics rendering is actually the bottleneck, as I said before I am no programmer, so I assume there will be limitations on what a change of DX version can achieve for performance. I suspect that most of the CPU is used for AI, so even if you removed all CPU usage from the graphics, I doubt it would have that great an effect. The other coming improvements around AI efficiency will likely do more (Lee will know for sure).

Hope that's useful! please bear in mind these are my own conclusions from my own research if anybody can find anything wrong in what I have found please let me know, I just wanted to put this in a context to allow non programmers understand what DX upgrade would mean

I think it's a combination in the end. Even though we have a decent Occlusion system now the poly count is still very high overall.


You can see this is at the same spot, one with entities and one with them hidden. The poly count is over 3 million in the first pic, and still over 1 million on the second. The poly count bar is as always in the red and right at the top as usual. Not sure what other games push poly count wise, but those seem high numbers to me. This is default media and some purchased store items, no optimisation with them (which is where you will be able to speed things up with a lot of hard work). The render bar also is higher when there are no objects to block the terrain, which points at the terrain grass being more hoggy than the entities, which from this shot seems odd.
Number of entities will also slow things and that will be down to the CPU as well as video, because with more entities on the map the bigger the loop to check through all of them will be. Optimisations to reduce both will result in far smoother games. Check out my New Beginnings WIP for a demo of a map I spent a couple of months on optimising everything (or a good chunk of it anyway).
I still think the Terrain is a hog polygon wise and could be improved considerably. DX11 could help with that with tessellation I imagine, but even in DX9 improvements could be made I think. It really depends on which is the fastest to implement and what the benefits would be to moving onto DX11. Instancing sounds good as well, although having programmed with other TGC products for some time wonder what that actually means, as you have been able to instance and clone objects since the original Dark Basic was released and that used DX8. Perhaps it is just a hardware option that is more efficient than older instance techniques.
We will have to see where GG is headed. I'm happy either way as long as the engine is faster

here is a visual representation of Tessellation I have found



And here is compute shading



and finally instancing

sorry one more lol
tessellation and instancing working together

Instancing would definitely reduce draw calls but I am not sure about the polygon count,
the terrain is most definitely the culprit for the high polygon count.

I might be talking out of my bum here but as far as the terrain goes I think it is classed as 'Dynamic' what if we had the option to sculpture the terrain then make it 'Static' i.e a fixed entity! during the process GG could optimise and reduce the poly count to only visible terrain and remove all the non vivsible polys, yes the drawback would be you could not make changes to your terrain once you make it static but think about it, once you release your game you cannot edit the stand alone anyway, not sure I have the concept right but I think a fixed terrain once loaded would increase FPS and lower polygons and rendering.

ok I have been messing around a little bit and created a static terrain, the differences are extreme as far as polygon count is concerned, please note this is very basic its just a flat surface but the results even on my poor PC are promising

Thanks for the explanation. Now I know more

@ GraPhiX. The difference you see between the first terrain is the fact one is a single plane with a single polygon and the second is a detailed plane with many polygons. Hence the massive speed difference. The terrain is already to all intents and purposes static when you play your game, you can't deform it other than in F9 mode as yet. Although I imagine if the appropriate lua commands were introduced that would be possible.

You can optimise the terrain yourself of course with the sliders, the minimum seem to be around 127k with them set to near 0 on a flat map.

Yes I know I created the terrain as an entity, my point was if you know how you want your terrain to be then why can we not export a sculptured terrain as an entity just like the EBE ! Then set the terrain to off in GG for most games the terrain is too much.
I can easily create the terrain I want as an entity in sektchup as proven above, I have optimised my model and get a FPS constant of around 176 now.
I have started to create my complete terrain for a level in sketch up hills and all

Because the polygon count ratio is higher using a sculpted model terrain than it would be for actual terrain. It doesn't seem it at the moment because you're only using a couple of polygons, whereas a flat terrain uses thousands, so although at the moment the per polygon is higher, once you start adding a model with thousands of polygons (which is what you will need to make terrain the same quality) the per polygon ratio will soon overtake the terrains peer polygon ratio.

A quick example with made up numbers to show what I mean:

A flat terrain might use, lets say 1000 polygons, a single plane will use 2 polygons, that plane may use let us say 1% of the performance the flat terrain is using, but when you add a 1000 polygon model of say a mountain, it's now using 1000% of the effectiveness of the flat terrain, that's 10 times the terrains resources, whereas sculpting the same mountain from the terrain, because of the way the engine handles rendering terrain, will only probably increase the resources 10% or so. So yeah, when you're talking flat plane versus flat terrain then you will be using less resources, but the resources used is an upward curve which is steeper for model rendering than it is for terrain rendering.

ok think I understand a bit more, so logically if I have a flat terrain and reduce the terrain size by 50% I would reduce ploy count by 50%?

but if I were to push/pull the terrain (hills/valleys) I would increase the poly count to account for the deformations (increase in triangles) also if I use the blend tool (smoothing) that will also increase the poly count because it would add more vertices/faces ?

or are you saying the poly count would remain the same because we only deform what is already there?

sorry for the confusion but I really need to get to grips with this

.

When you deform and smooth it wil increase poly count.

Dave

Yes it will increase the poly count as Granada says, but as far as I understand it because of the way the engine handles terrain 1 polygon of terrain has less effect on performance than 1 model polygon, at least that's how it should be if Lee's done it right.

so if we had the option of Terrain size we could reduce poly count, does anyone know the actual default terrain size in meters?

the plane I created was 100m2 and it was very large but did not touch a quarter of the terrain size, the terrain must be huge?

how difficult would It be to have a terrain size option i.e. 10% 20% 25% 50% surely this would be a huge benefit and performance increase, how can we define world size is it even possible?

You know that 100m2 is 10m x 10m yeah? so not that big

I think the terrain size is about 1 inch per 1 unit, a grid square is 100 units, not sure how many units the map has.

sorry my bad it was 1000m2 100x100

Looks like the terrain discussion is going off the rails a little.
1. A polygon is a polygon whether it's terrain or model makes no difference I can't think of how the engine would handle these differently for render other than the shader.
2 There are two types of flat terrain in GameGuru 'flat' and 'superflat' the former is simply a flat terrain with the same amount of faces as a sculpted terrain. The latter is a two poly surface which can't be edited apart from the texture 'layers' the terrain shader uses but that's not the point here and actually still more of a performance hit than a simple entity shader. You will still find that two poly terrain to be more a performance hit than a thousand poly model. It should be noted that 'superflat' is only available when enabled in the setup.ini.
3. It won't add poly's to a GameGuru terrain if you sculpt it, it only deforms the vertices already present and smoothing it will only relax the verts. If anything it should help performance if occlusion culling is working properly where hills etc remove hidden faces from render. Not sure of GG is using occlusion culling where the terrain is auto sliced or face culling which would make more sense but it definitely uses one or the other. Doesn't make a lot of difference all the same either way in my experience as even a small area of terrain in view still chews up fps..

There are around a million polys in a GameGuru terrain, slightly less if memory serves correctly, it's the shader that chews up fps, always has done. Not sure if Preben's new shader improves this or not as I haven't looked at it yet. But if you remove the terrain using F11 you will find that physics are still present whether sculpted or not but get a huge performance boost since it is removed from render despite all the faces still being calculated for physics.
If your going to use a model you should slice it up so occlusion culling works properly for performance sake otherwise the entire model is always in memory even if only viewing a small part of it.
It isn't about reducing face count per se but removing faces from render and as I pointed out it doesn't make a lot of difference when a terrain is smaller in GG, even a small terrain in GameGuru will suck the life out of your fps whereas a smaller (sliced) model using an entity shader would yield better results but you wont be painting much in the way of grass or trees onto that.

That terrain shader is badly needing optimised, always has done.

OK thanks for the explanation rolfy, I could have sworn I read somewhere it was the other way round, but you know way more than me about this, so ignore what I posted, I must have misread something else.