Hello,

how many polygons does GameGuru uptodate support, when

(1) importing a Model and
(2) using it inside a GameGuru Level?

I did look around and found some information and advice by LeeBamber:



https://forum.game-guru.com/thread/209894

How could I set up a Model, that is "vertex data only" ?


How high is it possible to go actually?

What is important to know, when it come to the use of highpoly meshes?
Might You know also some hints to make highpoly meshes run better?

That would be very great

Regards,
R.E.Z.

22,000 polygons. I have heard 22000 with bones, 65000 without, but any model I've tried over 22000 shows up all deformed, bones or no bones. Any more than that you need to decimate the mesh. Blender has a decimator, but I've had mixed results with it, as well as others. Sometimes it's best to just decimate by hand, I've learned.


EDIT: I just read that thread you linked to; man that was a while back, lol. Good info there, thanks!

Hello,

@ Jerry Tremble: Thank You for Your information
22,000 polygons -->> I will go for that.

about 15,000 I used so far.

Thank You ))

Best regards,
R.E.Z.

Long post short: Experiment. You may be pleasantly surprised.

I don't know where the sweet spot truly is. Just to see what would happen, I have imported some massive, highly detailed models that I did with Sculptris. Importing was easy enough. Walking around them was lag city in many cases. I've also recently purchased what looks to be a fairly simple set of objects from the GG asset store and found that just one or two of them grinds everything down to a slow slideshow. (I need to inspect those myself a bit more and look for a workaround.)

Overall, the models I make are usually higher than what most people seem to be doing but I have had no problems with them that were related to anything but my own mistakes. Of course it all depends a lot on the system and my current rig is middleground at best. I think a lot of people don't give GG the credit it deserves and treat it a bit more delicately than necessary. It's like a baby. It's much tougher than most would expect!

If you want performance, adding in huge poly count objects is not the way to go, Game Guru will become jerky and slow very quickly. In fact you really want to be doing the exact opposite, as low as you can get away with. Nothing to do with treating GG like a baby, just common sense. You keep your poly count as low as possible per entity to enable you to have more of them in total. No brainer. Can't see that changing anytime soon. Even professionals do this, with far more powerful engines. Sure they may have more polys on main game items and focus points, but if possible they will keep the poly count down as low as they can.

If you have relatively simple objects slowing things, then the texture may be the cause. Disable SAO and check again. You can normally tell by running up close and away from an object (normally buildings). When close it does a lot more work on the SAO stuff and so you notice a significant slowdown. The shader for this seems a bit hungry, so for most people, disabling it will improve things quite a bit. I'm sure if you have a Geforce 980 or similar you won't notice

Hello,

thank You for Your answers ))

@ DVader:

-->> Okay, that I will keep in mind

-->> Thank You for this hint, to save ressources

Got a Geforce GTX 560 Ti. I will go for Your hints Thank You

Best regards,
R.E.Z.

@DVader,

Regarding what you said about polygons , there is something I don't understand then with GG ...

Why all GG library objects are complete, I mean they are built entirely, even the parts of objects that are never visible ?

example: two pieces of walls overlapping each other or the back of a decor where it is impossible to go...

This is one of my first interrogation the first time I used GG ...

for information, that's how I created my scenery with DarkBasic Pro in order to maintain proper Framerate :

Not quite sure what objects you are referring to. Obviously being general purpose many have both interior and exterior, but as far as I know only when you can actually enter a building. All I can say is if there are objects like that it's an oversight perhaps.

Nice screenshots. I imagine they are in DB?

@DVader,

yes, it was an unfinished Dark Basic Pro project ... I would love to continue with GG by the way !

I actually was talking about objects included in GG. All are complete. For example, the lower portion (bottom) of a rock doesn't need to be created.
One can leave a hole underneath because nobody will ever look at this location.
If I build a wall for interior use only, I don't create the opposite side of the wall...

Else, I understands that should multiply the quantity of identical items (one for exterior use, another one for interior use)
and it's easier to use a "standard" object possibly visible from all sides.

I think we can make this effort with the objects we make ourselves and we import in GG.
Personally, I have already seen a big difference at the final FrameRate with this method...

Here is an example of a level that I am preparing with GG.

As you can see, there are no exterior walls, because normally, if all goes well, it will not be possible to go to the other side.
It is a closed level.

Ah I see what your getting at. I'm not sure how things stand at the moment with the store, but at one point it was actually a reason to be declined if you didn't cater for an object to be rotated to any angle, hence you needed the polys and texture included. I'm pretty sure that has been lifted and if you state the object is designed to work only as a floor item, you can avoid having them. The main problem here, is most models are designed to be used any way you wish, so optimisations like this are not really possible generally. Having total control of all your media is a great optimising factor. A game made of totally custom and optimised graphics will always run better than using generic store items. I just wish I had an artist to hand who could make this a reality It's not just poly count either, having several objects using the same texture will also increase performance. Well, it should, as technically it should use less draw calls, and for speed, draw calls are King.

I've often thought of trying to make an uber GG demo, which shows GG off as much as possible, but it really needs a good 3D artist to get the media needed for this. I'm convinced with optimised media I could make something really impressive in GG quite easily. Many performance issues are not helped with default media. Add some default trees and see how quick your FPS drops! Adding the same amount of default buildings is far less of an impact overall. I'm unsure if this is down to the tree poly count, or the fact it needs transparent textures to work properly. I know DB used to be a lot slower with transparent textures for example.

Your level looks great and is just the sort of thing I mean, optimisation wise

I understand where you're coming from, and for personal models I leave faces off where it's not going to be seen. However with media that comes with GG or media that is sold, it's not a good idea for the modeller to do this for one simple reason, you never know what the person purchasing it is going to do with it.

I've seen projects where they've used lots of small media at odd angles to make a different item I used to do that with the decorating system in star wars galaxies as shown in the pictures below:





In one of Lee's twitch videos he shows this with rocks, using the rocks as a roof to a hollowed out piece of terrain to make a cave system.

If you remove faces to make it run better you're in danger of the item no longer serving a purpose the customer may have planned for.

Sure, if you're making the model for your own use, or making a custom model on request, then there's no problem with cutting out unseen faces, however for stock/store media it's best for the models to be complete so peoepl can be creative with your work.

Gentlemen,
this is exactly the problem I wanted to talk !

If you offer an item for sale in the store, I agree you have to built it completely.
But the solution would be as follows : you could build the object into multiple parts (like LEGO) the user can use or not as if he needs it !

I have already made objects like this, with four differents parts (exterior walls, interior walls, roof and ground). It's easy to use for the final user (he chooses what he need) and also this increase resources for the GG engine !

But I agree that it makes more work for the creator of the object ...

I go to prepare a model soon to show concretely how it is feasible ...

Thanks !

I am hoping the EBE may be used to construct entity parts into prefabs which could be dropped in and edited to suit your build and player POV in the level.To create billboard style facades etc.
If this is done then you could remove all those unwanted faces and the store would be able to accept model 'parts' for use if per-built or for building purposes, the only thing that concerns me here with the EBE is the huge Atlas textures which may only use a small part and the rest is sitting in memory unused. Using entity parts which don't use the Atlas would work pretty well and reduce the texture size but increase draw calls which might balance out with a reduction in resolution, or artists can create a smaller Atlas for their 'construction' to reduce draw calls.

It depends on Lee to think outside the box with the EBE which could have a number of uses other than simply building with shapes or primitives, I know he is thinking that way from things he said when the original construction kit was on the cards so I have high hopes

Mostly the problem with store items isn't the poly count but the huge texture resolutions many Artists use unnecessarily. If you really want to increase your FPS right now then change setting in setupt.ini...dividetexturesize=1... to 2. It will reduce textures but you wont need to be turning off entity shaders to gain frames. It will look less sharp but the player wont notice it, to really get into it and manually reduce the textures which are not required (small objects with 2048 or 1024 res which would work fine with 512} then you can have the best of both worlds.

A model with 2048 diffuse doesn't need a huge normal and spec maps so reducing the scale of all of these should instantly help with FPS and memory right off the bat and neither yourself or the player are going to see much difference.

I understand your reasoning here, but again I go to point of "Your never sure what a user wants to do with the item". Having a really low texture size to start with limits the customers options. You may want to view them close up in an inventory or such and having low res textures would not be ideal. It's easy to reduce down as you say, either manually or in GG itself. At least when you have a decent sized texture you have the option It's a lot easier to scale down than up. Normal and specular maps can be smaller than the diffuse without losing much, so I always recommend reducing these first when having performance issues. - Edit I see you mention that in your post as well

I would be happy to include different quality textures with an object if the option was available. Then you could change it as you want for whatever use you need without reducing the overall quality. Really though, it's not too difficult to load the texture up into a paint package and reduce it down when optimising a game level.

I've seen many items which have excessive poly counts as well. Because I used DB so much in the past, I always try to keep them as low as possible. Ultimately though, draw calls are the biggest issue regarding performance in general. Obviously, having everything as low as you can get is going to be better for speed and also memory usage.

@Rolfy and DVader,

If I understand correctly (for me and the other users), you mean we can use smaller size of texture for specular and diffuse without alot of visual changes ?

I thought we should always use the same size for the 3 textures... also all the same kind (all in .DDS or .BMP or .TIFF)

That's good start to save memory use !

Thanks for this good information !

Artists can in fact remove unused faces if they state the reasoning behind it for approval, a rock for example would have none since it could be rotated and used over again, a house isn't going to be placed on its side so you can remove the floor. If an artist wants to sell fake house fronts they can do so if they state the reasoning for missing faces, but many items in the store simply don't require large textures so I see many that could be reduced and users who simply drag and drop are seeing fps drops.

Trees for example don't require leaves to be double faced and should have cullmode = 1 set in the fpe to force double sided and therefore reducing poly count immensely, nor do they all need to be animated, collision settings are important for these too and you should set all those that aren't reached to box collision or turn physics off entirely for them.

I guess the point here is that even with an 'easy' game creator users still need to have a certain amount of awareness and knowledge to build a game which runs at acceptable frame rates. This is true for any engine and though the top ones are better optimised they can still crawl if you put too many high poly/high resolution textures in a build. It is not entirely the engine to blame. Having said that GG performance could still be better but with the kind of assets required for a drag and drop game maker you are always going to have issues with the media for it. Personally I would rather see Artists being encouraged to cater for both those wanting 'easy' and 'advanced' where more optimised assets could be sold to those who know a little about what they are trying to achieve, I guess it may be down to users to create the demand for it.

You will see no great difference with smaller spec and normal sizes, they do however need to be the same format.

Thank you Rolfy for the clarification for the textures format !

...and also for all this !

But that would defeat the purpose, although a model split into two or three pieces would be almost the same poly count as a single model (it wouldn't actually, it would be slightly more depending on the complexity of the models), it increases the load and draw times because it has to access two or three sets of files instead of just the one. So really it id better to make a single model instead of multiple components. Of course multiple components also gives options in the sense that they can put it together how they like, so it's kind of a 50/50 scenario.

@Rolfy: I agree with most of your post, but ...



I did some testing with this a while back, I placed 30 complex objects with 4096x4096 DXT/1 textures, marked down the FPS. Then did exactly the same using 2048x2048 DXT/1, and again with 1024x1024 DXT/1. I then repeated the whole thing uses .dds textures that had been saved raw without choosing the DXT.

My results showed that between all the DXT/1 textures there was almost no change in FPS, maybe a fluctuation of 1 or 2 FPS between the 1024's and the 4096's. But the difference between the DXT/1's and the raw dds' was huge.

So I have a feeling that where people are having issues with large resolution textures isn't so much their size, but the level of compression and the memory footprint that leaves.

I don't think thirty entities is enough to test the fps in a level for this, I believe the average level would use a lot more than that and then you will see a more obvious result. The huge difference between compressed and uncompressed simply exaggerates and proves the point on FPS loss due to large texture file sizes impacting memory. You cant say that there is no fps difference in a level full of entities with 4096 textures and a level full of same entities using 1024 textures, doesn't make sense to me or anyone else trying to optimise their game assets

I highly doubt there are any store or default assets which are using uncompressed dds files so that shouldn't be the cause, unless they are user created.

There are quite a few, especially the older ones.

Really? I never encountered these, if they really are on the store you should point them out and have them corrected, isn't good for business if assets aren't being properly tested for approval. Though some will likely slip through, as you point out these are huge file sizes which are pretty bad for game design not to mention unnecessarily huge downloads for TGC servers. and purchasers, bandwidth costs are bad enough. So you would do both a favour by pointing these out to store admin.

I've not so clear if using texture array (mipmaps) is a mandatory in GG (diffuse map), nowaday.

I wonder myself, if we can explore another texture formats like "Rectangle texture" that contains a single 2D image with no mipmaps, it has no power-of-two restrictions on its size, but using texel values (floating-point) for accessing, rather than normalized texture coordinates.

3com

Probably need to change all the shaders to accommodate 'rectangle textures'. It's an old method which doesn't use mip maps so these cannot be used with LOD's.

It may not seem like much to reduce textures and is only a part of level optimisation, of course there are several things to do, but a ten or even five fps gain is a lot when your level is running at 20-25 fps and every little counts. Only scaling down the normal and spec would probably have no effect if entity shader is turned off and that's when diffuse would need reducing, it may not seem much but every little helps and up to the developer to make sacrifice where needed. Test it in your level by setting dividetexturesize= 2 or higher in in setup.ini. If it helps then you can decide which textures to reduce manually and which to keep resolution for, or if no gain then you wont neeed to be doing anything.

If there are entities with uncompressed textures then you might need to hunt those down, but at least you will know if texture file sizes are a problem or not by testing it first.

power-of-two restrictions on texture size often is a pain, ie: if you've a very nice 512x768 texture but you need to resize it such 512x512 it lose resolution, and usually you get streched texture, since that is not their natural size, because of power of two ruler.
"Rectangle texture" has not that issue, and it can be used at least in a non complex mesh, because if one entity need LOD ,usually meant a complex geometry with high polycount.

But yes is an old method, meanly used when non-power-of-two textures being available.

3com

Hello,

thank You for the different ways to save ressources and gain performance enhancement.
I think, I will also look closely over the files, I do use, setting up a Level.
The ideas, mentioned here, are very valuable.
Personally I kind of took a bit of distance to the idea, wanting to use Contend with a really big amount of polygons.

Now I also got neat ideas, to make Levels more "slim" as they need to be in terms of performance, but still high of Visuals and information for the Player. A kind of Balance.
Also taking a closer look at the Vegatation like trees etc. and how they are set up, is a great thing to keep ressources use pretty much down.


C.U. R.E.Z.

512x768 should work fine just as 1024 x 512 will. If the uv's are correct then these sizes will be perfectly ok.

Nice to know, thanks Rolfy.

3com