posted 01-06- 08:00 PM               

On the other hand, there are definitely polys that he will never see regardless of his viewing angle (under the seat for example) which can be deleted.

Things like knobs are good candidates for billboarding. Take a look at the knobs on the P-38 and you'll see that they rotate to follow your eyepoint. This has the effect of simulating a ball but in fact is only one polygon, textured to look 3-dimensional.

Polys *are* rendered when they are totally obscured (which is different from not being visible at all). We depend on the Z-Buffer to cull out polys which are covered by closer polys.

This is something that is high on my list to change, which will speed up many different areas of the engine.

posted 01-06- 08:13 PM               

I think it is best to delete faces that will never be seen.

The engine uses a thing called a Z-Buffer, and also maybe polygon sorting. .

As brief explanation of a Z-Buffer, it is a bunch of 16 or 32 bit numbers in a grid the same size as the screen, i.e. a 640x480 screen will have a 640x480 table of 32bit numbers. This is stored in video memory for speed and is one of the reasons a Voodoo2 card will do only 800x600 with a Z-buffer and 1024x768 without, or as some people perceive it, 800x600 in Glide and 1024x768 sometimes in D3D. What happens is that when a pixel is drawn, it has a depth value. When a pixel is about to be drawn, its depth value is compared to the corresponding position in the Z-Buffer, and if it is deemed to be closer, it is drawn and the Z-Buffer is updated, other wise it is not-drawn. The Z-Buffer starts out as the maximum distance away. Transparent stuff has to be handled specially because you normally want things behind a transparent object to be seen.

If polygon sorting is also happening, then yes a blocking door may help FPS slightly because only the comparison phase is done, and not the actual drawing. I don’t know how much help this is really unless you are already coming close to your 3D cards fill rate limit. If polygon sorting is not on then it’s probably dependent on how the polygons end up in the rendering stack and could be a 50/50 proposition.

Hope that helps

Bryan

posted 01-07- 06:03 AM               

"The key thing is "the graphics engine doesn't draw faces which are pointing away from the point of view" Your assumption would only be true if the object switched out in all other views. Otherwise... "

The sentence that you quoted is always true. If the poly is facing away from the viewer, it is never sent to the video card.

JT,

"isn't it more efficient, or just as ,to just model the knobs in 3 dimensions"

absolutely not. Even if a poly isn't truly visible, if it's in the viewing volume (the "pyramid" that represents what the user can potentially see) the engine has to do a number of tests on it before finally rejecting it from drawing. There isn't any code in the world that's faster than code which isn't executed.

specifically to knobs, think about what you see when you look at a perfectly round knob. If it's featureless, you'll see a relatively smooth surface with highlights from the nearby lights. An illusion of a 3D knob gets the job done just as well as a full-3D knob and is more efficient at runtime.

posted 01-07- 08:52 AM               

I agree. If one is willing to take the time, one can find polys that are never seen (undersides of objects, etc). For example, none of our houses have foundations. You never see them so the poly would be wasted cycles.

Joe,

No, LOD's always exist. They just aren't clipped and sent to the screen if the aren't in the viewing volume or have switched out due to distance.

The highest LOD of an object (if it's not marked with obNoCollide) is also used for collision detection, which is another reason to:
1) Use LODs wisely. If the object is far enough away that the user can't the the detail you've put in, it's wasted detail. Add a lower poly-count LOD. Because the highest LOD is used for collision detection, remember that if you've got a high-detail object on your aircraft and a tracer goes through that area, all the polys in that object will be tested for collisions. That takes time. Again, remember that code/cycles not used are the fasted in the world
2) use obNoCollide whereever it makes sense. For example, smoke is set with obNoCollide. If we did collision detection on every poly of every smoke trail (remember tracers), the framerate would end up in hell.

posted 01-07- 09:53 AM               

When I study the shipping FS planes I notice that the detail is kept quite high for fairly far distances. Why is this? It seems like you could get away with simpler shapes at closer ranges and not lose anything. Is this an attempt to limit the amount a plane morphs as you get closer/further?

My SE5a sucks poly wise It kills FPS, it was meant to be used for learning only. It is so tempting to give detail everywhere, but the FPS hit is obviouse. My cockpit view is what suffers most - I guess cause you can see the top wing, etc. and there are more ploys in front of the pilot than the average WWI plane (machine gun, foster mount, wind shield)

Does it matter how big the polys are? I have a lewis machine gin with like 600 ploys itself LOL! But when I delete it from the plane I see NO FPS gain. Most of the polys are very small, is this why?

Any other tips about LOD switching out, max polycount, and anything to help FPS would be very welcome!

posted 01-07- 10:10 AM               

Do you suggest to add the obNoCollide property to LODs that do not have the obDamage property and does not have any obBodyPts?

posted 01-07- 11:13 AM               

Sv Great questions man I have been wondering the same things forever and asked on 2 seperate occasions for answers. Maybe their not out there..

Mine were
Whats the max poly count for a

1 engine 1 crew plane (fighter)

1 engine 2 or more crew plane (figher/bomber)

2 engine plane (fighters/attack bombers/med bombers)

2,3 or 4 engines plane (med to heavy bombers and transports)

I know those arn't cut and dry but i would love a good estamite to work from.

Also i'll add to that Sv's question about poly size?

and one more about LODS k do more lods make the engine work more?

does having 5 lods for a wing hit the FPS more then 3?

what if i want to make a right hand wing for my p40 out of 4 detachable parts instead of 2? Will that hit the FPS by much?

Is the AI positions in bombers or the higher poly count the reason they hit the FPS so hard?

posted 01-07- 11:44 AM               

I think not. 600 faces alone won't really make a noticeable hit on framerate. The problem is that if you have that gun on multiple planes and those planes are on screen, the polygon count is multiplied dramatically.

>My SE5a sucks poly wise It kills FPS, it was meant to be used for learning only. It is so tempting to give detail everywhere, but the FPS hit is obviouse.

Heh, don't worry about it, dude. Technology will catch up to you in a couple of hours.

posted 01-07- 11:49 AM               

I realize that. I was just wondering about the efficiency of billboarding, since billboarding has to constantly position something. I was under the impression that it was only useful for objects like clouds, since there are often so many clouds on the screen.... so many that there's a significant advantage to not modeling them in 3 dimensions. Sorry if I was unclear.... it's really tough to pose questions about visual stuff sometimes :-)