-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
Implement Particle Trails #48242
Implement Particle Trails #48242
Conversation
I have no idea why this is not passing sanitizer, it makes no sense and I can't reproduce this here, but it looks like the Particles object is not being freed.. |
@akien-mga may it be a problem with one of the CI projects run? |
Any idea @qarmin? reduz suggests the leak might be a bug in the test project. |
update_configuration_warnings(); | ||
} | ||
void GPUParticles3D::set_trail_length(float p_seconds) { | ||
ERR_FAIL_COND(p_seconds < 0.001); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dumb question but while the duration influences the length, is length the right name for this property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is, "length" can be safely applied to time as well as distance
if (_baked_cache_dirty) { | ||
// Last-second bake if not done already | ||
bake(); | ||
const_cast<Curve *>(this)->bake(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this safe behavior? Seeing bake changes the data within the object it's not constant. Is there a reason for making this function constant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its an internal cache, so its either this or making it mutable and I did not want to change a lot of code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read through all the code changes and I think I get most of it. I'd have to do some proper playing around to fully understand the existing GPU particles implementation. Other then two little nitpicking things this all looks completely sensible to me. Will be interesting to see if I can get it going on the mobile renderer but I don't think it will need many changes.
I'll do a bit more experimenting with it but I think this is a cool addition to Godot
Test project is really hard to broke, because use list of classes taken directly from engine and only some breaking changes for basic elements are able to do this like This time leak isn't false positive.
|
I looked at the code and this leak is caused by LocalVector
after applying this patch, leak is gone
|
@@ -462,8 +601,9 @@ GPUParticles3D::GPUParticles3D() { | |||
set_one_shot(false); | |||
set_amount(8); | |||
set_lifetime(1); | |||
set_fixed_fps(0); | |||
set_fixed_fps(30); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for defaulting to 30 fixed FPS? Is it for performance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interpolation has been implemented for particles, so unlike CPU/GPU particles in 3.x
, it should look smooth regardless of rendering FPS when fixed FPS is enabled now.
Fixing particle FPS to 30 should help improve performance when using collision and attractors, especially with many complex shapes.
See the discussion starting from here: https://chat.godotengine.org/channel/rendering?msg=G8cNTJHiDcnEwQbuy
@qarmin found the issue, it was on my side, but its weird that this did not fail before. I would assume it is related to changes on the CI. |
66a092e
to
b632630
Compare
Ok, should be ready for review or merging. |
-Enable the trails and set the length in seconds -Provide a mesh with a skeleton and a skin -Or, alternatively use one of the built-in TubeTrailMesh/RibbonTrailMesh -Works deterministically -Fixed particle collisions (were broken) -Not working in 2D yet (that will happen next)
Can you rename the last option for transform to "RibbonBillboard" ? |
@QbieShay I prefer to use the current naming so its a bit more obvious to the user that Z is used for billboard and Y for aligning. The ribbon is mostly the trail mesh, and you can use this option for aligning regular meshes or quads too, so its not necessarily specific to ribbons. |
I think that practically this will be used only for ribbons, so I'm not sure it makes sense to be this specific in the dropdown. Calling it ribbon billboard will also make it way easier to understand for people that want to setup a ribbon billboard, rather than having to search what ZBillbordYToVelocity means .. |
I agree that |
Thanks! |
@QbieShay I am not entirely sure you want to use this only for Ribbons. I may add speed velocity scale at some point (this was kind of requested also) and this option will be useful for it too. |
moar.mp4
partimeshes.mp4
Once this PR is merged, will implement 2D GPU particles (currently not working).