 | | Re: Some secrets of MLCad revealed ...
|
|
(...) I guess points are shared only on a part basis, not on a model basis. So, 400 distinct points for a part is already a fair number. Thus I think the sorting technique I discuss is not candidate for implementation unless the ldraw library goes (...) (21 years ago, 7-Jul-03, to lugnet.cad.mlcad)
|
| |
| | Re: Some secrets of MLCad revealed ...
|
|
(...) <snip> Cool! Should perform a lot faster on searching I would expect 400 points? That seems low to me. Most of my models have more than that many elements! Even with shared vertices that seems low. (21 years ago, 7-Jul-03, to lugnet.cad.mlcad)
|
| |
| | Re: Some secrets of MLCad revealed ...
|
|
(...) Ok, the practical figures relativize the problem for everyday use. Thanks Michael. For the sake of sharing here is how I imagine a sorted point list. The sorted list is also implemented as an array, so points can be accessed by index for (...) (21 years ago, 7-Jul-03, to lugnet.cad.mlcad)
|
| |
| | Re: Some secrets of MLCad revealed ...
|
|
"Damien Guichard" <damien.guichard@wanadoo.fr> schrieb im Newsbeitrag news:HHKMxB.225G@lugnet.com... <SNIP> (...) the (...) in a (...) So far I could find out, it doesn't effect loading much, I think it was something about 10% less then without this (...) (21 years ago, 6-Jul-03, to lugnet.cad.mlcad)
|
| |
| | Re: Some secrets of MLCad revealed ...
|
|
(...) Thanks Michael. So, at loading time, each added point has to be compared to all points in the point list. Does this impact the loading time of big parts or big models in a significant manner? Or is it only minor slowdown? Regards, Damien (21 years ago, 5-Jul-03, to lugnet.cad.mlcad)
|
