P3D v5 LineToPoint questions

[Clutch Cargo]

You've lost me. when you say XML autogen definition. are you referring to the 'default.xml' file? I can find nothing in the SDK referring to XML autogen definition. How do you load this? ALso, you say load your .bgl. I don't have bgls, I have agn files

 

[arno]

You must have a photoreal bgl as well that you use along with the agn files. That's the file you load into annotator

I'm not behind my PC now, so can't check where the xml files that you need to load are exactly.

 

[Clutch Cargo]

See if this helps me show my issue as I am lost on Annotator at the moment. Here I am using what I would call scenProc's default LineToPoint. If you look at the shadows you can see the arm of the light pole is following the direction of the line.

I also created this in Photoshop/QGIS to further highlight the current direction of the poles. I am assuming for this example the lightpole's arm is 0 degrees.

The blue line shows the direction of the lightpole arm. The other points are of no concern for this test, one represents the light bulb that will be attached to the pole and the other point over the road is the light "splash" applied onto the road. So what I want to do is rotate the lightpole (in this example 270 degrees), so the light pole arm will FACE the line/road like so:

If I replace |HDG| to a numeral it will change according to true North, not the direction of the line/road as you say above:

The LineToPoint step does assign the heading attribute for each point based on the direction of the line segment that the point is on. So I don't see why a special step would be needed for that. A heading of 0 would not align it to the line, the would align it to true north.

So that is why I think I need an added Attribute that rotates the poly based on the road it faces, not true north. Not sure what step would work best to be introduced at either LineToPoint or PointToPolygon?

Hope this clears up my issue...

 

[arno]

I see, you want to add an offset to the heading just like you can do for xml objects. Does the PointToPolygon step not have that option already? I need to check.

 

[Clutch Cargo]

Yes-Yes! That is what I am seeking. I have 1,000's of light poles, telephone poles, transmission towers to add and I have always used agn's instead of bgls for best efficiency, best on FPS and not having to 1,000's of individual bgls in the scenery folder. I can only assume the option of adding so many objects where we couldn't in the past is due to better CPUs and GPUs that can handle so much more these days.

Also, in my post above of creating objects at the intersections of lines... this too would be an excellent reason to add the offset. You can see the image in that post the lightpole is at the intersection but there is no way to offset it to move it off the road.

There is a |hdg| attribute in PointToPolygon but refers to true north as you said. Maybe an additional Attribute that overrides to offset from the face of the line (looking something like ' |LEN;WID|hdg|OFFSET| 'or an Option at the end of the Step to override the HDG Attribute. It might be where HDG on its own refers to a true north heading as before but when OFFSET is added it overrides/changes the true north to offset from the facing line.

 

[arno]

You don't want to overwrite the heading, you want to add an additional offset value to the heading value of the attribute.

 

[Clutch Cargo]

I guess I am saying give the developer the option as there could be cases one does want the heading to remain attribute to true north. Kind of an either/or choice.

 

[arno]

Hi,

I have just coded the heading offset argument for the PointToPolygon step, so it will be in the next development release.

 

[Clutch Cargo]

ooooh You're making my Monday morning look very enticing. Have a great weekend.

 

[Clutch Cargo]

As an update, I used the latest scenProc and the new heading attribute is working great. I have used it so far for light poles and telephone poles. Many thx on this Arno!

Regarding placing an object (light pole), at the intersection of two lines (roads). So far I like using the buffered roads idea. They overlap and give me an intersection to work with and each road still has its own fields and values intact should I need to use. The next issue would be two items; 1) getting the object off the center of the intersection (OFFSET) and 2) get the proper heading (HDG) set so the arm of the light pole is facing to the intersection. Here's a few screenie ideas:

I see three major types of intersections, a 4-way, T-type, and an angled intersection.

The black dot represents the intersection of the two buffered lines where the blue are the light poles. As you can see, the pole arms always face towards the intersection. I feel that would be the easiest and most automatic way to get the HDG as putting a number in there may work for some intersections but not for others.

As for the OFFSET, I really don't care where the lightpole is placed (just showing the possible locations in the screenshots), but when I input a number , say 10 for 10 meters away from the intersection how would scenProc know in what degrees from the intersection it should use? This is where your "smarts" come into play, ha! Maybe some random location equally spaced between two lines?

So I've got the main steps I would think after importing data and SplitGrid:

BooleanFeatures|INTERSECTION|type="secondary" AND popValue="over200"|type="residential" AND popValue="over200"|1
PolygonToPoint|type="secondary" AND popValue="over200"|CENTER|0.0;0.0|0.0;0.0|String;Type|INTERSECT|hdg
PointToPolygon|Type="INTERSECT"|8;8|OFFSET|HDG|String;TYPE|LIGHTPOLE ---> (where HDG is always facing to the intersection unless a number is used?)

Hopefully you find this a challenging Step to want to add?

 

[arno]

Hi,

If you would use a double buffer you can get the points where you want, but the heading would be tricky.

I guess it is better to add a new step for this. Let me think about that.

 

[Clutch Cargo]

Thanks for willing to take a look at this. Not sure what you mean by "double buffer"? I do buffer both roads that intersect if that is what you are referring to. And that solves the first part of the puzzle of creating that intersection point. It's just getting it off the road and still point the object to that intersection. Take your time.

 

[arno]

I meant buffer each road twice with a different width. Then subtract the inner from the outer buffer. And finally do the intersection between the outer buffers of the roads. That should give you the positions you are looking for.

But not with the right heading, so I don't think it will help you that much

 

[Clutch Cargo]

Oh, I see. Yea, I think it would be better to be able to set an offset in meters. I'll hold off on this to give ya time to think about it. An entirely new Step might be the right approach as I was thinking try to add to much to PointToPolygon may be an overload as to what offset we are referring to and what hdg as well. Unless, maybe added as a Variable (like INTERSECTION), at the end of the step that overrides standard OFFSET and HDG parameters. Just thinkin'

 

[arno]

I have started implementing something, it will be a new mode (INTERSECTION) in the LineToPoint step. Let's see if I can get it working.

 

[arno]

I think I am almost there with the new intersection mode, see the screenshot below. Only at the roundabouts it looks a bit weird and I need to double check that all points get the right heading attribute assigned.

 

[Clutch Cargo]

That looks very promising. Didn't think about round-a-bouts. Those tend to be fairly rare in the US but would be a nice option for to have both here and in other countries. So, scenProc would randomly choose ONE of those points at the intersection? Looking at this gets me thinking about the step could be used to create signal lights at intersections (not that I am planning to), but that could add a whole other "can of worms"!

 

[arno]

I have checked the headings today and I think it should work. What I will do is update the documentation and then put it in the development release so that you can have a play with it. I'm sure we'll find situations where it works different than expected, but that is easier to find out in real life situations.

 

[arno]

So, scenProc would randomly choose ONE of those points at the intersection?

No, all the points you see here are added. It is like in your pictures, if you have 4 roads meeting at the intersection 4 lights are placed, if you have 3 roads three are placed. Each point is placed in between the two roads that connect there at a specified offset. And the heading is so that it points to the intersection.

 

[Clutch Cargo]

Ouch... that's not what I was hoping for. Out in a rural area they would not put 3-4 lights at one deserted intersection. It would be overkill. In my drawings, I was showing the possible locations where a lightpole could be placed. Sorry, did not mean to confuse. Hence, why I was asking for scenProc to randomly choose a spot for one. I guess the step could have an attribute or variable where a user could add an integer, 2, 3 or 4 (which could be used for street lights), but one would be the default. It's the one light/pole I need most though.