The next step...

[Unfound]

Where will the announcment that version 1.0.4 has been released be posted?

[ajtribick]

More on the catalog handling side of things: it would be nice to be able to select which catalogue is used as the primary catalogue in the star browser, in previous versions it used HD and then fell back to HIP, now if a star doesn't have a name it uses HIP by default. Personally I prefer HD numbers (if only because the extrasolar planet lists typically use HD).

Also some more catalogues would be nice e.g. Gliese (there is a reference to this in celestia.cfg).

[suwalski]

This is unfortunately true even for recent OS X systems running Tiger 10.4.3. The GL 2.0 render path is now selectable in many cases, but the rendering may be incorrect. I've already filed a bug report with Apple.

Apple is totally ATI, right? I'm wondering what it looks like for your end of the ATI spectrum. For me, on a Radeon 9800, Earth looks something like this with the OpenGL 2.0 renderpath:

http://pat.suwalski.net/celestia/misc/o ... clouds.jpg

Is that what you get?

[dirkpitt]

This is unfortunately true even for recent OS X systems running Tiger 10.4.3. The GL 2.0 render path is now selectable in many cases, but the rendering may be incorrect. I've already filed a bug report with Apple.

Apple is totally ATI, right? I'm wondering what it looks like for your end of the ATI spectrum. For me, on a Radeon 9800, Earth looks something like this with the OpenGL 2.0 renderpath:

http://pat.suwalski.net/celestia/misc/o ... clouds.jpg

Is that what you get?

I would be happy if I got even that. julesstoop posted screenshots previously that illustrate how much worse it is on OS X: http://www.shatters.net/forum/viewtopic.php?p=63554#63554 Planets that do normal mapping are typically rendered in a butterfly-like pattern, with the planet alternately rendered light and dark in 1/4 portions.

[suwalski]

I would be happy if I got even that. julesstoop posted screenshots previously that illustrate how much worse it is on OS X: http://www.shatters.net/forum/viewtopic.php?p=63554#63554 Planets that do normal mapping are typically rendered in a butterfly-like pattern, with the planet alternately rendered light and dark in 1/4 portions.

Interesting!

I've had my fair share of OGL2 errors, mostly because of GLSL floating point numbers that were incompatible with ATI's stuff:

http://pat.suwalski.net/celestia/misc/ogl2-clouds.jpg
http://pat.suwalski.net/celestia/misc/olg2-noclouds.jpg
http://pat.suwalski.net/celestia/misc/w ... n-ogl2.jpg

That last one's really cool! But these have all been resolved now. The driver from around 2 months ago did what I linked to in my last post. The current one just *crashes*, but only when viewing Earth.

I'm currently working on this, and I've found that it has to do with specularity. The bright oceans in the last post are the colour of the specular highlight. Changing it to red confirms this. It seems to not like the intensity or something; the old version ignored this "bogus" value while the new one crashes on it. The temporary workaround is to disable Earth's specularity in the data file.

If I manage to find the problem, I'll definitely want my fix in 1.4.0. It's about time I did some work on the celengine.

[dirkpitt]

http://pat.suwalski.net/celestia/misc/ogl2-clouds.jpg
http://pat.suwalski.net/celestia/misc/olg2-noclouds.jpg
http://pat.suwalski.net/celestia/misc/w ... n-ogl2.jpg

That last one's really cool! But these have all been resolved now. The driver from around 2 months ago did what I linked to in my last post. The current one just *crashes*, but only when viewing Earth.

At least drivers are getting fixed on Windows. On OS X, driver development moves at a snail's pace. GLSL is still undocumented after almost 2 months following its release on OS X, save for a few mentions on the Apple mailing list about how Apple followed the specs to the letter, implying that there couldn't possibly be any problems with their implementation. This is wishful thinking of course, because there are bound to be incompatibilities with different hardware and workarounds needed. But I should really stop ranting.

[suwalski]

At least drivers are getting fixed on Windows.

Funny story, actually. The first two are from Linux, and the good guys at ATI release new drivers about twice per month. The Linux driver is actually generally ahead of the Windows driver, which is the cause of the third screenshot in Windows.

I always thought that ATI provided Apple with a binary for the driver, and that Apple just built on top of that. Is that not the case?

[dirkpitt]

At least drivers are getting fixed on Windows.

Funny story, actually. The first two are from Linux, and the good guys at ATI release new drivers about twice per month. The Linux driver is actually generally ahead of the Windows driver, which is the cause of the third screenshot in Windows.

I always thought that ATI provided Apple with a binary for the driver, and that Apple just built on top of that. Is that not the case?

That's sort of true. Apple back-contributes a lot of Apple-specific OpenGL code to ATI (and NVIDIA? probably) and it's my understanding that the chaps at ATI and NVIDIA have to incorporate or otherwise reference it when making their drivers. Whatever the Apple stuff is, it's a major bottleneck in the video driver development and release process so ATI+NVIDIA couldn't release driver updates twice a month even if they can for Linux. Usually, driver updates are included only with OS updates but very rarely, there have been known to be standalone driver updates.

[buggs_moran]

Well, I might've missed the boat on all of this feature request talk. Better late than never.

My three big ones are
1) cyclical parametric equation movement (i.e. follow a path over and over)
2) cyclical texture change (i.e. seasonal change, variable stars)
3) beginning and ending dates in stc files (or even better cyclic dates, again )

[Chuft-Captain]

The depth sorting bugs occuring with models having transparent parts MUST be corrected! In my opinion, this should be a priority.

There are TONS of special effects (on black holes, pulsars, nebulae, spacecrafts...) which cannot be done just because of this bug.


Also, visible orbits with all binaries (double star systems) should be implemented.

Hi, I'm not sure if this is the best place to ask this question, but I noticed all this discussion about problems with models having transparent parts. I'm working on just such a model at the moment and noticed some strange things happening with positioning of one of the objects. Probably not related, to the problem you're discussing but I'd appreciate any comments you may have.

A brief description and some more pics of the model are posted here:
http://celestiaproject.net/forum/viewtopic.php ... de069b3ef9

The problem is as follows:

To give a sense of scale, I have positioned Discovery close to my model as follows:


If I then change to another viewpoint on the inside of the habitat looking down from the hub (using a bookmark), I noticed that Discovery is now INSIDE the habitat.

The only transparent parts of the model are the windows (blue areas) and a textured cylindrical structure which you can barely see which is a bit of a kludge to depict floating clouds.

If I go closer to Discovery, I "discover" that it appears to be located at the rotation axis of the model.


Anyone know what's going on here? Is this related to the transparency bugs, or is it something else altogether?

[forceflow1049]

Probably not the best place for that question. It does look to be transparency related however. Not much i know of that you can do about.

[Tesserex]

Yeah hi I'm new.

Most of what I wanted was covered (precession, barycenter orbits), but there is one thing that kinda bothers me. It's that nothing about orbits is actually calculated by Kepler's laws (they don't seem to be). You should still be able to create totally unrealistic orbits if you want, but I feel like you should be limited to a certain number of parameters and then the rest are calculated so the orbit works, eg. you can only input a two out of the three semimajor axis, eccentricity, and period, and the third is calculated.

Also, when whoever it was said precession, were they talking about orbits, Earth's rotation, or both?

[t00fri]

Yeah hi I'm new.

...thing that kinda bothers me. It's that nothing about orbits is actually calculated by Kepler's laws (they don't seem to be).
..

I am not sure from reading your post whether you are lacking understanding or whether you expressed yourself unclearly.
In short: I don't understand what you are trying to say...

Your post sounds as if you knew how we calculate orbits. Right? And that this bothers you? Do you really know how we do it?

Do you know what the VSOP87 theory is? Keplerian orbits are FAR too inaccurate in most cases, hence VSOP87 is used as much as possible. Let me know whether you have some physics background. If yes, I can change gears and explain things more precisely

Bye Fridger