Just bought the Pro and i have one very important question? Where the... is the roadmesh? I need to have access to it, i can not have it hidden in some secret location.. For ex: packing a scene does not work, the mesh gets lost if you try to make it as prefab. It doesn't work on any project but the original.

You design level in an empty new project, when it's about finished you pack it and import it to main project. I expect this to be very common pipeline (and we are just now going thru the pipeline, i'm NOT gonna tell my producer that the tool i so praised is unusable and we have to go back to 3DSmax/BTB/RTB.. so answer, please fast..).

I expect that when i "build" a new road mesh, it is an actual mesh and it is MINE to use where-ever i like. Kind of pointless if i have to use one project for the entirety of the game lifetime, working in a 6 men team

Just bought the Pro and i have one very important question? Where the... is the roadmesh? I need to have access to it, i can not have it hidden in some secret location.. For ex: packing a scene does not work, the mesh gets lost if you try to make it as prefab. It doesn't work on any project but the original.

You design level in an empty new project, when it's about finished you pack it and import it to main project. I expect this to be very common pipeline (and we are just now going thru the pipeline, i'm NOT gonna tell my producer that the tool i so praised is unusable and we have to go back to 3DSmax/BTB/RTB.. so answer, please fast..).

I expect that when i "build" a new road mesh, it is an actual mesh and it is MINE to use where-ever i like. Kind of pointless if i have to use one project for the entirety of the game lifetime, working in a 6 men team

Click to expand...

Hi SquidCap,

Indeed by default the mesh data is stored in the scene file. It is recommended to keep it that way for various reasons like cleaning up deleted road objects.

However In Build Mode you will see a button "Store Mesh Assets in Assets Folder" which does exactly that and was implemented to deal with road networks being stored as prefabs, exported in packages etc.

Hi Raoul,
I picked up the pro version a couple weeks ago and have had quite a bit of fun working with it. Congratulations on creating such a robust asset. I really love using easy roads. Can't wait for V3!! - thanks again for your dedication and hard work.

Indeed by default the mesh data is stored in the scene file. It is recommended to keep it that way for various reasons like cleaning up deleted road objects.

However In Build Mode you will see a button "Store Mesh Assets in Assets Folder" which does exactly that and was implemented to deal with road networks being stored as prefabs, exported in packages etc.

Thanks,
Raoul

Click to expand...

Wonderful!! I knew it had to store it somewhere, i was just looking at build sizes to fit the specs given and noticed that i can't use the mesh as-is so i definitely have to pop the mesh in blender/3dsmax Plus i want to test some extrusion stuff, making tunnels and such..

Really greatful that the camber is there, i was asking it last year... It still creates a lot of errors, harmless and temporary of course but it always adds a bit suspense when you see red in the console If i had to change one thing: to increase limits.. I'm doing 50m wide roads already with max shoulders. And camber to negative direction too, in my case digging the road in to the ground would be preferable in most cases (canyon podracer..).

Hi Raoul,
I picked up the pro version a couple weeks ago and have had quite a bit of fun working with it. Initially Congratulations on creating such a robust asset. I really love using easy roads. Can't wait for V3!! - thanks again for your dedication and hard work.

Click to expand...

Hi jcarrick,

Glad you like it and thank you for the kind words, much appreciated

The next beta will include many small improvements and some additions. It will also be included in the current asset store package (provided this is indeed allowed for asset store packages…). This will be the final feature set for the first public release. It will replace the current v2 once additional resources such as a new demo project is completed. After that there I still a lot more to come but I am eager to finally release this new tool. Meanwhile please report issues you are having so they can be dealt with before the release.

Wonderful!! I knew it had to store it somewhere, i was just looking at build sizes to fit the specs given and noticed that i can't use the mesh as-is so i definitely have to pop the mesh in blender/3dsmax Plus i want to test some extrusion stuff, making tunnels and such..

Really greatful that the camber is there, i was asking it last year... It still creates a lot of errors, harmless and temporary of course but it always adds a bit suspense when you see red in the console If i had to change one thing: to increase limits.. I'm doing 50m wide roads already with max shoulders. And camber to negative direction too, in my case digging the road in to the ground would be preferable in most cases (canyon podracer..).

Keep up the good work, my job would be so much harder without ER3D..

Click to expand...

Hi SquidCap,

By default generated meshes inside the Unity editor through code are stored in the scene data, that is why the objects created with EasyRoads3D are not available in the assets folder. Like you mentiond this does not work well with prefabs and packages, this came up frequently in v2 hence the export to .obj option in v2 (and v3) and now also the option to store the mesh assets in the assets folder.

The Mesh asset option I mentioned yesterday stores the object as a Unity Mesh asset. Please use the Export to .obj option instead if you want to tweak the objects in your modelling app.

By default generated meshes inside the Unity editor through code are stored in the scene data, that is why the objects created with EasyRoads3D are not available in the assets folder. Like you mentiond this does not work well with prefabs and packages, this came up frequently in v2 hence the export to .obj option in v2 (and v3) and now also the option to store the mesh assets in the assets folder.

The Mesh asset option I mentioned yesterday stores the object as a Unity Mesh asset. Please use the Export to .obj option instead if you want to tweak the objects in your modelling app.

What errors do you get with the tilting/camber option?

Thanks,
Raoul

Click to expand...

Ok, tried it: and no luck..
I don't have Export to OBJ under any menu... I do have Save Geometry and Finalize object and Build Easyroad objects. When switched to inside asset folder (different name there too, are you sure you are talking about v2 and not something that is already fixed in v3?

While i did manage to get some OBJ created with Save Geometry, it is empty.. Are there some limits i don't know about? The road is long, 20km and i got screen full of errors: http://imgur.com/fMBEaYf If i use Outside Asset folder, i get functional gameobject but with hidden mesh?

Tell me again how it is logical to have a control object destroyed, all the data needed to create everything and THEN having a hidden mesh AT ALL?? I'm not angry per se, just annoyed as i don't get the reason why. It is just like all other meshes, it has no control data, no markers, no ER data attached in to it, right? This is after i've build it and lost all connection to Easyroad, in fact, if i'm right, once i've build it, i should be able to delete Easyroad3D from the project? How can i dig it out after that if it is hidden, aka locked to one project..

So.. Why is it hidden AFTER build? I understand that it is hidden while i can still edit the whole thing, of course.. Hard to come with a parable even, a bit like having money in a bank but not allowed to transfer it to another bank. .hmm, not good example.. rendering a video that can be used in one TV?

So, no luck, OBJ is empty, 64b long.. I have been able to create some road meshes before, apparently while messing with it earlier in the same project (found out after i switched the save location to inside asset folder) so is it road length? Is it because i'm using max limits? Should i have that many red errors or is the project just corrupted and should i get v3 if it solves the problems? And sorry for venting a bit, getting frustrated but i get that when i see illogical decisions... And if there are limits, what are they?

The Export to .obj option is available in various places. In Build Settings as "Export Road Network Geometry" and for individual roads as "Export Road". Did you try these buttons? It will ask you for a destination to save the geometry in .obj format.

Those error messages are referring to Unity's Mesh limitation of 65.000 vertices. You can increase the geometry resolution value. However, what exactly are you creating? A 20km road sounds long, doesn't it have any crossings which will automatically result in shorter roads.

Tell me again how it is logical to have a control object destroyed, all the data needed to create everything and THEN having a hidden mesh AT ALL??

Click to expand...

Could you please explain what you mean with this? And this paragraph in general , I am completely lost what this paragragh is about.

What exactly is hidden after build? Is this when you get these 65.000 vertices mesh limit messages? In that case, these messages tell you that the mesh could not be generated because it is too big. If not, could you than please explain in detail what you are doing ideally including screenshots? Please check the history of this thread, I haven't heard of any of these issues before, I need something as a reference to understand what is going on on your end.

Ok, you end with the error messages. Is that indeed when the mesh turns empty? In that case, the above should have explained it.

But you also make a reference to getting v3 if it solves the problem. Is all this actually v2 related ( http://forum.unity3d.com/threads/ea...d-rivers-procedural-geometry-for-unity.82331/ )? This is the v3 WIP thread. I would indeed recommend to try the v3 betas if you are just starting with all this, many new features. But In v2 you can use the LOD Segment option per marker to cut the road in pieces which will result in multiple game objects. This is a way to deal with the 65.000 vertex limitation in Unity.

We use the export option (mainly the one for roads) all the time during debugging to examine the created geometry, it should work just fine.

The Export to .obj option is available in various places. In Build Settings as "Export Road Network Geometry" and for individual roads as "Export Road". Did you try these buttons? It will ask you for a destination to save the geometry in .obj format.

Those error messages are referring to Unity's Mesh limitation of 65.000 vertices. You can increase the geometry resolution value. However, what exactly are you creating? A 20km road sounds long, doesn't it have any crossings which will automatically result in shorter roads.

Could you please explain what you mean with this? And this paragraph in general , I am completely lost what this paragragh is about.

What exactly is hidden after build? Is this when you get these 65.000 vertices mesh limit messages? In that case, these messages tell you that the mesh could not be generated because it is too big. If not, could you than please explain in detail what you are doing ideally including screenshots? Please check the history of this thread, I haven't heard of any of these issues before, I need something as a reference to understand what is going on on your end.

Ok, you end with the error messages. Is that indeed when the mesh turns empty? In that case, the above should have explained it.

But you also make a reference to getting v3 if it solves the problem. Is all this actually v2 related ( http://forum.unity3d.com/threads/ea...d-rivers-procedural-geometry-for-unity.82331/ )? This is the v3 WIP thread. I would indeed recommend to try the v3 betas if you are just starting with all this, many new features. But In v2 you can use the LOD Segment option per marker to cut the road in pieces which will result in multiple game objects. This is a way to deal with the 65.000 vertex limitation in Unity.

We use the export option (mainly the one for roads) all the time during debugging to examine the created geometry, it should work just fine.

What illogical decisions are you seeing?

Hope this helps.

Thanks,
Raoul

Click to expand...

Ok, it must be the max vertex limit i'm kicking my head against..

This is what i mean:
I have the mesh in the scene but can't access it... I have "Finalized" the object*... Don't get why it inaccessible after that, i don't have active easyroads object in the scene and no way to revert back I can restore terrain data, not road meshes..

(yeah, v2, sorry i'm in the wrong thread.. i'm gonna use the right thread from now on and yes, of course i want v3 if it has new features..kind a surprised that it isn't more openly available, how many v2 users do you really want to keep? I get it if the licensing is more complicated, it is understandable for beta.. I've been leading BTB community support for years, i might be useful.. )

This is what i mean:
View attachment 157939
I have the mesh in the scene but can't access it... I have "Finalized" the object*... Don't get why it inaccessible after that, i don't have active easyroads object in the scene and no way to revert back I can restore terrain data, not road meshes..

(yeah, v2, sorry i'm in the wrong thread.. i'm gonna use the right thread from now on and yes, of course i want v3 if it has new features..kind a surprised that it isn't more openly available, how many v2 users do you really want to keep? I get it if the licensing is more complicated, it is understandable for beta.. I've been leading BTB community support for years, i might be useful.. )

Click to expand...

Hi SquidCap,

As mentioned before, by default the mesh data is stored in the scene file, that is how Unity works when generating meshes through code. That is why the mesh in the Mesh Filter component is not pointing to a mesh physically available in the assets folder.

When you finalize the road object all EasyRoads3D script components are removed so you lose the ability to export the road directly through EasyRoads3D. Please do not use the finalize option if the road object is not yet completed.

V3 is a completely new road tool with many new features, it is available in beta upon request. After the next update it will be part of the asset store package provided this is allowed. Please send me a an email or start a conversation for access to the beta.

I have no experience with Progrids but from what I see objects will snap to the defined grid. It looks like it depends on the nature of your road network whether you can use Progrids with EasyRoads3D.

In v3 markers are not game objects like in v2 so I don't think this will work well. But crossing prefabs are game objects so these objects should snap to the grid, roads pulled out from these crossing connections and instantly connected to a crossing on the other end (also snapped to the grid) will match the grid.

What exactly do you want to achieve?

Selecting mutliple markers has been implemented and will be available in the next beta. For now this is used to join two roads. But being able to select mutliple markers will also allow specific alignment options also part of v2.

I'm trying to build traffic paths for the roads in a scene. The road objects have an ERModularRoad component on them but they don't appear to have an ERRoad component or is there another way to access this?

I would recommend to stay away from ERModularRoad and use the API instead. For small implementations I can always create alpha builds if you need it urgently.

I can add something like ERRoad.gameObject to for example get access to the material like in your code?

Just in case, I assume you are using the material to get the type of road? I do not know what your road network looks like but if you have roads connected to dynamic crossings with sidewalks the road renderer will use multiple materials. It could be that the material assigned to roadMaterial is not the one you are looking for. I would probably use ERRoad.GetRoadType() for this.

Originally I was trying to use road types to setup the traffic data but the Crossing/Connection prefabs don't always use a road type for their connections. For example, the "custom roundabout prefab" does this. I suppose I can just make sure I always use connection prefabs with road types defined. I will try this out if you think it's the best way to go.

It would be useful to have some way to obtain the ERRoad interface from the game object or vice versa because I plan to add custom components to the road objects.

@raoul
Thanks. I was thinking it would be easier to place two roads parallel to each other when making a freeway in the editor, if the markers could snap to a grid. In the game I guess this wouldn't be a problem. I could do this with code.

Originally I was trying to use road types to setup the traffic data but the Crossing/Connection prefabs don't always use a road type for their connections. For example, the "custom roundabout prefab" does this. I suppose I can just make sure I always use connection prefabs with road types defined. I will try this out if you think it's the best way to go.

It would be useful to have some way to obtain the ERRoad interface from the game object or vice versa because I plan to add custom components to the road objects.

Thanks,
Miggy

Click to expand...

Indeed road types on custom prefabs were not supported but it is since beta 6.7. I will update the example prefabs.

That is indeed the recommended workflow. First create road types then assign these road types to your project specific dynamic crossings (General Settings > Crossing/Connection Prefabs). It will make creating the crossings easier. All together this workflow will greatly improve building your road network and indeed the road type info on both roads and crossings can be used for other purposes as well.

@raoul
Thanks. I was thinking it would be easier to place two roads parallel to each other when making a freeway in the editor, if the markers could snap to a grid. In the game I guess this wouldn't be a problem. I could do this with code.

Click to expand...

Two perfectly parallel roads close to each other is tricky for several reasons, certainly with regard to terrain deformation and the grid based nature of the Unity terrain object when the freeway is not flat. I will have a look at that. I would probably use a custom shaped road for that with a gap in the middle.

When I use a shader with normal maps, on the road no longer displays texture. I get just a black surface. Has anyone experienced this?

Click to expand...

Hi AiryKai,

In Unity 5 objects are rendered in black when using normal maps without tangent info being available for the mesh. Please make sure to toggle on "Calculate Tangents" in the Build Settings before switching to Build Mode.

Is there any way to use altitude data when importing via OSM or KML? I'm interested in creating a road that respects the real world heights. I have the road points exported from Google maps in GPX format, each point has latitude, longitude and elevation. I could convert it to OSM or KML if need be, but will the elevation be respected on import?

Another thing I'm interested in is accessing the coordinates for each point on the spline that makes the road so I can export them to a custom parser I have. I'm interested in the control points and the intermediate points generated by the spline algorithm, if possible.

Because EasyRoads3D generally works with the Unity terrain object I am quite certain that the terrain height data will be used at the moment. But if you want I can add an option to use the height info from the external data source.

The spline data can be accessed through the API, by for example selecting the specific road in the scene view and the following code:

Code (csharp):

ERRoad road = EREditor.GetSelectedRoad();

Vector3[] points = road.GetSplinePointsCenter();

The API is not yet properly documented in the manual. For now you can use /Assets/EasyRoads3D/scripts/runtimescript.cs as a reference.

L'alphe de huez, tour de france? Challenging! I wouldn't want to do do that 5th corner on my bike

Image 1: The road sections are too close to each other with respect to the terrains heightmapscale. The surrounding area of the white surfaces of one section should not intersect with the indent area of the other section. Otherwise you will get results like in image 1, the terrain breaking through the road at the lower section.

Image 2, 3 and 5: Bending roads with also a reasonable height differences, these are the trickiest situations to handle regarding terrain flattening. There simply are not enough terrain points available in that area to flatten the terrain according the road shape. In especially that area the bending is strong and the height difference is significant.

Image 4: Two roads coming together without using a crossing prefab will result in this. But also in this case where two roads come together with significant height differences near the crossing you will run into the same limitations of the grid based nature of the Unity terrain object as mentioned before. Unless your terrains have a very small heightmapscale it is impossible to flatten the terrain when two roads with height differences near the crosspoint. Just like above, there simply are not enough terrain points available to flatten the terrain accordingly.

So to handle this, either use terrains with a smaller heightmapscale or avoid significant height differences over small areas where roads join or where a road bends. The only other way to deal with this is to use terrain mesh overlays in these critical areas. The first page of this thread includes some mountain road examples with terrain mesh overlays automatically generated using side objects (Shape Type of side object).

copied them here anyway

Also, is this why ideally you like to use the actual road height data from OSM? I would think it will match the DEM elevation data, SRTM 90m?) I wonder if that will be accurate in this case? I will implement that and can sent you a test build if you want.

The surrounding area of the white surfaces of one section should not intersect with the indent area of the other section. Otherwise you will get results like in image 1, the terrain breaking through the road at the lower section.

Click to expand...

Is it possible to shrink the white surface of a section? Right now I'm using the default settings. For very tight curves there seems to be an overlap in some areas.

I'll look at the mountain examples and see if they can be of help to me, thanks for that

Also, is this why ideally you like to use the actual road height data from OSM? I would think it will match the DEM elevation data, SRTM 90m?) I wonder if that will be accurate in this case? I will implement that and can sent you a test build if you want.

Click to expand...

The data I get from SRTM (90m) or Bing (30m) is fairly innacurate for roads, the slopes are very steep and don't match real world road heights in a lot of places and accuracy is important.

I wrote a script that extracts a road path and coordinates (latitude, longitude, altitude) from Google Maps and that is what I ultimately want to use (after I convert to a format compatible with EasyRoads). It seems that Google offers better precision in this regard (about 5-10 meters, depending on region). This is why I want to set the road height from my own source and then let EasyRoads modify the terrain to match the height under the road.

Without this feature my project is pretty much stuck. Do you happen to know how long it would take to implement the road getting height from external source?

Do you indeed mean the biking route? I love to watch those battles in the mountains, Alpe d'Huez is a classic.

I belief for the surrounding areas, the outer part of the white surfaces that snap to the terrain, there is no minimum. The indent values however are important. They are locked to minimum value based on the terrains heightmapscale (size vs heightmap resolution) to make sure the terrain is flattened according the road shape in that area.

I do have code available to unlock that but you must be careful with this otherwise the terrain may pop through the road or the road will float above the terrain. Basically the indent area must always include at least one terrain point just outside the road area that will be leveled at the same height as the road. When you switch the Shading Mode for scene view to for example Shaded Wireframe and zoom in you will have a clear vision of this.

The default Indent and Surrounding values can be changed in General Settings > Scene Settings. Thesevalues will be assigned to new road objects. Than ifor the selected road object you can tweak these values per marker in the Inspector.

Ok, how are you importing the road data at the moment? This afternoon I had a quick look and was about to add this to the data extraction code. However, whereas KML files do include Y info, I actually cannot see any altitude info in OSM files for road data, only lon/lat info.

Yes, you will get better results with a lower heightmapscale. But some of those hairpins are quite extreme, if you are after an exact representation an heightmapscale of 1 or 2 will be required to handle the terrain detail in such a small area. It comes at a preformance cost.

We ourselves also need this kind of detail, we use 4097 heightmap resolution but when all is done the terrain is converted to mesh and highly optimized maintaining detail in the required areas.

As mentioned before the other option is to use mesh overlays in these critical areas for the terrain using side objects. You could use a shader package like RTP to blend the mesh surfaces with the terrain. In this case, because the outer areas of the generated terrain mesh will snap to the terrain, a more detailed DEM will also help getting the best results. I do not know any resources for France but for sure nextMap (5m but commercial) will have coverage for that area.

If you belief the OSM file you use includes height info you could send it to me so I can have a look at it. I will implement the height option for KML anyway.

Thanks for suggesting NextMap, I didn't know about them Indeed it has data for France

If you belief the OSM file you use includes height info you could send it to me so I can have a look at it. I will implement the height option for KML anyway.

Click to expand...

I have not found any information about altitude in OSM files so I'll stick to KML. Do you have an estimate how long it will take to implement?

Another question is if it's possible to change the spline algorithm used for road generation? Right now I'm assuming it's using Hermite or CatmullRom, right? I'm interested in using another algorithm like centripetal or chordal CatmullRom for some tests.

Using the KML altitude info should not be too complicated I will probably have a test build ready tomorrow.

I really like to get v3 out and support for other spline algorithms has not been brought up frequently in the past 6 years that EasyRoads3D exists. But I can certainly look into adding support for additional spline options after 3.0 is released. Otherwise, If you provide working examples easy for me to implement I can create test builds as well or even perhaps add it before the public 3.0 release, but no promises on that.

I really like to get v3 out and support for other spline algorithms has not been brought up frequently in the past 6 years that EasyRoads3D exists. But I can certainly look into adding support for additional spline options after 3.0 is released.

Click to expand...

It's no problem, I was just curious for some experiments, nothing very important What is the name of the algorithm used for splines right now?

Please fix the glitch where the road goes under the terrain. I'm not sure if I am the only person with this problem but it is annoying.

Click to expand...

Hi Netherboss123,

There are a couple of situations where the road can disappear below the terrain purely related to the grid based nature (heightmapscale) of the Unity terrain object and the fact that the terrain heightmap data does not accept negative values.

The Troubleshooting page in the manual covers these situations with suggestions.

Could you provide more info, screenshots, If you think your issues ar related to something else?

The built-in OSM/KML options haven't been really featured yet because indeed there is work to do here on the crossings bit, creating the actual intersections is not added yet. It will be done but, roads/crossings, literally a never ending number of intersection types... It will be hard (a long process) to fully integrate an automated exact representation of crossings that will work for every osm download.

At this moment roads should be cut at crosspoints. I remember I started on integrating standard X, T crossings but I have to check the status of that.

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.