Unexpected program state

After some five hours high quality reconstruction, I proceeded to Texture, was surprise to see the progress bar move so slowly, was reporting some 10+ hours to completion, which I’m more used to seeing about 1/4 of reconstruction for textures. Then I got the red screen, error “Unexpected program state”. I was monitoring system resources, CPU was kicking at 100%, but memory only down around 18%.

I tried rendering the untextured model, image presented all checkerboards, see attached. That’s not normal, right? I thought with reconstruction we have a mesh that will render the model without color.

Any thoughts?

Thank You.
Benjy

Hi Benjamin von Cramon

I tried rendering the untextured model, image presented all checkerboards, see attached. That’s not normal, right? I thought with reconstruction we have a mesh that will render the model without color.

This is absolutely normal, as you have not finished the texturing phase so when you render that model, you get only UVs to see. You can check this by clicking on the MODEL in the 1Ds view and see something like this:

Model_TXTR details_ChckBoard.png

If you want a rendered model without checkerboard, then render it as SHADED and FLAT - option in the RENDER menu…

What’s the appropriate response to “Unexpected program state” and the fact it indicated such a long processing time for something that normally should be a fraction of that for reconstruction? Was the latter a red flag that something was going awry, and the former an alert that texturing failed, toss the unwrap and try again?

I just clicked Texture to try again, a message returned saying the model already had textures, giving me the choice to unwrap again with “yes”, use the previous unwrap with “no” or of course cancel. So, chose to unwrap again in case the first go was corrupted. The timeline is behaving erratic, has started over a number of times, and the estimated finish has flipped between a matter of hours and days, seen this happen three times. Is this like watching water boil, not recommended?, or abnormal behavior that is normal to computers. :frowning:

I’ve answered my own question, but a larger question remains about stability and learning to read RC’s behavior. With everything described above with regard to erratic progress bar and Texture not finishing, sometimes crashing, I was able to reconstruct successfully by unwrapping again, then texturing, both of which took a fraction of the time BTW. I believe I see the culprit, the previous model broke into 206 parts and 296.3M tris, the same dataset reconstructed returned only 58 parts and 80.6M tris.

Given my 16 GB RAM, was this simply a lack of system resources that prevented texturing from finishing? Secondly, How normal is it for RC to return such radically different results with the same photos? I can keep running reconstruction as I have and see for myself, but appreciate your perspective. I’m not looking for the right answer here, can deal with reality. RC is performing awesomely, I’m in, just need solid ground to properly scope cost factors.

Thank you.

Hi Benjamin von Cramon

I believe I see the culprit, the previous model broke into 206 parts and 296.3M tris, the same dataset reconstructed returned only 58 parts and 80.6M tris.

It’s almost 4 times more triangles, it seems some settings were changed, haven‘t you changed RECONSTRUCTION->SETTINGS->IMAGE DEPTH MAP CALCULATION->NORMAL MODE->IMAGE DOWNSCALE from 2 to 3 ?
Can you click on the MODEL and make some screenshots of both models like this screenshot?

Model_info.jpg

Have you changed any other settings ? Can you make a screenshot of the overall RECONSTRUCTION settings ?

Alas, I had trashed model 1, can only show you the present settings for model 2 when I repeated reconstruction, see attached. What I can say is that no settings were changed, which my posts reflect. I suspected a problem, tried reconstruction a second time, was asked if I wanted to unwrap or not, I elected to unwrap, got the different results.

I’ve only been using default settings while developing a model. Still getting to know RC.

Hi Benjamin von Cramon
But you haven‘t included the last line of the model details. Please take a look at my screenshot, the bottom part…

Actually, I had that pane scrolled down as far as it went, ends with a part instance. I’ve attached another screen grab, this again being of the second reconstruction which you recall ran without issue.

If this happens again, I’ll be sure to look for and grab any info associated with model settings, but I’m certain I hadn’t changed anything between both reconstructions, at this stage wouldn’t know what to change and see little value in arbitrary experimentation.

Thanks.

Hi Benjamin von Cramon
I am reposting the screenshot that shows MODEL details. Please take a closer look and make it like in this screenshot. Crucial information is missing… Look carefully at my screenshot to see what I am interested in.

Model_info.jpg

Hello Wishgranter,

I do believe I was looking closely already at details presented under Model, alas on my end there simply aren’t any those items, e.g. Ortho projection 1 and 2, North, South, etc. My Model only displays 57 parts, then goes to the next model, a decimated version. I do believe I captured everything in the Settings window you might otherwise have been after, am attaching another view here with possibly a bit more to be sure. Thanks for your help.

Hi Benjamin von Cramon
finally the last 2 lines of the MODEL detail… image downscale 2x and NORMAL reconstruction mode…
try using UNWRAP, set FIXED TEXEL SIZE and use 4k-8k texture. You have set 16k and the utilisation is very low… Then set OPTIMAL TEXEL VALUE down to the UNWRAP tool -> TEXEL VALUE and let RC calculate the UVs.

Thanks on a Sunday, Wishgranter. I now realize my mistake, see this second attempt DID introduce a change in settings, against what I said originally. When my first attempt crashed, I tried with Normal, suspecting High quality might be taxing system resources too much (though Resource Manager reported Memory happy, and it’s not usual to see CPU at 100%).

try use UNWRAP and set FIXED TEXEL SIZE and use 4k-8k txtr as you set 16k and utilisation is very low… Then set OPTIMAL TEXEL VALUE down to the UNWRAP tool -> TEXEL VALUE and let RC calculate the UVs.

I’m questioning if you were thinking my posted settings represented the model that crashed during textures. Or maybe, it’s the other way around, you see with those settings, texturing may have crashed because of something, and these recommended settings address that. I’ll benefit from learning how texel size and size of textures and utilization, etc. how these variable relate in an ecosystem, one I’ve been absolved of understanding with other apps, but am eager to now learn in RC. Great having access to what’s under the hood. I’m clear, this isn’t the place to expect that level of education, so where in the RC Help or elsewhere would you point me to get to know these principles?

Hi Benjamin von Cramon
TEXEL size is related to Ground Sampling Distance aka resolution of images on the “ground”
In principle you DO NOT need to care about this :smiley:

Try to focus on getting best results using FIXED TEXEL settings in UNWRAP, do not use 16k textures, use 4k or 8k as they will be always utilised better than too large (more memory intensive ) 16k textures…