Using V8 SR7, I’m still finding that Worksessions are sluggish to the point of being unusable.
I try to use them to get large textured photogrammetry meshes or point clouds in my work model, as a reference, without having to save these very heavy assets every time I save my file.
The first issue is that if you want to de-attach one of these files, you can either call the Worksession manager or right-click on the layer that represents the file, but that puts Rhino in a coma, roughly proportionnal to the size of the file.
I don’t get it. This is like if I had to lift the elevator instead of riding it…
Now it gets more interesting : If I save my 24 MB work file while having a large attached file, it suddenly weighs over 500 MB which (surprise-surprise ! ) is similar to the weight of the attached file.
Then if I close the work file and re-open it, it still weighs 500 MB…until I save it again, and it’s back to 24 MB.
I think of Worksessions as a SolidWorks assembly. You’re just referencing a bunch of file in a “Master” file, and you can make any one of the part files “current”, and that’s great.
But if SolidWorks managed the data in memory and on drives like Rhino, if would not be so successful.
Please run SystemInfo in the Rhino command line and post the result. The above issue resolved in youtrack RH-81197 (private due to user files) in Rhino 8.8.24127.14001
I have this version. Sending you a huge file in private, the size of which is completely bonkers.
It went through some Worksession stuff, after which it got inflated to this byte obesity.
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 64GB)
.NET 7.0.14
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4080 (NVidia) Memory: 16GB, Driver date: 7-10-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 560.70
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port 0
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)
Yeah, that’s due to the lousy texture management in Rhino with the creation of the infamous"…_embedded_files" folders… . As I can see in your capture, the embedded textures display just fine without it.
The point is that this model even with its textures should never be this large.
The original OBJ is ten times smaller !
Amazing. So the textures are not the culprit after all, hey ?
What you could try is creating a worksession with the other OBJ I’m going to send you and see if it bloats the files, just like it did for me, thus proving that the cache problem with worksessions is not solved at all.
