I have a question concerning obj2mesh: for a large structure I get an error “obj2mesh: internal - too many patch triangles in addmeshtri”. I tried varying the maximum resolution (-r) and the maximum surface set size (-n), but could not suceed in creating the mesh. Any hints on that?
Maybe a question for Greg - would it help to raise the limit in mesh.c, line 520, which is hard set to 256? Or can this cause errors elsewhere?
Thanks in advance!
It’s not possible to encode more than 256 double-joiner triangles per mesh patch, so increasing the value in this test wouldn’t help. I don’t know and have difficulty imagining how this particular situation arises in your model, since there are typically just a handful of double-joiner triangles per patch. Have you tried exporting your model at a lower resolution to see if it works at all? I wonder if you don’t have a large number of triangles all coming to a point, which might be a problem.
thanks for the info!
It was already the lowest resolution in the Rhino export (and still gave a
180MB obj file, still that’s only part of my overall model ;-)). I will
check if there are many triangles meeting in one point (which might be as
Rhino sometimes works strange in the export…) and I will also try
additional export settings.
I’ll give you an update tomorrow!
Hi Greg and all,
a short update on the obj2mesh problem: in my example I had at most 19
faces joining one vertex. Re-exporting the geometry with a greater minimum
edge length in Rhino gave me a file where not more than 14 faces are
joining one vertex. This file can be converted to a Radiance mesh without
problems. Could it be that 16 (=sqrt(256)) is the limit?
I’m glad you got it to work. The limit of objects coming to a point should be over 500, so that must not be the problem in your case. It could just be a very high concentration of triangles in a particular part of the model – I don’t know. If you were to send me a pair of .OBJ files that work and don’t work, I could try to figure out the problem.
OK, thanks to David for sending versions of his .OBJ file that did and didn’t work. This turns out to be an interesting problem, but not one I can easily solve given the Radiance triangle mesh architecture. His model consists of long, skinny triangles (or quads) connecting smaller, denser regions. This causes obj2mesh to create patches in the dense regions, which then need to be joined to other patches via these many long triangles. The general assumption in the RTM data structure is that most of the geometry is local, which is not true in this model. If you have more non-local than local triangles associated with a patch, then the mesh cannot be represented with the RTM structure. I don’t think this can be fixed without a ground-up redesign, which would end up being much less efficient for most models, so I don’t think it is worth it.
Instead, I recommend the workaround of converting to a frozen octree using:
obj2rad model.obj | oconv - > model.oct
This can then be instanced in the same way one would an RTM, the only disadvantages being that it will take up more memory and won’t have local texture coordinates available.
A P.S. to this – I managed to massage the code used by obj2mesh so it would work on at least the one failing model you sent me, by being more judicious about which patch it added double-joining triangles to. I don’t know if this is a general solution, but you could try it on your more finely tessellated exports to see if it works on those as well.
many thanks for the analysis of the scene and for your changes to the code
which solved the problem!
And thanks for sharing the information about the background of the problem
with the long triangles - this helps for future projects to critically look
at exported geometry or even further tweak the export settings to avoid
Just a heads up that I have run into a similar problem, and that a fix that tends to work I found is to split my model up: instead of exporting to one
.obj, I export it to multiple
.obj files and convert them to separate
I am also facing the same problem with my models. What is the proper value to use with the -n flag I’ve tried with 7/15/30/100 (based on the documentation the default one is 9) but it didn’t work.
Increasing the -n option won’t prevent this error, as the error itself means there are more than 511 (MAXSET) surfaces in a tiny volume of space. This can be caused by software that turns a circle or a cone into 1000 triangles, all meeting at the center. There are other causes as well, such as duplicate, overlapping geometry that went unnoticed, but triangles coming to a point is the most common one. You have to find out which surface(s) are causing the issue in your model, unfortunately.
I see, thanks for the explanation Greg.