Ade_gp 0.0.92

[robystar]

Hi Don,

Sorry for the delay (I watched the Tour de France).
In reply, the following:
- I did not have any problems in GECE anymore except that the gp_poly program complained about triangulation difficulties and it still does. Nevertheless everything shows up fine, and as far as I am concerned, it can continue complaining as long as it wants to as long as it does what it should do.
- you have my very simple ADE workfile and I used textures that were already in the base texture and line def files (including the H from the gp_signs_white). Have you tried it out? Do you experience the same blurring or not?
- taking out the effect does not help.
- the foreground is blurred because it is default landclass and unless I put in some Hires photo texture it will always remain blurred.
- I do not know what the layer of the underlying terrain is. There is the default landclass and the flatten, nothing else.
- if different layer numbers are not relevant, how come the difference in visibility?
- in FS9 the standard heliport graphics are not transparent as far as I know.
And as for GECE and this triangulation error thing, I think the answer is given by you already when you said that when two vertices are superimposed they give lead to this error message.
What strikes me, Don, is that you say: ADE_GP cannot control how FS9 or FSX displays things. As I have said many times before, if it displays at all, ADE_GP has done all it can. and I do not think that is true or else it means you are trying to tell us that your own results give you the same aberrations as we are experiencing sometimes?

Roby

PS did not mean to sound harsh. It is just that I feel you are losing faith instead of George.

 

[gadgets]

It's not faith I need but a more descriptive error message

At that point, the object has lost its identity. It's just a poly to be triangulated and the triangulation routine is unable to triangulate it. You've got all the information available.

That being said, the editor already has a check for complex polys and, I've just added one for superimposed vertices. So, starting with the next release, you'll get the warning in the editor (as well). Also, I'll expand the user manual in this regard.

Don

 

[GHD]

Thanks Don.

BTW. I still get the odd occasion where the line texture is not being displayed, just the line background:



Another edit to re-select the textures fixes it.

 

[gadgets]

I did not have any problems in GECE anymore except that the gp_poly program complained about triangulation difficulties and it still does. Nevertheless everything shows up fine, and as far as I am concerned

I'm at a loss to explain this since on my system it compiles without any error. (Do you have a 64-bit system? If not, that might explain it.) In any case, if you "wiggle" some of the vertices in the lower left-hand corner, the issue will probably go away. Since you don't see any effect, then the faulty segment - in this case likely the last to be triangulated - probably has 0 area.

- the foreground is blurred because it is default landclass and unless I put in some Hires photo texture it will always remain blurred.
- I do not know what the layer of the underlying terrain is. There is the default landclass and the flatten, nothing else.

If it's default, then layering is not an issue. That's why I said "might". If you are updating an add-on, you have to be cognizant of what your "predecessor" has done.

if different layer numbers are not relevant, how come the difference in visibility?

Don't know what you mean by "difference in visibility". If you are referring to the less-blurred "H", then I would point out that the screenshot appears to have been taken from a slightly different angle/elevation (the distance from the peak of the roof of the house to the top of the trees behind differs between your S/S 1 and 2 on the one hand and 3 on the other) and you original concern was

the H (groundpoly) still disappear at a certain angle

in FS9 the standard heliport graphics are not transparent as far as I know

Could be. I simply offered that as "by the way". You did not comment on your texture sheet size.

What strikes me, Don, is that you say: ADE_GP cannot control how FS9 or FSX displays things. As I have said many times before, if it displays at all, ADE_GP has done all it can. and I do not think that is true or else it means you are trying to tell us that your own results give you the same aberrations as we are experiencing sometimes?

I'm not that subtle. If I can duplicate your issues, I'll tell you. If I can't, I'll also tell you. What I'm telling you with that statement is that ADE-GP simply specifies to FS (via the compiler output) that a certain texture is to be displayed between three points (defined in relation to the ARP) at the elevation of the ARP. ADE-GP has no control over how FS does that (or not).

Don

 

[gadgets]

BTW. I still get the odd occasion where the line texture is not being displayed, just the line background:

George, as file that demonstrates the issue would help.

I recall working this issue a long time ago, but there's been "a lot of water under the bridge" since and I don't recall the details.

Don

 

[GHD]

George, as file that demonstrates the issue would help.

I know, but I have no idea when it will happen. I don't have a current file (unfixed) file.

 

[gadgets]

George, I have found and fixed the issue with the line vertices being offset when you add a new one. (Basically, the system should have been doing - and now does - what you did to correct the problem, i.e., reselect the line type.)

Re the other issue, should it happen again - or if it happened the last time you compiled one of your files, please send me the AD3 file AND the ADE_GP.asm file generated by the compiler so I can determine if the issue is with FSX or ADE. But, first, please determine if the line shows up when the aircraft is positioned on the ground close to the line.

Since all the triangles in the curve are gone, not just a single segment, I'm suspicious its due to FSX's "habit" of not displaying very small scenery objects, given the large number of vertices you use in your curves and the correspondingly tiny segments generated. (The backing segments are larger and, hence, would remain displayed from a greater distance.)

Don

 

[GHD]

I'm suspicious its due to FSX's "habit" of not displaying very small scenery objects, given the large number of vertices you use in your curves and the correspondingly tiny segments generated. (The backing segments are larger and, hence, would remain displayed from a greater distance.)

Don

I don't think so, an edit to reselect the tetures always fixes it.

 

[gadgets]

I don't think so, an edit to reselect the tetures always fixes it.

"Always" covers a lot of possibilities. Unless the before and after viewpoints are identical, the reselection of textures may simply be coincidental.

I have spent the last hour or so reviewing all fsDeveloper threads that have anything to do with disappearing polys. I learned a few things, namely:

• the issue of ground polys (and other planar objects) in FSX disappearing at certain viewing angles is well-documented; don't know about FS9; see the early posts in this thread and
• in FSX, add-on airports that do not change the ground elevation are susceptible to ARP vs flatten elevation issues.

To end on a positive note, I also discovered that the display of a distant poly when none are closer to the ARP may be due to the calculation of V2. In the next release, as an experiment, I'll be increasing V2 slightly.

In the meantime, until I see some proof otherwise, I'm sticking with my suspicion that the non-texturing of the curve in that line is due to distance from the viewpoint.

Don

 

[gadgets]

Don't know whether or not Jon's "back in business", so I'm, attaching Version 0.0.93.

It includes the fix for the lines problem you highlighted earlier today. As well, I've increased V2 slightly in the hopes that may cure your no-display issue with single polys distant from the ARP.

Don

 

[GHD]

In the meantime, until I see some proof otherwise, I'm sticking with my suspicion that the non-texturing of the curve in that line is due to distance from the viewpoint.

I have sent you a project which, when compiled, shows three lines which are textured only with the background texture.



I won't make any changes until I see your comments.

George

 

[gadgets]

Thanks for the files, George. I have confirmed there's a problem somewhere in the compiler that's causing the U/V information for those lines to be ignore. (If you open ADE-GP.asm and examine the vertex information, you'll fimnd a block of vertices with UV both set to 0.)

Haven't isolated the problem yet, but it's only a matter of time.

Don

 

[gadgets]

Turns out it is not a problem in the compiler. The problem is in the data held by ADE. For whatever reason, the UV for the texture was not saved.

The key is in what you told me yesterday (that I doubted as a coincidence), i.e., that re-assignment of the texture and line type corrected the problem. Actually, you don't even need to reassign texture or line type, just edit and click OK.

The question is "Why?". Do you recall if these particular lines were created or edited differently than the others that display correctly - perhaps at a time when there was some bug in ADE-GP that has since been fixed?

Don

 

[GHD]

The question is "Why?". Do you recall if these particular lines were created or edited differently than the others that display correctly - perhaps at a time when there was some bug in ADE-GP that has since been fixed?

No, they were all created with 0.93. Those in error were edited in ADE to have common vertices but then re-edited with the GP editor.

As I said, I usually reset the textures and this seems to fix them.

 

[gadgets]

Those in error were edited in ADE to have common vertices but then re-edited with the GP editor.

Perhaps it's the way the editor handles this operation.

I'm not familiar with this feature of ADE. Please be a little more specific about what you did in ADE so I can duplicate.

Don

 

[GHD]

 

[gadgets]

Since you didn't mention it, I presume you did not edit either line after the operation.

Don

 

[GHD]

Since you didn't mention it, I presume you did not edit either line after the operation.

Don

Of course I edited both lines.

 

[gadgets]

George, is it possible your memory is playing tricks on you?

If I do as you indicated in the screenshots - without intervening edits of each line - then I get exactly the same results as you. If I edit after each operation, the display is correct.

Jon, re the pasting of coordinates, it appears that ADE deletes the old vertex (into which the coordinates are to be pasted), thus also deleting the saved ADE-GP information, and creates a new vertex at the pasted coordinates). If ADE simply pasted the new coordinates into the old vertex, there would be no need to edit afterwards.

As for the addition of the vertex, it may be possible to use a similar treatment as I do for polys and predict the UVs for the new vertex - thus avoiding the need for the edit afterwards, but that's not the current operation.

Don

 

[GHD]

George, is it possible your memory is playing tricks on you?

Anything is possible