GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Particles to rotate in 3D space?

This effect is achievable by using a constrain attribute with some different values on every single particle.

for example:
constrain attribute self.position.X to 100*sin( game.Time *50)+selfX

If i'm using this method, and I want a 100 particles in the scene, this would be very cpu intensive because of all the contrains.
I don't really think there is another method since the particle behavior is very poor on it's features, but maybe someone knows a better way to archive this effect.

Thanks:)!

Comments

  • SocksSocks London, UK.Posts: 12,822Member
    edited February 2015

    @Approw said:
    This effect is achievable by using a constrain attribute with some different values on every single particle.

    You can't really do this with particles as once born into the world they have a fixed set of values - you can have the colour change through a particle's life and the the size, but these changes are linear and set at birth, they cannot dynamically change due to influences that happen after the particle is born.

    You would have to do this with separate actors, as the their paths need to have a constantly changing direction.

    @Approw said:
    for example:
    constrain attribute self.position.X to 100*sin( game.Time *50)+selfX

    That's not quite it, it should be something like this:

    constrain attribute self.position.X to (distance from the centre of the rotation)*sin( game.Time *50)+ centre of the rotation

    I'll give it a check in GameSalad in a minute.

    @Approw said:
    If i'm using this method, and I want a 100 particles in the scene, this would be very cpu intensive because of all the contrains.

    100 constrained actors should be fine, I've run much more than 100 without issue on a lowly iPad 1.

  • SocksSocks London, UK.Posts: 12,822Member
    edited February 2015

    Here's a rough demo of the idea: (file attached)

    It's probably best to spawn more on the outer edges of the rotating mass, to prevent a build up of objects in the middle.

  • ApprowApprow Posts: 703Member

    @Socks said:
    You can't really do this with particles as once born into the world they have a fixed set of values - you can have the colour change through a particles life and the the size, but these changes are set at birth, they cannot dynamically change due to influences that happen after the particle is born.

    You would have to do this with separate actors, as the their path need to have a constantly changing direction.

    Im talking about a single particle (actor), not the particle behavior.

    @Socks said:
    That's not quite it, it should be something like this:

    constrain attribute self.position.X to (distance from the centre of the rotation)*sin( game.Time *50)+ centre of the rotation

    Sounds interesting

    @Socks said:
    100 constrained actors should be fine, I've run much more than 100 without issue on a lowly iPad 1.

    hmmm, on the forums I keep reading about not using to many contrains. I should test it

  • ApprowApprow Posts: 703Member

    @Socks said:
    Here's a rough demo of the idea: (file attached)

    It's probably best to spawn more on the outer edges of the rotating mass, to prevent a build up of objects in the middle.

    You got to be kidding me, this is amazing! Thanks for sharing! This shouldn't be cpu intensive right?

  • SocksSocks London, UK.Posts: 12,822Member

    @Approw said:
    hmmm, on the forums I keep reading about not using to many contrains. I should test it

    Never test anything, always listen to the forums. :tongue: :wink:

  • SocksSocks London, UK.Posts: 12,822Member

    @Approw said:
    You got to be kidding me, this is amazing!

    I'm sure you can improve it a lot, a better distribution of the actors would help, they are clumped around the centre at the moment, maybe have two spawners (or two separate spawner behaviours in the spawner actor) - and spawn a bunch over on the left and a bunch over on the right leaving the middle area empty . . . also a slow moving background image of distance stars moving across the screen will help a lot.

    @Approw said:
    This shouldn't be cpu intensive right?

    Hold on, let me throw it onto an iPad3 (same processor speed as an iPad2).

  • -Timo--Timo- Posts: 2,313Member
    edited February 2015

    and @socks has beaten it again... but still want to share mine also :P (only stole the 45 turned idea)
    you can move the rectangle actor at the bottom to move the stars.

  • SocksSocks London, UK.Posts: 12,822Member

    @Socks said:
    Hold on, let me throw it onto an iPad3 (same processor speed as an iPad2).

    Just using the left / right movement (like in the video) you get 60fps with 100 actors.

    With all the extra constrains I threw in (height, width, alpha etc) 90 actors runs at 60fps, above 90 the frame rate starts to drop (100 actors = 50 fps).

  • ApprowApprow Posts: 703Member

    @Socks I did run a quick test to on multiple devices.

    100 stars +self size width/Height:

    Ipod Touch 4th gen: 27 FPS
    Ipad 2: 52 FPS
    Iphone 5S 60 FPS

    100 stars without self size width/Height:

    Ipod Touch 4th gen: 38 FPS
    Ipad 2: 60 FPS
    Iphone 5S 60 FPS

    50 stars +self size width/Height:

    Ipod Touch 4th gen: 60 FPS
    Ipad 2: 60 FPS
    Iphone 5S 60 FPS

    50 stars without self size width/Height:

    Ipod Touch 4th gen: 60 FPS
    Ipad 2: 60 FPS
    Iphone 5S 60 FPS

    I figured that 50 stars looks better in my project anyway. plus it has an overall better performance on lower end devices.

    @timolapre1998 That is awesome! I did not knew these things where possible. Thanks for sharing guys!

  • SocksSocks London, UK.Posts: 12,822Member

    @timolapre1998 said:

    @Approw said:

    Sticking a background image in really helps with the illusion - I've done this incredibly crudely, it's just a quickly taken screenshot of the random actors, but it gives you the basic idea.

    I've also split the spawner into two halves to avoid the build up of stars in the middle.

    It's all a mess, but you can see how it would work.

    File attached:

  • ApprowApprow Posts: 703Member

    @Socks I get what you're trying to archive, and It looks a little messy indeed. But I can see the potential here, I tried it with a 360 panorama, and it looks awesome:)! You can even layer the moving background to create more depth.

  • SocksSocks London, UK.Posts: 12,822Member

    @Approw said:
    Socks I get what you're trying to archive, and It looks a little messy indeed. But I can see the potential here, I tried it with a 360 panorama, and it looks awesome:)! You can even layer the moving background to create more depth.

    You could also break up the linear left to right feel with a little subtle camera float . . . example attached is not very subtle ! But it gives you the basic idea.

  • ApprowApprow Posts: 703Member

    @Socks absolutely wonderful:)! the camera float gives it even more sense of depth.

    Right now I'm trying to put an object in the middle of the rotation.

    Particle 1=top layer
    Particle 2 = back layer

    If I spawn particle 2 below particle 1, how can particle 1 determine to change its opacity to 0 when it's close to the object?

  • SocksSocks London, UK.Posts: 12,822Member
    edited February 2015

    @Approw said:
    Particle 1=top layer
    Particle 2 = back layer

    If I spawn particle 2 below particle 1, how can particle 1 determine to change its opacity to 0 when it's close to the object?

    That seems like a non sequitur to me ? I don't know what it means, it seems to be saying that you have objects on two layers - and one layer needs to become invisible when it is near an object, I'm not sure how the the ideas are related.

    You can take a sine wave, clip the top and bottom of it off, and then move it up (or down) to recover one peak, so you have a sine wave with one extent (top or bottom) chopped off, you could then use this to make an object disappear only on one side of its orbit. Does that make any sense, it certainly doesn't sound like it does, let me try and make a quick example . . . .

    EDIT: (actually you don't need to recover a peak, you can cut both off)

  • SocksSocks London, UK.Posts: 12,822Member
    edited February 2015

    Example attached.

  • ApprowApprow Posts: 703Member

    @Socks I do understand it, sort of... I'm using custom time for the particles so i'm able to trigger the rotation. How did you come to the number 1000? I cant find the right values.

  • SocksSocks London, UK.Posts: 12,822Member
    edited February 2015

    @Approw said:
    I'm using custom time for the particles so i'm able to trigger the rotation. How did you come to the number 1000?

    I just chose a preposterously high number - the 1000 value is not related to the angle of rotation, so has nothing to do with your custom timer, the timer drives the angle, the angle is inside the brackets . . . . the 1000 value is just a multiplier, it gives you a super steep sine wave, which means rather than the opacity slowly fading from 1 to 0 to 1 to 0 to 1 . . . it instead cuts in and out suddenly.

    I'm not sure what you are showing me those rules, did you have a question ?

    Also, it's not clear why you would need (custom time + self speed ?) for the angle, why not just a single value ?

  • ApprowApprow Posts: 703Member

    @Socks Ah that was stupid of me, I can just use the custom timer (or speed) with a greater value:D There is a question indeed, how do I constrain your alpha method within the 3d spinning particles. I tried a couple of things, but i cant get it in sync with the actual rotation of the particles.

  • SocksSocks London, UK.Posts: 12,822Member

    @Approw said:
    There is a question indeed, how do I constrain your alpha method within the 3d spinning particles. I tried a couple of things, but i cant get it in sync with the actual rotation of the particles.

    Not sure without talking a look (a bit busy right now), there are numerous ways to cut an image in and out, the previous example just has the alpha channel switch to 0 during a certain range of angles, but you could use a rule like 'when the angle is bigger than 0 but smaller than 180 then make the alpha 0, otherwise make it 1, that's basically what this [1000 *sin( game.Time * 100)+0.5] is doing.

  • ApprowApprow Posts: 703Member

    I will have a look at it again tomorrow. I'm not able to make it work right now

Sign In or Register to comment.