Hi @mathieu1 ! (Ref: 44ac7c8e-9a0c-4b04-ac9f-3467991163a4).
It takes about 40 seconds to open the file in grasshopper.
This file is 16mb because of the internalized curves in it. I tested a 10mb file and the same error also occurred. I tried to change parameters but it didn’t work. Only when the file is about 5mb I can load it into the shapediver.
I tried another way by hosting the dxf files on the web, but the ShapeDiverImputGeometry component has some limitations that affect the quality of the curves or the computational time. I tried dxf files with different configurations, converting the polylines into arcs that will be joined by closing curves, but all this interferes a lot in the computational time.
I am afraid that there is no way around the time it takes to open the Grasshopper definition. We are working on treating the opening time separately from the computation time and therefore provide more flexible options for our users.
In the meantime, your workaround to use file inputs instead of internalizing geometry is a good one. We are aware of the limitations inherent to the dxf import and the new plugin will address this by allowing to define import options.
We’ve already made improvements that reduced the definition size to 6500kb and the upload worked several times, but the error still popped up once more.
We are uploading the file as if we were playing the lottery, sometimes we can, but there is a moment that it doesn’t work anymore.
Let me explain the improvements. 1 - All patterns have been redesigned to make them lighter, with just arcs and straights geometries. 2 - Some patterns with a larger number of curves are internalized in the model and a simple pattern that is default to facilitate the first visualization. 3- Other patterns are imported through the geometry import component that reads the url of a dxf file, when the pattern is selected. All patterns cannot be read at the same time. 4 - Other patterns were parameterized, without the need to internalize curves or import dxf files from the web.
We loaded this file with the patterns internalized in the definition, the parameterized ones and most of the patterns imported by urls and it worked.
But as we update the code we run into the same error. This was the last error reference.
(Ref: 636eec94-40bd-44a9-bca0-b2a7f36189d9)
I created a text entry that controls a gate of the parameters during upload, and after the upload I would activate this gate flow manually, but the same error still happened.
Do you have any idea how you could prepare the definition so that the shapediver could check the limits in two moments, first the definition size and then the computational time?
We have already made many improvements to this code and it is within the limits defined by the shapediver, but there is still an error in the upload.
I tested the loading time of your model locally. It typically takes 10-15 seconds to load after a restart of Rhino and Grasshopper. I assume this is comparable on your own workstation, please let me know.
Currently we do not specifically check the model load time during the model checking process, but such a check will be added to the model checking process in order to provide meaningful feedback. Our policy will be to allow the model load time to be up to the maximum computation time allowed, which is 10 seconds for your account. This means your model is scratching the limits of your account. Have you considered upgrading your account to higher computation time?
The point is that older and more complex code versions were loaded normally. This problem is only now appearing after months of development and even with improvements we’ve made to the code.
See this example
It’s a code inserted in early August. It was much larger and complex, without the enhancements of this latest version, and yet it carried without this requirement.
We decreased definition size, decreased computational time, improved dxf source files, parameterized some patterns, and didn’t add any functionality. But this file and all the previous ones that were already uploaded months ago don’t upload anymore.
It is as if the import rules were restricted as much as possible at the end of product development.
Have there been any changes to the upload code?
What are the other possible reasons why files already loaded just don’t load anymore?
For the client it is very difficult to understand that before the code was worse but it worked and now it is better but it doesn’t work.
many thanks for your feedback. I understand your frustration.
We didn’t change any of the logic related to model checking. If the model requires significantly more time to load (to open in Grasshopper) than the maximum computation time allowed for the model (which is defined by the account of the user who uploads the model), then it will get denied.
Regarding your question why previous uploads succeeded: Could it be that the account used to upload these models was on a trial for 30 second computation time, at the time the models where uploaded?
If you restart Rhino and Grasshopper, how long does it take for you to open the model?
Hello,
I’m on another stage right now - finishing the project. Have bought “Design Account”, but still having similar problems.
My question is: how can I know what part of the definision/model couses problems - which aspect of model (lines meshes textures etc.) is responsable for to long computation time.
Already I’ve done this:
Using Bottleneck Navigator - in grasshopper everything calculates under 300ms.
Optimising meshes and lines to minimum imo.
Using Shapedivers transform tool for all identical objects
Choosing the smallest textures acceptable for me - 128x128 and 64x64
My general problem is that error messages occure randomly to my mind. Examples:
a) model refreshes after 2s, but ther is error message
b) the most complex configuration calculates with no problem, the smallest crashes
back to question: How can I get any info of what causes computation problems?
Here is link to the model: https://app.shapediver.com/m/tak-shelter-1-22
I would be very grateful for technical advices.Thanks!
It seems you are following all good practices to optimize the model. It is likely that the issue is about how much time it takes to open the definition in Grasshopper. Could you tell me how long it takes when you open Grasshopper and load the definition for the first time?
Hello, thank you for responce,
When I open definition, and it computes for the first time it takes about 10s, later it takes fraction of a second. I’m pretty shure this is because of compilation of c# scripts. Once they are compiled c# modules compute in few miliseconds. Can we do sth about it? For example maybe I can create a plugin for grasshopper instead of having codes in the grasshopper definition?
Yes, if you have a compiled plugin that would remove the step where scripts are compiled when opening your definition. However, unless you make this plugin available and useful for the community, you will need an Enterprise account to deploy your own plugins. Alternatively, consider upgrading to longer computation times.
Very Interesting - thak you! - I need to think about it.
Does it mean that GH definition is opened and closed on your servers everytime an updete is requested from API?
Does it mean that making simple operations with built in GH modules is more optimal than custom c# ones?
No, our dispatching algorithm makes sure that computation requests typically get processed by a “worker” which already has the model loaded.
It depends, the rule of thumb to keep in mind is that both the model load time as well as the computation time (once the model is loaded) should stay below your computation time limit.
Soon our new platform will expose these numbers per model, i.e. you will be able to take more informed decisions on how to optimize.
The error of this file was corrected on the old platform. I tried to upload the new platform and did not upload, show an error message without identification of which error was. The old platform was still available and tried upload and ran normally. But now only with the new platform an error appears and does not upload.
Could you check if the fixes you did on the old platform are working on this new?
Did I understand correctly that you can not upload models using the new platform? If so, could you please post screenshots and the error message(s) you are receiving (if any)?
I did a test and tried upload the same file in the old and on the new platform.
In the old platform upload works, in the new plataform does not work.
This was the last file that I was able to upload, still using the active link of the old platform (https://app.shapediver.com/), after upload made on the old platform I edited on the new platform (https://www.shapediver.com/app).
Hi @pvilarim, many thanks for reporting this. The error that you are getting is most probably not related to model checking, but to some bug that must have gone undetected so far on the new platform (it is strange, because we log all errors, and I can’t find it in the logs). Please let me know this:
Which user account did you use on the new platform?
Does the error happen for every model upload on the new platform?
Does the error show immediately, or after some time? (maybe you can record a video)
The error appears in a file, the same file that the error happened on the old platform.
The error occurs after some time.
I recorded a video by loading the same file on the new and old platform. See the link.
I created an input that disables some sliders to help load the file. UPLOAD_CONTROL
At the time of the problem we decrease the size of the 20MB definition for 6MB by loading DXF files through FTP. Adefinition was optimized using C # components that you provide and sequinous recommendations from this post.
This was the file I show in the video I was able to upload on the old platform.
