Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the gaps between particle geometry in the Ribbon render modifier #332

Open
jakkos-net opened this issue May 26, 2024 · 9 comments
Open
Labels
A - shaders Compute and render shaders C - enhancement New feature or request

Comments

@jakkos-net
Copy link

Describe the solution you'd like

Currently each particle in a ribbon creates it's own disconnected geometry, this leads to gaps in the ribbon. See below image from the "ribbon" example:
image

It'd be cool if we could have consecutive particles share verts so that it'd be one continuous ribbon :)

@jakkos-net jakkos-net changed the title Remove the gaps between particle gemeotry with the Ribbon render modifier Remove the gaps between particle geometry in the Ribbon render modifier May 26, 2024
@djeedai
Copy link
Owner

djeedai commented May 27, 2024

This looks more like a bug to me. @pcwalton any idea what's going on or a limitation I'm not aware of regarding ribbon joints?

@djeedai djeedai added C - bug Something isn't working A - shaders Compute and render shaders labels May 27, 2024
@djeedai
Copy link
Owner

djeedai commented May 27, 2024

Oh I guess we never implemented miter joints so it makes sense. We only render a quad from one particle to the next, without looking at the previous one for example.

image

@djeedai djeedai added C - enhancement New feature or request and removed C - bug Something isn't working labels May 27, 2024
@djeedai
Copy link
Owner

djeedai commented May 27, 2024

Changing from Bug to Enhancement because I think I remember this was a known limitation of that first ribbon/trail version, we didn't want to complexify right away. So that's more of a feature request to improve the current implementation.

@mrteathyme
Copy link

mrteathyme commented May 28, 2024

Changing from Bug to Enhancement because I think I remember this was a known limitation of that first ribbon/trail version, we didn't want to complexify right away. So that's more of a feature request to improve the current implementation.

Preface, im not too well versed in graphics programming so I could be talking out my ass here.

But couldnt you just fill in those gaps with a single tri? youve got 3 vertices there (the single vertex that the two quads touch on when following the curve, and the two hanging vertices where they arent touching) so you could render a tri with those 3 vertices, shouldnt introduce too much complexity that way and should be relatively cheap since theres nothing to compute really.

@jakkos-net
Copy link
Author

But couldnt you just fill in those gaps with a single tri?

Ideally you'd want to have the quads share verts (e.g. the last 2 verts of one quad are the first 2 verts of the next), you don't need additional tris.

However, it looks to me from glancing at the RibbonModifier code that the current vertex shader generation relies on the idea that each particle gets rendered as a single quad (specified by axes, size, and position).

I don't think there's a practical way to get all the quads join up nicely with the current system. Even if you skewed the axes to make the quads into parallelograms you'd have to look at every previous particle to work out the correct angle for the current particle, so not practical lol.

So to implement this feature, I think you'd either need to change how the vertex shader code gen works for all effects, or make the ribbon effect code gen separate from the normal effects - both sound annoying to do 😁

@djeedai
Copy link
Owner

djeedai commented May 28, 2024

I don't think there's a practical way to get all the quads join up nicely with the current system.

Plot twist, there is! Each trail particle stores the index of its previous and next particle. This is how we can draw a quad between two consecutive particles. So it's "just" a matter of looking at a third particle in the chain to determine the orientation of the edge shared by two consecutive quads.

@jakkos-net
Copy link
Author

Plot twist, there is! Each trail particle stores the index of its previous and next particle. This is how we can draw a quad between two consecutive particles. So it's "just" a matter of looking at a third particle in the chain to determine the orientation of the edge shared by two consecutive quads.

I only quickly looked at the code, so sorry if I'm being dumb 😁.

It looked like the only way to change the orientation of the edge was through the axis_ variables, but this would mean that when you set one edge of the quad you'd also be setting the other edge. So to calculate the orientation for a particle you'd also need to know the orientation of the previous particle which would depends on it's previous particle, which depends on it's previous particle... etc

Also while I'm here asking possibly dumb questions: the ribbon modifier code declares that it needs both NEXT and PREV attributes, but isn't it just using the current and next particles, not the prev?

@djeedai
Copy link
Owner

djeedai commented May 28, 2024

I only quickly looked at the code, so sorry if I'm being dum

No you're perfectly right that it's a bit more complicated, you need indeed some changes in the vertex shader I think.

Also while I'm here asking possibly dumb questions: the ribbon modifier code declares that it needs both NEXT and PREV attributes, but isn't it just using the current and next particles, not the prev?

I believe this is correct and was in anticipation if this very feature, which we culled in the first version to keep things simple and easier to review.

@jakkos-net
Copy link
Author

Ah, I get it now! Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A - shaders Compute and render shaders C - enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants