scubaman3D 0 Posted January 26, 2011 (edited) I'm not exactly wanting to dig up an old thread, but well I'm interested in the answer to a question.If theres a 8bit (32,767) max number of vertices, how many are actually drawn in the engine at any one time? Or is purely a per model constant... yet you mention DirectX? as an example, I'm working on a vehicle for VBS2. The customer required that it had a 3D interior and it will have a functioning ramp that you can climb in and out of. The poly count is currently ~22,000 triangles (~16k O2 'points). Bulldozer can render the model without a problem. However, if I select my model and hit 'U' to sharp all faces, this blasts the amount of vertex normals past 32k and bulldozer gives an error "Too many vertices" and will not render anymore. The point count remained ~16k but the vert count changed. For this reason, it is smarter to split geometry along hard edges to save on the amount of vertexes. This allows you to play with the 'sharpness' of edges without sending vertexes over the limit. Unfortunately, I don't know how to get O2 to tell me how many vertexes there are on the model.. Edited January 26, 2011 by scubaman3D Share this post Link to post Share on other sites
sparky 0 Posted February 25, 2011 (edited) I thin that vertex count and polycount are at the bottom of your O2 screen. About proxies. Be cautious, although proxies is a good technic to save some of the polies actually made on the vehicle, there are some things that you need to take care and walkaround them. i apologize to the admins about reposting a post of mine from an other thread but it's the best example to demonstrate the proxie use. The following is part of the HWM pack 4.0 release which included an ah64a. -------- ok, since we've promissed to reveal the polycount. here it is. The AH64 is quite BIG poly, BUT, we based the design, on proxies in order to minimize the parts render by the engine at a time, and make it off course loadable in game. Unfortunately since the model has a lot of details, we've created quite a few maps to get textured and in quite big size cause we wanted the best we could get. And that has as a result quite a few sections. Although we gave our best to eliminate ST point errors, no planar face errors, nd keep the section count the minimum, still we are quite high. Also keep in mind, that all the 3 weaponry versions are based on that one p3d. But anyway. Here the screens The 1st O2 screen represents the AH64 as is in game, proxy parts are visible by the triangles The next image represents the WHOLE ah64 combined, no proxies, higher version of cockpit that in the ingame version areavailbale only to pilot view and gunner view and even the missiles. You can read polycount/tri count and sections on the bottom, the last image hasn't very meaning since you can't have this polycount drawn at a time, basically cause of the cockpit, which are visible only in 1st person view, for 3rd person view it has been replaced with a simplified proxy of them. --------- comparing the previous images you can see that we have designed the wheels, the missile pylons, the whole interior cockpit,the tads and some other parts as proxies, also by noticing the bottom of each image you can see that we have already break the barrier of 30000polys (quads - no tris) since Arma1, using the proxy technic. BUT, here are the side effects. at least for ArmA1 since i haven't work with Arma2. 1)Engine doesn't handle proxies the same, which means that damage textures etc, aren't change for the proxie parts, you need to work with scripting technics in order to make an illusion. So, better use proxies for smaller parts which probably you will make them disappear when the vehicle will destruct. 2)since proxies are rendered seperately of the main object, as seperate you can have layered problems, which means that you can see some parts through the other, or you won't be able to see. alsop digging up, that post i found an other research of mine about what a high poly model could cause to your system (ArmA1), here it is. ------------------------------------------------------------------------ Well i think it doesn't matter very much the polycount at this point since the source for the BIG Fps drop is an other factor. So to sum up Issue -Stringtable problem with the non_English ArmA Versions (will be fixed in next version) -FOV although FOV isn't really an issue but a personal taste thing, since the majority wants a closer FOV, it's going to be fixed -Flight Model, Well at this point we can't invest very much in researching for the ultimate FM, but we will try some ideas to find a better one -Leopard Armor, well don't worry about that wait and see... -Tail Rotor, wrong spin direction, will be fixed in next version. -Glass grey effect, that issue needs some research before we can have a solution, we're going to try though. -Bullet Proof glass, Can easily fixed. The Chopy/Frame Drop Issue After the frame drop issue, we begun to invastigate in order to find the source. We do a varius tests in order to see different combinations and sum up with the safest results. Scores that will presented here, are from my PC which is at the low-med PC category to RUN ArmA. The configuration is Intel PIV Prescott 3.2Ghz, 2GB Ram 400Mhz, ATI X1950Pro Sapphire 512MB Ram AGP. ArmA configuration, all options to max, with terrain detail LOW, postprocess LOW and view distance 1630, Screen Resolution 1280X1024. With the following PC and ArmA configuration i Have 25-28FPS in an empty Rahmadi. The test was to have 9 empty AH64A's with players back at them and when the mission starts to turn and face them in a way that all of them can be on screen from close distance Results As you can see the number of materials and Texture sizes doesn't have great effect on the FPS Drop issue but the Major Factor for the FPS Drop is primarily the Huge Number of selections and secondly the shadow polycount and the model polycount. Indeed if you consider that there are around 78 selections only for hydra missile proxies, plus 78 for the flashes, plus 16 for hellfires the number is raising quite high. The better results for a low-end version could be a version that uses the 2nd LOD as 1st, and with no missile proxy disapearing or flashes (at list the way we do it now). Also the thing that must be revaluate for this version is dummy selections that have been left there from editing and probably have no use, but may raise the lag possibility, and a better more less poly shadow, or even an other lod (no matter if i think that won't have FPS effect since the problem is greater in closer distance. Also we need to consider the possibility for an other last LOD very low poly, and lowering the Resolution LOD numbers in order to achieve faster lod switching if that's possible. Hope that table can helps others to learn what thinks to avoid, in order not to face the same issue as we do. ------------------------------------------------------------------------------------- these are all i can remember now. The key when using proxies to lower your polucount but keeping the details high, is to use always smaller parts which aren't significant for the engine as proxies and not big and significant, like a turret or the maingun cause you will have problems. And off course try to make proper LODs Edited February 25, 2011 by Sparky Share this post Link to post Share on other sites
Kraetzer 10 Posted February 25, 2011 For sure the Texture of one Model makes not a Problem but bring up many with 2048x2048 in the same area and you will get your drops. The Drawcalls weight more than the Polygones. Share this post Link to post Share on other sites
