Blank after loading

[KurtH]

I've had some projects work in Kintsugi so far but just try to make one and after loading the camera, model, and images, the progress bar at the top runs for a long time, then runs a faster process, then the image goes blank. No model, no grid loaded. Besides the menu at the top the screen is entirely black.

Builder version: 0.3.21, Windows 10 Ryzen Thread Ripper 32 Core processor, 2x 4090 GPU, 512GB RAM.

I cleared the cache and went into settings to allow up to 128,000MB at which point it asked to allow PowerShell to make changes to the device and then asked to restart Kintsugi. But after restart the value to 4096MB, though "Limit Memory Usage" is NOT checked so don't know if the memory setting is used if it's not limited.

Have 1059 50MP images (trimmed down) from two different (but same model) cameras: Canon 5Ds: one with a 24mm lens, one with a 50mm. I ran once with a 160k model decimated from a structured light scan (but aligned to photogrammetry) and had the issue. Then I made a new project loading a 200k model decimated from the photogrammetry model (incase there were issues with the structured light model). Both have the same issue. 

I don't know if there is something basic I'm doing wrong.

[Michael Tetzlaff]

Thanks, Kurt.  We'll note that there are at least some UX issues, if not a bug with the "limit memory usage" feature.  I haven't looked at that one in a while.

Occasionally I've noticed that it will produce a blank screen after loading -- in most cases it's fixed by closing and then re-opening the project (which was saved before loading started, and the re-opening should go faster as it can still re-use the cache generated the first time).  The bug hasn't been occurring consistently from what I can tell so it's been difficult to reproduce and fix, and doesn't seem to be common or workflow breaking when it does happen if you just try re-opening it.

I do also know that there can be a hard limit of 1024 images on many graphics cards -- so that may also be what you're running into.  I'd try trimming down the images just a little more to get it under 1024 and see if that works.  And also try re-opening it once as noted above.

After trying all of those things, if it still doesn't work, feel free to send me a link to the dataset in an email and I can see if there's a more specific bug.

[KurtH]

I tried reopening a couple times and the problem kept repeating. I'll try trimming the number of images. Does the builder only load images that are listed in the Camera Locations XML? In other words: If I just remove the images from the chunk that I export the camera locations from but still point it to the same JPG directory with 1600 images, will it be fine or is it going to try to load every image in the JPG folder (In which case I should clear out the trimmed images from there too)?

[KurtH]

Went ahead and tested it... Just removed the images from the chunk got it down to around 860 images and exported a new Camera Locations file and works fine (didn't need to remove the JPGs from the folder) and now after loading the object shows up.

If it's graphics related, for your notes: we are running dual RTX-4090's with 24GB each. And it turns out I got it to load this after cutting down the images while my intern had a rather large alignment running in meta shape at the same time (which should be leveraging the GPUs), though it's probably something dumber like Nvidia wanting you to go to an A series card.

[Michael Tetzlaff]

As you probably figured out, it respects images that are disabled in the chunk when you export the camera locations XML (you don't even need to delete, just disable them).

The problem is not so much hardware related as it is a hard-coded OpenGL constraint on most drivers -- so you'd probably have the same limit regardless of graphics card or whatever else is running at the same time.  OpenGL has proven to be a convenient development environment for me that works really well in most respects, but it wasn't originally designed for what we're doing so much as for real-time games and simpler 3D graphics, and it's an old API at this point -- so there are a few arbitrary limits like this one that may be 10 years old at this point.  (The newer graphics API, Vulkan, presumably wouldn't have this limit if used properly -- but porting to Vulkan would be a significant undertaking).

There are workarounds that wouldn't require a full port to Vulkan if more than 1024 images are needed on a regular basis -- Charles typically has around 500 images if he does two hemispheres (right side up and upside down) on his turntable, and even if we have some extra passes for an unusual feature on the object, it's usually still under 1000, so I haven't worried about it.

If there's common use cases where more than 1024 images would be desirable, I can put that on the roadmap -- let me know if this would be a common situation for you or if it's more of an edge case.