native nexus
I'd like to keep this halo-looking spinny thing on the back of a hero while it is running around. For that, I need to orient the particle system's normal relative to the hero's facing direction. Is there a way to do that? Tried all the PE functions related to "orientation" and "normal", and none seemed to do that.
Here's what it looks like without the proper orientation (i.e. the wrong behavior):
prime burrow
Does the cp already rotate with the model? I think there was an option for that (in lua)
Then is it a single particle? How does it currently work?
Does it spawn with an offset and is kept in place with lock to cp?
native nexus
it's a parent particle which follows CP0 position and orientation
attached with PATTACH_OVERHEAD_FOLLOW
I think it might simply not be sending any orientation information to the particle system
yeah, that's exactly it, PATTACH_ABSORIGIN_FOLLOW solves it by actually providing orientation to the particle
native nexus
Then is it a single particle? How does it currently work?
Does it spawn with an ...
correct, lock to CP on both translation and rotation
native nexus
it's a parent particle which follows CP0 position and orientation
child particle just follows parent
prime burrow
yeah, that's exactly it, PATTACH_ABSORIGIN_FOLLOW solves it by actually providin...
Does that already solve it?
Or is overhead essential
native nexus
It's not ideal, I wanted to use overhead's property of adjusting particle height based on hero size
but it's much better than nothing
prime burrow
You can also try to do something else
Provide the orientation as a new cp
Hmm, but I don't know if that actually works with follow ent... sending it on a loop doesnt seem practical. maybe scrap that thought
Should the particle actually be like close to the models head?
Because you could also provide the head attachment location as position
prime burrow
Ah true...
native nexus
I'm actually testing OVERHEAD's functionality now and... it's actually pretty minor. I can live without it
difference is like 20-30 units
It won't look as nice for some heroes, but that's acceptable
native nexus
yeah I thought it would make sure to always be above the model entirely, but that was just placebo
prime burrow
I think it looks fine 👌
native nexus
thanks for the help :]
prime burrow
Barely did anything, np :)
native nexus
oh
@prime burrow PATTACH_ABSORIGIN_FOLLOW locks into the origin of the model
how do I produce an offset that "spins" with model orientation?
example of undesired behavior:
this is using position modify offset random to set up the particle's offset from origin
prime burrow
Oh, I would solve it with a secondary CP.
native nexus
constrain distance to control point, with an offset and based off CP0, almost does it:
prime burrow
Constraint could also work, notice this:
native nexus
constraints are very expensive for computation
sadge
prime burrow
If there the are just few of them it's no problem tho
native nexus
it's really just 1
all I need is to adjust the golden model's yaw to be relative to CP0's normal instead of absolute
hmmmm
let's try your method first
prime burrow
Hope it works, can't test right now :/
meager trench
attached with PATTACH_OVERHEAD_FOLLOW
that's your problem
overhead follow doesn't use hero rotation
prime burrow
Ahh, the new cp does not have the right orientation
You can just set the orientation of the other cp to the same
prime burrow
overhead follow doesn't use hero rotation
We're past that and back to abs origin :)
meager trench
is the parent a blank particle?
you should not try to set rotation of the model itself directly, you should be setting the orientation of the parent
native nexus
is the parent a blank particle?
it is
meager trench
hey there ya go
prime burrow
Yay ^^
native nexus
[SOLVED] orient particle to hero forward direction?
meager trench
I assume you set the position initializer to the same rotation setting
native nexus
ya
prime burrow
It's just personal preference, but I really like solving stuff with pre emission 😅
meager trench
eh..
at that point it's not a matter of preference, it's about what can and can't be affected throughout the lifetime of the particle
sometimes pre-emission only works on the first tick or whatever
but that depends on the thing you're changing during pre-emission, so it's context-senstive
native nexus
this is now off-topic, but can I make the "wobble" from a distance constraint happen only on the xy plane?
meager trench
since distance constraint is a sphere, probably not, unless you can somehow scale the scphere's z to be 0
prime burrow
I mean on a permanent particle or on the root it's irrelevant and back to preference (I think)
meager trench
this would be super easy in any other engine 😅
native nexus
or add something like a linear distance from ground constraint
prime burrow
Expensive but you could add 2 more constraints as planes that limit the . Top and bottom
meager trench
you could also just code a custom delay yourself
idk it that's easier or not though
prime burrow
sometimes pre-emission only works on the first tick or whatever
Btw, don't most pre emission fire every tick if not "only once" or what it's called is ticked?
meager trench
I was under the impression that some do, some don't. depends on their function
native nexus
Expensive but you could add 2 more constraints as planes that limit the . Top an...
eh... a bit too wobbly still, I'll give up on that aspect specifically
prime burrow
Btw you're solving with constraint or second cp now?
native nexus
there is a spring constraint
FWIW, it ends up looking very similar to the distance constraint
prime burrow
The dampen movement to cp or whatever it's called
Operator
It somehow works after constraints
native nexus
hmm experimented with it a bit but not liking how it looks, will abandon the idea
thanks for all the help tho 
prime burrow
vague marten
I think your particle is like this, its normal wont rotate with cp rotation
I init normal once in initializer
