Many to Few - What is best for performance?

[Merrie]

I hope this does not seem like an odd question but I have seen answers in different engines both ways. For better speed in GC is it better to make 1 object or several parts to make up an object.

For example:
  A cottage - You would have sides, floor, roof or
All one model?

Thank you!

[cohen]

I would say its better to make it one model for various reasones.  First reason is keeping things managable in the editor.  The less things in your scenes, the easier it is to work.  Also managing your content directory would become less obfuscated as the project grows in size.

On the flip side, having an object made in seperate parts would allow you to lightmap only individual pieces if you ever find a need for that.

**This part is speculation**
As for performance, I think seperate objects each hold a block in memory and are addressed this way.  So while its technically not more data that would be streamed to the video card, it would result in larger data set that would need to be bussed/streamed.  Which may affect performance if it has to call up thousands of different objects to draw versus calling hundreds of objects.  Atleast this is my thinking.

[Coty]

This is how I would make a cottage, I would make an outside shell in one object and an inside shell in another object.
I would build my windows, doors, and furniture, etc... as other objects.

I will explain why.

I want my outside building shell to cast shadow to block the sunlight from the inside shell. I may not necessarily want to lightmap it. I want it to have a simple lod until player gets close, then I would switch to the higher poly building with real windows and doors. The windows and doors are separate objects because they would be instances of one window and door that I could use throughout the map, or game (re-usable). The same goes with the furniture. I can lod them and/or remove them completely when player is far enough away to not see them anymore.

The inside (walls,floor, ceiling) I would either lod it really low or not have it appear at all, until player gets really close. Having separate objects for the inside is mostly for lightmapping. I would lightmap the inside really nice.

OK, now imagine a building with a parking lot. You want to separate the parking lot, sidewalk, or whatever so that the building will be smaller (smaller bounding box). If you include the parking lot or sidewalk with the outside of the building, the occluders won't work as well, this is because if just one poly (say sidewalk poly) is peeping through the side of the occluder, the engine will draw the whole building shell. But if the sidewalk is a separate object, the sidewalk will be drawn first, but the building shell won't be drawn until player moves close enough to the edge of the occluder for one poly of the building to show. It may not seem like much, but in a game, every poly counts.  It adds up.

In your modeling program, you would have the outside shell, the inside shell, and the sidewalk with the same origin at 0,0,0. When you export them out as separate entities, they should all line up perfectly by coping the position of one and pasting it on the others, in the editor.

You can also place occluders in building that are just an outside shell (fake buildings you can't go inside) and they work great to block geometry when player is on the other side of the building.

That's what I do...
Coty

[Merrie]

Wow thank you Cody for explaining that in detail.

[Steely Dane]

I have just joined a team that is using Gamecore to build a game that involves battleships and the like. Even the least detailed ship is in the 150 000 poly range.

I've discovered that trying to load anything over 45000 or so totally crashes GC, (not that unusual really, most engines can't load objects that size  ), so the only option is to break it into smaller parts, which is what we've done anyway.
Objects that complex are way easier to work on in chunks, as Coty basically pointed out.

On the upside we haven't noticed any performance hit from using objects that have that many poly's, and even had up to 4 ships in a scene, with a total of 2 453 782 poly's, not counting the water and terrain objects.
Not really surprising I guess, since I read in an earlier post by gekido ( I read through almost the entire forum when I joined the team, because up till then I had never heard of Gamecore) that they have had scenes with millions of poly's, without issue, and that the real performance hit happens with map sizes (don't know, not my department and we haven't got that far  ).

[Squat]

Well, for my project I have to go to a bit of an extreme. My whole game is one house, so I'm breaking up the rooms into completely separate levels. If I were to be building a real-world scaled game, I'd do the shell approach with separate interior/exterior major structures with the props and details as separate objects.

The one thing you need to remember is that if you include a bunch of meshes in one object export, you will be referencing the same pivot location for all the pieces. This isn't good on an interior as it can put you in a situation where you can't get a higher poly LOD to show up on a small part when you're right next to it because the distance is calculated to the pivot, not geometry, which can be at the bottom of the whole thing (export). You'll need to hand place the minor objects in the editor and copy/paste the whole thing manually to duplicate it. For something like a giant battleship, you'll need code to tie all the pieces together. Perhaps adding the elements as inventory items to the ship itself will work easily.

Actually, I suggest that people export dummy anchor objects that are in the right position on the main model. You should then no longer need to worry about the position of the attached objects as you can use the .opr to add them and parent them to the anchor object and it's automatically aligned to where you need while still retaining its own set of properties, hence its own pivot location and its own local calculation on the LODs. I think anyway.

[zknack]

Actually, I suggest that people export dummy anchor objects that are in the right position on the main model. You should then no longer need to worry about the position of the attached objects as you can use the .opr to add them and parent them to the anchor object and it's automatically aligned to where you need while still retaining its own set of properties, hence its own pivot location and its own local calculation on the LODs. I think anyway.

Squat, that idea is genius!

I honestly feel embarresed for not thinking of it, as it would be basically just making a dummy bone structure in the static models *shakes his
head* I should have thought of that....

*chuckles* Thank you Squat, you have no idea how much I appreciate this idea :-)

Cheers,

Z

[Steely Dane]

For something like a giant battleship, you'll need code to tie all the pieces together. Perhaps adding the elements as inventory items to the ship itself will work easily.

For the most part, that is the plan. You will have the option to upgrade a specific hull design with different exhaust stacks, gun turrets, bridge decks and mast configurations (as well as colors, such as sea camo) in the "shipyard" at the start of the game and after each successful mission.
So for all intents and purposes, they are inventory elements.

The basic hull patterns are still quite large poly-wise (visible detail up to 20 meters away, portholes, anchor chains and what-not...), so your idea of using the dummy anchor objects sounds like a pretty good solution, since obviously you don't need to see full detail on a porthole that is 100 meters down the side of the hull from the one you are currently looking at.
Not to mention the fact we are dealing with a couple dozen different classes of ship with completely different configurations, so that solution becomes even more attractive.

We are basically looking at each ship as if it were an entire town, only it moves, floats on water, and has great big freaking guns all over it.....

[gekido]

There should be no reason you can't load objects with higher poly count than 45000 poly's - I have character models that are more complicated than that (with all of the various submeshes etc for character customization).  Poly count is becoming less and less of a concern as hardware progresses, the things that will slow your scenes down are complicated pixel operations.

I've run tests with single objects of more than 5,000,000 (quite literally) verts in a single model that have loaded and ran perfectly fine (by that I mean at 60fps) in the engine - the slowdown you'll get with more complicated meshes is if you try and make that complicated model the collision object (using renderobject collisions) - you will most definitely want to make optimized collision models in almost every situation (or simply use boxes / bounding boxes).

The other thing that will slow a scene down is if you start hitting the memory limit for your textures - once the engine has to start paging textures in and out of gpu memory, you'll start seeing slowdowns - particularly if the textures are large.  the texture streaming system is multi-threaded, but you will definitely have the potential for slowdowns once the memory limit is surpassed.

(btw, the status bar in the editor will display the total memory being used by a world at any point - which includes things like render buffers, shadow buffers etc) - plus any graphics that are being used / loaded by the UI system (which are resident all the time currently).

[Steely Dane]

When I try to load stuff over that i get this:

I can't find the CRASH LOG, otherwise I'd send it in...

[BigDaz]

In the past I've had problems with models with faces that have more than about 20 vertices. You could try triangulating the model before importing and see if that fixes it, if you haven't already.

[Steely Dane]

I hadn't tried that, so I did a little experiment.
I created a box and divided it's surface into 72384 - 4 sided polygons.
Tried to load it and got the previous crash screen I showed.

So, then I went back and tripled the polygons ( Lightwave has a function that is called tripling, basically turns a polygon of any number of sides into  however many 3 sided polys it can make with the vertices present, in case you were unaware). I then got this screen you see below. It's something new I haven't seen yet, but still is of little help to me.

I can't load stuff over 45000 poly, wether they are all square, triangle, or Hexidecamegamultigon. It was a theory worth trying but doesn't necesarily seem to be the issue in this case.

As an aside, poly's that have more than 4 vertices often show up as transparent in GC (for me anyway), so I tend to "triple" them before going into GC, or in some cases cutting them into smaller 4 sided poly's...

Any other suggestions?

[Steely Dane]

If someone could point me in the direction of the CRASH.LOG file that it says it makes, I could open it up and either send it in for support or post it up for y'all to peruse and perhaps shine a light on the problem.
Have searched literally my entire hardrive, and haven't found it.......

[Ron]

Have you tried other formats instead of lwo? I use obj and 3ds for almost everything and never had a crash like that. Also, does your computer have on board video or a graphics card?

My computer is lower end (AGP video and single core processor) when compared to a typical gaming computer and I can still load about 1/2 million poly scenes and 100,000+ poly objects.

[Ron]

One more note... the lwo has two formats. I do not know alot about it, but I guess Lightwave 1 is the old format and Lightwave 2 is for "Huge" objects. I use a utility called Accutrans (http://www.micromouse.ca) and it allows you to save / convert various 3d formats / triangles to quads,...., best $20 I every spent.