Flux poly limits

My testing of POG performance leads me to think that the game is reserving a fixed slice of time for script execution. Even a very tight loop will only slow down the system until it hits the max slice, and then it will stop.

I am getting this information by watching the performance meter (flux debug feature) while running dozens of highly intensive loops - just to see what happens.

Essentially, POG scrips can choke each other out, but they don't seem to change frame much.

Shane, I think your right about the "load" performance drop. There is a POG command that "preloads" a sim. Preloaded sims are created without delay. Unloaded ones always pause.


If I understand what you are saying about lighting, every light source must be considered by every poly (for reflection). Which means that bright lights - like the counter measures - are going to cause a fair amount of slow.

Is there a non reflective light? One that is visible to the player but does not get factored into surfaces? That might be a good choice for navigation lights, or window type lights.

-Gtrout

But again, what good will the information do you? Everything you just asked will have a different result on each machine.

If you want to reference the foundation problem, you're not looking deep enough. We know what the foundation is made of. The problem is, the ground we build on is different for each system. In my experience, there are no poly limits for game engines. The number of polygons displayed is purely a function of the hardware. So some machines have a mile of solid granite to build on, and some machines offer nothing more than mud.

So yes, ten 5000 poly ships might cause my system to throw up, but GT's system might not even notice 20 of them. You cannot know how detailed you can make a model without it causing a slowdown unless you specify which system it's going to run on, because Flux doesn't display it, the video card does. And every system's hardware is different. Even the stock EoC ships will cause a slowdown on somebody's system (like one with an old 8 Meg vid card). That's why games have minimum and recommended hardware requirements.

edit - this post was supposed to come much farther up, but my ISP is on the fritz. It sounds like what you're really after are some minimum hardware specs to run a dozen several-thousand poly ships on.

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
.

So let’s make a mini-mod to cram people’s screens with spheres, and we’ll each run it. Then we see how many our comps can handle with a reasonable rate, and post the results. That way we’ll get a picture of how many polys many different machines can handle.

Is there a non reflective light? One that is visible to the player but does not get factored into surfaces? That might be a good choice for navigation lights, or window type lights.

I think this is something Second Chance solved a bit ago. Short answer (from what I understand of it); Yes. When we place a standard light in the game (meaning, incorporate it into the avatar setup scene) it does not 'shine'. Only the lens flare is visible.

For instance, the Spiff model had a helmet-lamp. Because of its flare options it's visible to the player... but it does not illuminate any nearby polys.

I seem to recall Second Chance mentioning a light had to be named 'glow' to actually illuminate objects.

So let’s make a mini-mod to cram people’s screens with spheres, and we’ll each run it.

Worked on it some last night. The sphere has 812 polys (some quads, some triangular). However, the model itself didn't show up (I obviously screwed up something in the avatar or ini file - I've gotten rusty). Worked on it for about a half hour, then said 'screw it' and went inside to play Ratchet and Clank. I'll have another go at it tonight.

But again, what good will the information do you? Everything you just asked will have a different result on each machine.

Exactly. But we're looking to develop mods that can be run on some of the slower machines. So we run the tests and look at the data and base our mission design/model quality on the lower-range specs so the majority of the fan base can play the mods. Like GrandpaTrout, I don't want to spend my time putting in extra gantries and dockports and intricate ships if it turns out older systems cannot run them. (Although I'm probably pretty safe... I'd bet I've got one of the slower machines/cards.)

Shane, I think your right about the "load" performance drop. There is a POG command that "preloads" a sim. Preloaded sims are created without delay. Unloaded ones always pause.

And that's interesting in itself. Why would the programmers choose to have the program preload a Puffin during launch, but not a carrier? My only answer to that is that the carriers are more rare and usually tied to a script (i.e., they appear when you shoot up a station or when a mission determines they will appear).

Now here's the funny thing. Notice that a lot of the more common ships have their setup scenes located in the folder 'Common Setups'. Do you suppose the items in this folder are preloaded at launch and others are loaded when needed? Certainly the designers would seek a simple method of selecting which craft are preloaded (and one which could be easily modified). This method would fit the bill.

Originally posted by Shane

Shane, I think your right about the "load" performance drop. There is a POG command that "preloads" a sim. Preloaded sims are created without delay. Unloaded ones always pause.

And that's interesting in itself. Why would the programmers choose to have the program preload a Puffin during launch, but not a carrier? My only answer to that is that the carriers are more rare and usually tied to a script (i.e., they appear when you shoot up a station or when a mission determines they will appear).

I use the preload command in MP to prevent the game from stuttering when a new ship joins or new bots are created. It does make a difference.
I think you're right in your assumption on the carriers being script specific and not general traffic. But remember, the size of an object makes a big difference in the frame rates too. (I'm asuming size is not always directly proportional to poly count)

I do agree, that we need a means of calibrating something like 3DMark preformance to specific parameters in EOC.

Also note, a number of newly created identical objects will stall the game too. Remember, I made a wall of cargo pods ( I think it was 270 of them or the like) to give us a rough estimation of the sim creation time for the Death Star? It's somewheres in the DS thread IIRC. In it I noted the loading delay caused by creating all 270 of them (1/10th sec. each?) Now, by using different pod models with different known poly counts for the pods in that "wall" we could see if the Poly count has an influence on the sim creation delay time too.

Postulation: Poly count shouldn't have a measurable influence on sim placement delays (stuttering) for multiple identical sims: Because, once the first sim is created, it's preloaded!
i.e. stuttering is primarily due to the creation, placement and positioning loop and would remain constant(for the same PC/preformance specs) independent of the individual objects poly count [?] [?]


Iwar2 Multiplayer Fan Site

Right. And, right again, Shane. You memory about the lights is excellent.

Designing for a minimum spec makes sense. I can live with that answer.

And good guess about the preload situation. Essentially, right on the money. It would be nice to preload all the game's assets, but that eats up memory - fast. And the designers know that they can only use X amount of memory to load assets with (X being a common amount of memory equipped in new machines at the time). The Puffins are everywhere, the carriers practically nowhere. So it's easy to see why some ships are preloaded and other aren't.

If I remember correctly, the Common in Common Setups means in this case that the various setups are shared by several different ships. Although they are commonly (frequently) used as well. If you look at one of these setups in LW they have about 100 redundant subsims placed all around them. One ship variant uses one particular set of subsims, a different ship variant uses another. But all the ships use the same INI entry for the setup scene. And they can all be accessed and worked on from one file. Very clever exploitation of the system.

btw - GrandpaTrout is dead-on about the lights in a scene. Adding lights to a scene will give one of the biggest frame-rate hits there is. In fact, many (older) engines were designed to be able to handle only a set small number of dynamic lights (remember, old FPS game lighting was static and "baked-in" before hand by the editor), or none at all. Particle effects too are quite costly.

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
.