I just came across a weird phenomenon.
First I thought I set the orthophoto region too close to the object and cut something protruding off (which happened before).
But in this case it is actually the TEXTURE that has holes in it - several in the same model. The mesh is absolutely fine!! A few others of 15 similar models in the same building also show holes. The Black colour is only the background, PNGs have a hole. Many of them show slight “burns” around the edges, meaning they are slightly darker. The sample one is by far the biggest and most complex, most of them are only several pixels of size and trianglularly shaped - as if one (or in this case several) surface triangle has simply been omitted. The coverage is not different from the areas directly adjacent and there is nothing special there like stains or reflecting pebbles or anything. Texture quality is 100%.
Hi Götz Echtenacher
Where ahve you created UVs for this model ? inside of RC or outside ? As the informations on UVs look to be wrong. ( run UNWRAP tool with the FIXED TEXEL DETAIL option and use the OPTIMAL TEXEL Value to get 100 % Tx quality )
Hello again,
so the first 2D view is an orthographic projection or a render of the textured model created in RealityCapture?
And how come that the texture quality is 100%, when there are holes in it?
Hi Wishgranter,
inside RC - I don’t do anything else (yet).
The TXQ is already at 100%!
Hi lubenko,
sorry, yes, the blue view is a textured orthophoto, the green one the same model but shaded (ambient occlusion vertices from meshlab - there is no hole), the coral one is a photo, the last one the dense point cloud (obviously).
I don’t know why it says 100%. That’s what RC tells me!
The holes are very small in comparison to the entire model, my guess is maybe combined max 20 triangles at 2.000.000 (whatever RC gives as info - I am working on sth else just now so I can’t look).
The confusing thing in my eyes is that the texture isn’t wrong (which I would never have spotted anyway) but entirely missing!
Also they occur in the best parts of the model with the highest resolution and not in some obscure problematic corners at the margin.
They are not too big as well and could be easily fixed in IP but I think it is at least worth investigating.
I will try an unwrap like WG has suggested and report back.
Ok, the texel size was already at the optimum according to unwrap calculation.
Did the unwrap and the identical hole showed up (made an orthophoto with checkerpattern).
The TXQ was 99% after original 100%.
We will check it.
I have recently seen this as well.
I am using fixed number of textures (2 or 3) for my small models which is more than ample texture space for those.
I do get those “holes” as well.
See example model here:
https://dl.dropboxusercontent.com/u/255 … _holes.zip
Nice model!
Looking at ST’s model I went back to mine and discovered to my shame that the holes actually ARE in the Mesh!
Apologies for the confusion!
I realize now that in the cases I was looking at the orthophotos I created from the shaded models still had the large triangles of the RC-model-wrapping in the background, so it did not show in the orthos…
This fault does not show up in a slightly different alignment of the same set.
Although I did run that one through Photoscan first and used the undistorted images.
This results in a better alignment but sadly in a slightly blurrier texture, but that is another issue…
Oh, and not to forget that it only showes in the simplified model, at least there are no abnormalities in the original mesh as reconstructed.
I do practice the fusion-technique, meaning I simplify to a marginally smaller number first so that all parts get fused into one and then to the target number. Maybe that is relevant?
Tried to repair the mesh by Close Holes filter in meshlab, but RC doesn’t seem to accept the additional faces…
I can say with certainty now that one or both of the simplification algorithms create random holes in the mesh.
I had a 7mil tri model.
Simplified using legacy to 3.5 mil, from 16 parts to 1. Otherwise new algorithm introduces dense lines of points along part borders.
switched algorithm to new one.
Simplified to 1mil, 500k, 24k tris.
unwrapped, textured, exported.
Below picture shows you the various holes I got. They roughly seem to be on or near where part corners used to be.
So I am not sure if its the new or the old algorithm that is causing them.
I can provide the project folder if needed.
rc_simplify_creates_holes.jpg
ShadowTail wrote:
I can provide the project folder if needed.
That could help, please do.
Here’s the project folder:
https://dl.dropboxusercontent.com/u/25588164/Frecso.zip
its a 1.4 GiB download.
Hi ShadowTail
use SIMPLIFY and do the process from full res model to desired tris count, but not from already simplified model or inbetween results.
That is what I usually do.
But sometimes I do need meshes with specific different polycounts.
I’m seeing them as well…
Simplified from 45m mesh to 4m and seeing holes in some of the shadows (holes from outside to interior, not through due to filter chopping off the back)
Since the original is so large and thus can’t render with mesh (yay I got the update) it’s hard to tell if the holes exist in the source model.
anim gif showing holes in untextured model:
https://goo.gl/photos/XEkzsZFRJyRp9GPd9
Could it be caused by self-intersecting faces (or however it’s called properly)?
Because very often the holes cannot be filled by standard repair algorythms either.
Tried it with The Competitor, blender and also meshlab…
Dear all,
we assume that this is not a bug but an alignment problem. We mean that there can be a few wrongly aligned images that actually cause that the algorithm fights between the good and the bad solution and delivers the “hole”. This explains also the behavior when you disable some cameras for meshing.
Hmm, in my cases there are no problems.
Real good surfaces, as crisp as one can hope for - even stone tooling shows up.
Also, it does not explain why it occurs after the simplification step - that should be independent of the alignment and just deal with the mesh, right?
Has anybody looked yet if there are holes already in the original mesh in the affected area?
lubenko wrote:
Dear all,
we assume that this is not a bug but an alignment problem. We mean that there can be a few wrongly aligned images that actually cause that the algorithm fights between the good and the bad solution and delivers the “hole”. This explains also the behavior when you disable some cameras for meshing.
I disagree with this statement.
To prove my point I have taken a number of pictures under pretty much ideal conditions.
You can download this project and see for yourself: https://dl.dropboxusercontent.com/u/255 … -08-10.zip
Normal reconstruction returned 2.5 million tris.
Simplify to 2 million - looks fine.
Simplify further to 1 million - you can see holes appear.
Simplify further to 500k - you can see the holes getting larger.
Simplify further to 25k - You can see new holes appear.
When you disable visibility of the individual mesh parts you will observe that all holes are either on or close to the part borders.
These holes do, however, not seem to appear when you simplify straight to the target polycount. so 2.5mil => 25k will look fine.
Mayhaps the bug is not with the simplification algorithm but with the code that determines which tris are sharing a border with another part.
But a bug there is.