Holy macaroni! Ty Epic, I can’t wait for it.
I’m very disappointed, this is still not fixed in unreal 4.5.
Hi,
any news concerning a bugfix after 4.5 ?
If you need repro-data, please let me know.
Thanks,
Nevermind.
My issue seems to be fixed in 4.5.
In 4.4.3 local space did not work.
I have attached a Sample Project with a Default Particle System to this post. I am not seeing any bug related to a shift in position when Vel/Life is set to Absolute as long as the Emitter is set to Local Space. I have also slowed the emitters themselves down in the level using a time dilation so the particle can be seen spawning at origin and then moving.
Thank You
Eric Ketchumlink text
Dear Eric, I won’t be trolling over this issue if there wasn’t a problem with positions in UE emitter.
I understand that it works in most cases, but if you really want to tweak them to the limit, then this bug need to be solved. I have made several bugged examples using “local space” and send them over to your staffs and I’ll be willing to do so again. Just give me another email and I’ll re-create the bug using 4.5.
Best,
Hey KillerPenguin -
I absolutely do not think you are trolling at all. If you see an issue we want to try to address it as best we can. That being said I have sent you contact information about a way to get a sample project to use that demonstrates your issue.
Thank You
Eric Ketchum
Well, pic below is from 4.5. Same thing as before, particle is shifted in weird direction when local space is not ticked. (And when it’s ticked, ribbon data is not rotated with it, making it unusable.)
I already sent this sample project to you in via mail. Hope you could really fix it this time.
Hey KillerPenguin -
I have re-entered a bug report using your assets for the test case (UE-4523) and will keep you up to date as we continue to investigate this issue.
Thank You Again for your help -
Eric Ketchum
SO after all my time creating all these project files to show the bugs, The issue get shrugged back into the rug and queue up to be tested again? What happens to this promise? →
“Normally I have to deliver bad news, but today GOOD NEWS!! This issue has
been fixed on our internal branch of the engine and should be included in
the next engine release.”
I’m very disappointed to say the least…
Hey Killer Penguin -
There were originally two different issues that your issue ended up being reported and the first issue “Ribbon Data doesn’t follow its source particle when local space option is checked.” and that issue has been fixed. The second issue (the one that obviously is more concerning to you) was not placed back under the rug but was and is in fact still being worked on. I reported it again so that it would not be lost in the shuffle.
I appreciate your concern and we are working toward a solution as fast as we can.
Thank You
Eric Ketchum
Well, the problem is still there in 4.6.
Same bug in 4.9
From our Graphics Programmer:
"The offset from center is related to the spawn/tick order of operations. With these high velocities, small variations in frame rate during spawning make a huge difference. The emitter is also offset by 100 on each axis in the spawn module, so it’s not going to spawn directly on the origin, but the biggest issue is that, with framerate variations, the initial spawn location can vary substantially because we update particles immediately after spawning - so the first time the ribbon emitter runs, it’ll spawn from the initial location that has already been updated by the velocity, which is large, which is going to offset the initial particle substantially from the origin.
A possible workaround: insert one additional control point at the beginning of the curve, at an InVal of 0.0 with a small X velocity of 0.1 or so to trigger the SpawnPerUnit module, and constant interpolation.
Move the second control point to InVal around 0.3 (0.2s * 0.3 = 0.06s or 60ms) instead of 0.0. This should make sure that the initial movement of the particles directly after spawn is very small, so they’re likely to be very close to the center except in the unlikely case of a long hitch. The above fixes the issue with this particular emittter for me."
This issue is still listed as backlogged. I have bumped the community interest again.
Thank You
Eric Ketchum
That’s not it. if local space has one problem, and world space has another, I would say the problem lies somewhere else.
Your programmer just doesn’t take it seriously. The ability for users to directly influence how particles precisely move in a line is actually very neat and crucial if you want to create something spectacular.
It’s over a year now and I really doubt that this will ever get fixed.
Hi Eric,
I just wanted to voice my support for this issue to be worked on.
I wasn’t able to successfully implement the workaround but that is probably because of my misunderstanding.
Thank you
Has this been resolved? I’m seeing a lot of chatter about ribbons not following source particles if they have an orbit velocity applied, but in my case when the particle emitter is using local space and rotates with its parent, the ribbons only flow in world space. They disregard the parent rotation completely. I’ve checked every box, applied every trick, still cannot get the ribbons to unlock from a world space velocity.
