How to know if your Model is Too High Poly or Not (Plus information on Nodes)

[drogoth232]

Thanks to BlackJax for most (if not all) of this information.

When importing into the newest brawlbox, when you see the MDL0 of the character (what you replace for the new character), you should see some values on the top right window. Facepoint count and Node count are the important ones.

Node count for brawl characters are around 300, although I have seen 600 (that might have been a skin wrapped character, though). Node count is essentially how accurate your skinning is. The more accurate (all the weights have like 0.0000000001 difference), the higher the value. The less accurate, the lower the value. When importing and using Tristripper, it's weight precision. A value of 0.01 should be fine, although you can play around with it and check your results out to see if a higher value would be better (with a value of 0.01, that means that values that are 0.01 apart are considered the same).

Node count can inflate when using the Blend tool a lot while rigging. Keep that in mind.

Facepoint count is the more obvious one. It's a value of all the Faces, Verts, UV Points, and some convoluted stuff that equates to the final value. In a vacuum, a Facepoint count of 17,000 will be around when a model will lag with 4 on screen on Skyloft (iirc). It is important to remember that the Facepoint count only takes into account models that are on screen. So if the model has expressions and has visibility bones set up properly, they won't affect the lag until they show up (but if you did set visibility bones up properly, there won't be a problem at all). This can be seen with Wolf and how his Facepoint count is at 22k, but he doesn't lag (because visibility bones are set up properly).

NOTE: High polycount = High Facepoint count
Low Facepoint count != Low Polycount

Just because you shaved off 9000 faces, doesn't mean you'll see that much of a reduction of Facepoints. But the best way to reduce Facepoints is by reducing faces.

I have no idea what the formula for calculating it is, but this is what I've found out from asking people and a lot of testing.

Hope you find this information useful.

Useful stuff:

Uber Vert Count:

I just checked out uber vert count (a simple google search will do wonders), it's accurate on the cube, but not on other objects (calculated uvc was at 970 while in bbox it was around 2k without being able to optimize the facecount any further). I might have been wrong, so I'm going to put it here anyways.

The link to it is here: http://www.ericchadwick.com/examples/files/HaywoodTools-UberVertCount.mcr

What you'll have to do is copy the whole page, open max and go to maxscript (at the top), go to new script. Paste it in, and go to file->save as and call it whatever you want (I called it uber vert count because duh). After saving, go to run and find your script and open it up. Then go to customize -> customize ui (or something similar to that), there should be a giant table that you can scroll down in. Go all the way down to uber vert count, assign a hotkey to it (make sure to click assign), and then hit that hotkey anywhere in Max.

It'll open a window up, upon which you have to select a single object (this is important, it is a single object. Not multiple) and then click on "Do it". It'll calculate the amount (which can take a while depending on how complicated your object is) and then output a result within the same window. Tadaaaa!


Beautiful, Yet Friendly Pt 2:

I absolutely recommend "Beautiful, yet friendly", specifically part 2 which is here: http://www.ericchadwick.com/examples/provost/byf2.html

I didn't find this myself at all (although I did just google it now), blerb brought this to my attention a few days ago and it's pretty great to say the least. A good read (albeit a bit confusing for the early starter).

Read the other parts too, if you have the time to do so.

 

[Llama Juice]

Solid information dude! In the PMDT we always would test on Green Hill Zone for lag on our models as that stage was surprisingly almost laggy all the time. Bowser's Castle would be another solid lag test candidate since that's pushing against the Wii's limits pretty hard.

As far as stage lag testing goes, we'd grab four shogun DDDs or Zeldas and toss them on the stage. For a stage to avoid lag you're going to want to aim for a triangle count of around 25,000 with 28,000 being your hard ceiling. Any higher than 28,000 and you'll encounter lag issues guaranteed. Try to have your facepoint count be under 50,000 as well. Also, things like higher resolution textures being used on your models will increase lag without increasing facepoint count. So if you have a bunch of higher resolution textures (In context of brawl modding, a "high resolution texture" would be anything 512x512 or bigger) you can easily run into lag issues with the Wii.

These are the guidelines that I came up with while creating my stages while in the PMDT. While the Wii can take stages with 50,000 triangles in it and run it seemingly fine in 1v1 matches as long as it's not zelda vs DDD but always design for lagless doubles instead, because then it should definitely give 1v1 matches a lot more wiggle room and guarantee lag free 1v1 play.

I hope you don't mind me hijacking your thread to include this information. Your thread wasn't titled with characters in mind or anything, so I figured there'd be a handful of stage people coming across this as well via google and whatnot.

 

[drogoth232]

Don't mind at all. I never worked in stages and the documentation on stages is quite lacking. This information will be great for everyone.

Plus information on textures is great. I was debating whether to include it or not because of a recent event that could be explained by multiple reasons.

If you could provide specific results and tests you ran with your stages as a benchmark for people in general. I'm sure the stage guys would appreciate it a lot.

 

[PegasusKnt]

For a stage to avoid lag you're going to want to aim for a triangle count of around 25,000 with 28,000 being your hard ceiling. Any higher than 28,000 and you'll encounter lag issues guaranteed. Try to have your facepoint count be under 30,000 as well.

Llama Juice, do you know how the number of facepoints in a stage is calculated, and/or what the best way to bring this number down is? I have a stage with about 22,000 triangles, but the facepoint count is about 55,000. I'd like to bring the facepoints down to your recommended number of 30,000, but I'm not sure how to go about it.

 

[blerb]

PegasusKnt you likely have very unoptimized geometry.

Game engines read geometry in a ton of different ways. Usually the polycount itself isn't as important as overall vert count, and even then your vert count as displayed in BB and Max isn't your "true" vert count.

Say you have a cube that has 8 vertices total. Each face has a unique smoothing group and UV island. While the vert count will list it as having 8 vertices, most game engines (Brawl included afaik) will actually read this as 24 verts, and potentially more depending on other factors. This is because the engine has to read each vert's individual normal direction, vert colour, material, and UV coordinates. When you begin splitting vertices along these UV and normal coordinates, the game engine no longer reads a single vert as one; it reads it as two, or three, or however many different times it has to refer to the vert.

In the case of our cube, each unique smoothing group and UV island means that each vertice is multiplied by 3, essentially tripling the processing power it takes to render it. Depending on what you're making, this may be necessary, but it's usually a large waste.

It helps greatly to understand these concepts if you're planning on making detailed stuff for any game engine. If you want a more in-depth (and much more accurate) description of what I'm discussing here, google the article "Beautiful, yet friendly". Also the max script "uber vert count". Both are made by the same person but his name escapes me currently.

 

[drogoth232]

I just checked out uber vert count (a simple google search will do wonders), it's accurate on the cube, but not on other objects (calculated uvc was at 970 while in bbox it was around 2k without being able to optimize the facecount any further). I might have been wrong, so I'm going to put it here anyways.

The link to it is here: http://www.ericchadwick.com/examples/files/HaywoodTools-UberVertCount.mcr

What you'll have to do is copy the whole page, open max and go to maxscript (at the top), go to new script. Paste it in, and go to file->save as and call it whatever you want (I called it uber vert count because duh). After saving, go to run and find your script and open it up. Then go to customize -> customize ui (or something similar to that), there should be a giant table that you can scroll down in. Go all the way down to uber vert count, assign a hotkey to it (make sure to click assign), and then hit that hotkey anywhere in Max.

It'll open a window up, upon which you have to select a single object (this is important, it is a single object. Not multiple) and then click on "Do it". It'll calculate the amount (which can take a while depending on how complicated your object is) and then output a result within the same window. Tadaaaa!

I will, however, absolutely recommend "Beautiful, yet friendly", specifically part 2 which is here: http://www.ericchadwick.com/examples/provost/byf2.html

I didn't find this myself at all (although I did just google it now), blerb brought this to my attention a few days ago and it's pretty great to say the least. A good read (albeit a bit confusing for the early starter).

Putting (almost) everything here in the OP as well.

 

[Llama Juice]

PegasusKnt make sure you have the tristripper on when importing your models. Try reimporting them with the tristripper on. Also, it's worth noting that depending on what your stage is designed around (casual vs competitive play) you can get away with some tiny tiny bits of lag if it's a casual stage. Casual Bowser's Castle is sitting at 60,500 facepoints and around 39,000 triangles... and it does have some very minimal lag on a four player match.

For the competitive version of Bowser's Castle, we needed to strip it down a lot further, and so we did a better job of optimizing that stage. The competitive version of the stage has around 49,000 facepoints and 30,500 triangles and we couldn't feel any lag on it. I always tried to focus more on the triangle count since that's a much easier thing to measure. If the triangle count for your stage is at 22,000 then you probably should be fine and not have a laggy experience honestly.

Now, there are other things that contribute to lag quite heavily, such as a lot of semi transparent textures layered on top of each other. Dracula's Castle for example had like 5-7 layers of clouds + lightning + moon + other stuff in the background that were all layering on top of eachother... and that gets really expensive for rendering, so that stage lagged pretty easily.

Also, avoid having materials set to "Cull None", as that essentially doubles the triangles for that object, but brawlbox won't count those triangles.

 

[drogoth232]

Also, avoid having materials set to "Cull None", as that essentially doubles the triangles for that object, but brawlbox won't count those triangles.

This makes so much sense, but I never thought about it.

I'm assuming you'd have it to Cull None if you really wanted to have them set to not backface cull anything.

 

[PegasusKnt]

Llama Juice Thank you for those very helpful statistics and information. This whole thread is a treasure trove, really. The bit about materials being set to Cull None in particular is so good to know- practically all of the materials in my stage are set to that, so I will definitely fix that soon. It's also good to know that Zelda and DDD are good test characters. I tried your test of 4 Zeldas earlier and sure enough I noticed a frame or two of lag. (Even if my stage is mostly played by casual players, I want to make it as excellent as possible, so I will work to get it lag-free with 4 Zeldas). It looks like tristripper is on by default in brawlbox, so all my models have it. If just fixing the materials doesn't work, I'll have to learn about more sophisticated ways to optimize. (will definitely read the aforementioned articles by Eric Chadwick).

 

[Llama Juice]

The Cull None flag is to be used in very rare cases, stuff like the metal fence thing that the koopa is hanging off of in Bowser's Castle uses that flag, but that's probably it in that stage. It really should only be used on things like that, where it's something that's thin, has a border around it, and could be seen from both sides without throwing the camera through a wall.

If you're using Cull None on a house in the background of your stage for example, then it basically makes two houses, one that's inside out, and one that's proper. The inside out one will never be seen, but it still is using up the Wii's very limited memory and it can cause issues with performance.

I always appreciate when people put in the work to properly optimize a stage, because I know how much effort I always put into making our stages run as smoothly as we could. For a stage like Bowser's Castle, that had a solid month of just optimization tweaks to get everything running the best we could. There were things that we created for Peach's Castle that never made it into the stage due to performance reasons. We made a baby yoshi to sit on top of the small tower on the right (with the red switch on it.), and we made a super koopa to fly around in the background of the stage. Hell, even the red coins that were in the background hidden about got swapped out between 3.6b and 3.6 proper to optimize the stage better.

 

[cramazzratazz]

Any advice on reducing node count?