PDA

View Full Version : Mirror issue



ianay
01-18-2020, 01:49 PM
Ive been having this issue for a while now and it continues to appear, ive been getting around it by copying and pasting but Im getting a bit tired of that now.
On the odd occasion when using mirror X Some of my polygons appear black and no matter what surface i put on them?
Theyre black and they render black, how can this be when they are supposed to be a direct copy of a previous polygon which looks fine..
Here's what im talking about..
Im using 19.1

Thanks for all help

Kryslin
01-18-2020, 03:01 PM
Try tripling them (crtl t) and then fusing them (shift z). This forces a rebuild of the normals for the polygons.

If the process is repeatable, I'd submit it as a bug report with sample geometry; Sounds like Lightwave is getting confused about something.

ianay
01-18-2020, 03:26 PM
Tripling and merging it worked fine but...
The obvious problem there is that I then have to go around selecting all the tripled polys then merging them and I may as well just copy and paste as it'll likely take less time. Thus pretty much making the mirror tool useless
This pretty much proves though that this is a bug.


Thanks for help

Carm3D
01-18-2020, 04:43 PM
I've had problems using the mirror function too.. When using mirrored geometry with 3rdPowers' Cage Deformer I was getting nasty deformation artifacting. I started using copy/pase/scale X by -100 and haven't looked back since.

ianay
01-18-2020, 05:06 PM
I can copy and paste without much drama but scale x by -100? That went right over my head, Can you let me know more?

Carm3D
01-18-2020, 06:11 PM
I do my editing on one side.... Say, the positive X side. Nothing exists on the negative X side. So I copy the polygons on one side, copy and paste it into the next layer. Then I scale it on the X by -100% in Origin mode. Hit "f" to flip the polygons, then cut and paste it to the original layer. Merge points.

jwiede
01-19-2020, 08:21 PM
Is kind of sad that the scale -100% trick works so much better than the tool explicitly built for the purpose.

Carm3D
01-19-2020, 08:59 PM
Silo 2 gives you a virtual mirror so you can see the mirrored side of your model as you work; even though it doesn't exist. Pretty neato.

Tim Parsons
01-19-2020, 10:13 PM
I do my editing on one side.... Say, the positive X side. Nothing exists on the negative X side. So I copy the polygons on one side, copy and paste it into the next layer. Then I scale it on the X by -100% in Origin mode. Hit "f" to flip the polygons, then cut and paste it to the original layer. Merge points.

What??? I use mirror all the time and never have issues. (Unless of course I'm trying to mirror CC subdivisions with edge weights. :))

Skonk
01-20-2020, 06:53 AM
Do you have Merge Points enabled in the mirror tool? if you do, try turning that off.

if that fixes it then it's likely your model has some duplicate points/polygons which are being merged in the mirrored half of the object.

omichon
01-20-2020, 07:24 AM
I too have issues with mirror tool every now and then. In such cases, I use a 3rd party tool (LWCAD) instead of the native tool. Yeah, it sucks, I know :(

Tim Parsons
01-20-2020, 07:32 AM
Do you have Merge Points enabled in the mirror tool? if you do, try turning that off.

Yep - I wish that was off by default.

Tim Parsons
01-20-2020, 05:12 PM
If you get a weird result when you mirror, undo and merge points and mirror again. There is probably a good chance the merging of points will not show in the info window, but something happens to correct the issue. :) Again don't ever use the merge points in the mirror tool. (Unless you desire all your points to be stuck to one another - a bad thing if you have used snapping tools to line up geo but still want the geo separate.)

ianay
01-20-2020, 05:13 PM
Skonk, I turned off merge points in Mirror tool, also got rid of any duplicate polys and merged all points...

Made no difference..
But I was messing around looking for a solution and I found a tool I havent used before 'Flip it' (Modify, Translate, More)
It allowed me basically to mirror along the X axis..
It seems to be ok so far, so no more mirror for me

Thanks for all help guys

Sensei
01-20-2020, 05:45 PM
Ive been having this issue for a while now and it continues to appear, ive been getting around it by copying and pasting but Im getting a bit tired of that now.
On the odd occasion when using mirror X Some of my polygons appear black and no matter what surface i put on them?
Theyre black and they render black, how can this be when they are supposed to be a direct copy of a previous polygon which looks fine..
Here's what im talking about..
Im using 19.1

Thanks for all help


Have Polygon Statistics window all the time open.
When n-gon (> 4 vertex polygon) is made, you will see, if it's caused by it.
OpenGL is calculating normal vector of polygon from 1st, 2nd and the last vertex of polygon.
If two points share the same position, delta between them is 0, and normal is also 0,0,0.
Which disallows properly shade such polygon.
5-gon with two points positions shared looks to human as 4 point polygon.
LW renderer prior rendering converts everything to triangles, so it often disappears during rendering.

jwiede
01-20-2020, 07:55 PM
Have Polygon Statistics window all the time open.
When n-gon (> 4 vertex polygon) is made, you will see, if it's caused by it.
OpenGL is calculating normal vector of polygon from 1st, 2nd and the last vertex of polygon.
If two points share the same position, delta between them is 0, and normal is also 0,0,0.
Which disallows properly shade such polygon.
5-gon with two points positions shared looks to human as 4 point polygon.
LW renderer prior rendering converts everything to triangles, so it often disappears during rendering.

Even if we accept that LW can't be fixed to not make such "junk" in the first place (which isn't the case, but let's presume it is), it would be fairly trivial for LW to occasionally scan through the poly definitions for "coincident vertices", and when the same poly has em within a nano-margin, just merge them (or at least offer to do so). Make the cleaning a pref that comes enabled, but can be disabled in case some hermit up on a mountain requires those to exist for their workflow.

The real answer is to be more diligent about detecting and queuing junk geometry for later inspection/merging during tools' operations (with tool context, so the inspection can log context of generation as well as potentially remove, to isolate "problem tools"). Unfortunately it appears that kind of defensive coding is apparently inconceivable, so having something hanging off the event loop that periodically scans/cleans such cruft would be a fine alternative answer.