Bentley/LumenRT Laundry List of Issues V2

This was a royal pain.

Received practically no assistance from Bentley, Eon, or PTV's end. Exact workflow for incorporating animation created in Vissim for a complex model created in Bentley's PowerCivil was unknown even amongst "advisors" (no set route). "Advisors" argued incorrect details on their packages example being that no additional module is required in license to export an *.ani.txt in PTV Vissim, evident that this was incorrect. True this is not Bentley, but it if stated that something works please include such details in the workflow you produce should you advertise integration. 

Bentley's applications generally provide the user with the ability to customize the programs to work for them (evident in workspaces and config files), please provide an extract on what LumenRT expects to see in *.xml format to enable some features and customization as needed. Seems this is very much on the hush and no one is particularly interested in helping in this regard, evident on the forum.

In addition to this the following list highlights my annoyances in this experience, and hope this gets addressed at or aids any users looking to explore this topic. Luckily this was a learning experience by a student/hobbyist and held no expected deliverable:

  • No option to have animation “cling” to a created surface like 3DSMax. Had to learn maxscript to use 3DSmax to simultaneously import then export a *.ani.txt file with corrected gradients and elevations so that LumenRT doesn’t show flying objects at a 0 pitch where slope grades are clearly visible. Also to correct the distinction between entity numbers for vehicles and characters to not flicker. Incorporate a method to have traffic cling to a surface, if I raise the terrain in LumenRt the objects raise with it. Once the animation resumes their positions reset. An alternative is through import of *.alg's to ConceptStation and then export of *.inpx to Ptv Vissim, but this is a mess and too long (also geolocation is a mess)

  • Pedestrians aren't included in the "Vissim2LumenRT.py". Had to learn python to add the pedestrian portion to the .py file, Also to add a file type of *.dae (for custom rigged characters) to be used. LumenRT’s rigged animated characters (*.lob) does not support translation from the *.ani.txt file (they are imported as static). Once the *.py file was edited my custom character worked just fine following the animation from Vissim’s *.ani.txt. Problem with this is in analysis of animation is when the character has to stop translation, say to cross the street, rigged animation proceeds.

LumenRT’s *py file only recognises the bear minimal of vehicle object information highlighting:

  1. Position
  2. time frame
  3. rotation
  4. Gradient

The *ani.txt file is more than that. Allow for signalizes, time frame for display of signalizer lights, vehicle indicators and brake lights and colours instead of random selections

  • Allow for soundclips to be attached to vehicles via the *.py or included in a model to be attached, or maybe via meta-coding?
  • Add door section to the py and relevant models so that buses can have people exit buses where doors actually open.
  • Allow for the user to click on a object and assume its view on the scene
  • Fix ghost drivers
  • Water direction
  • Animated grass or better textures. Current grass textures look like a mat that’s been placed in a scene. Nothing close to the 15cm description
  • Crossfalls are ignored in import of vissims traffic, understandable considering the ani.txt file doesn’t include it but if traffic could drape this problem wouldn’t exist.
  • Better climate control (rain, snow)

The compatibility between Vissim, LumenRT and a Bentley's design packages doesn't work as well as made out to be. In order to explore possible workflows for projection of existing and predicted traffic conditions to a detailed design, engaging with the models in real time and improving general technical delivery, I've ended up learning basic python, maxscript, xml to create and edit scripts and config files to allow for a working output, and using excel to the point where crashes are practically the norm. This in addition to various packages in constrained time.

I've been notified that several things are on the roadmap but are not likely to be solved in the near future. I choose not to believe this, and ask that if someone with no previous coding and animation history, experience in one civil/cad application can solve this issue and develop a workflow and understanding on how the packages integrate with each other, why cant the developers. Why is it taking so long and why hasn't this been communicated more effectively.

  • More of the same i guess. Well done on solving the problem with next to no prior knowledge of any of the applications! Sounded like a great idea especially when linking to Concptstation or OpenRoads but the reality is the development is not quite there yet.

    Should patent your workflow quick sell it back to Bentley ;-)