by lcsaba » Thu Aug 16, 2007 2:40 pm
Hello,
I would like to summarize my experiences how to create FMS panorama landscapes using FMSXYZ and FMS_PL, and hoping that Perry would have time to improve FMSXYZ I am collecting the present bugs, and giving some thoughts, how to improve FMSXYZ in the future. A lot of things can be done. I hope finally spherical mapping would be possible as well. (In this posting I will not deal with the “sky†problem.)
1. “,†is used instead of “.â€, I have downloaded the last version.
2. If the 2*8 pictures are produced by FMS_PL two pixels overlapping should be used.
This is the first picture U, V> X, Z, Y mapping of FMS_PL. This is perfect. No white stripes are visible.
TEXTURE 1-1
254.75 254.75 212.13 212.13 0
254.75 0.25 212.13 212.13 256
0.25 0.25 0 300 256
0.25 254.75 0 300 0
0.25, and .75 suggests me the two pixels overlapping. By the way FMS_PL can make the pictures from .jpg pictures as well. The size of the picture made by PTGui varies, if it is bigger than a limit, the FMS_PL error message is sent, no reason code is given. Finally I figured out that if the picture is converted to .bmp it is ok.
Remark: Some postings before I suggested to smcxx66 finding a conversion program, and converting spherical photos made for reflex to cylindrical. Now I guess it is possible that this type of converter doesn’t exits. The reason is that a parameter should be given to the converter.
The spherical goes up to the zenith. If it would be converted the zenith would be infinitely far away.
TreeHuggers example above gives 60 degrees as “maximumâ€. PTGui can not make “normal†pictures above a certain degree. FMS_PL and FMSXYZ requires +/- 45 degree cylinders.
If somebody would like to play with cylindrical pano I can offer what I am making. The first which is now licensed similar to the presented one, see above.
Possible improvements:
The design goal of FMSXYZ is to visualize and make editable the 3D sceneries.
1. Ddwanner has already asked to have this feature in the case of panorama pictures. Perry said if he had time he would look after this. Now I have to tell you, that in certain conditions the crash object (I am playing with) is visible. If edited in the .scn text file the position is properly presented, it can be moved but the coordinates are not kept.
2. The size problem. Some posting above, I have mentioned this problem. TreeHugge, if I understood him well, has said that because we have panorama picture, which is in fact a wall painting, either on a cylindrical or a globular “wall†(or box) and the observer is in the middle there is no sense to talk about distances. BUT my landscapes diameter is about 600 meter; meanwhile the FMSXYZ diameter is 2400. I have made a change. I have divided each X, Z, Y number with 4. The result is a view which is identical to the big one but if the airplane is flying towards the wall it crashes earlier, and therefore its size is bigger at the moment of crashing. It would be nice to introduce a scale factor at FMSXYZ. I can do by editing. Now it is easy because there are 16*4 lines only, but later this number can be bigger (better approximation, spherical mapping).
Finally I have to mention, that I have find out the reason why are so enormous U, V to X, Z, Y, mapping lines at Riesa crash objects definitions. The black background is not a black square instead the contour of the object. Therefore not the four vertices of the black square are defined, instead all vertices of the polygon covering the object.
My effort now is to use squares even if those are not covering the object (tree) but inside the tree. In this case the “skirt†of the object will be on the remote wall. I am not expecting collision problem, mainly because the collision points of various FMS models are very incidental any way, but how the model will disappear behind those is a question.