Visualizing road signs

[johschmitz]

I am working on a road sign implementation for my Blender addon and was wondering if it is possible to visualize them within esmini as some kind of boxes or so when pressing O?

[eknabevcc]

The way signs are visualized in esmini, currently, is simply by referring corresponding 3D models.

See odr example: https://github.com/esmini/esmini/blob/master/resources/xodr/straight_500m_signs.xodr

So, one way would be for Blender to export the sign models following naming system described here: https://esmini.github.io/#_road_signs

Regarding export step, there is some info regarding how to get models into .osgb format supported by esmini: https://esmini.github.io/#_openscenegraph_and_3d_models

If only bounding boxes are required, these could be specified as any OpenDRIVE road object. Like how poles for the signs are done.

[johschmitz]

Yes the idea is indeed to export the 3D model including the signs. But then it would be great to see that the underlying OpenDRIVE data matches the 3D model in the same way as it is possible with the road reference line and lanes. So drawing a simple 3D bounding box for each sign plate would be sufficient. Do you get what I mean? Would that be possible when pressing O?

[eknabevcc]

I think I understand. Using any dimension info from the sign definition in the OpenDRIVE, esmini could generate a bounding box. I guess that would be possible.

But we'd had to find another key shortcut since 'o' is used for complete environment model. What about length (thickness) of the sign. I guess a hardcoded 5 or 10 cm would be OK?

[johschmitz]

I think the thickness parameter is indeed missing in the standard. Maybe this could be added in a future version so hard coding it to a couple of mm or cm should be fine for now. I think mostly for simple signs the steel is 2mm.

What would be useful as well in my opinion is to draw an additional line from the road reference line to the bottom of the pole and then a line up to the bounding box (maybe those two in a different color than the bounding box). In that way it becomes clear to which road a sign belongs even for roads which are close together.

I don't understand what you mean regarding the shortcut. Are there multiple shortcuts for the different components of the OpenDRIVE data?

[eknabevcc]

Just a simple bounding box could be a fairly low hanging fruit, but I agree it's not too useful without additional visual cues/features, as you also outline. To clarify, we will not be able to prioritize this in near time. So it would probably rely on external contribution, or when we have time and/or need.

Regarding shortcut, almost every key is assigned to some feature in esmini (or OpenSceneGraph) 🙂 See User guide - 10.1.2. Runtime key shortcut commands Ah, now I see. I guess you mean that the sign bounding boxes could be assigned to that same visual "group", in that case there is no problem.

[johschmitz]

I have to correct myself, a length argument for signal has been added in OpenDRIVE 1.8, it is just missing in the Figure 125 but exists in Table 120.

[johschmitz]

One more comment: if adding only bounding boxes without any extra info would be very easy for you that would already help a lot. Otherwise I can try to have a look..

[johschmitz]

Tried the example above but getting error messages like

Failed to load signal se_c_31-5.osgb / speed_50_0_0.osgb

Where do I have to download the assets? Are they not part of the esmini release? I was expecting esmini to put some default sign models or something like that.

[eknabevcc]

Your expectations are correct, it should work. Just grab demo package for your system (mac, Windows or Linux): https://github.com/esmini/esmini/releases/latest

Then just unzip and go ahead, from esmini-demo root folder run: ./bin/odrviewer --window 60 60 800 400 --odr ./resources/xodr/straight_500m_signs.xodr

There is also some info in User guide - Get complete esmini on how to get further content (demo does not include everything, but it should include signs referred by straight_500m_signs.xodr).

[eknabevcc]

Simple bounding box for the very sign plate was a low hanging fruit. It's implemented (42f676d4043f806d25b330a2f17dddf5241bc81c) and included in release v2.36.5.

If sign 3D model fails to load -> the bounding box is used as stand in model else (if 3D model is loaded) -> the signal bounding box can be visualized as wire frame on top of 3D model. Toggle on key 'O' (shift 'o')

[johschmitz]

Awesome, will try it out 👍

One Github hint: you can write <kbd>O</kbd> to get O.

[johschmitz]

This already helps, I have to fix some code on my end to properly export width, height, length and zOffset. I am going to post an example when it properly works.

One quick feedback though at this point: I think there should be no box displayed when O has not been pressed and a scene. osgb model is used already.

I think there are 4 cases

1. Running a scenario without .osgb file for the scene available and osgb models for signs from esmini found
2. Running a scenario without .osgb file for the scene available and osgb models for signs from esmini NOT found
3. Running a scenario with .osgb file for the scene available and osgb models for signs from esmini NOT found
4. Running a scenario with .osgb file for the scene available and osgb models for signs from esmini found

Only in case 2 do you have to display the box without pressing O. In case 3 and 4 the sign model can be part of the scene .osgb file.

Also I would strongly recommend to make the O box a wireframe box to be able to distinguish it from the 3D model box, similar to the lines on the road. Regarding this point I am a bit confused because I can't seem to see the box when pressing P to remove the model

Also if the case 2 box could have some kind of checkered pattern or red color or so to show the user that it is more like an error message/place holder I think that would help.

[eknabevcc]

I’m in ski slopes for coming full week. Will look into it after that. But one clarification: For cases where an odr signal 3D model has been found, the BB is visualized as wireframe already. Only when an odr 3D model fails to load, the BB is rendered as solid.

[johschmitz]

Alright, enjoy! I am going to upload an example after fixing the zOffset bug and then we can do some back and forth based on that after you get back.

[johschmitz]

example.zip Here is an example project for you to try. Looks to me as if there is a little offset bug in the zOffset calculation of the esmini boxes. I used some slightly unrealistic values on the STOP signs to make the calculation and bugfixing easier. Pole below the sign should be 2m and the sign plate 1m.

Also the boxes always show up as noted before.

[johschmitz]

Sorry, I found the problem with the zOffset on my end. So now the problem remains that the gray boxes are always shown and I can not display them as wireframe boxes.

example.zip

[eknabevcc]

You're right, there are a few cases which makes it a bit complicated. The scene graph file can include road signs or not. In the case it does, esmini should not create a solid 3D model as well (only wireframe version).

Hmm, the question I see is how to conclude from the information in the xodr that a 3D model should be created/loaded or not (since it's already in the global scene graph model)?

I hope there is a simple way. Otherwise, a potential idea: When parsing the xodr signs, the simulator (e.g. esmini) will check whether the sign is already present in the global scene graph model. This can be done by matching

1. Name substring. E.g. any node with leading part of the name matching "de_274-30" is considered a German speed limit 30 sign)
2. Position. With some tolerance, e.g. 10 cm. If both name and position is matching we have the sign already present in the scene graph model, and we can skip creating another 3D model.

You have some thoughts?

A quick fix is to retire a little bit: Let's create only wireframe variant for all signs, and make them appear by pressing 'O' (not visible by default). I.e. skipping the creation of solid models as stand-in for (potentially) missing ones.

But it would be nice to cover all use cases :)

[johschmitz]

Quick thoughts:

Let's create only wireframe variant for all signs, and make them appear by pressing 'O' (not visible by default).

I agree with that!

For the other discussion my suggestion would be to have the default behavior like this:

1. When there's no mesh files defined in the OpenSCENARIO in sceneGraphFile, display esmini default 3D models for everything that is available. Also display a placeholder model for models missing in the esmini model library, for example a sign with an chess pattern sign plate or so.
2. When there is a sceneGraphFile defined assume, by default, that the tooling will also include 3D models for signals, etc. and don't add any esmini models, leave the responsibility to the third party tool. Only if the OpenSCENARIO somewhere explicitly specifies a 3D model file somewhere in model3d which is not available on disk, show a placeholder model (preferably something with a green colored pole or so to make it easy to spot), to inform the user about this explicit error and also print an error message.
3. For the hybrid case where sceneGraphFile is specified but object models are not and the user wants to use esmini models, don't implement too much magic. Just provide a command line switch to enable this mixed mode which is off by default. Something like enrich-scene-model-3d, use-esmini-signal-models, add-esmini-signal-3d-models or so (not sure what a good name is).

If you absolutely don't like 2 and 3 we can discuss some alternatives but so far I don't see a simpler more intuitive approach to distinguish. Anyway just my quick 2 cents, I hope I forgot no important aspects.

[eknabevcc]

The problems with your proposal is 1. Some signs might exist in the scene graph model and some not. Secondly, it could be useful to re-use a complex scene graph model only replacing signs, e.g. due to target market/country. So, we'll probably not change the old esmini capability to load external sign models (disregarding scene graph model loaded or not).

What about: "Hmm, the question I see is how to conclude from the information in the xodr that a 3D model should be created/loaded or not (since it's already in the global scene graph model)?" You have some idea here?

Probably the simplest short-term solution is to just go for wireframe models (on 'O'), skipping solids. Potentially adding some magic or smart solution for the other cases later, when needed.

[johschmitz]

I guess your last suggestion will work as a starting point and I think for now maybe a distinguishing feature for esmini to decide if to insert 3D models can then be if the OpenDRIVE only specifies signals or also additional objects linked to those signals? Also if there are some legacy constraints you could also make the command line switch to disable this feature default ON.

Anyway, I will keep thinking about this question but if you could have a release with the bounding box wireframe as a start that would be awesome 😀

[eknabevcc]

For v2.37.0 we made slight changes:

1. Wireframe bounding box is always created for all signals. Off by default. Toggle on 'O'.
2. Added launch flag controlling model creation behavior as:
   • If set: When external scene-graph model is loaded, skip loading or creating individual sign models
   • Not set (default): Always try load or create sign models

The current motivation behind default behavior is that, for us, it makes sense to keep signs parameterizable. E.g. using scenariogeneration, or other tools, you can re-use the same (potentially large, complex) road/environment model and on top of it create many variations wrt signals, like sign locations, sign type, country/market.

So, for your use case I think you can set the launch flag always, and it should prevent creation of solid signs.

[johschmitz]

Cool, will try it out 🙂.

[johschmitz]

I tried it out and the --use_signs_in_external_model works to turn off the gray boxes. I notice some things though:

• I can't seem to activate the bounding boxes with O, any hints?
• I don't understand the name "use signs in external model" what is that supposed to say? Something like "osc scenegraph model already contains signs therefore disbale esmini internal signs"? I think something like --disable_sign_model3d_overlay, --disable_esmini_sign_models, --disable_internal_model_overlay, --disable_internal_sign_models, --disable_creating_sign_models or so would be more understandable. I think it is good practice to have the word enable or disable in there when turning on or of tool features.

Edit: here an example.zip

[eknabevcc]

1. Hint: 'O' = shift-'o' (upper case 'O' letter, not 0 zero)
2. See command ref in User guide - esmini launch commands, or run esmini without any args too see help. It says "When external scenegraph 3D model is loaded, skip creating signs from OpenDRIVE", should be good enough.

Running, from resmini root folder: ./bin/esmini --window 60 60 800 400 --osc ./resources/xosc/distance_test.xosc

Then (after driving with the arrow keys for some meters), pressing 'O' I get this:

You can see the bounding boxes. The lower right sign has a small bounding box, why it's barely visible. The lower left sign was not found on disk (I hide the file), so instead esmini created a solid stand-in model according to bounding box.

Running same command with the flag: ./bin/esmini --window 60 60 800 400 --osc ./resources/xosc/distance_test.xosc --use_signs_in_external_model

gives:

I.e. no signs created or loaded, simply because there are no signs in the model (only other road objects, like poles in this case).

BTW, strange that bb ('O') does not work on your side. Your odr and scenario works on my side, Windows and Ubuntu.

Can you share more details on how you launch the scenario (esmini) or OpenDRIVE (odrviewer), and we can investigate.

[johschmitz]

Alright Shift+O works. Great! It was confusing me a lot that you just wrote a capital O, quite uncommon in my opinion. The reason is that people usually refer to the print on the keyboard when they document shortcuts which is always "capital" (at least on most common keyboards):

I am wondering why not just use O without the Shift modifier and display the sign boxes together with the road lines? Is there any need to separately display the sign bounding boxes from the rest of the OpenDRIVE model? Otherwise I think it would be nice to have one shortcut for all of it.

Also another question, do you think there is any simple way to depict the orientation of the wireframe bounding box to see if it is correct with regards to the model? Like only having the diagonal as an X at the front side or a different color or so, like red color for the front, gray for the back?

[eknabevcc]

Slight adjustment by commit f79adff7bc1b9d98df669919a4e823432ed42390: Skipping 'O' (shift-'o'). instead adding road sign bounding boxes to same drawing groups as other road features. I agree it makes sense. It also saves one possible key for future needs (we're almost out of keys 🙂).

Included in release v2.37.1.

[johschmitz]

I am closing this since it is working fine.