transparent line on opacity mapped geometry intersections.

[super gnu]

im using tyflow to scatter opacity mapped planes over a globe. these have an animated "ping" texture on them.

since they are all bunched up and overlapping, ive added a "push" operator to randomise their offset from the surface so they intersect as little as possible.

this cannot be pushed too far since you then see the pings floating above surface on the sides of the globe.

it generally works ok, but on the points where two planes intersect each other, i get a thin transparent line in the solid areas of the opacity map. . (since they are flat planes, scattered on a sphere, they are never actually perfectly coplanar)

ive played with the secondary ray bias, and there is a sweet spot where the line is minimised... higher or lower and it gets worse.

however im unable to eliminate it entirely.

the scene has no lights or gi..

any suggestions as to why vray cannot deal cleanly with this, and any ways to fix it? im guessing its a precision issue, and at those points the geometry is considered coplanar? given infinite precision the defect would be infinitely thin.... doesnt help much though.

attached a screengrab showing mesh and a zoomed in render to highlight the issue.

[fixeighted]

That's annoying. Maybe someone has a Vray solution but I suggest, if it's only the pings that you need as an overlay, then do them with scanline, which has no similar issue. Plus it will be light years quicker to render

[super gnu]

thats not a bad suggestion, however id be concerned that, since i need satellites passing over the pings (and behind the earth/pings) , which would need doing in vray, it all starts getting quite fiddly from a post point of view, especially with reference to motion blur.

[fixeighted]

Bah...bloody motion blur....although you may be able to get away with scanline multipass mb, as it'll get lost in the mix....still would be quicker even with 12 to 24 passes I reckon. Worth a shot.
I'll do a little test and see

[super gnu]

thinking about it , this should really be avoidable, for opacity maps at least. even if the faces are coplanar... if one is more transparent and the other is more solid, it should always pick the solid face to shade.. its probably not that simple, but if a dinosaur like scanline can deal with it, why not vray? they both surely have to decide what to do when there are two sets of "shading instructions" at the same point.

fortunately when the cam is moving and the moblur kicks in, the errors are lost in the movement, but i have a couple of shots which you can see it on start and end frames.. i guess if client notices i can paint them out

[fixeighted]

It is annoying yes. I fall back to scanline for stuff like this...just simpler.

Maybe a solution would be to render them top down, in clusters, using that as an animated texture.

[fixeighted]

Ok, so I just had a little eureka moment...which may help you, though it is using Forest to scatter the planes.
I was just trying various random things and found that by using rotation randoms set to -1.0/1 x/y and 0/0 z the problem goes away, as in this grab before/after.
Maybe something similar in Tyflow will effect the same solution...

[fixeighted]

And weirdly, as you can see in this grab, the planes are still clearly intersecting, so I have no explanation for why it worked

[Joelaff]

Not sure if this is your issue, but I find with trans maps I frequently have to set textures to mirror, rather than tile. (Then I think you set the UV tile amount and UV offsets all to 0.5 to compensate since max stupidly changes the scale when you mirror. )

Is that what you mean? I couldn’t tell what I was supposed to be seeing in the examples.

[Joelaff]

Oh that may be different from my comment above. Maybe coplanar polygons Z fighting? When you rotate them they no longer line up perfectly?

Or they are casting shapes on each other?

A slight offset might fix it too.

If the scale of the scene is large perhaps manually setting hither and yon clipping planes in the camera would help if it’s Z fighting. Not sure this plays a role in VRay or not.

[Joelaff]

You could also try disabling VRay instances in Forest Pack.

[super gnu]

Hi Joe.. Im actually using Tyflow to do the project, not forest pack. im not sure how disabling instancing would help? i can give it a try..

and if you look at the original post, you can see transparent lines in the solid parts of the opacity map, where any two planes intersect. its a result of z-fighting im sure.

I cannot move them far enough apart to avoid all intersections, since they would stand off the earth too much and look like they were floating.

[fixeighted]

Just as a thought, could you not make the planes themselves curved to match the earth curvature. That would eliminate any intersections, no?

[super gnu]

Just as a thought, could you not make the planes themselves curved to match the earth curvature. That would eliminate any intersections, no?

i thought of that, but given the scales involved (ive got 200 subdivisions on the earth sphere, the max the spinner will allow) and the planes are all different scales and sometimes smaller than a single face on the sphere.. i was wary of making them curved.. first, unless the sphere was subdivided massively, id not match its curvature with a curved plane... second, with different scales, the curve would be different on each plane...

maybe i could do some kind of "conform" trick in tyflow... i know it has a nice conform modifier.. maybe there is a conform operator i could use in the flow before the push operator... need to check.

[fixeighted]

Yeah you're right, however, could not the planes be all the same size but the pings different sizes, as a compromise?
There is also the trick you can do on the sphere, using a Vray disp mod to smooth it completely at render time, so you wouldn't have to worry about matching any poly 'curved' stuff.

It's annoying that you couldn't get that little trick of a tiny offset to work with Tyflow. No idea how that happens with Forest but it did solve it....well actually
it solved it 99.9%...on extremely close inspection it still happened in just one area, so one tiny intersection line on just 2 planes. Weird 3D shit for sure