|
Waterman
|
 |
« Reply #8 on: December 13, 2011, 07:20:56 PM » |
|
Ya that must be a depth sorting issue. If the trees are billboards, then their rotation matrix is bound to the cameras rotation. Maybe that's why they disappear when just turning the cam. And related to what Mith said; meshes have center points, by which various comparisons take place. It's always good to have them clearly distinguished, so that not all mashes are located at (0,0,0) or identical coordinates.
I don't know what you actually code, but IF it's some kind of train (or large area) simulator, your technique is not good. As such, it's correct to keep the camera at 0 and move everything else. But going your current way, you lock yourself into technique of adjusting the position of (more and more, as your scenario gets richer) objects - per frame! Plus you have no realistic motion (with mass forces, G forces) for the train (and actor, everything inside the train).
It's never good to do too much work per frame. And you now probably have a repeating schema for the trees? I.e. you have no way to get variations in their locations. No (easy) way to get more dense forest, other types of trees, groups of trees, bushes... odd mysterious boxes along the path :-).
Instead, you should use minimeshes for the trees. And work in the domain of 0...1000 meters. Each time your train (and camera) is further away from (0,0,0) than 1000 meters (or TVUnits), move EVERYTHING back to (0,0,0). The train, camera, landscape, minimeshes. As you do it, you just add (1000,0) to a variable called Orig (that holds X,Z). If you go backwards with the train (or actually any X/Z direction), just move accordingly, so Orig may also be e.g. (-3000,4000). Use SetPosition(GetPosition() - deltaOrig). Also SetBodyPosition() accepts that happily.
This way you get a proper coordinate system for the landscape. This allows for sensible management of landscape chunks and all the rest - i.e. seed new trees at surrounding chunks (of e.g. 1000,1000 in size) as the train moves. New trees in chunks ahead, and discard from chunks to forget.
One reason to stay close to (0,0,0) in ALL positioning calculations is indeed also Newton and it's maximum area... was it 10000x10000 by default? Or 30000. Anyway, and this is IMPORTANT: Once your train (and camera) reaches a position of "a few thousand" along X or Z or both, movement becomes CHOPPY. You can see it easily; movement happens in small but increasingly bigger portions, as you get further away from 0.
The reason is that DX works with singles only. 32 bits gives max 7 significant digits and it's apparent that small increments cannot be added to large numbers with that precision. Only when a big enuff number is added (the accumulated movement of several frames) it's actually realized visually - whop, jump! You must get this right from start, otherwise you're doomed.
Another advantage is that you can check the current position only occasionally, say every 10 seconds - no need to do it per frame. If pos is over 1000, re-set everything back to the zero domain. That's only one step, then you have fast business as usual again until the re-positioning is triggered next time, maybe several minutes later.
Are you using Engine.SetFPUPrecision 1? You should do that, otherwise you have only single precision even though you define doubles in code. The doubles will have only 7 significant numbers instead of 14. By using doubles (with SetFPUPrecision 1) you can define exact geographical (absolute) positions accurately, then pass them as needed to Newton (which uses singles) in the (0,0,0) domain. I.e. (AbsolutePosition - Orig) = what you tell Newton.
Well, 5 cents :-)
|
