Object generation utility

  • Hello Ken,

    an interesting idea.

    As far as I know, lights can only be defined in a TOC file.

    If Stu likes the idea, he could create a toc together with the tsc file (and include the toc call).

    I played a bit with traffic lights, with the aim to have an automatic switching between green - yello - red.

    With the below lines I managed to get a 22 sec green, 2 sec yellow and 22 sec red phase. The disadvantge is, that scenproc then only generates the same signal colors for the whole city. And random color is not possible; otherwise the signals would not sequence the colors.

    # Traffic signals

    CreateAF2Light|highway="traffic_signals"|1.0;0.0;0.0|5|0.15;0;6|5

    CreateAF2Light|highway="traffic_signals"|0.0;1.0;0.0|5|0.15;3;6|5

    But with Stu's program he maybe could assign the following:

    All streets in E-W direction which have the attribut highway="traffic_signal" get this light:

    and all streets in N-S direction which have the attribut "traffic_signal" get that light:

    Optionally the toc generation could also take care of lights assigned to a model:

    high chimneys, wind generators, railroad crossings and signals ...

    What do you and Stu think?

    Cheers, Thomas


    Edited 3 times, last by TomSimMuc (March 19, 2019 at 10:37 AM).

  • Traffic on motorways. Autogen on every node.


    To all 3D modellers: we need low/medium-poly count 3D models for cars and trucks! (N-S orientation)

    Offset for cars, left lane: 0.9m

    Offset for trucks, right lane: -0.8m

    Cheers, Thomas


    Edited 6 times, last by TomSimMuc (March 19, 2019 at 4:02 PM).

  • Tom, one possible solution for the traffic signal problem would be to use 2 TOC files (red & green).

    - run scenProc for all red lights with a 30-sec "on" time and a random delay generated for each one (10sec, 20sec, or 30sec)

    - copy that "red" TOC file and rename it the "green" TOC file

    - then do a find/replace on 10sec --> 40sec, 20sec -->50sec, and 30sec --> 60sec

    Granted, the signals at a common intersection won't be coordinated but the illusion from the air is probably good enough for the time invested.

  • It looks like traffic signals are just Nodes but those Nodes are included in a street Way.

    If the node is referenced from a way it will be treated like the power pylon or ski lift and the orientation will be calculated from the way

    Seems like it would need 2 levels of parsing, one to get all the traffic_signals Nodes, and a second to find those same nodes in street Ways.

    Reverse order.

    Ways are processed by walking along the way and processing any nodes referenced from the way.

    If Stu likes the idea, he could create a toc together with the tsc file (and include the toc call).

    Roadmap item

    As long as there is a generic way define lighting specification.

    I don't want to code a special case for traffic lights.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Tom, I took your 22-2-22 green/yellow/red traffic light timing numbers and duplicated them and shifted them a half cycle and then added a FRAND branch that randomly assigns the original or shifted timing to each traffic_signals node in your osm file. This creates the illusion for 2-light intersections that are assigned an orig & shifted that the 2 lights change in sync from red-green and green-red.

    Code
    # Traffic signals
    
    CreateAF2Light|highway="traffic_signals" And FRAND<=0.5 |1.0;0.0;0.0|1|0.15;0;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND<=0.5 |0.0;1.0;0.0|1|0.15;3;6|5
    
    CreateAF2Light|highway="traffic_signals" And FRAND>0.5 |1.0;0.0;0.0|1|0.15;3;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>0.5 |0.0;1.0;0.0|1|0.15;6;6|5

    A quick VR test flight made me think the transitions need to be faster, maybe 11-1-11 . This may seem too short, but with all the other streetlights I think the red-green transitions need to be quicker to catch your attention. I'll continue the experiments.

    Ideally, we'll be able to plant traffic signal poles at the intersections with the lights at the right height and spaced appropriately but that will probably require a parser routine to detect close traffic signals in the toc file and output additional toc files with adjusted coordinates for the other lights as well as matched timings.

    The best we can do short-term is to expand on the FRAND approach above to go from 2 random groups to 10 random groups. With faster timing, the 1-light intersections would function normally, but the 2, 3, and 4 light intersections would have random changes occurring.

  • Traffic on motorways. Autogen on every node.


    To all 3D modellers: we need low/medium-poly count 3D models for cars and trucks! (N-S orientation)

    Offset for cars, left lane: 0.9m

    Offset for trucks, right lane: -0.8m

    Hi,

    I found a set of really low polygon cars at 3D warehouse.

    So I can provide about a dozen different types with any kind of color, if you don't find them too ugly.

    I just have to recompile them since I missed the offset.

  • I just have to recompile them since I missed the offset.

    This would be very nice, Rodeo.

    Please orient them as:

    (N-S orientation)

    Offset for cars, left lane: 0.9m

    Offset for trucks, right lane: -0.8m

    so all PKW will drive on the left lane and all trucks on the right (not nice, but reallity here ;) )

    Can you add the 3d warehouse links each please, so we can officially distribute them ?

    Cheers, Thomas


  • Hi,

    find a first set here please:

    cars_offset.zip

    This is the specific link:

    https://3dwarehouse.sketchup.com/user/136313741…milo?nav=models

    Don't you think it will be ok to link generally to the sketchup 3D warehouse?

    Regards

    Rodeo

  • Uploaded new release of ObjectGen

    Major change is a new SelectionExpression capability to allow compound selection conditions to to specified instead of simple AndCriteria

    Added general expression evaluation engine to evaluate the result of the expression.

    Some other smaller updates.

    See readme and UserGuide for details

    /Stu

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Tom, here are ScenProc lines I settled on for the traffic_signals random changes that I added to the South Florida TL add-on update (V2) ...

    Code
    # Traffic signals
    
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.0 And FRAND<0.25 |1.0;0.0;0.0|5|0.25;0;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.0 And FRAND<0.25 |0.0;1.0;0.0|5|0.25;3;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.25 And FRAND<0.5 |1.0;0.0;0.0|5|0.5;0;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.25 And FRAND<0.5 |0.0;1.0;0.0|5|0.5;3;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.5 And FRAND<0.75 |1.0;0.0;0.0|5|0.33;0;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.5 And FRAND<0.75 |0.0;1.0;0.0|5|0.33;3;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.75 And FRAND<=1.0 |1.0;0.0;0.0|5|1;0;6|5
    CreateAF2Light|highway="traffic_signals" And FRAND>=0.75 And FRAND<=1.0 |0.0;1.0;0.0|5|1;3;6|5

    I also experimented with 3D traffic signal pole objects being placed at each traffic_signals node using ObjectGen but there's currently no orientation control and the poles aren't really noticeable above 500 feet anyway. Highway street light poles might be a better investment in time/effort to get the orientation right.

  • Stu, have you attempted street light poles?

    I don't think the highway nodes match the light pole locations like power poles. ScenProc allows you to choose the spacing of the street lights along the WAY so it would be great if we could do the same thing with highway light poles in ObjectGen so that the lights can be matched to the 3D light pole objects.

    Here's an example ScenProc highway set of lights …

    PlacePointsAlongLine|highway="motorway"|SINGLE|200;250|6;6|0|String;point|mlight|hdg

    The 200;250 section controls the spacing of the poles - in this example it generates a random spacing between 200-250 meters for each pole. For ObjectGen, we would have to use a fixed spacing for both the lights and poles so they would line up (fixed would be 225;225). The 6;6 section sets the distance from the centerline for double-lights (6m offsets). This would require a "T" light pole object centered on the base of he light pole. The "mlight" attribute is assigned to these new points and the hdg from the line/WAY is also copied to the point.

    Obviously the heading is needed to properly orient the light pole. If it's a 1-light light pole (either a street lamp "I" or "r" shape), the object needs to be centered through the light so the pole light fixture and light will line up.

    Thoughts?

  • Hello Stu,

    thank you very much for version 0.5.

    The expression term now offers a lot of new possibilities, a big step forward.

    Well done in such a small time.

    However I stepped into a problem:

    1) Whenever there is a rule, for which no object is found in (real) osm data, ObjectGen terminates.


    Please see my attachment for sample xml, log and osm data.

    (c) OpenStreetMap contributors

    "unhandled exeption: ... Index out of arraybounds"

    In version 0.4 the xml still worked.


    2) Can you please give an example for random orientation of oneObject nodes?

    Greetings,

    Thomas

  • However I stepped into a problem:

    Thomas

    Do you have 0.5.2?

    I updated 0.5 with a fixes for case where features cross the bounding box boundary. There was a clipping problem introduced with large file support.

    2) Can you please give an example for random orientation of oneObject nodes?

    The storage tank examples in the text.xml or test_expression.xml show random orientation (not #0.3.3.1 since it is single node not oneObject based)

    There was no clean way to allow optional configuration of random orientation. The is a redundancy in the TMC specifications. Regular objects] have the [orientation] property and animated objects have [rotation_in_degrees] property for the same purpose. So allowing both orientation and rotation_in_degrees on a model in the XML is awkward. I probably should have split the animated model out separately from the static model but that would have made the XML more complicated.

    Although I do not like that the choice of animated or static model is is implicit in the presence of animation attributes with the model configuration.

    No clean solution.

    /Stu

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Stu, have you attempted street light poles?

    No

    I have not tried that scenario

    It would require the introduction of a <virtualObjects> choice on the <wayconfiguration> as an alternative to <oneObject>

    with specifications for <spacing min= max= ... />, <offset left= right= .../> ...

    Does it require explicit <orientation= /> ? Or is left and right offsets with opposite orientation perpendicular to the way sufficient?

    Does it make sense to have a modelMap or is a single model sufficient? Choose model based on highway classification???

    If there is any variability in the spacing, the objects would not align with scenProc lights.

    Does this require light generation as well as the object generation?

    Are there other scenarios. What about barges or road vehicles? (or will those scenarios be handled by Aerofly Life??)

    I like to understand the full requirements before I design anything.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10