Texture crisis -- a plea for workarounds

Answered

Comments

49 comments

  • Avatar
    Benjamin von Cramon

    Hello again. Thanks, Kevin, for your insights and helpful suggestions. I'm unfamiliar with command line structure, was barely able to get openMVG compiled in Visual Studio 2015, much less figuring out the workflow front to end. If you think otherwise and can point me to resources or tuts, I'm all ears.

    I've been waiting to respond, was hoping to report a successful outcome to my strategy of activating only those camera poses on one side of the wall for one reconstruction, then the converse for the tunnel just on the other side of this sharp divide. This worked for the one side, but not for the other. Since, as you point out, RC operates under sequential SfM, the images falling on side A of the divide come earlier in the image sequence, which I though might explain why side A ran just fine. But, when I deactivated side A images and activated side B, I got the invalid function call again. I then deactivated incrementally more images on the front end of the sequence I thought might be the culprit(s), but no go. I then cleared cache, still no go. I then tried Götz' idea, select side B camera poses and export XMP Metadata. These dropped into a new project with cleared cache, noted the georeference icon on some of the images, ran alignment and now RC crashes every time. Here's the window it presents, but note in the console behind, WARNING: some calibration groups contain conflicting priors:

    I can run this batch of images completely separately, but then face the dubious task of scaling and aligning for (next to) invisible seams. I'm truly out of ideas how to deliver this scene in its entirety into a common scale and coordinate system. 

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Hello, Benjamin,

    First, I have to say that I really feel for your plight.  It's very painful -- excruciating even -- to find you're unable to get your work done for reasons that really aren't your fault.  I've worked in visual effects for film for many years and there's a feeling in the TD community that you spend your time 'tricking software into working'.  That's no fun.

    Since you're on deadline with this, I know your time is short.  Please humor me by reading my capsule discussion first, not just my concrete suggestions after.  Götz -- you and I have talked about this before, so you can feel free to skip ahead.  ;-)

    The real root of your problem, I think, is that RC is not allowing you to find high quality points in the feature search state.  RC obviously puts great emphasis on speed -- to the point that they don't allow you to set the feature search parameters at all.  Whether this is a good marketing move for them I won't expand on here (I think it's dubious, actually -- I'm biased).

    The result is that RC feature search fails under challenging situations.  Wishgranter can rely on the old trope "just shoot it right and you'll have no problems", but you and I understand that in difficult capture situations like your cave or my Egyptology locations, you often have very difficult access and no possibility for reshooting.

    As such, RC is particularly brittle when it comes to scenes without true lighting consistency, and I think your input photo set falls into that group.  Because of that, RC can't establish tight enough correspondences to "deliver this scene in its entirety into a common scale and coordinate system".

    This is even more true if you're using manual control points.  I think the user has no business competing with SIFT anyhow -- even with good 'subpixel' point selection you end up introducing noise error even if you can supply tie points the system couldn't compute.

    My practical suggestion for getting a result with the least effort is:

    • Create models for both side A and B separately, if there's any overlap between the two.  Export high resolution meshes for both sides, and then align the two via scaling ICP in CloudCompare, MeshLab, GeoMagic, et cetera.  Since the two models will be in two separate coordinate systems, you need to use SICP, e.g.: assuming CloudCompare for now, turn on scaling here:  http://www.cloudcompare.org/doc/wiki/index.php?title=ICP 

     

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    If the approach I suggested above shows some noise in the overlap region when you export the final model, here's one more step that should help:

    • Now that you've aligned the two into the same coordinate system and scale, you can export the two separate models from CloudCompare, etc. and create a final, clean isosurface without a visible seam using Stanford's mesh zippering approach which is ideal in a case like yours:  https://github.com/sh0/zipper 

    If you have more time and want a (potentially) higher quality result, you can go back to the beginning in a different system and set high quality feature recognition.  I think you'll find that if you start with good points, you'll get good matches and the model that results will be complete.

    I know you didn't have an easy time with Pierre's OpenMVG, so let me suggest again MVE, which is precompiled for Windows in the link I gave you before, and has nice tutorials and documentation:

    https://www.gcc.tu-darmstadt.de/home/proj/mve/ 

    Yes, MVE is sequential in its approach to alignment, however the difference from RC is that you'll have the chance to provide the initial matching pair for sequential alignment.  That could be decisive.

    Of course, it may be that your image set cannot be brought into alignment by today's methods.  In that case, all I can say is that you should keep the data handy because new contributions are coming all the time, and what was difficult or impossible one year becomes simpler thereafter.

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    Hello Kevin,

    That's truly kind of you to take the time writing and sharing with me your trove of knowledge and resources. Many thanks. If I could simply download a Wiki from your brain into mine.

    "RC obviously puts great emphasis on speed -- to the point that they don't allow you to set the feature search parameters at all."

    I might be off base here, but under Alignment settings is Detector sensitivity only geared to time spent detecting features, not matching them to produce tie points?

    "Because of that, RC can't establish tight enough correspondences to "deliver this scene in its entirety into a common scale and coordinate system".

    This is even more true if you're using manual control points."

    This is what gets me. I'm not having to resort to manual control points to achieve alignment, was even able to ratchet down to beneath .5 max reprojection error without dropping camera poses, so to Götz' point, wouldn't this qualify as a bug, and not just a challenge to RC or any SfM solution, when my capture sequences delivered this level of alignment without touching manual control points? My situation with this high up window on the mine wall is actually quite similar to what Götz once faced tieing in a space above and below a thin floorboard, the only connection being though this tiny space, which he achieved beautifully. That makes me question if maybe we're not yet pinning the culprit. 

    This doesn't necessarily stand in conflict with anything you're saying about the ultimate cause(s), but the proximate cause, perhaps a particular photo or some problematic data baked into the component, might be the manifestation set up by those aspects of RC you describe, am wondering if there's any merit to pinning down that gremlin.

    More clues and more weirdnesses. At Götz' suggestion, I exported Metadata (XMP), using the export as locked state and all default settings, then placing those in the same folder next to the source imagery. Imported to a new project, the first weirdness I encountered was that only one image imported from the group I had selected. I checked the directory to see my XMPs, noted that only a small percentage made it out. I went back to the previous project and exported again, this time all XMPs made it out and all images made it in. A possible bug? Did I close the project or make some move to interrupt the export? If so, and I noticed this happening a couple times, that's a bug if RC doesn't manage such expected circumstances.

    Once I was able to confirm all XMPs got exported, I brought the associated imagery into a new project, noted that some images had "exif" next to their name in 1Ds, while others had an icon, which on rollover said "georeferenced". I thought that was interesting, why wouldn't all the images be georeferenced? I ran alignment, got the red flag and same invalid function call. I thought, maybe I could unlock the camera poses, might they change rotation, but keep position, keep something that allows scale/coordinate system to ride along. After exporting XMPs with camera poses changed to draft mode, then importing those to a new project, I now noted all "exif" next to each image. I figured I'd lost what's needed to georeference from the previous project, component quickly aligned and indeed, it showed up centered on the grid, not what I want. I then tried XMPs using exact position, which sounded like that would hold the translation of each camera fixed, but allow rotation to adjust, nope, alignment brought component to center of grid.

    I forget my reason for returning to the previous project, but I discovered that I hadn't been careful enough when selecting the  desired camera poses in 2Ds for activation/deactivation  (didn't scroll high enough to spot first row of three photos), so I tried once more to export XMPs using locked poses, and strangely this time when the group of 501 images dropped into a new project, every one of them displayed the georeferenced icon next to them. What is up with that? I found it all the more encouraging when I ran alignment that the resulting component wasn't at the center of the grid. Might I be there? Of course not. I ran reconstruction and minutes later got the invalid function call.

    So, I'm now running these images without any reference to the mother set, was able to get median reprojection error to .366, will now deal with scaling and aligning by eye. Again, because of the challenge posed by joining these two spaces across this sharp divide to which my best efforts at capture fell short, I have no overlap to work with, if I'm hearing you right about CloudCompare needing some overlap. When I searched SISP and scale ISP I stumbled into camp brainiac at MIT and such. The work on zippering meshes at Stanford looks really interesting, can see how this approach might be useful to mending other problem in RC meshes, especially the problems I encounter with straight lines and smooth surfaces ubiquitous in manmade environments.

    I'm not averse to biting off a steep learning curve if I'm confident the tuts and forums are rich and viable. Balancing deliverables against learning cautions me against heading down dark alleys, moving too fast into new directions. For the present deliverable, which serves an art film and a VR project (not science), I believe I'll get by scaling and aligning this fourth related mesh manually, playing down any problems at the seam with lighting and some other tricks. You do have me curious, however, what's in your toolbox, how you made friends with them, and given I'm not a veteran VFX artist, my background being in live-action adventure docs, how I might proceed in learning openMVG or Zipper. I'll do some reading in the meanwhile. Many thanks.

     Addendum: What gives? I just got the invalid function call after simply importing these 501 images, ratcheting down on max reprojection error (MRE), no XMPs in play. I'll try reconstruction at the default setting, 2.0. Ugh. Götz, I hear you in my ear, "I told you so". I'm now thinking this iterative alignment workflow exceeded its utility. Let's see how 2.0 MRE works. If so, I'll have to go back and reconstruct 1-4 with a doable MRE.

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Broadly, I agree it's one (or more) bugs in RC.  More specifically, I was trying to paint a picture of why there are bugs in this part of the RC pipeline. What you said about 'heading down dark alleys' applies equally to developers -- if we back up a bit, we should acknowledge that RC has been speeding down some of these dark alleys and, sometimes, it gets caught in them.  RC has raced ahead to try to establish a presence, which is normal in software but the human cost of that edge is what you're paying now. 

    Very specifically, looking at your addendum -- I think the fact you're using an iterative approach to alignment (like I find I had to in complex scenes) is the problem.  Based on what I've seen, RC files can become corrupt.  I can't say if its a scene tree problem without looking at the source code, but it feels like that could be at least one of the areas that often present headaches and could could the kinds of progressive errors we see in this forum and in this thread.

    A few short responses:

    • True, 'Alignment settings:Detector sensitivity' is there to give some control over feature point quality, but it's not explained and there should be lots of choices:  first the algorithm (SIFT, etc.) and then all of the tuning parameters, so that you can choose the threshold for rejecting points and allocate more time to search to improve the stability of the results.
    • The zippering approach is old (a classic!) but still useful for cases like this, and still used by vfx studios in a pinch, like yours.
    • Manual alignment is going to be a hard road, but perhaps possible for your needs.  If you truly have no overlap, iterative closest point alignment (ICP) will fail even with good pre-selection of features.  There are approaches for registration via consistency of empty space (no overlap required) but that would require diving into research code, which you've suggested you're less comfortable with.
    • You're correct that learning another way of doing this could take you off path, even if you learn in the process.  You're right to approach things practically, I'd say, which may preclude jumping to another SfM/MVS system.

    Thanks for asking about me -- we can catch up outside the forum, you can reach me as 'kevin' at my domain and see a bit of our work for archaeology (including some for NatGeo/Discovery documentaries) here:  http://www.insightdigital.org/

     

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    Hello Kevin,

    The plot thickens. Perhaps, the iterative approach to alignment sparked the corruption, but as I moved the line of scrimmage back and back, I'm now in my own end zone, fans are booing. Play by play:

    • reconstructed regions 1-3, no issue, region 4 returns invalid function call (IFC)
    • disable all camera poses in region 4 north of the rock window, region 3 delivers mesh
    • disable all camera poses regions 1-3 south of the window, region for returns IFC
    • clear cache, repeat previous step, repeat of IFC
    • export XMPs (various camera pose settings), new project, another IFC
    • clear cache once more just to be safe, new project, another IFC
    • Uninstall RC, reinstall RC, Shift/open RC to reset prefs, new project, another IFC

    I should stop here to note that I question if the most recent build of RC supports resetting prefs with Shift-hold while opening RC. The default cache drive should be back on C Drive, it's not.

    • load another project to isolate against RC working at all, reconstruction worked fine.

    I should note another weirdness, and this one is partly me, but only partly. In light of the fact that the one thing common to the older project that went awry and the new project used to isolate against a potential corruption in the older - are the images relating to region 4. When Götz first pointed me to your post and referring to "offending images", I thought he meant the files themselves might have been corrupted, so I wrote over this set with a "new" set. That brought nothing, but now that was seeing this IFC in a new project with only those images being the common denominator, I wondered about not just the files, but the drive itself. I checked Storage and see the drive these images resided on was red, as in less than a MB "free space". The first thought in my mind was that maybe I should have reframed the problem more broadly all along. Maybe, this had nothing to do with RC. 

    I cleared 20 GB and tried reconstructing region 4 in the old project, another IFC, and you can pick up with the remaining steps in the bullet list. The thing is, I knew this drive was about full, but then I wasn't adding a single file to this drive throughout this epic saga, so why would the drive show up red with less than a MB? 

    I come from Mac OS. I have no visibility into what's thinkable with Windows 10, or if RC is involved. I plan to run a checksum on the folders in this drive and watch it closely, see if it changes at all while working in RC.

    How could images that open fine, align all 501 without a fuss, throw an IFC in a newly installed version and in a new project with cleared cache, while other projects run fine? The only thing in my head presently is the seemingly minor issue/question about resetting RC workflow settings.

    BTW, I perused your site, so very interesting. We may know some of the same people. I'll hit you up offline.

    Best,

    Benjy

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    Hi Benjy,

    happens to me too frequently that only one XMP makes it out - I always thought it's a marking issue within RC. I can't tell you exactly what is probably the right way, but it always worked after re-selecting everything. Might be that if something else in 1Ds is activated/selected before export, RC looses the rest of the shift+ selection and only keeps the last one? If that is so, then it's a question if it counts as bug or just an awquard GUI...

    The grid center could actually be a display issue - the geo coordinates are probably still correct, only RC displays it at the center with each alignment. It might be different with properly georeferenced data.

    I can't really say anything else about your main problem, apart from sorry for the slapdash phrasing of "offending" images. What I meant, as I think you know now, is that they are not suitable as in that they introduce some instability that causes RC to crash.

    What I didn't quite understand from your posts, did you actually run an entirely new alignment in a new project with no old components imported? If yes, this image set also leads to an IFC? That would really point to some images in my view, since everything else should be ruled out by this procedure. And that RC can indeed work with your other images kind of shows that it's more on the input side. The last thing you might want to try is what Kevin did and try to further pinpoint the images that are responsible by painstakingly deactivating small groups up to individuals. I keep all my fingers (and toes as well) crossed that this painful project finally works out in the way you need it!

    If the two of you get up to something exciting behind the scenes, let me know!  :-D

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    Hi Götz,

     

    You're back! 

    "What I didn't quite understand from your posts, did you actually run an entirely new alignment in a new project with no old components imported?"

    You got it, and yes, it points to something in these images, will need to divide and conquer to isolate the culprit(s). If it's not the file itself, seeming they open fine into various programs, and considering RC has no issue detecting usable features in each and every one to deliver alignment of the set without a single manual control point, and then considering this only happened to rear its head in an area of the mine AT the window (without the iterative approach in a new project BTW) that all the images taken on the far side of the window in region 4 align and reconstruct in preview, then this surely is a strange case. What Kevin says about the "initial matching pair" makes me wonder how that figures in. When RC is freed up from running textures on another project, I may try a new project only importing images with no view of the "window", see if reconstruction hits the IFC wall.

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    Hi Benjy,

    was I gone? :-) Or am I missing the irony?  :D

    Well then it really points very strongly to an image or several. What I mean (and I only got that from Kevin's posts in the other thread) is that it is actually the content of the images that cause the trouble, as in introduce some knot in the geometry that causes RC to fail somewhere along the (pipe-) line. So the image itself can be absolutely fine, but only in combination with a few others starts to misbehave. This could also only become apparent in larger sets, so the "offending" images all by themselves might work just fine and only with an overhead of a few hundred of images the algorythms navigate themselves into a feedback loop or something. I am really speculating wildly here.

    Kevin's expertise is on a completely different planet than us "mere" users, so I soon reach the limits when he starts with some in-depth explanation of the interior mechanisms at work...  :-) I guess I keep taking away bits and pieces and it also helps the understand that it's not that simple and also that there are many other possible options that could be incorporated into RC at some point.

    Happy easter bunny hunt!

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    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.  ;-)

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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.

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    Time dilation - excellent. Must admit I haven't thought of that...  :-)

    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...  :-)

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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.

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    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. ;-) 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...

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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. 

     

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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.

    0
    Comment actions Permalink
  • Avatar
    ivan

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

    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.

     

     

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    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...   :-)

    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...

     

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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.

    0
    Comment actions Permalink

Please sign in to leave a comment.