RefPoint v2 value

[arno 1]

During the recent tests about the autogen exclusion we bumped into the fact the v2 value of the RefPoint isn't the radius of a circle in which the object should fit, but more the size of a square centered at the same point.So this thread is meant to take that discussion out of the autogen exclusion thread and have a look at other effects that might influence the v2. For example the scale of the RefPoint. Another interesting question is if the minimum value should be half the length/width of the square or half its diameter.Let's see where this discussion leads to :D.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[rhumbaflappy 113]

Hi Arno."Finally, at this is nice I think. I did a test with the v2. I made a circular shape polygon with a radius of 1000 meter. On top of that I draw roads in a square with sizes of 1000 meter (so the circle is bigger). Both had their own RefPoint. For the circle I set the vw value too small (at 500).Then I moved from the centre point forward at heading 0 and indeed the polygon dissapeared when I was 500 meter from the centre (just crossing the road). Then I did the same at a heading of 45 and now the polygon dissapeared when I reached the road again. That means that the v2 is indeed a square and not a radius as we have always thought.This makes me think, I should still test it, that we might have set the v2 value to big all the time. If you have a square of 1000x1000 meter then the radius is sqrt(2)*500 = 707. But maybe 500 is enough because we are talking about a square that should fit and not a circle anymore. I'll try to test this this evening." - ArnoIn addition to the ground polys, I now wonder about tall buildings, as well. Does the v2 need to encompass the height, as the SDK hints, or is this simply a square ground area that needs to enclose the 'footprint' of the object?And, I wonder about the effects of a RotatedCall. Does the v2 rotate with the object? If not, then a rotated object's corners might be outside the v2 area.. does that matter?V1 appears to actually be the radius of a sphere. If you set v1 at 1000 meters ( with the scale at 1.00 ), the object disappears at AGL +1000 meters... or at 1000 meters from the refpoint in any combination of x,y,z, following a spherical border around the refpoint.Dick

[arno 1]

Hi Dick,Here is the code I used for the test:

Header( 1 41 39 -39 -41 )LatRange( 39 41 )Area( 5 40 -40 35 )RefPoint( 7 :R 1 40 -40 v1= 10000 v2= 500 )Points( 0-1000 0	 0; 0 -707 0   707; 1	0 0  1000; 2  707 0   707; 3 1000 0	 0; 4  707 0  -707; 5	0 0 -1000; 6 -707 0  -707; 7)RGBSColor( EF 255 0 0 )Poly( m 0 32767 0 0.00 0 1 2 3 4 5 6 7 )RotatedCall( : 0 0 0 ):RRefPoint( 7 :R2 1 40 -40 v1= 10000 v2= 1000 )RRStart( 3 5 -500 0 -500 )RoadCont( -500 0  500 )RoadCont(  500 0  500 )RoadCont(  500 0 -500 ):R2EndA

I did some additional tests yesterday and I indeed think that we can use half the width of the square that fits around the entire object as v2 value (see pic, sorry for the quality). While we are now used to using half the diameter (which is square root of 2 bigger then half the width). I tested it with this smaller v2 value and didn't notice any problems.http://home.wanadoo.nl/arno.gerretsen/pics/v2r.gif>In addition to the ground polys, I now wonder about tall >buildings, as well. Does the v2 need to encompass the >height, as the SDK hints, or is this simply a square ground >area that needs to enclose the 'footprint' of the object?I expect that we also need to take the height into consideration, but we need to test this. For most object this will be no problem though, as the height is ussual smaller then the width.>And, I wonder about the effects of a RotatedCall. Does the >v2 rotate with the object? If not, then a rotated object's >corners might be outside the v2 area.. does that matter?Normally the RotatedCall is placed before the RefPoint and then the entire coordinate system of it is rotated. So that should mean that the v2 box is also rotated with it.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[rhumbaflappy 113]

Hi Arno.I'm find that v2 should be 1/2 of the greatest distance of either width or length of an object... and I can see how MS would have taken a shortcut, and called this radius, rather than explain the 'shape' of v2 is square.I've also found that v2 is meters, and not scaled, nor is it rotated... it's always alligned n-s, e-w.The v2 determines the distance the object continues to be displayed in the current viewpoint, as we fly away from the Refpoint. If you go to a greater elevation... and use ")" and "(" to tip the frontal viewport downwards ( in slew mode ), the object will "pop" into view just as the v2 point enters the bottom of the screen! The zoom function will also play a role here! This is very noticable with the use of your roads and the large red polygon. So v2 definately interacts with the viewport, and it's angle or rotation of view.Now while tipped towards the ground, over the object, and rotate the airplane ( Keypad 1 or 3 ) towards the corner of the roads.... again, the image pops into view as the corner of the road angle enters the bottom of the screen.So v2 is 1/2 the width of a north orientated square, measured in meters. This ties in with autogen's reaction to surfacetype... the v2 square must enclose the area of the surfacetype, or autogen disappears to the square shape of the undersized v2.I'd still like to know the effects of a building's height on all this. Perhaps the display calculation automatically adjusts for the building's height, and v2 need not account for that, as the viewport display should compute that.Now a question arises concerning offset refpoints ( transformcalls ? )... does the apparent v2 get offset, or do we need to account for this, by setting the size larger?Dick

[arno 1]

Hi Dick,>I've also found that v2 is meters, and not scaled, nor is it >rotated... it's always alligned n-s, e-w. OK, good to know. Then I don't need to look at the scale anymore.But are you sure that when you rotate the entire RefPoint with a RotatedCall that the v2 square isn't rotated with it? That sounds a bit surprising to me.>I'd still like to know the effects of a building's height on >all this. Perhaps the display calculation automatically >adjusts for the building's height, and v2 need not account >for that, as the viewport display should compute that. That would be interesting. I'll try if I can make a very tall test object and see the effects (if I find some time :D). I have no clue if MS adjusts for it or not.>Now a question arises concerning offset refpoints ( >transformcalls ? )... does the apparent v2 get offset, or do >we need to account for this, by setting the size larger?Normally you don't transform an entire RefPoint, but the transform is inside the RefPoint. So I would expect that the v2 square should cover the entire scene (with all the transformations accounted for). But it might be a good idea to test this theory :).Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[rhumbaflappy 113]

Hi Arno.You should probably double-check both scale and rotation. But It appears to me they have no effect.. so we would have to account for rotation in the v2 setting. That leads us back to the idea of using a circular... or perhaps spherical setting, even though the actual shape of the v2 is square.In other words, our v2 square needs to be big enough to cover the possible spherical, rotational bounds of an object.If so, MS is actually right, that the radius of a sphere that would enclose the object assuming all possible rotations. If we allign the object n-s e-w, then we can tighten the v2 to just 1/2 the width, and the display of the object would be fine.MS just forgot to tell us v2 was square, and a rotating square ( cube, actually ) becomes an apparent sphere.Height is what puzzles me now... I don't think height is a factor in v2.... but seeing as how we may rotate an object onto it's side, then generically, the height of a tall object makes a much larger sphere.If we don't rotate the tall object to it's side, then we don't need to include height into our v2 accounting... If we don't rotate an object around, then we can tighten the v2 to the greatest width.So our v2's, especially for library objects, and API objects, that may get rotated as they are placed, then need a circular radius, from center to farthest corner, so the objects don't disappear too soon from the display.Whew! *:-* Here's a top-down diagram as to how I'm starting to understand v1 and v2:Dick

[arno 1]

>You should probably double-check both scale and rotation. >But It appears to me they have no effect.. so we would have >to account for rotation in the v2 setting. That leads us >back to the idea of using a circular... or perhaps spherical >setting, even though the actual shape of the v2 is square.I looked at the rotation last night and I thought wrong yesterday. The RotatedCall is behind the RefPoint and that indeed means that the v2 is not rotated with it.I also look at a transformation and that has the same effect. Because this is inside the RefPoint the v2 value should be big enough to cover the transformed object, the value is not transformed itself.>If so, MS is actually right, that the radius of a sphere >that would enclose the object assuming all possible >rotations. If we allign the object n-s e-w, then we can >tighten the v2 to just 1/2 the width, and the display of the >object would be fine. True, and this is why half the diameter is still the minimum value for the v2. Otherwise not all rotations will work fine. Seems we had the same thoughts last evening :D.>Height is what puzzles me now... I don't think height is a >factor in v2.... but seeing as how we may rotate an object >onto it's side, then generically, the height of a tall >object makes a much larger sphere. I thought about a way to test this last evening, but I haven't had the time to do it actually (was working on the transparant texture tutorial).Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest GerrishGray]

Hi guysThis was an interesting discovery. I have just been doing some quick testing on it myself and I can add some further information.[ol][li]The shape of the v2 rectangle may not be square - I get the impression that the NS axis is considerably longer than the EW axis. Why anyone would program it this way is a mystery, perhaps it is just an error in the code or perhaps my testing was incorrect...[/li][li]The visibility check IS affected by altitude above the RefPoint - i.e. the calculation of whether the aircraft is inside the v2 'box' does take account of the vertical coordinate. Obviously, the correct calculation for the 'advertised' sphere should be sqrt(x^2 + y^2 + z^2). We know from testing that this isn't what is actually done, but my testing suggests that the z (vertical) part of it is done correctly! This seems very odd, although I can think of two hypotheses for how this may come about: EITHER the test is done in 3 steps, with the x and then the y, or vice versa, checks done on simple distance - hence the 'rectangle', and finally the z component 'added in' in a more accurate fashion, OR maybe a BSP/octtree type structure is used - which would also help explain the rectangle - but not very accurately set up.... just guesswork though.[/li][li]Thirdly, I have discovered that if one has an Area() with multiple RefPoint's, the v2 check is done using the first RefPoint only. If that check fails, the whole of the Area() is culled immediately. Strangely, if the first v2 check is passed, the individual v1 checks on the RefPoint's are done correctly, one by one, so that the different objects are correctly culled at their individual v1 ranges, so the behaviour of the v1 check is not the same as the v2 check - another programming inconsistency that is not in accordance with the advertised spec' in the SDK. The consequence of this is that the first RefPoint should be in the centre of the overall Area() and its v2 value needs to be set to cover the whole Area(), rather than being tight around the first object. I don't see this as any sort of problem - the overall frame-rate-saving effect is probably much the same as if separate v2 checks were done on a tight radius for each individual RefPoint'ed object (because the extra work of individual v2 checks would balance, to some extent, the benefit of the more accurate culling) ... it's just a "feature" that we needed to know about for a proper understanding and accurate programming!!! (As it happens, it has an important bearing on some of my tree macros ...).[/li][/ol]Actually, these features all strike me as 'fixes' that have been applied to code that was found not to be working correctly when it was first programmed - there seem to be quite a few instances of that around FS. But that too is only theory and I might be quite wrong!Incidentally, the overall effect of these features of the v2 check has been observed several times over the years, and this is why it has always been recommended that the v2 distance needs to be somewhat larger than the 'theoretical' value. But I don't know whether anyone got right down to the nitty-gritty of working out why before!CheersGerrish

[arno 1]

Thanks Gerrish, interesting additions again. I think we now almost have the complete picture.Especiialy what you write about multiple RefPoints interests me, I should do some testing with that as it is not how I thought it would work (and I want to see it before I 'believe' it :D)Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest luissa]

>[li]Thirdly, I have discovered that if one has an Area() >with multiple RefPoint's, the v2 check is done using the >first RefPoint only. If that check fails, the whole of the >Area() is culled immediately. Strangely, if the first v2 >check is passed, the individual v1 checks on the RefPoint's >are done correctly, one by one, so that the different >objects are correctly culled at their individual v1 ranges, >so the behaviour of the v1 check is not the same as the v2 Gerrish,Sorry for asking this but is the label in the first Refpoint correct?In FS98 and FS2000 I used the technique of placing several objects in the same Area block. In FS98 this was critical for frame rates. ASD for example places all ground (2D) polygons in the same Area block. I never got what you say and that seems strange to me.The code should be:Area()RefPoint( :second ... )... first poly here:secondRefPoint( :third ... )... second poly here:third...EndAor something like that if using LayerCalls to draw the polygons. Regards, Luis

[Guest GerrishGray]

Yes, my code had the structure you describe - that's the whole point of what I am talking about (although, of course, there is a PerspectiveCall before the Refpoints).You won't see this effect unless you include a v2 check in the first Refpoint and set it to a tight radius around that Refpoint's object.I have no idea whether you would get the same effect with LayerCall'd ground polygons - I was doing some testing on PerspectiveCall'd 3D objects. And, of course, to be accurate it's the PerpectiveCall that is actually getting terminated prematurely on the basis of the first v2 check, not necessarily the whole of the Area() (although that is usually effectively the same thing).Kind RegardsGerrish

[arno 1]

I looked at my scenery and I can say that for LayerCalled ground polygons (using the new FP commands) this effect does not happen. In that scenery I had about 400 polygon in one Area command with each there own RefPoint and they are all visible when needed. The v2 value of the first polygon (which was rather small) had no influence on the display.I'll do some tests with PerspectiveCall to see that that is the difference.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest GerrishGray]

Now, isn't that interesting! It confirms what Luis thought - that this doesn't happen with LayerCall. So the difference between LayerCall and PerspectiveCall must affect more than just the way that the object(s) are added to the display list.The intriguing thing about the PerspectiveCall behaviour is that if the first v2 test is passed, then the v1 tests are done separately for each of the RefPoints (just as one would expect for the v2 checks) - so I rather think that this is a 'bug' in the implementation of the v2 check inside PerspectiveCall - failure of the v2 test simply does an immediate return to the PerspectiveCall instead of actually following the :fail label ... I guess that the programmer assumed that this would be a valid shortcut and didn't think about the case of multiple RefPoints within the same PerspectiveCall'ed block.I would be interested to hear whether you see the same thing though, just to be on the safe side. I used some of my trees (of course!) but any other simple 3D object would do. I set the individual v2 checks to 25m and placed 25 trees on a 5x5 grid at 500m spacing - so the grid was 2km x 2km overall. I made the trees pretty big so I could see them easily amongst the Autogen, but you might want to use tall masts or something of the sort. The first Refpoint was at one corner of the grid (NOT in the middle) - which helped show up the effect. I wasn't looking for this, or expecting it, at all - I was checking Autogen exclusion! All of the trees disappeared when the first corner went off screen. When I kept them all in view and backed away to increasing distances, they disappeared individually as they went outside the v1 range - showing that the v1 tests jump correctly to the individual :fail labels.CheersGerrish

[arno 1]

I'll have a look. For the new terminal I am making of EHAM I have made each pier as a seperate object (in a library) and I put them all in the scenery in one Area block with each their own RefPoint. Until now I have never seen problems like the one we discuss here, but I can't remember if I had already put in the correct v2 values. This is surely interesting, so I'll have a look at that source and come back here :).Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[arno 1]

OK, it took some time, but I didn't forget it :). I had a look at my terminal source this morning and the v2 values where not yet set to their optimal values.After I did that the objects indeed all dissapeared when the first one was outside his v2 value.I think I had noticed this behaviour before, but then I didn't link it to this :).So I can confirm it and this is very interesting to now. LayerCall works fine, PerspectiveCall doesn't.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...