Jump to content

Mergemetatriangles take sooooo long...


Recommended Posts

Posted

Before the passage portal flow in second compile state was a problem but now i have a problem with MergeMetaTriangles in the first compile state. What is it and how to make it faster ?

Posted

-lomem doesn't affect this, it's used for lighting not vis/geometry. If anything it would make it slower based on what I've heard.

 

@@Langerd: are you using any areaportalling, hinting, that sort of thing? Optimizing it will possibly help you. I believe mergemetatriangles is used in the first part (or the second part) of vis. Also you might reduce the number of triangles that your map contains by either using models instead of big, complex brushes.

 

And yes, what @@Apprentice said: how long does it take exactly? If it takes more than 30 minutes or so, there's definitely an issue. What about your hardware, specifically your CPU/processor?

Posted

Hmm i am using a lot of models but not a md3 . I made a bespin decoration wall and I sculpt this wall in gtkradaint. After that i convert it to the ASE model - i wanted a 3D decaration not just a texture.

About this hinting and areaportaling i have no idea how to do it and i am not a pro mapper D: I am polish and my trip with english language is not far enough to understand difficult tutorials about mapping.

It take 10 minutes ... but in the compiler is in 4 number :/ So it takes 15-20 minutes i guess

Posted

Hmm i am using a lot of models but not a md3 . I made a bespin decoration wall and I sculpt this wall in gtkradaint. After that i convert it to the ASE model - i wanted a 3D decaration not just a texture.

 

About this hinting and areaportaling i have no idea how to do it and i am not a pro mapper D: I am polish and my trip with english language is not far enough to understand difficult tutorials about mapping.

 

It take 10 minutes ... but in the compiler is in 4 number :/ So it takes 15-20 minutes i guess

Are you using detailed brushes in your map ??

 

About the areaportaling i must put the areaportal brush in the place where are the doors?

Yes, though I always make a hint brush and apply the areaportal texture onto one face of the brush. Otherwise, all entities will "flash" the moment you enter a complete areaportal brush . . .

Signature.jpg

Posted

Whole map is detail brush... only sky and fog is structural. I use func_misc ( i didnt make them solid because i saw in one tutorial that making them solid creates too mamy brushes.)

Posted

Whole map is detail brush... only sky and fog is structural. I use func_misc ( i didnt make them solid because i saw in one tutorial that making them solid creates too mamy brushes.)

 

That is an inefficient way to do visability for a level. It will end up being an FPS and entity nightmare later. Before you worry about anything else, take a few steps back and replan your use of structural vs detail brushes.

 

This thread contains a lot of information about visibility.  http://www.quake3world.com/forum/viewtopic.php?t=3620

 

Your playable space is split into leaf nodes by the compiler. A leaf node is defined by the plane of a structural brush. A recursive operation in the BSP phase continues to split volumes into nodes until it has used all the planes of structural brushes in the volumes. The Leaf Nodes in the void are carved away because they are non entity containing hulls.

 

Where leaf nodes join, portals are created in a .prt file for when visibility is calculated. Where one leaf node sees into another leaf node, all geometry and entities are drawn.

 

Because everything your map is detail, you basically have giant leaf nodes (A lot of them the 512 x 512 default blocksize) that see into each other. Meaning, no matter where you are all the complex tris, expensive entities and so forth are being rendered. This will cause you a lot of issues with performance. You will also start running into problems with entities being truncated because you are drawing too many at once.

Boothand likes this
Posted

That is an inefficient way to do visability for a level. It will end up being an FPS and entity nightmare later. Before you worry about anything else, take a few steps back and replan your use of structural vs detail brushes.

 

This thread contains a lot of information about visibility.  http://www.quake3world.com/forum/viewtopic.php?t=3620

 

Your playable space is split into leaf nodes by the compiler. A leaf node is defined by the plane of a structural brush. A recursive operation in the BSP phase continues to split volumes into nodes until it has used all the planes of structural brushes in the volumes. The Leaf Nodes in the void are carved away because they are non entity containing hulls.

 

Where leaf nodes join, portals are created in a .prt file for when visibility is calculated. Where one leaf node sees into another leaf node, all geometry and entities are drawn.

 

Because everything your map is detail, you basically have giant leaf nodes (A lot of them the 512 x 512 default blocksize) that see into each other. Meaning, no matter where you are all the complex tris, expensive entities and so forth are being rendered. This will cause you a lot of issues with performance. You will also start running into problems with entities being truncated because you are drawing too many at once.

Thnaks for that ^^ . I didnt know that. But now i checked the main problem this mergemetatriangles and i think i find the reason... I use too many ASE models. I have started a compiling and first state was very very long ... after that i have started a compiling but before it i have deleted all misc_models on my map. And ... compiling was so quick it take only one minute. I thing the reason is this http://forums.xonotic.org/showthread.php?tid=1246 - tZork is right i think. But like i said. I didnt use a solid spawnflag in models... The reason i think is that the models are too detail. 

Posted

I highly doubt that if you made the models from radiant originally that they are too detailed. Besides, if they were, you'd first run into (if auto-solid) max_map_brushes (auto-solid makes brushes for every model triangle and covers them in clip)

Posted

I highly doubt that if you made the models from radiant originally that they are too detailed. Besides, if they were, you'd first run into (if auto-solid) max_map_brushes (auto-solid makes brushes for every model triangle and covers them in clip)

That is why i didnt use this spawnflag... But nevermind everybody . I have deleted these ASE models and i put just textured walls. It looks good like the first one.

 

Many thanks for help You all ^^

Posted

I used Ase models and i just made a brush wall model_clip texture... But just their exstence in the map causes (even without solid spawnflag) Mergemetatriangles taking too long...

It was just a observation.

With ASE models (no auto clip) - 18 minutes

Without them - 2 minutes
 

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...