Space Ship Trails [NEW INFO ABOUT QUESTION]
Author
I have this space ship that should produce a trail behind it.
The trail is a single curve, a list of points. I don't want to insert a new point for each frame of the game, instead I want it to be something adaptive perhaps. Insert a point when it's needed kinda style. I think it has to do with the curvature of the path. But further than that, am blanked out.
Another subproblem is with the initial points of the curve, and when they should be placed. The first point of course is the initial position of the ship. But the placement of the second point could be very crucial to the points coming afterwards.
So far am considering some ad hoc methods that came to mind, like crossing previous segment with the current segment, and not inserting a point until a certain threshold, but perhaps there are constants to consider or something, so am still unsure. I don't want to try something that's gonna fail directly..
[Edited by - arithma on May 9, 2007 12:16:16 AM]
I would record the position of the ship every few ticks, and build my trail from that. It's probably not as expensive as you think.
You could have the ship drop particles after a certain amount of time. After X amount of time has expired create a new particle at the current position of the ship (or the position of it's engine). When the ship moves particles blend together to form a trail. You could use a fixed amount of particles so that when you run out of particles you kill the oldest particle (at the back of the trail) and place it at the front of the trail (at the engine/ship position).
One drawback to this approach however, is that if the ship moves very fast, then the particles become more spaced so they fail to blend and the trail looks choppy although you could have more particles emitted when the ship is moving fast than when it is moving slowly.
One drawback to this approach however, is that if the ship moves very fast, then the particles become more spaced so they fail to blend and the trail looks choppy although you could have more particles emitted when the ship is moving fast than when it is moving slowly.
Quote:Original post by geolycosa
I would record the position of the ship every few ticks, and build my trail from that. It's probably not as expensive as you think.
You're right about the method and the performance. I'm not so sure that 'every few ticks' is good advice.
I did something similar not too long ago, and was quite displeased with the idea of recording the positions of several entities at 30fps. But when I profiled it running for two minutes, it turned out to be the least of my worries.
You could compare the current position against the last recorded position, and use it only when a certain distance has been traversed, but this would be shifting the load from RAM-consumption (abundant) to CPU-time (far more valuable). Extending the method to form variable-length segments according to curvature, as clever as it may seem, is veritable frame-rate-icide.
If you consider that recording three floats thirty times per second takes 360 bytes per second (a second is quite a long time), there's really nothing to worry about. You could even up that to 60Hz if you like.
Admiral
I think we're talking about the same thing here. By 'every few ticks' I simply meant that you could save your position at a lower frequency than your frame rate if you were really concerned about ram usage.
Author
The thing is: the trail is a game element. I will have to do collision detection against every segment in the trail with a sphere.
In light of this new information, is this still premature optimization?
If the ship moves in a straight path for like a second, it would create a single segment instead of at least 30 segments (and at maximum 80 at the moment). I'd really prefer collision detection against the optimized version.
In light of this new information, is this still premature optimization?
If the ship moves in a straight path for like a second, it would create a single segment instead of at least 30 segments (and at maximum 80 at the moment). I'd really prefer collision detection against the optimized version.
You could use some sort of rubberband solution here.
Store segments in your list which contain the origin and the direction(needs to be normalized). The last segment in this list represents your moving object.
If the dot product of the directions of segment N and segment N-1 is not 1-threshold anymore, insert a new segment.
In the initial case you have two segments. The first segment is the initial pose of your object and the second is the current pose (identical of course in the beginning).
h.
Store segments in your list which contain the origin and the direction(needs to be normalized). The last segment in this list represents your moving object.
If the dot product of the directions of segment N and segment N-1 is not 1-threshold anymore, insert a new segment.
In the initial case you have two segments. The first segment is the initial pose of your object and the second is the current pose (identical of course in the beginning).
h.
Quote:Original post by arithma
The thing is: the trail is a game element. I will have to do collision detection against every segment in the trail with a sphere.
In light of this new information, is this still premature optimization?
If the ship moves in a straight path for like a second, it would create a single segment instead of at least 30 segments (and at maximum 80 at the moment). I'd really prefer collision detection against the optimized version.
In that case, maybe Not optimizing is a good thing.
If you do optimize, then the number of segments will be smaller for straighter paths. Won't this mean that when colliding with the trail, straighter paths will do less damage than curved ones? Having the brute force method of always adding a new point to the trail each frame also accounts for the trail density caused by ship speed.
Author
Quote:Original post by haphazardlynamedQuote:Original post by arithma
The thing is: the trail is a game element. I will have to do collision detection against every segment in the trail with a sphere.
In light of this new information, is this still premature optimization?
If the ship moves in a straight path for like a second, it would create a single segment instead of at least 30 segments (and at maximum 80 at the moment). I'd really prefer collision detection against the optimized version.
In that case, maybe Not optimizing is a good thing.
If you do optimize, then the number of segments will be smaller for straighter paths. Won't this mean that when colliding with the trail, straighter paths will do less damage than curved ones? Having the brute force method of always adding a new point to the trail each frame also accounts for the trail density caused by ship speed.
I know I haven't provided this info yet, but the trail will be instant kill (think TRON), so trail density isn't a real consideration. Still though, I believe recording ship velocity at key points can provide trail density in some kind of matter.
Am not gonna go brute force style because I believe it will be wasted effort and I'll eventually have to optimize, unless someone bashes otherwise into my skull.
The method I'll use is recording position and velocity of ship at each point.
If either distance or curvature exceeds a limit, a point will be created... For now, I'll implement distance. I still find the curvature thing a bit fuzzy even with hoLogramm's method.
Quote:Original post by arithma
Am not gonna go brute force style because I believe it will be wasted effort and I'll eventually have to optimize, unless someone bashes otherwise into my skull.
The method I'll use is recording position and velocity of ship at each point.
If either distance or curvature exceeds a limit, a point will be created... For now, I'll implement distance. I still find the curvature thing a bit fuzzy even with hoLogramm's method.
It is almost always easier to get something simple that works done first, then optimise that rather than going from scratch to a complete optimised version.
In your case it's easy - you can do your basic implementation with a shouldCreateNewPoint(oldPoint, newPosition) which returns true if some tolerance (curvature/distance) is exceeded. To start with you just stub the function out with something which always returns true. You can then implement all the other bits and have a brute force version working which has a new point every frame.
Then you can start worrying about the exact implementation of shouldCreateNewPoint() - a simple change would be every X frames rather than every frame, but you could start taking into account distance or curvature if you want. And you can do that safe in the knowledge that the rest of the implementation already works and is bug free.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
