Flux poly limits

This all seems rather unnecessary, since there are already professionally made 3D benchmarking systems available for free, like 3D Mark.

A good point it does bring up though is that maybe we modelers should package new content with documentation about poly counts and texture sizes, as well as the machine specs they were developed on. That alone should give new end-users an idea of what works for them and what doesn't.

Oddly enough, there doesn't seem to have ever been a huge amount of new models for EoC. I find that strange when compared to other space-sims. Even ones that are mod-unfriendly get all the basic popular ships early on (Star Trek, Star Wars, etc.). Could this be an unfortunate side-effect of the game not reaching the popularity it should have? It would be fun to think that I've opened the floodgates to higher poly modeling for EoC. Maybe I should put more time into the modeling chapter of the Ultimate Guide.

But does anyone know any of the poly counts for the Buda 5 models? They're pretty nice looking. They can't be too low poly. Oh well, if models didn't start pouring out of the woodwork after those things, I guess they won't after mine either. Too bad too, it's really not that hard to do.

Anyway, if you guys are dead-set on making a benchmark for EoC, I would suggest making an in-game movie as the test. Since the benchmark is specifically for this game, precise repetition of screen and object movements will be more important than knowing the number of polys on-screen. Also, you'll have to set standard rules for all the game option settings when running the benchmark. The sphere idea is a good one, you'll need to include a disply to indicate how many spheres are on-screen at any given time. And what would be really nice would be a Pog script that dumps all the relevant system specs and benchmark scores into the log atomically (for non-programmers; no, I didn't mean automatically) so all the user has to do is copy and paste that chunk of the log here at the forum.

Oh yeah, and don't forget to address mip-mapping. It could give you a false score.

Let me know if I can help.

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos (on hold during SW MP mod)
cartoons.sev.com.au/index.php?catid=4
.

Ok, but how do you relate 3D marks back to X number of ships displayed at 40 fps in EoC? We already know one system is faster or slower, but what is my budget for objects around stations? 100, 200, 10? None of the standard ships have known poly counts or texture sizes. Even a handful of spheres would at least let us calibrate the 3D mark score.

-Gtrout

I don't think I understand what it is exactly that you're after. What difference does it make what your budget is for objects around stations? It's only relevant to your system.

I think it would be fun to have a benchmark for EoC to compare scores, but I don't see how the scores are any more relevant to developement in EoC than they are for any game. Unless your trying to target your mod for a system with specific specs, or minimum specs.

Could be I'm missing the point entirely. What exactly are we trying to do here?

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos (on hold during SW MP mod)
cartoons.sev.com.au/index.php?catid=4
.

Originally posted by Second Chance

What difference does it make what your budget is for objects around stations? It's only relevant to your system.

What exactly are we trying to do here?

I want to know how detailed I can make a model and still have it display without slowdowns. Let's say I build the Dreadnaught and use 3000 polys and Flux displays it fine.

But what if I'm planning a mission which features a large space battle? Will 10 of the same ships slow my computer to a crawl? 30? 50? I don't want to build a craft with 5000 polys that drops my framerates into the negative when another ship appears.

Epic (I believe) has an enormous amount of polling (compared to the standard EoC game). And will also require a greater amount of polys to display around stations. Will the mod developed and tested on GrandpaTrout's machine run on mine? Or would I have to upgrade my computer just to play it?

We have no idea what limits Flux has with polys. Until we do, making a large-scale mod for EoC is a little like designing a building when you don't know what's in the foundation. How many floors can the building have? Who knows? Just build it 'till it falls down. That's the way we currently operate.

I think the tests should be run on a couple of cards/setups.

The Sandbox mod would perform this test well. Very little polling; all items created on the fly and then set free (well... given attack or defend orders... nothing we can do about that). If we perform tests in free-form mode, no mission polls should interfere. What do you think GrandpaTrout? What size spheres (poly-wise) should we use? Should they be textured?

Edit: Whoops! My bad! Of course, the spheres will all be 800 polys. There's no reason to build a larger sphere... Flux doesn't like more than 800-1000 polys per section.

Will the mod developed and tested on GrandpaTrout's machine run on mine?

Yes, this is exactly my question. Getting some testing on even a few machines will help figure this out.

By 'my' budget I really meant budget for the Epic Mod. Finding some way to predict how well things will work so people don't spend hours placing cool objects here and there only to see them ripped out at the last moment so the game is playable. Or forcing us to change the nebula textures or something else horrible.

Good idea about the standard test numbers though. By getting some feel for the relationship we don't really need this "test" to run on more than a few machines. The "minimum" can just be spec'ed in 3D marks.

As far as texturing: do we think that the slow down when viewing stations is mostly caused by polys, textures, glowing panels, or lights?

Sandbox will work great. And can place the objects far away from any current station to avoid "interferance".

-Gtrout

As far as texturing: do we think that the slow down when viewing stations is mostly caused by polys, textures, glowing panels, or lights?

Hah! Interesting question... wish I had an answer.

The pause the player gets when a large object is placed is interesting. For instance, using the Sandbox I can create a standard Puffin tug. No pause. But when I create a carrier I get a momentary slowdown. The next time I create a carrier (in that session) there is no pause. Which leads me to believe the object is loaded from resource (which means for some reason it's not loaded during the 'Loading' phase of launch). When needed again, the object is already in memory and displays instantly.

Judging from what I've read on 3D-engines (which is not terribly much), the biggest hit Flux would suffer is the caculations needed to ray trace the lighting (how it illuminates polys/where shadows fall/etc.).

Some elements which will affect frame rates (and please add in any else you think of... I seriously doubt I can name everything). Then we'll see what we can get rid of for the tests.

Any polling of the CPU. This could be a mission directive or something as simple as watching to see if the player ship is still alive. Traffic patterns, combats, current wingman orders, etc.

Raytracing light (as mentioned above).

Number of polys currently being displayed.

Resolution of surfaces of polys (textures).

Reflection properties of textures (glossiness).

Phong shading of polys (smoothing).

Transparency of polys (for glass).

Enviromental elements (nebula backgrounds, starfield quality, etc.)

Animations/special surfaces (i.e., glowing surfaces).

Subsystems.

Collision hull complexity.

Size of polygons (This one may be way off. I've never heard that size of an object can affect framerates. Then again I've never heard that it cannot, and it seems reasonable. More knowledgable people can feel free to shoot this down if I've gotten it wrong.)

Anyting else I've forgotten.