The new half-baked pbr thing does more harm than good.

I see a lot of percentages going on in your tool.
I would genuinely be curious to know: percentage based on what?

How do you define "100% geometry load"?
What is "Crash Risk percentage"? Is there some deterministic way to calculate crash risk percentage?

What about "Texture memory percentage"? 117 MB is 1%, ok, then 100% is supposed to be 11,7 GB.
What does this actually mean? It's calculated based on actual free system RAM? VRAM?

What is the "Health" percentage? What parameters is it based on?

Is there a documentation available for this tool that explains what all this parameters are supposed to represent?

Massive work.. do you model everything in Zbrush or you do something in Sketchup (e.g masses/concept)?

Try to turn on all the layers in the "tags" panel and se if it's something related to layer visibility.

@fredo6 said:

there is nothing I can do (or other scripts can do)

Well, actually I've found myself in the same exact situation with the TAB key causing the viewport to lose focus in SU2023+, but i guess I've managed to find a working solution for this in a couple of plugins.
Check your inbox, is included in the things I shared today.

@JanSteinman said:

When you pay money for a product

Isn't Lord Of The Toolbars free??

Bestiale!

@fredo6 said:

I will probably dicontinue the plugin.

Please no, is my favourite plugin ever

@AISmebel said:

I would like to ask you to share this interesting plugin. I created a lot of interesting things myself with the help of Claude. It's interesting to see what others are doing.

It's currently in the last (I hope so) alpha stage, I'll need to fix a couple of edge cases before it can go beta.

@fredo6 said:

I also want to suggest that after using the plug-in, the components do not deform, bend in shape and retain their component properties

I don't understand what you mean.

Wow, I realize that I didn't understand correctly the proposal, so I retreat my + 20 on this.
Because you basically can't do that in Sketchup (you'd need some sort of modifier system similar to the 3dsMax one to accomplish this).
I understood that he was talking about a non-slicing behavior instead (which would be preferable).

@fredo6 said:

I am not sure it is possible to identfy and carry over the quad mesh, because of the slicing.

I guess it's super-difficult when you need to slice (so you are creating new geometry with new vertex-order/face-IDs), but it's actually quite easy when you just need to deform.
The key is that you apply preemptive triangulation (with different properties for planar quads/planar n-gons) at the very beginning of the deforming operation in order to stabilize vertex order, edge properties and UV mapping, then you can safely preserve/restore everything once the deformation is done.

I'm not a programmer, but I managed to formalize the whole algorithm decently enough that Claude can execute that brilliantly (based on the steps that I use to do manually in order to stabilize a mesh for proper Subdivision/Uv-mapping workflow).

I achieved good deformations which are reliably preserving quads, and UV mapping with decent fallback methods for n-gons.
I was planning to share the code with you regardless (for review before publishing it on Sketchucation), I think it could be interesting if you could integrate (and probably improve) it in some of your plugins, this one could be a clear candidate.

@AISmebel said:

the triangulating line that appears after using the plugin should become soft+smooth

Nope.
It should be soft = true; smooth = true AND cast shadows = false otherwise it will not work.

@AISmebel said:

I also want to suggest that after using the plug-in, the components do not deform, bend in shape and retain their component properties

I agree +20 on this!
I already said that in the original discussion on Trimble forum and I 100% stand on that.
Slicing should be optional. The default behavior should be "deform only", that would make more sense.

Amazing. Does it support quads and/or UV preservation?

This is nice, but definitely has nothing to do with LUTs. LUTs are about color, not grain.

@Gus-R said:

"what's wrong with movies today" video on Youtube

Do you have a link for it? Sounds like something quite interesting to watch..

@Arkanthiell said:

what exactly you did

I did exactly this and it worked perfectly.

Give_A_Proper_Name_To_Your_Files.skp

@Arkanthiell SketchUp is a polygon modeler not a "solid/nurbs" cad modeler such as Solid Works or Inventor.

In whatever polygon modeler (including the most powerful ones, such as 3dsMax or Blender) ngons are a well-known source of problems, in particular the ones which are concave and/or have holes into them.
They are always triangulated at a machine level and this automatic triangulation tends to give artifacts and problems more often than not. This is even worst when you have very elongated ngons with lot of vertices, which is exactly your case here.
In this kind of situation, you have those very long and thin triangles which can cause holes and shading artifacts.

The proper way to manage this (aside from super-pro full quads mesh typology) is to place a few "strategical" cuts to shorten the ngons and "encourage" proper triangulation on concave ngons.

@jackieboyharpster apparently, you are trying to do it with 4 curves selected using the "loft by splines" command, this is clearly user error.
Just delete the 2 straight segments (and the attached existing face of course), then select only the 2 arcs and run the command again.

This is insanely great!

It's 99,9% related to clipping planes tolerance

To troubleshoot this you can type in Ruby console

Sketchup.send_action 10624

Then in the windows which will pop up, check the "Force" flag and try to play a bit with "Near" and "Far" parameters.

If the "Model Far" is a really huge number compared to the actual expected size of the model (causing the "Far" clipping plane to be REALLY FAR, then you can have that kind of floating-point-precision-related z-fights happening like in your screenshot).

There are a few reasons that can trigger this kind of behavior (which is the pretty much the opposite of the well known "clipping problem").

Usually there's something REALLY FAR from axes origin (maybe a tiny stray segment miles away from world 0,0,0 or possibly you accidentally created a misplaced copy of your 3d text which for whatever reason ended up at light years distance from model space).
In that case you can try to select whatever should actually be in your "intended" model (maybe temporarily group & lock it for added safety), then invert the selection and erase whatever else is in the model (this will clean up accidentally misplaced geometry that you can't see because it ended up into some different solar system) and everything should be fine.

Another possible reason is that some of the objects in the model is actually in the right place, but its internal coordinate system has the origin miles away from model origin. In that case you can troubleshoot that looking at object bounding boxes or if you want to fix that super-fast, just install the "Axes Tool" plugin from Thomthom and recursively select components and sub-components and run the tool in order to place the object's axes in the center of the bounding box. Being that you apparently have just a few objects, you could just try to explode and regroup them one by one and that could fix the problem.

Another reason which comes into my mind that can trigger this kind of glitches, is when you have some "giant" component and you scaled it insanely small compared to the original size.. in that case you can try to "scale definition" (or, again, just explode and regroup it) and that should fix the problem in such specific case. If you created your 3d text insanely big and you scaled it a lot, that could be the culprit.

If none of this fixes works, maybe you can share the model and I could try to see what's goin'on exactly.