I’m getting error messages in the latest 8.2 build using the Content Cache component on what I would consider a pretty straight foreword “cache operation”.
Error Message 01: 1. Output parameter Index [0] too high for Component Content Cache.
Another End Of The Error Message, Error Message 02, 1. Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
Everything is fine running the script for the first time:
It’s worth noting that the cache completes properly and the geometry shows up as expected, it just takes a VERY long time as a result of the expiration of unrelated Query components.
@kike , Still seeing this on my end after yesterday’s update, I was able to isolate the problem to a specific data tree of Model Block Instances but when I open the blocks, nothing is different between them and other blocks that work just fine.
The majority of the blocks bake without issue where as others throw the indexing error.
The only thing I can think of that I haven’t tested is that these blocks may have been saved/updated in between updates and perhaps “something” got corrupted in the block saving. I’ll try saving the problemed blocks as both the latest R8 release and as R7 to see if it has any effect.
If that doesn’t work I have an isolated grasshopper script and Rhino model I would like to share with you.
And you can see it did spawn the blocks in Rhino after (B) despite the null output of the cache component:
Thanks for your help!
Rhino Version:
Rhino 8 SR2 2023-12-5 (Rhino 8, 8.2.23339.13001
So the to repeat, I just have to jiggle any of the referenced model points in Rhino to re-run the script or just recompute the script and it will succeed when the script initially runs on open, then it will fail when the script runs again, and then it will succeed again, and this repeats (fail, success, fail, success, etc.) every time the script is run respectively.
You can see the rest of the data tree is caching perfectly fine in the upper left of the snips, there’s not real difference between the blocks except an extra line here or there, a different hatch shape, etc. but the properties, layer structure, annotation style, etc. is all consistent
Yes I will share just the plumbing and electrical portion as it’s repeatable with the toilet symbol block as well.
I used an explode component on the block and it caches okay when exploded, oddly this same workaround did not work for the electrical symbols. I’m stumped and appreciate your insights.
@kike I just sent you the Rhino model and isolated portion of the grasshopper script that reproduces the issue, you may need the block files if they aren’t already in the Rhino document, if that’s the case let me know and I’ll send those as well, thank you!
It’s worth noting the script excerpt if from a larger 8000+ component definition heavily utilizing Model Objects, Referencing, and Content Caching without issue so the portion I shared is the only area of the script having issues.
Thanks for your files! It allowed me to reproduce the problem.
The problem is specific to linked blocks.
I also updated the ‘Import Model Block Definition’ component, now is no more necessary to Import the geometry in Grasshopper if you are using a Linked block. The geometry will be loaded by Rhino when is pushed to the model.
It still works if you need a preview of the block before pushing it to the model as before.
Thank you @kike you’re the best and retaining preview while being able to pass the linked block directly through Rhino sounds great. I look forward to trying it out, thanks again!
Hi, Am I missing something? I can’t update linked blocks. I tried to push Model Block Instance and Model Block definition but none of them works as expected.
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 64GB)
.NET 7.0.11
Computer platform: LAPTOP - Plugged in [95% battery remaining]
Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA RTX A3000 12GB Laptop GPU (NVidia) Memory: 11GB, Driver date: 2-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.61
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA RTX A3000 12GB Laptop GPU (NVidia) Memory: 11GB, Driver date: 2-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.61
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Secondary graphics devices.
Intel(R) UHD Graphics (Intel) Memory: 1GB, Driver date: 6-15-2023 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 2-15-2024
Driver Version: 31.0.15.5161
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 11520 MB
Rhino plugins that do not ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\RhinoToGrasshopper\RhinoToGrasshopper.rhp “RhinoToGrasshopper” 1.0.0.0
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\VisualARQ.rhp “VisualARQ”
C:\Users\Czaja\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\Bella (813de3fb-18eb-405f-bfcd-b0b4d3da91fb)\24.2.0.0\bella_rhino.rhp “Bella” 24.2.0.0
C:\Program Files\Rhino 8\Plug-ins\Tibidabo\Tibidabo.rhp “Tibidabo”
C:\Users\Czaja\AppData\Roaming\McNeel\Rhinoceros\BlockEditNew\BlockEditNew.rhp “BlockEdit” 1.0.0.0
?
