Apparently Blender’s OBJ export is broken.
I am not really sure if it is broken or just not compatible with TerraSculptor import.
I have been in contact with David - The developer of TerraSculptor - regarding importing OBJ files into TS, but it seems that the blender export is very messy, and it isn’t possible to read by TS.
If anyone has any development skill and knowledge of OBJs and wouldn’t mind contributing his time to try and fix the situation, I can put you in contact with David.
TS is a great software to create world terrains and maps, and it would be great to see Blender and TS compatible.
Could you be more specific about this? Because the OBJ-format is very simple and very old and also a pure text file… and for simple geometry this seems to work for the most users… Can you give an example? Did you tried STL because TerreSculptor seems to know that too?
I have tested STL files, and I get strange results, object is too small, off centre and not normalized.
In general, working with imported meshes in TS is a bit tricky, or maybe I am just doing it wrong.
Here some of the early correspondence I had with David -
"The data looks to be a flat plane with non-equal grid vertex locations and in the order of XZY.
With XY being the vertex locations and Z being the elevation data. So a Swap Y Z would fix that.
However, what will be messing up TerreSculptor is Blender’s method of specifying the faces, which is non-standard for OBJ files.
The faces in the file you sent are specified in triplets for a quad:
f 135/1/1 24/2/1 4/3/1 35/4/1
f 34/5/1 2/6/1 15/7/1 45/8/1
f 45/8/1 15/7/1 16/9/1 55/10/1
f 55/10/1 16/9/1 17/11/1 65/12/1
f 65/12/1 17/11/1 18/13/1 75/14/1
f 75/14/1 18/13/1 19/15/1 85/16/1
Whereas the normal OBJ face definition is supposed to be three vertices per triangle face defined like this:
f 1 6 2
f 6 7 2
f 2 7 3
f 7 8 3
f 3 8 4
f 8 9 4
So unless Blender has an option to list separate faces in the OBJ exporter instead of the 0/0/0 triplet method, then these files from Blender will not work at all."
But that triple-slash description is in the OBJ-standard-definition See here:
OBJ does support quads, normals and UV which can be descript by lines with vn and vt or in that triplet-notation.
So the problem is not Blender but TerreSculptor not implementing the full OBJ-standard. (Just exported a complex mesh and imported it in MeshLab… no problem at all.) So the title is missleading and should be changed into:
Rework other apps OBJ import…
I always wonder why people often blame blender is broken in the first place…
Anyway:
If you could provide a small file… maybe we can make a script to rearrange this? (Are the normals needed? Skipping them is a simple search and replace with …)
For example your slash example in a text file q.txt and a script in blender likes this:
import re
import sys
filename = “pathTo/q.txt”
file = open(filename, ‘r’)
text = file.readlines()
for line in text:
print(re.sub(r"/[0-9]/[0-9]", “”, line))`
(Ups preformating is scrambeld now by discourse… have to look into this…)
Would produce an output like:
f 135 24 4 35
f 34 2 15 45
f 45 15 16 55
f 55 16 17 65
f 65 17 18 75
f 75 18 19 85
I think maybe an add-on for a TS OBJ exporter or something like that would work great.
As I said, I am not a coder and have very little understanding of python, so any help would be greatly appreciated.
ps, You can always download TS, it is a great software
Hmmm so the TS developer does only use triangles with no normals nor UVs… this is usually not the way someone implements a standard but try this while eporting (the gears icon at the file chooser):
So…
It seems that TS is capable of more than 256 tris attaching a 28,800 GRID MESH that TS imported with no problem as long as the export transform were set to Forward -X and Z Up.
But when trying to import a generated landscape from a.n.t I got an error:
It seems that the only meshes I can import is a GRID MESH, why?? what is the difference??
I find this an interesting thread. I use .obj format files a lot, because I use several 3D applications for work. Blender, Poser and DAZ Studio primarily, but I also model in Blender for other applications like LightWave, 3D Studio Max or Maya. I always export from Blender as an .obj file because that way customers have no trouble reading the file, and I myself have no trouble getting it into Poser or DAZ Studio for rigging.
Because I import and export .obj files a lot using Blender I must support the statements that it works properly. Because the obj format specifications didn’t originally make it clear what the scale is that aspect of a file can require attention, because different applications interpret the scale differently. For example a model in Poser exported for use in Blender must have the size specified at 243% (2.43 times bigger) to come out at real world size in Blender. 3D Studio Max also requires some scaling, though I can’t offhand remember the numbers. Once I have discovered the scaling multiplier though I have not had any trouble with Blender’s exported .obj files in recent years. The only time there was ever a bug it was fixed quickly.
See here:
so the TS developer does only use triangles with no normals nor UVs… this is usually not the way someone implements a standard but try this while eporting (the gears icon at the file chooser):
