Texture crisis -- a plea for workarounds

Hmm, I didn’t undestand half of what you said again, which is no surprise…  lol

I fear there aren’t too many people out there (or rather in here) who understand the intricacies of the theory behind all this as thoroughly as you! I hope to be proven wrong!

It is a real problem though and in my opinion it could and should be possible to implement some kind of probability filter to identify the obvious errors, like I suggested for the distortion model once. https://support.capturingreality.com/hc/en-us/community/posts/115001352772-identify-obvious-distortion-errors

Since I am not sure how closely RC team members follow extended threads like this, I would suggest to create a new bug report or feature request.

I’ve seen this I think.

I would get lot more crashes as i added control points. it only affected some projects.

it was probably fighting with the tie points.

i think adding minimum number of control points needed helps. in case you add errors with each one you place.

Hello Kevin (and others),

I’ve been experiencing similar behavior under somewhat different conditions, believe these problems and ground causes are related, so let’s compare notes and explore workarounds. I get the same sanity check red flag when, instead of running textures, I’m running reconstruction at normal. The one difference is, in console I’m seeing the same invalid function call with identical “0x2012\0x2010\0x2000\0x4999\0x5051” as reported in this post, which also features my response.

Kevin writes,“Tie points are the crucial numbers to watch for this in the case of this crash – an image with_ less than 10 tie points_ is able to reliably cause crashes in my experience.”

In my experience, I get consistent crashing with images having plenty of tie points, but I believe too few where I need them, these regions being in the distance, which only exacerbates re projection errors. I was aware during capture that the subject matter, a transition between a large space in a mining tunnel through a small window high up on a wall leading into an upper chamber (a ventilation branch), would call for great care in how I stack the ordered pairs of images leading into this high up window. Without a jet pack, I was further constrained by precarious stances on ladders set on lose cobble, cantilevering the camera out as far as I could reach at times, really sketchy work conditions. I might have used my extension pole, but believe that wouldn’t have delivered much different perspectives. Another factor, dust and fog really high that day, producing back scatter and polluting the subject matter into the distance. Here’s 2D in 6-panel view showing some of these images with tied points enabled:

You see what I mean with a dearth of tie points in the distance. So, might it be more than simply not having enough tie points in the image, but not enough where they’re needed? I’ve wondered why when users have written in questions about capturing objects, that dominate the center of the frame and asking about how the background figures in, whether it can be masked, whether it’s preferable to let distant background subject matter go into soft focus or dark, why Wishgranter suggested RC supported such notions, that RC doesn’t benefit from that information, that it might even mess with properly modeling the object. I can see how these two scenarios aren’t in conflict. If RC keeps its eye on the object, no problem whatever the background wants to do, but if you’re capturing the environment, now corner to corner in every frame, that data now has to properly triangulate, very different situation. 

To Kevin’s thought that the problem is born when insufficient tie points create a situation locally, that may pass the test through alignment, and in his case through reconstruction, but not through unwrap/texture, that this localized solution hits a wall when tied into loops at the macro scale, I find that idea most intuitive. Now what? Should the bar be raised on what allows a component to stay together at alignment? BTW, I also run iterative alignment, ratcheting down on max reprojection error, RC gets me to below .5 with a mean around .3. I can live with some minor flaws around a transition, much support keeping the component whole, but then there needs to be some work around.

My proposed solution is to provide for allowing the user to export either an .rcalign file or a smaller chunk mesh that preserves scale and coordinate system, allowing user to process this smaller section successfully by not requiring it to solve against the global model, to then match it up as close as common scale/coordinate system will satisfy. I can deal with the minor flaws at the seam between the globally modeled set and this smaller problem child mesh. I’m wondering if RC already supports this, haven’t worked with ground control points in my work. Can I set a ground control point in the larger set and export that with the smaller reconstruction region used to define reconstruction of the problem child mesh section, and will that provide this common scale and coordinate system? Thanks for other ideas.

Hi Benjy,

I think the XMP workflow would be ideal for this. That’s the one I didn’t remember last time we chatted. What it does is very similar to working with a RAW file and the corresponding file with the alterations in it. If you press that with all the cameras selected that you are interested in, it creates XMP files with all geometric data of the cameras in it. If this XMP is present and has the identical name as the image, then RC takes those infos instead of calculating new one. You might have to tick a box somewhere to tell RC that the position should be fixed.

Nice, didn’t realize RC supported exporting scale/coordinate system over XMP metadata. I’ll have to hunt for where to “press”. I may have found another work around in the meanwhile. Once this clicked about the problem resting in this dramatic transition, with no great way to counteract that with stronger capture, I thought to disable all photos across this divide, RC had no problem reconstructing mesh D, let’s call it, since A-C were in place. In the same component I can then reconstruct everything falling on the other side of the divide with a neighboring reconstruction region, now disabling all the photos falling on the A-D side of the window and enabling the previously disabled images. I might need to do a little trimming, and the seam may not be perfect, but I’m confident this approach is optimal, and surely delivers an identical end result as what I’d expect comes from the XMP workflow, yes?

Hi Benjy,

awesome that you solved it! Very important insight.

That really reeks of bug to me though. The software should be able to deal with such situations…

And yes, I think it would be the same result. The button is “hidden” in Alignment - Export. I’d written it already but then deleted it again for apparently no reason…  :wink:

Thanks, really curious how close this gets in the seam. I’ll post some snips from UE4 to show results. 

About it being a bug, yes and no. If humans doing the best we can to mitigate the challenge posed by the data deliver acceptable results, then yes, RC should also be able to support a solution to the bug. But, given the issue with either too few tie points in the image or not where you need them to connect two very different/adjoining chambers, it’s also fair to say any SFM solution has its limits. I do believe the human solution here may point to a strategy for CR coders. Since RC was able to deal with the challenging data to deliver a mesh in Preview, it should be able to isolate, as I did, which images fall to either side of the divide where the math becomes too challenging, solve separately for each before then producing the combined result. That is, if I’m able to reconstruct each separately while maintaining the same scale and coordinate system from a common component, then bringing these together later, why can’t RC do something similar. If it can present other anomalies, like a step in a plane where groups of related cameras aren’t tied in with other groups, that’s in essence the same behavior I’m suggesting inviting here, bring the two sides of this divide together the best you can, let us deal with cleaning badness in the less than perfect seam.

Well, in my opinion every unexplainable crash (and I mean NOT having to experiment like you guys did for ever) is a bug. Also, it gets much more atention in the specific bug area of the forum. It is no bug anymore if RC stops the process and tells the user why it did so and, ideally, what the user should do.  :slight_smile:

As usual, your logic is ahead. Thanks, RC if you’re reading, for addressing this bug.

Says the one who has worked out the clues…  :wink:

Thanks Benjamin for letting some light into the topic, Chris for saying you’re seeing related errors in your world, and as always to Götz for stepping in faster than those of us in the New World can!  :wink:

To quote Benjamin:

In my experience, I get consistent crashing with images having plenty of tie points, but I believe too few where I need them, these regions being in the distance, which only exacerbates re projection errors

You’re certainly right – the tunnel you describe makes it hard (or, maybe, impossible) to get fully supported access in an unbroken chain extending to the furthest reaches.  Based on my recent jaunts with RC, however, I’d be willing to bet that the problem is not the number of tie points.  In my case, I was able to turn off the objects with poor point counts, and the crashing stopped.  But in your case, where you have plenty of points but also registration instability, I’d be willing to bet that the problem is how RC picks the initial views during alignment.

In other words, yours is a classic failure case for sequential SfM – not starting the reconstruction with the best initial view, when the order of views matters.  That causes the alignment to fall into local minima before it can converge on the actual best RMSE for the given views.  Tie points establish the network of neighbors, but initial view selection is often independent.

The good news is that a global SfM approach doesn’t have these initialization problems.  Can you test your data set with a (free) system like Simon Fuhrmann’s excellent MVE?  (https://www.gcc.tu-darmstadt.de/home/proj/mve/).  Simon’s work is very good and he has a nice Windows front end to make things easy, although there are many equally capable systems (Theia, OpenMVG, and others) you could also use.

Perhaps the best ‘production ready’ global SfM system is Pierre Moulon’s wonderful OpenMVG:

https://github.com/openMVG/openMVG 

If you use one of these, just make sure you use the global alignment option, not incremental.

All of these have the advantage that they’re free, and they’re open source so you can see what they do and extend them.  They have the disadvantage of not being as well optimized for the GPU as RC, so if you’re running on a single PC it will take a lot longer.  However, the final mesh results from my tests demonstrate that while the open solutions are slow compared to RC, they can generate better surfaces than RC:  both cleaner and more accurate to ground truth.  That may be important, or even decisive for you as it seems you’re working for a scientific result.

As Götz and I have discussed in other threads, Global SfM methods solve for all positions at once, so they are much less brittle in cases like yours.  It appears that RC uses a sequential solver, but I’ve asked for clarification on this and never got a response.  Since RC isn’t open source, we can’t check for ourselves.  :wink:

While the backscatter isn’t helping the focus, any of those points that get recognized during feature search will be discarded in the next image as the dust moves, so they’ll fail the homography test.  If the dust is enough to cause blur, that’s a different story – blur is destructive to reconstructions in exactly the slippery way you describe your current trouble.

 

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. 

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

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 

 

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.

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.

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/

 

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

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!  :smiley:

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.

Hi Benjy,

was I gone? :slight_smile: Or am I missing the irony?  :smiley:

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…  :slight_smile: 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!