why read .stl file so slow ?

[wh0xjjx]

when i test your project on windows10 , it complied done. but when it read stl, it is very slow, the file size is 6142KB, i need three hours to show it out, so does this program support large stl file (over 10000 triangles ), is there a better way to do this ? thank you

[wh0xjjx]

[wh0xjjx]

[wh0xjjx]

why does the gear.stl file show such fragments of triangles?

[KASUYASU]

Hi,

but when it read stl, it is very slow,
why does the gear.stl file show such fragments of triangles?

Because the algorithm to read a stl file has defects. Would you please try the cutsim-q5 version?

https://github.com/KASUYASU/cutsim-q5

It has a little better algorithm with faster and less fragmentation properties.

[wh0xjjx]

thanks a lot，i have used cutsim-q5 ，but it run error，here is my code to show stl file:

• cs = new cutsim::Cutsim(octree_cube_size, max_depth,octree_center, gld, w);
• StockVolume *stockVolume = new StockVolume();
• cutsim::StlVolume* stock2 = new cutsim::StlVolume();
• stock2->setCenter(cutsim::GLVertex(0, 0, 0));
• stock2->setRotationCenter(cutsim::GLVertex(0, 0, 0));
• stock2->setAngle(cutsim::GLVertex(0,0,0));
• stock2->setCubeResolution(cube_resolution);
• stock2->readStlFile("Antena.stl");
• stock2->calcBB();
• stock2->setColor(0, 1, 1);
• cs->sum_volume(stock2); //here make errors
• cs->updateGL();

error is in octree.cpp

please help me to figure it out , i am very appreciated!

[wh0xjjx]

And i have two tips for you in the file volume.cpp

line 560
for (int ic=0, i=neighborhoodIndex[src_index][index_x/ratio][index_y/ratio][index_z/ratio][0]; ic < index_size; ic++, i=neighborhoodIndex[src_index][index_x/ratio][index_y/ratio][index_z/ratio][ic]) {

after revised
for (int ic = 0; ic < index_size; ic++) {
int i = neighborhoodIndex[src_index][index_x / ratio][index_y / ratio][index_z / ratio][ic];
for that it may exceed the range of array in the last index. Similarly, in line 578,

	for (int ic=0, i=candidate[0].index; ic < (int)candidate.size(); ic++, i=candidate[ic].index) {

to
for (int ic = 0/, i = candidate[0].index/; ic < (int)candidate.size(); ic++/, i = candidate[ic].index/) {
int i = candidate[ic].index;

[KASUYASU]

Hi,

Do you have any problems without the definition of "MULTI_THREAD_SUM" ?
Please try to comment out it

// Multi Threadings
//#define MULTI_THREAD_SUM
#define MULTI_THREAD_INTERSECT
//#define MULTI_THREAD_DIFF
#define MULTI_THREAD_STL_NEIGHBOR

in the file "cutsim_def.hpp".

And thank you for your revise about the 'overrun' problems.

[wh0xjjx]

Thanks for your advise!
After i revised the volume.cpp
in line 690

for (int ic=0, i=neighborhoodIndex[dst_index][index_x][index_y][index_z][0]; ic < index_size; ic++, i=neighborhoodIndex[dst_index][index_x][index_y][index_z][ic]) {

to like this:

_for (int ic = 0; ic < index_size; ic++ ) {
	int i = neighborhoodIndex[dst_index][index_x][index_y][index_z][ic];_

it runs correct with the Gear.stl file (529KB)

but i use my .stl file (1040KB), it is not correct fully .

what do the white and red triangles represent ? actully, they are not contained in the .stl file triangles.
while runing in the console window, it does have bugs

This is my stl file , would you like to have a test on it , thank you very much!
stl_file.zip

[KASUYASU]

Sorry! I've laid this aside for a long time, because now I'm developing a new CNC simulator which has a new algorithm without Marching Cube method. So please give me a little time to recover the memory of my head. The console messages indicate the correction of calculations and not indicate errors. The algorithm must calculate the distance between the facets and the cube and determine whether the part of facet exists inside the cube or not, so please also note that the algorithm is influenced by the precision of calculation and not robust inherently.

[wh0xjjx]

It’s very kind of you to help me give suggestions. I learn a lot for your codes, i will take more time to do the research on the algorithms in your codes. I am also very expected to hear that you can make greater progress on it.

[KASUYASU]

Forgive me my late response, because I was hospitalized for pneumonia. I think there are two reason why your stl file will be so fragmented. One is the weakness of my algorithm against the sharp edge of 3D stl data. And another is your stl file contains incorrect data, like unclosed facets, overlapped facets, and upside down normal vector.
Please try the attached file. It makes less fragmentation, except the result of defect on my algorithm.

P. S. If you have some g-code file for this stl data, would you please give me it? My new CNC simulator is now ready for test.
stl_file.zip

[wh0xjjx]

Sorry for my late response. Are you feeling better？Please take good care of your body.

I use your code to simulate the motion of a industrial robot with electrical drill to cut the knee bone, it is a part of surgical robot system for knee replacement, so i don't have the G code file , the data i can get are end positons of the robot hand. The STL file is the model of knee implant to be cutted.
indeedly, there are many sharp edges in the process of STL model generation, hence using below codes may sometimes cause failure

cs = new cutsim::Cutsim(octree_cube_size, max_depth,octree_center, gld, w); StockVolume *stockVolume = new StockVolume(); cutsim::StlVolume* stock2 = new cutsim::StlVolume(); stock2->setCenter(cutsim::GLVertex(0, 0, 0)); stock2->setRotationCenter(cutsim::GLVertex(0, 0, 0)); stock2->setAngle(cutsim::GLVertex(0,0,0)); stock2->setCubeResolution(cube_resolution); stock2->readStlFile("Milling_area3.stl"); stock2->calcBB(); stock2->setColor(0, 1, 1); cs->sum_volume(stock2); //here make errors cs->updateGL();_

so i am expected to learn about your new algorithm to build the octree, or other new ways with different algorithms to show the realtime simulation of robot motion, such as your new CNC simulator , thank you for the support.

[KASUYASU]

Hi,

Are you feeling better？.

Thank you. I'm now (almost) fine.

hence using below codes may sometimes cause failure

Almost all defects exist in the function 'double StlVolume::dist(const GLVertex& p)'.
This function calculates the distance from cube's vertexes to the facets and determines whether the vertex exists inside the stl polygons or not. I've uploaded a revised algorithm to the Git, so please try it with next new attached file.
new_stl_file.zip

[wh0xjjx]

OK，i have tested your new version code, while, most of the time it caculates correctly，you can try it with as more as STL files.
It is very difficult to complete such a tough task , but you did, thanks for your great achievement .

[KASUYASU]

Hi,

It is very difficult to complete such a tough task , but you did, thanks for your great achievement .

Please be careful, because my algorithm is not so complete. It produces small white and red pieces with inaccurate calculation, but you can filter those out by using a function 'heck_node' as follows.

tree->sum( volume );
tree->check_node( volume );

. This 'cutsim' uses the technique of 'Maching Cube', so its defects influence the precision of simulation result. Next two jpeg files show the differences of marching cube method and my new algorithm when the same stl and g-code file are used. The cutsim-q5 application can't reproduce the thin wall of 'stl' file and makes inaccurate result, but my new method produces more accurate one and also detects the fast cutting problem exactly.
So I want to stop improving cutsim's algorithm and concentrate upon new one :-).

[wh0xjjx]

In cutsim-q5,
Is it right to change the color of red and white pieces as same as body part ?
or
just delete the "check_node" function ?

Actually, i have spent 2~3 weeks to read your code in June, and i can understand most of the code. it is really complex. even though , i don't have the ability to modify it.

The following png file is my milling simulaiton of knee replacement based on your code. The green part is the area to be removed, but the software seemes not robustly, however, i can't find the reason. The efficiency and acurracy of the simulation are also important and need improving. so i am expected to learn about your new algorithm showed in New-CNC_Sim picture. Would you like to give me a demo if you finish the new algorithm ?
My email: wh0xjjx@gmail.com

[KASUYASU]

Hi,

Is it right to change the color of red and white pieces as same as body part ?
or
just delete the "check_node" function ?

The red or white color pieces indicate that the function 'check_node' has detected those as irregular cubes. Then 'check_node' will force to change the state of cubes from the situation of those surroundings.

if (state == Octnode::OUTSIDE) {
std::cout << "Force Outside x:" << current->child[m]->center->x << " y:" << current->child[m]->center->y << " z:" << current->child[m]->center->z << "\n";
current->child[m]->color.set(1, 1, 1);
current->child[m]->state = Octnode::OUTSIDE;
}

So after everything is well-done, red or white small pieces will disappear.

Would you like to give me a demo if you finish the new algorithm ?

Maybe I think you are going to use those for Head/Head type multi-axis machines.

https://www.waykenrm.com/5-axis-cnc-machining.html

Now, my new algorithm only supports Table/Table type 5-axis machine and you must modify it. But also I think it's more time saving to modify by me than you do.

so i don't have the G code file , the data i can get are end positons of the robot hand.

Anyway, to test my algorithm, I need the data of robot motion, stl file of thighbone and the size of endmill tool. The module which read the G-code file is separated from the core algorithm, so I can make the motion translator easily if your robot's data is readable, understandable,... etc.

[wh0xjjx]

Hi
The data for your test is upload. For easy simulation, i set the robot orientation fixed and the position varied. It is no need to calculate interpolation because the point is set to be the center of the milltool directly. And the milltool is set

` cutsim::BallCutterVolume* s0 = new cutsim::BallCutterVolume();
s0->setRadius(2.5);
s0->setShankRadius(2.0);
s0->setColor(1.0f,0.843f,0.0f);
s0->setLength(30.0);
s0->setFluteLength(2.5);
s0->setCenter(cutsim::GLVertex(0,0,0));
s0->enableHolder(false);
s0->cuttertype = cutsim::BALL;

w = new cutsim::GLWidget(DEFAULT_SCENE_RADIUS);
w->setTool(s0);
w->setToolPosition(ptool[0], ptool[1], ptool[2], ptool[3], ptool[4], ptool[5]);
w->update();`

Please take some time to have a try, sorry to trouble you！
STL and path file .zip

[KASUYASU]

Hi,

I've converted your data file to a G-code one and tested it.

Milling_area3_data.zip

The next video represents the aspect of milling process. Is it right?

By cutsim-q5.

Milling_area3_video.zip

By new algorithm. (The endmill is plunged from the different direction, because the new algorithm hasn't provided interpolating smoother for Z axis yet.)

Milling_area3_new_video.zip