CaptBevvil
I HAVE A DEGREE IN FYSIKS!
Posts: 798
Correct.
-3do surfaces that are not facing the camera (in the slightest bit) are not rendered. This can be easily proved by creating a sphere 3do and placing the walkplayer inside of it on startup and checking the fps on a low end machine against that of not having the 3do.
-3do's do not render if the player is in a different sector from the 3do's origin and the origin for that 3do is off screen (even if the surfaces for the 3do should still be on screen).
-3do's do not render if the player is in the same sector as the 3do and all surfaces of the 3do are completely out of view.
Again, the last 2 can be varified on a low end PC by setting up the condition and simply looking around and checking the fps against each other. The last two are the source of the "flickering" problem. The work around is to constantly refresh their template by creating/destroying them thus forcing them to render momentarily in a repeated cycle less then the time it takes your monitor to refresh. This creates the illussion that the object is being continuously forced to render.
The thing that has led some people (for the first point above) to believe that all 3do surfaces are rendered even if not facing the camera is because flags and varibles such as "EMITS LIGHT" still work even if the surfaces are not being rendered. The thing to remember and keep in mind is that, even though the surfaces are not being "rendered" on your monitor screen, they are still being psedo-rendered by the system. By that, I mean, the system is still keeping track of the surfaces and which way they are facing relative to the player...which is how it knows when and when not to render the surfaces (and the texture across it) on the screen.
"The solution is simple."