Artefacts in RibbonTrail

Hi,
I am getting some artefacts in RibbonTrail. It looks like polygon kinks are causing this. The trail is drawn only using x and y. The trail type is set to TT_FACE_CAMERA and my camera is orthographic. The material is RibbonTrail. Any ideas on how to fix this issue?

I had noticed the same distortion and increased the number of columns (default 1). Maybe this can help?
/// Set number of column for every tails. Can be useful for fixing distortion at high angle.
void SetTailColumn(unsigned tailColumn);

I think it does help, but also increase the number of triangles a lot. I am getting it on straight lines as well it is quite apparent in 2D, with higher width. Would it help to change TRIANGLE_LIST to TRIANGLE_STRIP or nudging the triangles not to overlap?

I am kind of stuck with this issue. It is getting worse if I increase the width and the segments. Is there anything I can do it in the shader or anything else that would help reduce these artefacts? I think it is similar to this topic: https://www.reddit.com/r/gamedev/comments/387pwc/rendering_3d_trails/

So, from a geometrical point of view, the fact is that offsets are nasty… You simply can’t offset using only vertex translations, and a) get a good offset and b) not get intersections.

In my project, I basically did the same thing as in the link you posted. The idea is:

• Get the vertices of the path. This is the center line.
• Create a billboard for each edge whose Y direction is parallel to the path edge, whose position is the midpoint of the edge, and has some width. Enable FC_DIRECTION to constraint he billboard to only rotate around the Y axis.
• In a shader, trim back the rendered pixels to avoid the intersections. This is not perfect, since you usually use one value for all edges, which is not good.
• In my implementation. I added another set of billboards at each vertex of the path. These render a circle whose diameter is the same as the width of the edge billboards. Enable FC_ROTATE_XYZ to have this always face the camera. This hides errors in the edges and creates rounded corners.

It’s not perfect, but it is substantially better than the ribbon trail…

Here is an example of how this technique looks: https://meshgeometry.github.io/Demos/CurveEdit/IogramPlayer.html

I’m still using CodeMonkey’s TailGenerator in heXon. Cross-breeding these two components might be what more people are looking for.

Thanks godan. I tried the demo but the joints are quite visible. Also I am not sure if this technique would work with textures properly and might look segmented. Do you have more demos with ribbons?

Thanks Modanung. I already tried TailGenerator but it exhibits the same problems as the one in Urho3D is based on this one if I am not mistaken.

Not sure if this would be appropriate as I think you’re working with 2D not 3D - Vehicle Skid Strips

Thanks Lumak. I think the vehicle skid strips have the same problem. Do you know if there is a way to fake transparency by sorting the polygon strips or a way to handle transparency per trail?

No, don’t know how to fake transparency. But in regards to vehicle strip, I think overlaps would occur if distance from segment to segment is relatively short and curved rapidly. However, the strips are connected from end to end and if the short curving segment causes overlap then it is actually really easy fix. Think about how a plane eqn works; in the strip case, it’d be as easy as checking the dot product of new points with the last segment line.

Part of my work in robotics programming involved computing ‘motion paths’, I’m considering taking a closer look at this issue, as I think the current results are unacceptable - the wireframe in particular displays some fundamental issues in the way the tri-strip is being tesselated, including slivers generated by vertices which are very close to others, and rightly should have been ‘welded’ with some distance threshold, although the overdraw caused by z-fighting overlapping triangles can probably be eliminated by drawing the trail geometry in two passes - the first with depth-writing enabled, as a depth-only pass, and the second as the full pass, with depth-testing enabled.

PS - ugh, they’re not even tri-strips, they are quads in our current implementation. I think that a possible solution to the issue of overlaps is to generate two Catmull-Rom splines, and then generate a tri-strip based on sampling the two curves. But using two render passes as mentioned above would likely be more performant.

As a workaround you can use checker board “discard” in pixel shader in screen space. It will be consistent on overlapping geometry. The only question is - will the image be acceptable for your case.

I once implemented sword rail using triangle strips which means there is no overlaped between quads.
Edit: it is the overlapped part of the quads cause the issue.

Yeah, I sort of said that too, well I implied it

What about changing the alpha blend mode?