Entities automatically get mutliple SubEntities? [solved]

Oogst · Post by **Oogst** » Mon May 22, 2006 1:57 pm

For The Blob I am using meshes that were exported using the MAXscript-exporter. When I load these in the game (simply using SceneManager::createEntity()), they have several submeshes. I checked this with NVPerfHUD and saw that indeed a car with only 100 or 200 polygons has around 4 submeshes.

Looking at the rendercalls and the shape of the submeshes, I think this is because Ogre wants to make trianglestrips. As far as I know, seperate render calls is very expensive. In the case of objects of 100 to 200 polygons, will these trainlestrips not actually kill my performance? My game has around 1000 to 1500 objects in the scene (of course not all visible at the same time), so the number of render calls is an important performance factor, I think.

If it is indeed bad for performance, how can I solve this problem?

Post by **xavier** » Mon May 22, 2006 2:01 pm

It's nothing to do with Ogre and everything to do with how the model was made in Max. The model should be done as a single object if you want to render it in a single batch. Otherwise, you need to do some fancy footwork in render-queue-listener event handlers to suppress the render state changes for subentities that use the same material.

Oogst · Post by **Oogst** » Mon May 22, 2006 2:16 pm

I am 100% sure that is was one single object in 3D Studio MAX. Or do you mean something internal that the modeller cannot control?

Post by **sinbad** » Mon May 22, 2006 2:30 pm

You probably used several different materials, which require the object to be split.

Oogst · Post by **Oogst** » Mon May 22, 2006 2:59 pm

Nope, I did not use more than one material.

I have a stick with a nail through it here to hit my artists if they make objects with more than one material.

Post by **sinbad** » Mon May 22, 2006 6:02 pm

It's likely to be an exporter issue then, although I can't imagine why it would arbitrarily split the data like that.

I have recently been given a copy of 3DS Max 8 by Autodesk so I can try to take a look if you send me the Max file. I've had no time to get up to speed with the API yet though so you might need to give me some head-scratching time

Oogst · Post by **Oogst** » Mon May 22, 2006 6:53 pm

Okay, so the problem is most probably in the exporter?

Before you are going to spend too much time on this, would it be easy to alter the meshes on load and merge all submeshes into single meshes for every mesh? I know for sure that no object has more than one material, so that will not be the problem. Will it be hard to do this (I have already jiggled with custom meshes, which was no problem) and, above all, will it be worth the effort for performance? Is a 200 polygon car with 4 submeshes much worse than with 1 submesh, or will I hardly notice the performance difference?

Oogst · Post by **Oogst** » Mon May 22, 2006 7:19 pm

OK, knowing I had to look for things in the exporter, I found out what the problem is and can explain exactly how to solve it. It is actually a kind of bug in the exporter, I think.

What happens is that if an object has one standard material, but different material ID's, which are not used at all because there is no multi/sub-material, the exporter exports these to submeshes anyway. This really is a fault of the exporter and not of the modeller, because if you create a box in 3dsmax, it automatically gets six different material ID's, one for each face, even though there is no material available on creation anyway. So these are just numbers that 3dsmax ignores as long as the modeller does not apply a multi/sub, which is usually not done. Modelling from a box is very common, so many meshes created in 3dsmax will have this problem, so the exporter should handle it, I think.

The solutions are quite simple. The quick solution for my current project and close deadline is to simply reset all material ID's and then export.

The permanent solution for the exporter is to check whether the material is a multi/sub and if it is not, then do not split the mesh into submeshes for each different material ID. Some people might make obscure use of the material ID's, so it would probably be a good idea to add a checkbox to the exporter to turn this on and off, and make it checked by default, because in general this improvement will be wanted, I think. The change would have to be made to OgreSkeletonLib_meshfns.ms and then in the function getDatas, I think.

I could make a patch for this, but a previous bugfix I did for the MAXscript-exporter in March has still not been looked at so far, so how much use will it be if I fix this? If it is going to be used, I would of course not mind to do something back for all the help I get here by creating a patch.

Post by **sinbad** » Mon May 22, 2006 8:53 pm

It's still useful. Your patch hadn't been looked at because we had no 3DS maintainer until a couple of weeks ago (and now it's me, although I have yet to find time to dive in).

Chances are I will rewrite the exporter but these kinds of max-specific gotchas are exactly the sorts of things I'll need to know.

Oogst · Post by **Oogst** » Tue May 23, 2006 3:21 pm

OK, the quick fix for me was to simply add a Material-modifier to all objects before exporting, which I have automated in my exporter. The Material-modifier resets all material ID's.

This cannot be done in the official exporter, however, because it would not support multi/sub anymore then. Two weeks from now I have time to create a proper fix for the official exporter.

Ow, by the way, if you need help with rebuilding that exporter, I am available, I have lots of experience with 3dsmax and MAXscript. However, I am wondering why oFushion is not fully replacing the current exporter. Does it not support everything yet? Is rebuilding the MAXscript exporter worth the effort while oFushion exists?

Post by **sinbad** » Tue May 23, 2006 5:51 pm

oFusion is owned by Lioric and is not open source, which is fine but it means we can't support it (support as in, get involved in development, not support as in promote, which we clearly do). The idea is to at least have a base 3DS Max exporter which is open source as part of the OGRE project to replace the existing one. oFusion is likely to remain the superior option but at least we should have the common denominators covered (mesh and animation support).

Oogst · Post by **Oogst** » Tue May 23, 2006 6:44 pm

By the way, in a simpel test-scene for The Blob at some random point my fix turned down the number of render calls from 150 to 50. That is quite an awesome improvement.

As for the exporter: if you really plan to rewrite it, then I think that should be done in C++ and not in MAXscript. In a scene with some 300.000 polygons in 1000 objects, the MAXscript exporter will easily take over 15 minutes to export that. That is just not workable.

I repeat that I would like to help out with the 3dsmax-exporter, so just let me know if I can help with that.

Post by **jacmoe** » Tue May 23, 2006 7:00 pm

Xavier is already doing one in C++. He's the one to ask.