7.1 Performance

Gaieus

Well, in my above example, I made the three groups instances of the same component - certainly however SU keeps track of "instances" of the same group, too.

mitcorb

@chrisjk said:

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....

I apologise if this isn't considered a performance issue.

I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.

Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb

Whaat

@mitcorb said:

@chrisjk said:

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....

I apologise if this isn't considered a performance issue.

I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.

Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb

+1

thomthom

++

Aerilius

+++

mitcorb

I hope my previous quote and comment weren't perceived as being harsh or disrespectful, because I certainly did not intend that.
I just wish to gain better understanding of the program. And I believe open discourse is elemental to understanding.

remus

++++

...and another thing, im noticing slow downs in transforming lots of geometry and grouping lots of geometry (when i say lots im talking about ~50,000 faces.) Like you say, its only now SU can navigate such models with ease that i've really noticed it

Tyler Miller

@mitcorb said:

@chrisjk said:

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....

I apologise if this isn't considered a performance issue.

I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.

Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb

The small dimension issue is not a performance issue, but I feel your pain. Under the covers, SketchUp represents all geometry in inches with 64-bit floating point precision. When dealing with floating point numbers in applications like SketchUp, you have to establish a tolerances for things like length, angles and planarity. In SketchUp's case, that tolerance factor for length is 0.001 of an inch. Below that threshold, two lengths are considered equal. In practical terms, that means that SketchUp does not support edges that are less than 0.001 in length. SketchUp was originally designed for architecture and it was not conceived that users would want tolerances lower than 0.001 of an inch. Changing it now, while theoretically possible, could have disastrous effects for existing SketchUp models.

That said, the issue is on our radar and does get discussed around here a fair amount. If we can see our way to a solution that works for new and old models, then we'll try to fix it.

Hope that helps,
Tyler

thomthom

Tyler: that bit of info is greatly welcome! It allows us scripts to more reliably match and control the tolerance that Su works with.

I don't suppose you got some info in regards to what is considered co-planar? If you make a script that iterates a model's edges, and check if it's adjacent faces are co-planar using face1.normal.same_direction?(face2.normal), and remove the edges then that method returns true, then in some cases the faces are lost as SU doesn't really consider them co-planar. It also goes the other way, it sometimes says they are not co-planar, while you can remove the edge and the two faces merge. It's a very tricky issue (all though not a performance issue). The SU API methods that compares vectors doesn't seem to match 100% with how SU really works.

mitcorb

Thank you, Tyler, for responding. Your explanation helps a great deal. I had no idea that a modification on the precision would affect older models, but I could imagine scenarios where devastating results could occur.
If .001 is the threshold, what would happen if another camera were implemented that only deals with the very small, so that correction of these triangles can occur with the tools at hand> make face, repair tiny triangles? Or perhaps, we the users just need to retopo the problem area by redrawing it, assuming there are only a few areas. Or a diagnostic tool could be developed for finding the problem, and ultimately fixing it?
If the microscopic camera is a whack idea, how about this one: A special scaling system that automatically applies a multiple to a model being developed in real world scale, so that input doesn't require meticulous calculation for each element being modeled? I mean, I am slow enough as it is, so something like this would really help.
Once again, thank you very much for your response.
Sincerely,
mitcorb

driven

@mitcorb said:

If the microscopic camera is a whack idea,

I don't think is such a whack idea at all,

but,
could it not be implemented as a 'Scene Style' SU can already change pretty well everything else through styles, you can even drag an old styled drawing into a new one.

I for one already use a testing style, a watertight style , a rendering style all in one drawing, so having a `Let's Get #nnal' would be one approach.

If drawing in that environment everything 'off screen' could have a scale factor applied to it and so when I input 20 microns radius, SU just scales it up by 'X' (behind the scene), once small geometry is drawn, I've never noticed SU to reject it, so, you could then import/export from any style...

is this whack??