Celestia Forums

To avoid this effect (see picture below) without setting 500 points in 0rbitPathSamplePoints (cfg), no way to write some kind of behavior to increase the number of points only in the zone of the curve being too accented?
It would be nice to use 100 points wisely instead of 100 points at equal distance...
Possible?

Or what about concentrating the points in the on screen part of the orbit?
With 30 points only a curve would looks quite nice almost all the time...

Since I know very well the maths of curves, I think this would be very hard to code. In the case of ellipses, there may be some simpler tricks, but I'm very sceptic. Of course, only the dev team could certify this.

...but the gain could be cool (or not?) in case of global view of hundreds of asteroids for example... (for 100 bodies, if only 30 points are used instead of the official 100, 3000 points total vs 10000...)

Personaly, I'm using a pretty high number of points for all my orbits. I never tested rigorously the impact on the frame rate, but since it appears to be relatively minor on my system, I did not worry about it.

From time to time I tend to write a post suggesting cubic splines for these problem zones...and then Chris L. tends to reply with arguments that I did not understand up to now

Bye Fridger

Cham wrote:Personaly, I'm using a pretty high number of points for all my orbits. I never tested rigorously the impact on the frame rate, but since it appears to be relatively minor on my system, I did not worry about it.

How much? because this is a 800 points orbit...



I remember asking for splines but I don't recall exactly why it wasn't possible (haven't search the thread )

If splines are a problem, the concentration of 30 points would result pretty neat even on the above image.

100 bodies 800 points = 80000 points vs 3000... I suppose it would do a difference

In my .cfg file, I'm using these parameters :

just tried out 1300 points (which don't solve completely the problem in the above view) and it definitively makes a huge difference on my system I cannot move anything with heavy catalogues!

(I was saying 30 points would be enough for an orbit in full view, I wasn't right, 70/80 are necessary to simulate a soft curve...)

t00fri wrote:From time to time I tend to write a post suggesting cubic splines for these problem zones...and then Chris L. tends to reply with arguments that I did not understand up to now

But how would you suggest we use splines? The answer would be obvious if graphics hardware could directly render splines, but current GPUs do not. The sample points for an orbit path are just calculated once, then reused every time the orbit is rendered. Rendering an orbit path is just a matter of sending the sample points to the graphics card. Calculating splines just adds an extra step: when rendering the orbit, the code would have to break the splines down into line segments first, then send them to the graphics hardware.

There are some things that can be done to increase the performance of orbit rendering so that we can just send more points. In addition, I think that the code for rendering elliptical orbits can be modified to use more sample points in regions of high curvature.

--Chris

chris wrote:...There are some things that can be done to increase the performance of orbit rendering so that we can just send more points. In addition, I think that the code for rendering elliptical orbits can be modified to use more sample points in regions of high curvature.

It's exactly what I was trying to express!

chris wrote:

t00fri wrote:From time to time I tend to write a post suggesting cubic splines for these problem zones...and then Chris L. tends to reply with arguments that I did not understand up to now

But how would you suggest we use splines? The answer would be obvious if graphics hardware could directly render splines, but current GPUs do not. The sample points for an orbit path are just calculated once, then reused every time the orbit is rendered. Rendering an orbit path is just a matter of sending the sample points to the graphics card. Calculating splines just adds an extra step: when rendering the orbit, the code would have to break the splines down into line segments first, then send them to the graphics hardware.

There are some things that can be done to increase the performance of orbit rendering so that we can just send more points. In addition, I think that the code for rendering elliptical orbits can be modified to use more sample points in regions of high curvature.

--Chris

How about "Non-Uniform Rational B-Splines" (NURBS) or perhaps simpler Bezier splines? I guess they can be rendered in OpenGL (NURBS renderer, evaluators).

Also couldn't we use a rough approximation to the gradient of the orbit as a measure for the required number of sample points. Small gradients <=> few sample point, big gradients more sample points...

Bye Fridger

t00fri wrote:

chris wrote:

t00fri wrote:From time to time I tend to write a post suggesting cubic splines for these problem zones...and then Chris L. tends to reply with arguments that I did not understand up to now

But how would you suggest we use splines? The answer would be obvious if graphics hardware could directly render splines, but current GPUs do not. The sample points for an orbit path are just calculated once, then reused every time the orbit is rendered. Rendering an orbit path is just a matter of sending the sample points to the graphics card. Calculating splines just adds an extra step: when rendering the orbit, the code would have to break the splines down into line segments first, then send them to the graphics hardware.

There are some things that can be done to increase the performance of orbit rendering so that we can just send more points. In addition, I think that the code for rendering elliptical orbits can be modified to use more sample points in regions of high curvature.

--Chris

How about "Non-Uniform Rational B-Splines" (NURBS) or perhaps simpler Bezier splines? I guess they can be rendered in OpenGL.

There are OpenGL functions to render various curves, but these functions just produce lists of line segments. It's faster just to precompute the line segments and skip the intermediate spline representation of the orbit path. Now, the spline representation can be more compact, but memory usage for orbit paths hasn't been a big problem so far.

Here are the things that I think need to be investigated:

- Increasing the number of sample points: speed up orbit rendering so that more sample points can be used without hurting performance. Orbits paths are currently rendered using OpenGL immediate mode functions, which are much slower than vertex arrays and vertex buffer objects.

- Better sampling of elliptical orbits, so that more sample points are used in regions of high curvature.

- Adaptive subdivision of orbit paths. Calculate and render extra samples when the observer is close to the path. The problem is that determining the distance from the observer to an arbitrary curve is rather tricky.

--Chris

Well using a solution or another, IMHO it's one of the stuff that should be fix before working on new features. It's a very old issue reported many times and one of the last bad point of Celestia... (and I don't see this in the roadmap...)

There's a similar thing that should be done for the comets. Their model is extremelly crude ! It should adapt it's shape with the scale (distance to the user), like what is already done for the planets.

Cham wrote:There's a similar thing that should be done for the comets. Their model is extremelly crude ! It should adapt it's shape with the scale (distance to the user), like what is already done for the planets.

Is there really an interest for comets? you can increase the number of point describing their geometry in render.cpp. I don't think it will represent a problem for FPS (not much comets can be rendered simultaneously)...

On the contrary. The impact on the frame rate is HUGE ! Just try it !

I've already done it before and the effect is striking.

Changing the number of points affects ALL comets at the same time, and it doesn't depends on the observer's distance.

Cham wrote:On the contrary. The impact on the frame rate is HUGE ! Just try it !

I've already done it before and the effect is striking.

Changing the number of point affetcs ALL comets at the same time, and it doen't depends on the observer's distance.

knowing you for sure you pass from 16 to 4096 points!

Well if the difference is so huge, definitively something should be done...

Even a change from 16 to 32 had a significant effect on the frame rate. And yet, I don't have that much comets installed !

A change from 16 to 24 just isn't worth it. It still very crude.

The bodies themselves ride their orbits in smoothly, without visible segmenting in their movements.

It's a rather large visible discrepancy; seeing a planet move through space at several times its own width removed from the drawn orbit curve, while the curve undulates from side to side as segments pass.

So can basic orbit data not be used to draw orbit curves as well?