Texture crisis -- a plea for workarounds

Development Asset Creation
,
41

Hello Benjamin – thanks for your continued descriptions of the water surface around these whirlpools you face…

I appreciate your attempts to tease out the states that cause ‘invalid function calls’.  RC’s input tree is set in stone on initial import – WishGranter has confirmed that indices for input images are set on import, which makes me think the scene graph relies on a single vector of class instances at runtime, or something similar.  This fixed index means that deleting files ex post facto is hard, not simply something RC chose not to expose in the UI.  It also means that disabling/enabling sets of images does not change the index, which RC could use for initial pair selection or other alignment processed.  It’s possible, then, that disabling regions is merely shuffling deck chairs on the Titanic, if the index itself is corrupt.

This possibility is one that you could explore with RC by sharing the files and making a bug report.  I think you’ve demonstrated beyond reasonable doubt that this is one (or more) bugs relating to indexing; unfortunately, these may be subtle issues or ones welded into the core schema.  Another sign of growing pains in a fast-expanding code base…

You found another concrete sign of trouble if you SHIFT-reset RC without an effect on your swap target.   That’s helpful.

Hello,Götz!  I think Benjamin is demonstrating time dilation:  when you’re stuck with a problem, minutes can feel like hours.  I guess the weekend you were away from the forum might seem like an eon.  :wink:

42

Ha, time dilation, hadn’t considered that, explains a lot.

Regardless of where I put the files originally for use in project A, I can’t see how relocating those images on another drive would matter to a  new project B. With cleared cache, newly installed RC, a new project B, I can only see two possibilities, something related to not being able to reset RC settings or what Götz and you point to with a problem for RC in the imagery. I’ve had to shelve this scene in favor of getting farther down the road on other scenes (RC behaving otherwise smoothly), but plan to divide and conquer the 500 images, see if I can isolate the problem child or children photos. You’d think if a single problem child photo existed, that alignment with max reprojection error at default 2.0 would cry uncle, leaving that child orphaned. So, how could my component retain all 500, moreover maintain alignment as I ratchet down to .5 max reprojection error? And while the iterative workflow, we agree, might invite problems, recall that even the new project set to 2.0 MRE lead to IFC.

I’ll have an aneurism overthinking this weirdness, the physiological counterpart to invalid function call. Maybe, it’s contagious, spending too much time down in the data mines with RC ;^) I’ll contact support offline and see if they’ll look at shared files. Will report back. Big thanks to you both for all the time you’ve given here. It says a lot.

43

Time dilation - excellent. Must admit I haven’t thought of that…  :slight_smile:

Benjy, it’s probably the right thing to do to get some stuff finished that works before continuing with the trouble child. Sometimes after giving it a break, things just resolve themselves.

I have another observation that puzzles me a tiny bit. For my latest projects, I usually don’t do the ratcheting any more since all I need is one alignment (K+ Brown 4 tangiental, MRE 2.0) with exif grouping followed by another one with no grouping and I get 0.3/0.4 Median and Mean Errors, which I think is quite acceptable. Tightening the MRE often introduces areas with no or insufficient Tie Point coverage. So I wonder if you could improve your errors elsewhere in the process, for example by playing with the distortion model. Your optics should be way superior to mine, so you should be getting better results with the same workflow. In theory at least…

Kevin, but shouldn’t starting an ENTIRELY new project and loading all images ANEW into it resolve any issues that might have been introduced as corruption along the way? I am certain that I have experienced similar issues of corruption and it has even been officially recommended to make backups before each and every step for exactly that reason (which in my view is almost unrealistic because it’s not worth it for small projects and can easily get out of control for large ones if you don’t have a huge infrastructure at your disposal).

I’ve read about the problem of the fixed index before but nobody has ever put it so clearly as you have just now. Thanks for that! In that respect it is all the more worrying that it is not possible to influence the order in which the images are being indexed short of dragging them in one by one…

It’s really quite a shame that there are no comments from the DEVs on this at all. Like you hinted, Kevin, it is almost impossible to prevent difficulties along the way of expanding a code like this. So I wish there was more openness on the side of RC because an enemy that you know is much better than one that is lurking in the dark. If we knew where the problem is or how it may be caused we could probably work around it and wouldn’t even feel the difference after a while. As it is, it is like Russian roulette…  :slight_smile:

44

Thanks, Götz. I like your idea of dropping the ratcheting, only keeping the group by exif True to False state switch, keeps it simple. Indeed, this IFC happening on a new project with no history in cache and freshly installed app truly positions this case as the poster child of mutant math mysteries. I left out one consideration, the subject matter. A mining machine bores through solid stone leaving a tunnel not unlike a plunge bit driving into wood or metal. The one difference here is that gravity acting on the removed debris falls to the ground, leaving piles of finely ground mineral in rows:

Not exactly what’s meant with “a highly occluded environment”.

I’ve reached out to support offline, invited them to this thread. It takes a village, and ours features a bustling castle making its way in the world, so let’s give it a chance.

45

Hey Benjy,

that’s a good plan, to knock on other doors as well. I’m amazed that you manage to stay so calm, which is the only way of course. But still…   :-)   My German frankness might come across as more negative than it is intended. :wink: But as you probably know, my intentions are good!

Anyway, so you are saying that the dust piles don’t provide for many usable tie points in that area? Then it might be better to keep exif grouping on, since that is perfect to bridge those gaps because it can figure out the geometry from toher images where the bottom is filled with better suitable surfaces. If you did not play around with the focus or aperture, then the geometry of each image should be identical anyway, which again means that you won’t have any disadvantages from keeping the grouping.

Oh, forgot to press send last night…

46

Hi Götz,

Frankness is healthy, of course without sharp barbs, but I don’t hear that in your words, which are consistently vernünftig and polite. 

I don’t believe the dust piles lack reliable features, at that high-frequency scale, there might be noise, but leaves plenty to go on to say “this is the ground connected to the walls”. Again, with MPE left at default 2.0 RC has no problem aligning. Especially in light of what I now have to share, I think we’ve been barking up the wrong tree, that this has anything to do with “knots” propagated by buggy code. Sure, the ultimate cause may still reside there, I’m just saying we now have to get out of the box that is RC and talk about system as well, to wit;

Thanks to Ivan’s benchmark project, as discussed here, I saw an opportunity here to isolate against RC Promo, given the benchmark.bat only works with Demo over Steam and CLI versions (maybe, leaving out something). Interestingly, the 500 images I pointed benchmark.bat to made it through depth map creation!, this being where Promo consistently gets stuck and throws the IFC, then reconstructed all parts, though things go off map after that. I missed what happened next, as this happened while sleeping, but awakened this morning to a results.txt that reported empty fields for elapsed time for any of the operations, “echo is off”. Is that behavior related in any way to the badness in the licensed version? Let’s not rabbit hole that deep, but clearly this latest test holds important clues.

I’m working with RC devs to sort this out, have shared my images. How many other scenes feature the same subject matter, the same walls, the same powedery salt mineral on the ground, and have reconstructed without event? I’m suspecting the imagery still plays a role, kind of obvious since RC is behaving well with the other related image sets, but something between RC and my system, possibly a largely dormant but nasty bug, is creating the mining inverse of a mountain out of molehill.

I’ll surely report our findings, the case only grows curiouser and curiouser. 

 

47

I’m thinking I have an audience of two, Kevin and Götz, hello guys, and I’m thinking you’re both bored by now reading the continued saga of my troubles with invalid function call. If you can spare a firing neuron, I could use it. I come from Mac OS, so I’m thinking this issue may relate as much to Windows as to RC, but I also believe RC fired the first shot, am curious what you believe.

Götz is aware of the benchmark project begun by Ivan, thought this test useful for isolating against the licensed version, since benchmark.bat only works with Demo and CLI. Indeed, the set of 501 images ran without an issue through textured model. To recap, These 501 images throw the invalid function call when residing in the same project with some 2800 other related images, but then also when in a new project, but then also in a new project after uninstalling and reinstalling RC. So, if the images not only align without a problem in the Demo install, but reconstruct and allow texturing, then clearly this doesn’t relate to the content in those images triggering a corruption, at least not in a predictable and consistent way that RC can’t deal with the content, as the Demo demonstrates. Ivan pointed out that sometimes Windows fails at deleting all program files during uninstall, to try CC Cleaner. In fact, after uninstall and reinstall I launch RC and see the setting for cache drive location hasn’t reverted back to the default C drive, so something is bleeding through. 

RC devs loaded the imagery and were also able to run them without an issue. I’m awaiting further word.

I’m still relatively new to Windows, don’t see these issues on Mac OS, am clueless how to isolate and zap this issue. If I didn’t know any better, I’d think a clean install of Windows before a fresh install of RC should ensure zero pollution, but do I need to zero out all drives first to be absolutely sure? Do I need to toss this PC in a dumpster and transfer licenses to a new PC to be even more absolutely sure? Whatever happened in RC to spawn this nutty behavior, I’d hate to take any drastic measures beyond the minimum necessary. Thanks for any ideas.

48

Hey Benjy - you are not alone, well - in the sense that your not being ignored :slight_smile:

If you are confident that it’s your personal installation.  You could as a last resort try manually searching for any instances of reality capture in the registry and deleting them, however at that stage, it really is taking an axe to a butterfly and you could end up needing to reinstall windows due to the damaged caused.

 

A few possibilities I can see could be the issue in no order, and I’m shooting from the hip.

  1. The promo version acts differently to other editions, even if it technically shouldn’t. 

  2. As previous thought, the installation is corrupted by a setting that isn’t easily removed even by uninstalling.

  3. Your windows installation is knackered.

  4. You have a hardware issue that is only brought to attention by the promo version.

  5. Your drivers are causing issues that are only brought to attention by the promo version.

Have you tried installing the Promo demo ? (which is effectively the cli demo, cant be installed alongside promo), and if so does that work ?

Before throwing the system out of the window or reformatting, you can dual boot 2 separate installations of windows ( I do).  You will either need to install the 2nd on a separate partition or another drive.  

If you do go for a full re-install which is easier, a quick format is fine on the windows drive. no need to zero the drive, or the other drives.

 

 

49

Hi Ivan,

great to have you on board here! I have scheduled the benchmark (along with putting in a new harddrive) for the Xmas break, promise!!!

Benjy, I guess that you have probably already started with Ivan’s suggestions. My vote for the first step is on the excellent idea to just take a different drive (sounds like you have plenty) and create a new windows install without nuking the old one. That way you can easily roll back without any issues. Think about removing the old drive entirely for that. I agree with Ivan that messing with the Registry can do more harm than good, expecially if you are not familiar with it. Plus you can never be entirely certain what kind of keys RC adds to it anyway…

I can’t imagine that it’s down to the Promo as opposed to the CLI since, as Ivan says, they are (or should) be identical except for the restrictions. Of course, there is always the unpredictability of complex software. But, as you said, the success of the Steam Demo proves that it’s not the imagery nor the algorythms per se but some permanent corruption. Did the guys from RC provide you with their project file yet? Should be another clue how that will behave in your system (first only texturing, then reconstructing plus texturing and finally realigning with the following steps) - if all succeeds, then the error is somewhere in the first files that RC spews out, if not, then it must be in the Registry somewhere. At least in the imagination of a non-programmer (that was the third neuron today, btw…   :slight_smile:

In any case the DEVs should be very interested in all this because it points to a serious bug. You might be responsible for homing in on the cause for those random crashes tormenting people in the past!

I am sure the end is nigh…

 

50

Thanks, both Ivan and Götz, steering me through Windows Wonderland. I may have to create that drive, but also possible it’s something else, which I discussed with Götz offline about a possible problem encountered when images are moved, but also a question raised about files being generated (by RC?) that possibly filled up a drive, forcing me to move said images. More to come, but hopefully we’ll all learn something.