1.5Gb … thats some Brep!
In theory this is irrelevant. The disk write looks like just a binary dump of the data STRUCT from the object in question. In low level languages this is trivial, in very structured languages, there can be problems passing data or pointers to data that big within the framework. .Net and Java are famous for problems like this. I have no idea in what language GH is written, but given the multiplatform goals of Rhino, and the notes I saw once about brittle C++, it is probably very structured.
Its hard to imagine a Brep that size. Is it a complete building all joined together or something? How many surfaces/solids? just curious
To be fair, we have been talking about the Data Input and Data Output components. @Proterio mentioned he has 24 of these components in one project, which amount to about 16MB of data being passed on.
@osuire for what seems to be a reading miscomprehension mentioned he works with 1.5GB files, which is a totally bizarre piece of data for the conversation. Who cares what size your files are and why is it relevant to the discussion ? Clearly @Proterio was talking about the amount of data being passed on, not the size of the Rhino file. Maybe you need to learn to read, man?
Why do you feel the need to add more irrelevancy here ?
It’s not a size issue, of course. I just mentionned the size of my projects because Proterio seemed to claim he was passing lots of data through the INPUT/OUTPUT.
If you can READ, I specified :
I think that if your goal is just a bit more ambitious than playing around, this workflow cannot be trusted, and ends up being a waste of time as it is not robust enough yet.
We found a workaround to the Server file path problem as we store our Data on Google Drive and mapped it to a virtual local drive with the Google Fileshare system.
Regarding the specific B-rep that never managed to pass through in the GHdata file, I’m struggling right now to put my hands on it.
Needless to say that without that single bit of data, the whole process came to a halt, and all the efforts in segmenting the workflow in multiple GH files were rendered useless.
We had to reconfigure our whole approach to the problem, and this was a huge waste of time, plus a big disappointment.
I have the feeling that the discussions in this forum are really loosing their constructive and positive character in almost any thread. Don’t know if this is related to the general Corona depression. Any problem which is related to Software can be solved to a certain extend. Its not about providing perfect solutions but to hint guidance and propose different ways of thinking. This however requires people to stop complaining and investing own brain power to correctly ask for help and finding own solutions.
If Data Input/Output is not going to work for some reason, maybe someone with coding knowledge can propose a different solution. By the way, there are pointers and low-level solutions for C# and the .Net platform in general. I deal with even bigger data on time critical applications so there is definitly a solution to whatever the problem is. Just saying…
Merely stating my painful experience here.
It’s great that you have the time and skills to develop your own data transfer system between GH definitions, as you are keen to point out.
I don’t have these skills yet, and hoped to rely on the INPUT/OUTPUT GH components.
To tell the full story, I first discovered this feature while in advanced GH training with David in Barcelonna.
We used it to carry data along in a chain of definitions which each had it’ own didactif focus.
It gave me the goosebumps as I understood the potential of this to split the workload between multiple developers on a large upcoming project.
Sadly, it just didn’t work.
Unfortunately we are not aloud to map certain folders on the server. We’ll have to implement a work around when we get up to the next stage of the project.
Are you able to try and internalise the brep and save the file. Then when you reopen the file, is that brep still there?
That might check if the brep has issues deserializing or serializing originally.
I’m unable to get my hands on that specific example, unfortunately.
The Brep in question was a GH objects, not a referenced Rhino object if I remember correctly.
At the time, I just baked the said Brep and checked if Rhino considered it as a “Bad” object, which it wasn’t. It was a complete mistery.
I think I sent the whole thing to David, but I can’t find that darn message fo some reason.
Just asking, have you succeeded in isolating the issues, regarding Data I/O, into a minimal definition others can test? I’m a little bit interested here.
Yep, thats what I wanted to propose. Create a new thread with an minimal example and maybe someone has fun solving it for you.
I really don’t like this statement. Almost everybody in the Western World has time. Eventhough working fulltime and caring about a child after work, I frequently find time for some reading and playing around.
Of course you have to invest a lot of time to get better in something. But essentially creating GH definitions and solving coding puzzles is not so different at all. Just that writing code gives you more freedom. In the end you might save time at work if you implement a taylor-made solution.
All my data between serializing and deserializing is generated in grasshopper, hence why I was wondering if there is something about that brep could be blocking the reading writing process when saving.
The data may seem fine going between components like my case, but when it comes to saving, there was issues with the data.
I agree of course. But if a feature exists, I rather use it than re-do it myself, specially if the one who made it is David.
If you have made something that works better than the OUTPUT/INPUT components, you might want to share it here, since this is the “Managing large projects” thread, instead of patronizing.
That was a custom Param so I found the error in code. And fixed it.
The error meant it worked in code when moving between components. But the data could not be saved when opening and closing the file.
Clearly 