What need I do for that problem?
All limitations regarding definition outputs are described in this article.
I was trying a lot of thing for 2 days… But I cant understand if it is benefit or not that what ıchange on grasshopper file…
I am changing a lot of thing but I cant understand it is ok or not… How can I see the total size of my file=???
You connect shapediver upload limit something like “mesh loading time”…
But we caant see that time anywhere in grtasshoperr data… and cant understand what is our data loading time etc…
that is really absurd…
and the only error message is that : you are up limit of 20 mb etc…
so what is your solution for that please?
I think I wrote a detailed answer to this problem in the past but I can’t find it anymore, so there.
First of all, let me acknowledge your concern with the limitations of ShapeDiver. While calling the process really absurd seems a bit uncalled for, we do agree that a much more detailed feedback is needed, and not only at model upload. In your case, we could detect the size of your outputs directly in Grasshopper and send a warning that our servers will probably deny the algorithm. Such “debugging” features are in our plans and should be added to both the plugin and the platform later this year.
More specifically about your problem: the size of your definition is very different from the size of the geometry that is created in your definition. Consider the definition below:
It’s as tiny definition but it creates a mesh with 1 million vertices. Therefore the .gh file weight 10kb but the output size represents several mb, at least in our viewer (it could be optimized with some compression algorithms).
Please check the total size of meshes that are displayed in your definition (usually through ShapeDiverDisplayGeometry components) and check if you can’t reduce some of them, or even prevent them from the beginning. If you need to keep detailed geometry for exporting purposes, you can always do that but simplify what is displayed in the viewer. In most cases, our users realize they don’t need the level of detail that is used for detailed production drawings for example.
Read more about this in several locations:
- regarding the difference between definition size and output size: https://support.shapediver.com/hc/en-us/articles/360020300692-Model-checking
- regarding the topic of meshing for performance optimization:
I already read those documants. I convert nearyl all of my datas to the mesh files. None of my files are more than %2. Nearly all of them are even not 1 ms. %99 of my data are 0 ms… but what ever I try I couldnt upload my files. At last I delete %90 of my file to try if will accept. Even that it dinied. At last I get crazy… pls help me how will I control my mesh size???
Pls tell me how will I do that?
Again. I understand mesh size and file size are different I just wonder how can I see,how much is the mesh size?
When you hover your mouse over the inputs to the display components (after flattening them unless you have a good reason not to), you will see the list of objects that need to be displayed in the ShapeDiver viewer:
In your model, the meshes that are sent to the viewer represent more than a million vertices. In addition to that, there are hundreds of Surfaces and Breps also sent to the viewer without mesh representation, which need to be converted by our servers and probably represent a lot of vertices as well.
There are several factors influencing how much data is needed to represent a mesh, depending on the inclusion of normals, vertex colors, if the mesh has triangular or quad faces, etc… However, to give you an idea, a typical mesh with normals on ShapeDiver will weigh around 1mb / 100k vertices. Given that estimation, I have no trouble believing that your definition’s outputs overreach your 20 mb limit.
As I mentioned above, you need to reduce the size of the output geometry. Please keep in mind that you don’t need much detail for online visualization. For example, there are a dozen such pieces in your outputs:
That mesh has 40k vertices, but in the viewer it is a tiny, barely visible part of the structure. It can easily be replaced by a much simpler version. I don’t even think this piece is parametric, which means you can reduce the mesh in Rhino once and for all and internalize the low poly version in your definition.
This is just an example among many. I guarantee that you can easily work around the limitations of the viewer with the model you are working on.
Yes You are right… I understand you now a bit better… But for solution:
1- converting meshes to breps?
2- converting meshes to simpler meshes?
which is better?
As a general rule, you should not send Breps to the viewer, because you will lose control over performance and visualization accuracy. This is mentioned multiple times in the documentation.
The one simple rule is to send meshes that are as small as possible while keeping the details you need for visualization purposes. Of course, when possible, it is better to work with small meshes from the start (either internalized or parametrically defined) rather than having to reduce meshes at the end of the definition, since this will hurt the performance (your gain in size will be transferred to long computation times).
That is a good start, yes.
Yes Thanks. that worked for me… My file was also 7mb before reducing meshes after reduceing meshes , also file size become 2.5 MB…
We have covered some optimization tricks and tips to avoid hitting the maximum output size in this video tutorial: https://youtu.be/K45_Z_gB6YU