[Plugin] Mirror

Elibjr

Thank You TIG. You have some of the most reliable plugins in the forum! You have changed my view of SketchUp forever!

JGA

Thanks for keeping on the development of this tool; it's the first one I loaded years ago that made SKUP more familiar to an AutoCAD user.

bmike

TIG,

Seems that Mirror doesn't honor Locked Components...

[flash=640,480:hycafqxq]http://www.youtube.com/v/AQrNxCOZZuQ[/flash:hycafqxq]

bmike

@mental said:

Hi. Forgive me for possibly a stupid question but which advantages does this plugin bring compared to good old scale x -1. Probably I'm missing something.
Thanks

Much quicker, using the plugin, especially when dealing with off axis objects - compound roof rafters, sloping parts of stairs, etc. etc. No need to create an extra plane or line to include in the -1 Scale Operation to get the axis right...

And it auto copies things for you, about any axis you choose, to dropping an identical assembly or rafter or whatever, exactly where you want it, is much easier.

TIG

Here's v3.8
http://forums.sketchucation.com/viewtopic.php?p=276512#p276512
It now honors any selected 'locked' components or groups, and does not mirror them.
I've also included some minor 'behind the scenes' code tweaks...

bmike

@tig said:

Here's v3.8
http://forums.sketchucation.com/viewtopic.php?p=276512#p276512
It now honors any selected 'locked' components or groups, and does not mirror them.
I've also included some minor 'behind the scenes' code tweaks...

Thanks TIG!
Sorry to call it out, but this is how I noticed the lock glitch!

TIG

This something to do with Sketchup itself.
If the arc/curve is grouped/mirrored with other connected-geometry [that borders a face] then the arc gets exploded !
If you replicate the arc+other_geometry_around_face > group, copy, scale -1, explode... you will find that native Sketchup breaks the arcs too...

jim smith

TIG, thank you for the update

pilou

@unknownuser said:

Sketchup breaks the arcs too...

It's a pity!

pilou

So solution is to group the rectangle first!

With that all the mirrors of the arcs will keep the arcs not explosed!

TIG

Yes - it's just the same in Sketchup when it's done manually...

urgen

@unknownuser said:

@unknownuser said:

Sketchup breaks the arcs too...

It's a pity!

....Pilow,don"worry. make mirror and use plugin nilinies2arc.rb (http://forums.sketchucation.com/viewtopic.php?t=21155)...properties of the arc( in Entity Info) must have been restored

pilou

Don't know this little last one

jeff hammond

rainy day ideas..

mirror would be a good one for doing what you did to split_to_plane.. where <enter> is Z instead of the 3rd click.. lathe would be another candidate (2nd click when defining the axis)..

pilou

Seems there is a glitch ?

An arc is drawn up left corner then "Mirrored"

Making a group don't resolve the problem
when explode mirrored group , arc is exploded!
when explode original group , arc is not exploded!

Mirror_arc.skp

rv1974

I use to render my projects in 3DS Max and my pipeline is to turn all entourage components to the cubes proxies (by Fredo's Ghost plug in), open simplified entourage skp file in Max and then replace
them by another Max script with hi-poly vray proxies.
What is interesting is that the mirrored (at some stage) SU components get wrongZ value in Max.
I just wandering where is the wicked link:
SU itself, mirror.rb, ghostcomponent.rb, exporters\importers?

pilou

@Jeff
Sorry don't understand first proposition ...and second proposition!

@unknownuser said:

mirror would be a good one
: it's that the problem that don't work
with 2 or 3 clicks even I split horizontally the rectangle

@unknownuser said:

lathe

??

A Copy Rotate works (don't explode the arc) but it's not the mirror function and i must draw some helper lines

TIG

@rv1974 said:

I use to render my projects in 3DS Max and my pipeline is to turn all entourage components to the cubes proxies (by Fredo's Ghost plug in), open simplified entourage skp file in Max and then replace them by another Max script with hi-poly vray proxies.
What is interesting is that the mirrored (at some stage) SU components get wrongZ value in Max.
I just wandering where is the wicked link:
SU itself, mirror.rb, ghostcomponent.rb, exporters\importers?
When you 'mirror' or use 'scale -1' [which is all that mirror really does] the component-instance is flipped [aka 'transformed']; however, inside its definition the geometry still has the original orientation.
When exporting such objects into another format that exporter's code must identify the original geometry and its container's 'transformation', then typically it applies the transformation so it now looks right - some formats have limited 'transformation' abilities, so make everything changed so it looks right perhaps messing with the object's innards while doing this. This then breaks the direct link to the original's transformation, so maybe 'swapping' a component won't adopt the original's transformation...

When you 'mirror' something it's typically about a bounding-box center-point - so is this 'Z difference' you see after swapping related to say half of the object's bounding-box 'height' [actually Z is its 'depth'!] - it might be that the Max script is incorrectly interpreting that point when applying its own transformation - would a fix be for the script to adjust the Z-value as it swaps ?
Are you sure that the paired simple and complex proxies have the exact same bounding-box and insertion point etc - if they don't then the swapping of them can easily get muddled... If you swap and swap back do things reset properly or get worsened ? This could indicate such a state...

rv1974

may be the attached files would help.

skp+max files example

It looks correct in SU: axes are OK and the same definition of the components

after opening in Max it looks OK too

After the Soulburn's Object replacer was applied: Z values :(

the same area after some brief messing:)

TIG

So the Max 'swapper' script is misinterpreting the transformation of the imported objects ?
If you swap and re-swap back as you were, are you back or has further wrong-transformation happened ?
Seems to me the issue is with the Max swapper script itself, which is clearly flipping the 'mirrored' versions of swapped pyramids about their centers ??
If you used a non-symmetrical object as the two simple/complex we can better see the extent of the 'flipping' which might be a 'rotation' or a real 'scale -1' ??? try a pyramid placeholder with an offset apex so we can clearly see its transformation, and a more complex version for the 'swap'.
The Z-offset issue should be solved if the script correctly flips these mirrored versions...
I know little about Max scripts.
Have you tried looking for solutions over on their forums...