Exported OBJ files are invalid for most software

[cshaa]

As you wished, I continue to bugtest OSM2World, now with a fresher build (2016-12-01) 🙂

If I open an .osm file containing a building and export it to .obj 3D model, most software either fails to load the model or at least throws an error. I've tested many programs, among them:

MeshLab, throws Identical vertex indices found in the same faces -- faces ignored. but then it opens the file without problems.

Microsoft's 3D Builder throws At least one object is ivalid. and offers to repair the model. Before repairing, the floor (the bottom face) of the building is not visible. After repairing the floor appears, but lots of other stuff (including roads, ground, water) goes away.

Sketchfab (an online 3D model gallery) didn't show the floor and reported:

• Geometry has no normals
• Geometry normals have been recomputed
• Geometry normals have been dropped

From my understanding, the fact that roads etc. disappear in 3D Builder is not much of a deal, as it's mostly a 3D printing software. It seems to me that it simply ignores solids of zero thickness. The rest however seems to be a problem with OSM2World.

I attached both the source file and the output from OSM2World. examples.zip

[balazsdukai]

@m93a are these the errors that you refer to? because I'm having these issues and I'm not sure if the problem is on my side (Blender) or with OSM2World.

[pinglis]

Hi,

does enabling backface culling in blender solve this problem? I seem to remember having the same issue with jMonkeyEngine last year and enabling that solved my problem.

I'm not sure if OSM2World could do something different to prevent this being needed though. The problem (I think, tordanik will know for certain) is that walls (for instance) have two sides but there is no depth between them. The front and the back are essentially in the same x,y,z coordinates but facing the opposite way from each other. Blender, when rendering, doesn't know which one to show and so shows half of both. jMonkeyEngine flickered between them which was way worse.

Enabling backface culling tells blender to take notice of the direction the planes are facing and ignore those with the back to you (I think) and should fix the problem. It might cause other issues for you but it mostly worked for me with jMonkeyEngine.

paul

On 6 April 2017 at 12:15, Balázs Dukai [email protected] wrote:

@m93a https://github.com/m93a are these the errors that you refer to? because I'm having these issues and I'm not sure if the problem is on my side (Blender) or with OSM2World.

[image: building1] https://cloud.githubusercontent.com/assets/7190603/24751645/afeacd42-1aca-11e7-8729-8d837befdfc2.png

[image: building2] https://cloud.githubusercontent.com/assets/7190603/24751690/d6484e60-1aca-11e7-9541-6d231b52fc2b.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tordanik/OSM2World/issues/120#issuecomment-292142678, or mute the thread https://github.com/notifications/unsubscribe-auth/AMRdbYzCAADxcc8I7J9BWmvVcByJJA_7ks5rtMlTgaJpZM4LrLO2 .

[balazsdukai]

I'm afraid there is more to the problem than incorrect rendering. Also, because enabling backface culling doesn't solve the issue.

This is how the wireframe of the building looks:

I validated the object with a 3D primitive geometry validator val3dity and it says that the object has repeating consecutive points. See section 102 -- CONSECUTIVE_POINTS_SAME

[pinglis]

Is the roof of that building supposed to be flat?

I asked because it appears i also made two other changes in my copy of OSM2World. I changed the default roof type to be gabled. This means that if the problem is specific to flat roof i generally wouldn't have seen it as most buildings do not have a roof specified. I prefer this but i understand why todanik does not.

The second change I made (over a year ago so apologies for not remembering all the details) was to remove two overridden functions from the FlatRoof class in BuildingModule.java (functions starting 1371 and 1396). Honestly, i didn't really follow what they were supposed to be doing but removing them seemed to fix my issue at the time.

https://github.com/tordanik/OSM2World/pull/110/commits/2b146feaf7aa0af92abac95ec0fd8b0e215ec356

My comment against this change was:

'Fix flat roof rendering issues

The FlatRoof renders incorrectly when imported into blender. I've fixed this by removing the roof height of 0. Not sure if this is the right thing to do but it works.'

paul

On 6 April 2017 at 14:18, Balázs Dukai [email protected] wrote:

I'm afraid there is more to the problem than incorrect rendering. Also, because enabling backface culling doesn't solve the issue.

This is how the wireframe of the building looks: [image: building3] https://cloud.githubusercontent.com/assets/7190603/24755779/b7400ccc-1adb-11e7-8474-0df16c9a91a1.png

I validated the object with a 3D primitive geometry validator val3dity http://geovalidation.bk.tudelft.nl/val3dity/ and it says that the object has repeating consecutive points. See section 102 -- CONSECUTIVE_POINTS_SAME https://github.com/tudelft3d/val3dity/blob/master/errors_description/errors_description.md

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tordanik/OSM2World/issues/120#issuecomment-292171440, or mute the thread https://github.com/notifications/unsubscribe-auth/AMRdbR5TuM33bQB-01qQLiJFUJy3o-Azks5rtOYrgaJpZM4LrLO2 .

[balazsdukai]

Hm I don't know if the building should have a flat roof, but when I repair the geometry with FME it does have a flat roof. The repair essentially corrects the consecutive points.

Also, if you take a look into the .osm file in the examples.zip above, there is no info in it about the shape and height of the roof. So I went ahead and added the tag <tag k='roof:shape' v='gabled'/> manually. Then the building is constructed and rendered correctly in Blender.

So it seems that the code on the master branch doesn't handle well when there is zero info about the roof.

[tordanik]

For the record, I've found a potential problem related to degenerated triangles, see #121. This is probably also the source of the error message in MeshLab.

[RaceTheMaSe]

Is this issue being worked on? It sounds like you have located the problem with the roof attributes and say its easy to fix/workaround that.

Could the roof attributes be added to buildings internally if non-existant in OSM data so they exist and generate a valid obj?

I manage to get usable files but with additional import/export steps which is a little annoying. Apart from that, awesome project! Keep it up! :-)

[tordanik]

The specific sub-problem described in #121 has essentially been solved. (I still need to actually implement the fix though, sorry for the delay there.)

As for using default roof shapes if no roof information is tagged in OSM, that's already being done. It's just that the default is a flat roof, which happens to be the shape most affected by degenerated triangles. After fixing that issue, there will no longer be a difference between gabled and flat roofs in that regard – both should then work properly.

[tordanik]

Update: #121 is now fixed. This may also resolve the MeshLab error message.

[RaceTheMaSe]

Just tested importing obj for two test areas and MeshLab still produces the error. Importing to Blender 2.78c also fails with this error:

But thanks for working on it again. :)

[walzert]

The Error with string to float from @RaceTheMaSe could be solved by replacing the commas by dots in the ".mtl" file. That worked for me.

[RosaryMala]

Just reporting that this problem is still there in the current master branch.

Opening "validFile.osm" from the test files, and exporting to obj, results in faces with duplicated indices.

# This file was created by OSM2World 0.2.0 - http://osm2world.org

# Projection information:
# Coordinate origin (0,0,0): lat 48.57416506536009, lon 13.46649169921875, ele 0
# North direction: (0.0, 0.0, -1.0)
# 1 coordinate unit corresponds to roughly 1 m in reality

mtllib mayapur.obj.mtl

g Road
o Road0
usemtl ASPHALT_0
v  -350.2923953719684 0.0 182.85599319899404
v  -348.1036046280316 0.0 186.20400680100596
v  -297.474687695838 0.0 148.32599319899404
f 1 2 3
v  -295.2858969519012 0.0 151.67400680100596
f 2 4 3
f 3 4 3
f 4 4 3
v  -241.09439537196837 0.0 111.46692491301788
f 3 4 5
v  -238.90560462803163 0.0 114.8149385150298
f 4 6 5
f 5 6 5
f 6 6 5
v  -75.23228738635932 0.0 3.039917852594316
f 5 6 7
v  -73.2997126136407 0.0 6.542082147405685
f 6 8 7
o Road1
v  59.167220277181144 0.0 -58.51863040410322
f 7 8 9
v  60.832779722818856 0.0 -54.881885742589716
f 8 10 9
f 9 10 9
...

f 4 4 3 is invalid, and will cause most programs to not be able to import the file.

[RosaryMala]

I've made a fix in #136

[artlog]

Please see my fix #137 for ',' inserted instead of '.' with french language.