Thread: [Celestia-developers] glext.h / extern "C"
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Bob I. <bo...@re...> - 2002-12-08 01:18:53
|
I'm not sure if this is true for other platforms, but g++3.1 on MacOS X 10.2.x doesn't like the fact that namespaces are inside an extern "C" { } in glext.h (latest CVS).. it seems that somewhere along the line, the extern "C" causes it to ignore the fact that it's a namespace, and look for the symbols as _symbolName instead of however they'd normally be mangled for C++. This breaks the linking phase. However, if you take the extern "C" {} out, it works just fine.. It shouldn't really be there anyways, given that it's not going to compile in C b/c of the namespace syntax. -bob |
From: Christophe T. <ch...@te...> - 2002-12-08 19:07:17
|
On Sunday 08 December 2002 02:18, Bob Ippolito wrote: > I'm not sure if this is true for other platforms, but g++3.1 on MacOS X > 10.2.x doesn't like the fact that namespaces are inside an extern "C" { > } in glext.h (latest CVS).. it seems that somewhere along the line, the > extern "C" causes it to ignore the fact that it's a namespace, and look > for the symbols as _symbolName instead of however they'd normally be > mangled for C++. This breaks the linking phase. > > However, if you take the extern "C" {} out, it works just fine.. It > shouldn't really be there anyways, given that it's not going to compile > in C b/c of the namespace syntax. Indeed, removing the extern "C" from glext.h fixes the crash for me, celestia doesn't crash when starting and I can visit Mercury without any problem. Thanks for the tip Bob! Does it fix it for you too Fridger? -- Christophe |
From: Chris L. <cl...@ww...> - 2002-12-08 19:40:21
|
On Sun, 8 Dec 2002, Christophe Teyssier wrote: > On Sunday 08 December 2002 02:18, Bob Ippolito wrote: > > I'm not sure if this is true for other platforms, but g++3.1 on MacOS X > > 10.2.x doesn't like the fact that namespaces are inside an extern "C" { > > } in glext.h (latest CVS).. it seems that somewhere along the line, the > > extern "C" causes it to ignore the fact that it's a namespace, and look > > for the symbols as _symbolName instead of however they'd normally be > > mangled for C++. This breaks the linking phase. > > > > However, if you take the extern "C" {} out, it works just fine.. It > > shouldn't really be there anyways, given that it's not going to compile > > in C b/c of the namespace syntax. > > Indeed, removing the extern "C" from glext.h fixes the crash for me, celestia > doesn't crash when starting and I can visit Mercury without any problem. Great! Nice work Bob . . . And sloppy work on my part--I should have caught this. Bob, did you run into any other problems with the move from EXTfuncName to glx::funcName?? --Chris |
From: Bob I. <bo...@ma...> - 2002-12-08 21:35:56
|
On Sunday, Dec 8, 2002, at 15:31 America/New_York, Chris Laurel wrote: > On Sun, 8 Dec 2002, Christophe Teyssier wrote: > >> On Sunday 08 December 2002 02:18, Bob Ippolito wrote: >>> I'm not sure if this is true for other platforms, but g++3.1 on >>> MacOS X >>> 10.2.x doesn't like the fact that namespaces are inside an extern >>> "C" { >>> } in glext.h (latest CVS).. it seems that somewhere along the line, >>> the >>> extern "C" causes it to ignore the fact that it's a namespace, and >>> look >>> for the symbols as _symbolName instead of however they'd normally be >>> mangled for C++. This breaks the linking phase. >>> >>> However, if you take the extern "C" {} out, it works just fine.. It >>> shouldn't really be there anyways, given that it's not going to >>> compile >>> in C b/c of the namespace syntax. >> >> Indeed, removing the extern "C" from glext.h fixes the crash for me, >> celestia >> doesn't crash when starting and I can visit Mercury without any >> problem. > > Great! Nice work Bob . . . And sloppy work on my part--I should have > caught this. > > Bob, did you run into any other problems with the move from > EXTfuncName to > glx::funcName?? Well, it doesn't look like there's any other issues relating to that.. However, when I was playing with it yesterday, it didn't seem to be loading fonts or the databases correctly (so I don't see any text or planets).. I made one change to CelestiaCore::initRenderer() to get rid of a crash relating to the fonts not loading properly: it should be: if (font == NULL) cout << "Error loading font; text will not be visible.\n"; else font->buildTexture(); before, it was (I think, this is from memory): if (font == NULL) { cout << "Error loading font; text will not be visible.\n"; } font->buildTexture(); I haven't really started to debug the databases stuff, but I couldn't figure out why the fonts aren't loading, but tracked it down to the in.read().. I opened up the files w/ python and wrote a little script to verify their integrity and I couldn't figure out why celestia was having a problem with them.. they looked completely fine, I checked the read pointers and they were all in the right place before the read, and -1 afterwards. Is it possible that the apple/g++3.1 implementation marks in.fail() if you read all the bytes in an ifstream without going over? .. the kind of error messages I'm getting are: ... Parent body 'TYC 5503-946-1' of 'b' not found. Reading planet Sol/Earth/Moon Apollo 11 Parent body 'Sol/Earth/Moon' of 'Apollo 11' not found. Reading planet Sol Hale-Bopp Parent body 'Sol' of 'Hale-Bopp' not found. Reading planet Sol/Jupiter Metis Parent body 'Sol/Jupiter' of 'Metis' not found. Reading planet Sol/Jupiter Adrastea Parent body 'Sol/Jupiter' of 'Adrastea' not found. .... Font contains 85 glyphs. Reading 256 x 256 1-bit font image. Missing bitmap data in font stream. Error loading font; text will not be visible. Font contains 91 glyphs. Reading 256 x 128 8-bit font image. Missing bitmap data in font stream. Font contains 85 glyphs. Reading 256 x 256 1-bit font image. Missing bitmap data in font stream. -bob |
From: Fridger S. <t0...@ma...> - 2002-12-08 20:02:52
|
Christophe Teyssier wrote: > > On Sunday 08 December 2002 02:18, Bob Ippolito wrote: > > I'm not sure if this is true for other platforms, but g++3.1 on MacOS X > > 10.2.x doesn't like the fact that namespaces are inside an extern "C" { > > } in glext.h (latest CVS).. it seems that somewhere along the line, the > > extern "C" causes it to ignore the fact that it's a namespace, and look > > for the symbols as _symbolName instead of however they'd normally be > > mangled for C++. This breaks the linking phase. > > > > However, if you take the extern "C" {} out, it works just fine.. It > > shouldn't really be there anyways, given that it's not going to compile > > in C b/c of the namespace syntax. > > Indeed, removing the extern "C" from glext.h fixes the crash for me, celestia > doesn't crash when starting and I can visit Mercury without any problem. > > Thanks for the tip Bob! > > Does it fix it for you too Fridger? > > -- > Christophe > Great, no crashes anymore!!! So, Christophe, why don't you commit your code, then i'll follow... I have been packaging textures over the weekend...also trying to adjust Jupiter's red spot etc. What again was the light time delay w.r.to Jupi? 19 minutes, right? Please remember, the awkward "freeze" stuff under Linux;-) Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-09 20:58:09
|
On Sunday 08 December 2002 20:59, Fridger Schrempp wrote: > So, Christophe, why don't you commit your code, then i'll follow... Done! I've also corrected glext.h Sadly I've just noticed that there are still problems with the Celestial Browser. If you go to Proxima, it will still appear to be more than 4 ly away in the 'Nearest' list. It looks like the star and observer coordinates are not in the same frame of reference... Otherwise your automag patch works fine here. -- Christophe |
From: Fridger S. <t0...@ma...> - 2002-12-09 21:33:32
|
That's what I get from your latest commit about hallf an hour ago: ------------------------------------------------------------------ kdeapp.cpp: In function `static void KdeApp::popupMenu(float, float, Selection)': kdeapp.cpp:955: no matching function for call to `QLabel::QLabel (string, KPopupMenu *)' /usr/lib/qt3/include/qlabel.h:61: candidates are: QLabel::QLabel(QWidget *, const char * = 0, unsigned int = 0) /usr/lib/qt3/include/qlabel.h:63: QLabel::QLabel(const QString &, QWidget *, const char * = 0, unsigned int = 0) /usr/lib/qt3/include/qlabel.h:65: QLabel::QLabel(QWidget *, const QString &, QWidget *, const char * = 0, unsigned int = 0) /usr/lib/qt3/include/qlabel.h:160: QLabel::QLabel(const QLabel &) make[5]: *** [kdeapp.o] Error 1 rm celestialbrowserbase.uic.h make[5]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' make[3]: *** [all-recursive] Error 1 Bye Fridger |
From: Chris L. <cl...@ww...> - 2002-12-09 23:15:43
|
On Mon, 9 Dec 2002, Christophe Teyssier wrote: > On Sunday 08 December 2002 20:59, Fridger Schrempp wrote: > > So, Christophe, why don't you commit your code, then i'll follow... > > Done! I've also corrected glext.h > > Sadly I've just noticed that there are still problems with the Celestial > Browser. If you go to Proxima, it will still appear to be more than 4 ly away > in the 'Nearest' list. It looks like the star and observer coordinates are > not in the same frame of reference... The observer position is in units of microlight years, but the star positions are stored in light years. That's likely the source of the problem. Observer position used to be in light years also, but I was running into precision limitations in the the 64.64 fixed point numbers. In retrospect, it may have been a better idea to just move to 48.80 fixed point instead of a new base unit. --Chris |
From: Christophe T. <ch...@te...> - 2002-12-10 20:41:04
|
On Tuesday 10 December 2002 01:06, Chris Laurel wrote: > The observer position is in units of microlight years, but the star > positions are stored in light years. That's likely the source of the > problem. Observer position used to be in light years also, but I was > running into precision limitations in the the 64.64 fixed point numbers. > In retrospect, it may have been a better idea to just move to 48.80 fixed > point instead of a new base unit. That's the correction I made to get something that 'looks' right, but is still obviously wrong. Here is how the distance is currently calculated : UniversalCoord ucPos = appSim->getObserver().getPosition(); Point3f obsPos( (double)ucPos.x * 1e-6, (double)ucPos.x * 1e-6, (double)ucPos.x * 1e-6); Point3f starPos = star->getPosition(); Vec3d v(starPos.x - obsPos.x, starPos.y - obsPos.y, starPos.z - obsPos.z); double distance = v.length(); So, what am I missing here? -- Christophe |
From: Christophe T. <ch...@te...> - 2002-12-10 21:20:16
|
On Tuesday 10 December 2002 21:40, Christophe Teyssier wrote: > UniversalCoord ucPos = appSim->getObserver().getPosition(); > Point3f obsPos( (double)ucPos.x * 1e-6, > (double)ucPos.x * 1e-6, > (double)ucPos.x * 1e-6); Funny how you can go over and over again the same piece of code and not see something that obvious. The fix is in. -- Christophe |
From: Chris L. <cl...@ww...> - 2002-12-10 22:00:45
|
On Tue, 10 Dec 2002, Christophe Teyssier wrote: > On Tuesday 10 December 2002 21:40, Christophe Teyssier wrote: > > UniversalCoord ucPos = appSim->getObserver().getPosition(); > > Point3f obsPos( (double)ucPos.x * 1e-6, > > (double)ucPos.x * 1e-6, > > (double)ucPos.x * 1e-6); > > Funny how you can go over and over again the same piece of code and not see > something that obvious. Even after you pointed out that the bug was in that statement, I had trouble seeing it :> --Chris |
From: Fridger S. <t0...@ma...> - 2002-12-11 19:49:36
|
I have commited code to allow changing the limiting magnitude at standard FoV (45deg) by means of the [,] keys, if AutoMag=ON. The default value (8.5m) may be set via a new script command. ------------------------------------ In more detail: 1) If AuotoMag=ON: the [,] keys adjust the /limiting magnitude at StdFOV=45deg/, with actual value being displayed via flash messages. This parameter is crucial for the appearance of the Automag scheme for different FOV's. It's default value is preset to 8.5m. 2) This default value may be changed by means of a new script command: setfaintestautomag45deg {magnitude float} in the start.cel script, for example. Chris suggested to do the external setting via the script rather than via celestia.cfg, as I had it at first. 2) If AutoMag=OFF: the [,] adjust the usual FOV-independent limiting magnitude instead. 3) If one switches from Automag=OFF back to Automag=ON, the last value for the limiting magnitude at StdFOV=45deg is used. Affected files: render.cpp, render.h, celestiacore.cpp, cmdparser.cpp, command.cpp, command.h Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-09 21:41:30
|
Another QT3.0/3.1 bug. 3.1 accepts std::string in place of QString, 3.0 does not. That's fixed. On Monday 09 December 2002 22:30, Fridger Schrempp wrote: > That's what I get from your latest commit about hallf an hour ago: > ------------------------------------------------------------------ > > kdeapp.cpp: In function `static void KdeApp::popupMenu(float, float, > Selection)': > kdeapp.cpp:955: no matching function for call to `QLabel::QLabel (string, > KPopupMenu *)' > /usr/lib/qt3/include/qlabel.h:61: candidates are: QLabel::QLabel(QWidget *, > const char * = 0, unsigned int = 0) > /usr/lib/qt3/include/qlabel.h:63: QLabel::QLabel(const > QString &, QWidget *, const char * = 0, unsigned int = 0) > /usr/lib/qt3/include/qlabel.h:65: QLabel::QLabel(QWidget *, > const QString &, QWidget *, const char * = 0, unsigned int = 0) > /usr/lib/qt3/include/qlabel.h:160: QLabel::QLabel(const > QLabel &) > make[5]: *** [kdeapp.o] Error 1 > rm celestialbrowserbase.uic.h > make[5]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' > make[3]: *** [all-recursive] Error 1 > > > Bye Fridger > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <t0...@ma...> - 2002-12-09 21:48:12
|
Christophe Teyssier wrote: > > Another QT3.0/3.1 bug. 3.1 accepts std::string in place of QString, 3.0 does > not. > > That's fixed. > Great! Did you actually have a chance to test the AutoMag patch that I send you some time ago? I want to commit it... Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-09 22:07:16
|
On Monday 09 December 2002 22:45, Fridger Schrempp wrote: > Christophe Teyssier wrote: > > Another QT3.0/3.1 bug. 3.1 accepts std::string in place of QString, 3.0 > > does not. > > > > That's fixed. > > Great! > > Did you actually have a chance to test the AutoMag patch that I send you > some time ago? I want to commit it... Yes, I told you so in my previous message. I've had no problem with it, very useful too! -- Christophe |
From: Fridger S. <t0...@ma...> - 2002-12-09 21:53:25
|
Still dieing: ------------- kdeapp.cpp: In function `static void KdeApp::popupMenu(float, float, Selection)': kdeapp.cpp:955: no matching function for call to `QString::QString (string)' /usr/lib/qt3/include/qstring.h:716: candidates are: QString::QString() /usr/lib/qt3/include/qstring.h:384: QString::QString(QChar) /usr/lib/qt3/include/qstring.h:385: QString::QString(const QString &) /usr/lib/qt3/include/qstring.h:386: QString::QString(const QByteArray &) /usr/lib/qt3/include/qstring.h:387: QString::QString(const QChar *, unsigned int) /usr/lib/qt3/include/qstring.h:389: QString::QString(const char *) /usr/lib/qt3/include/qstring.h:609: QString::QString(int, bool) /usr/lib/qt3/include/qstring.h:628: QString::QString(QStringData *, bool) make[5]: *** [kdeapp.o] Error 1 rm celestialbrowserbase.uic.h make[5]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/cvs/celestia/src/celestia' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/cvs/celestia/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/cvs/celestia' make: *** [all] Error 2 Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-09 22:04:45
|
Arg! I should really test all my changes on KDE 3.0, I usualy do that at work but I took the day off... Fixed for good this time, I hope. On Monday 09 December 2002 22:50, Fridger Schrempp wrote: > Still dieing: > ------------- > > kdeapp.cpp: In function `static void KdeApp::popupMenu(float, float, > Selection)': > kdeapp.cpp:955: no matching function for call to `QString::QString > (string)' /usr/lib/qt3/include/qstring.h:716: candidates are: > QString::QString() /usr/lib/qt3/include/qstring.h:384: > QString::QString(QChar) /usr/lib/qt3/include/qstring.h:385: > QString::QString(const QString &) > /usr/lib/qt3/include/qstring.h:386: QString::QString(const > QByteArray &) > /usr/lib/qt3/include/qstring.h:387: QString::QString(const > QChar *, unsigned int) > /usr/lib/qt3/include/qstring.h:389: QString::QString(const > char *) > /usr/lib/qt3/include/qstring.h:609: QString::QString(int, > bool) /usr/lib/qt3/include/qstring.h:628: > QString::QString(QStringData *, bool) > make[5]: *** [kdeapp.o] Error 1 > rm celestialbrowserbase.uic.h > make[5]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/usr/local/cvs/celestia/src/celestia/kde' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/local/cvs/celestia/src/celestia' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/cvs/celestia/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/cvs/celestia' > make: *** [all] Error 2 > > Bye Fridger |
From: Fridger S. <t0...@ma...> - 2002-12-09 23:08:52
|
Christophe Teyssier wrote: > > Arg! I should really test all my changes on KDE 3.0, I usualy do that at work > but I took the day off... > > Fixed for good this time, I hope. > Yes, indeed, everything is working fine now. It's about time to state (again) that I am extremely happy with your KDE interface! My occasional critics is merely meant to serve a constructive purpose;-)...Notably the browser arrangement is looking very handsome now as well as a lot of little changes here and there...(like the neat little popups with info etc). It's really fun sorting these things out in close interaction... Bye Fridger PS: There are still 2 buggies I am chasing right now: 1) Under small FOV (arc seconds), rotating objects with Mouse3 makes them vanish right away. There is somewhere a rotation angle that is missing a factor propto FOV! No big deal, but awkward...I thought that I had added corrections for FOV everywhere, but... 2) After KDE-bookmarking an object under small FOV, the 'I' key (clouds ON|OFF) does not work properly. The image becomes dark and that's it... Looking into the code... Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-10 20:23:12
|
On Tuesday 10 December 2002 00:05, Fridger Schrempp wrote: > Christophe Teyssier wrote: > It's about time to state (again) that I am extremely happy with your KDE > interface! My occasional critics is merely meant to serve a constructive > purpose;-)...Notably the browser arrangement is looking very handsome now > as well as a lot of little changes here and there...(like the neat little > popups with info etc). Thanks, it's nice to see that at least someone likes it! > It's really fun sorting these things out in close interaction... Yes, we're not done yet, there're many things left to be done. > 1) Under small FOV (arc seconds), rotating objects with Mouse3 makes them > vanish right away. There is somewhere a rotation angle that is missing a > factor propto FOV! No big deal, but awkward...I thought that I had added > corrections for FOV everywhere, but... I can't reproduce that behaviour, on what object do you see it? Under small FOV I do get some strange artefacts, on the Earth if the cloud layer is displayed I get the same kind of problems as on eclipse shadows, and on bodies with an atmosphere, the atmosphere is off centered (quite odd). > 2) After KDE-bookmarking an object under small FOV, the 'I' key (clouds > ON|OFF) does not work properly. The image becomes dark and that's it... I can't reproduce that either, how do you bookmark it, using the menu or a [user defined] shortcut? -- Christophe |
From: Fridger S. <t0...@ma...> - 2002-12-11 22:14:41
|
Christophe Teyssier wrote: > > > 1) Under small FOV (arc seconds), rotating objects with Mouse3 makes them > > vanish right away. There is somewhere a rotation angle that is missing a > > factor propto FOV! No big deal, but awkward...I thought that I had added > > corrections for FOV everywhere, but... > > I can't reproduce that behaviour, on what object do you see it? > Under small FOV I do get some strange artefacts, on the Earth if the cloud > layer is displayed I get the same kind of problems as on eclipse shadows, > and on bodies with an atmosphere, the atmosphere is off centered (quite odd). OK, here you go: cel://Follow/Sol:Earth/2002-12-08T06:33:09.20?x=4abL+eD6kXLBDA&y=49tXSLnxHw&z=Qzi5ndEU1uXw/////////w&ow=0.913375&ox=-0.006264&oy=-0.407071&oz=0.000564&select=Sol:Jupiter&fov=0.019509&ts=1.000000&rf=54403&lm=0 Once Jupi is centered under a small FoV, push mouse3 and try to rotate it slightly. Jupi is gone after the slightest movement...It's so easy to reproduce;-). What's the problem? > > 2) After KDE-bookmarking an object under small FOV, the 'I' key (clouds > > ON|OFF) does not work properly. The image becomes dark and that's it... > > I can't reproduce that either, how do you bookmark it, using the menu or a > [user defined] shortcut? > Use the above cel: and push 'I' ON|OFF you may also push CTRL p for further odd effects... Bye Fridger |
From: Christophe T. <ch...@te...> - 2002-12-11 22:40:13
|
On Wednesday 11 December 2002 23:10, Fridger Schrempp wrote: > OK, here you go: > > cel://Follow/Sol:Earth/2002-12-08T06:33:09.20?x=4abL+eD6kXLBDA&y=49tXSLnxHw >&z=Qzi5ndEU1uXw/////////w&ow=0.913375&ox=-0.006264&oy=-0.407071&oz=0.000564& >select=Sol:Jupiter&fov=0.019509&ts=1.000000&rf=54403&lm=0 > > Once Jupi is centered under a small FoV, push mouse3 and try to rotate it > slightly. Jupi is gone after the slightest movement...It's so easy to > reproduce;-). What's the problem? It looks like normal behaviour to me : Follow/Sol:Earth, you're rotating around the Earth, not around Jupiter, press 'F' and everything works! > > > 2) After KDE-bookmarking an object under small FOV, the 'I' key (clouds > > > ON|OFF) does not work properly. The image becomes dark and that's > > > it... > > I can't reproduce that either, how do you bookmark it, using the menu or > > a [user defined] shortcut? > > Use the above cel: and push 'I' ON|OFF you may also push CTRL p for further > odd effects... You're on the surface of the Earth, if you turn cloud rendering on it is to be expected for your view of the sky to be obscured. For the Pixel Shader I think it's simply the haze effect (?) -- Christophe |
From: Fridger S. <t0...@ma...> - 2002-12-11 23:16:45
|
Christophe Teyssier wrote: > > On Wednesday 11 December 2002 23:10, Fridger Schrempp wrote: > > OK, here you go: > > > > cel://Follow/Sol:Earth/2002-12-08T06:33:09.20?x=4abL+eD6kXLBDA&y=49tXSLnxHw > >&z=Qzi5ndEU1uXw/////////w&ow=0.913375&ox=-0.006264&oy=-0.407071&oz=0.000564& > >select=Sol:Jupiter&fov=0.019509&ts=1.000000&rf=54403&lm=0 > > > > Once Jupi is centered under a small FoV, push mouse3 and try to rotate it > > slightly. Jupi is gone after the slightest movement...It's so easy to > > reproduce;-). What's the problem? > > It looks like normal behaviour to me : Follow/Sol:Earth, you're rotating > around the Earth, not around Jupiter, press 'F' and everything works! > > > > > 2) After KDE-bookmarking an object under small FOV, the 'I' key (clouds > > > > ON|OFF) does not work properly. The image becomes dark and that's > > > > it... > > > I can't reproduce that either, how do you bookmark it, using the menu or > > > a [user defined] shortcut? > > > > Use the above cel: and push 'I' ON|OFF you may also push CTRL p for further > > odd effects... > > You're on the surface of the Earth, if you turn cloud rendering on it is to be > expected for your view of the sky to be obscured. > > For the Pixel Shader I think it's simply the haze effect (?) > Great! You are of course right. Thanks;-) Bye Fridger |
From: Fridger S. <t0...@ma...> - 2002-12-11 22:20:41
|
Thanks for the NVIDIA-driver news. The persistent freeze seems to be a task for Chris.;-) One of his colleagues at NVIDIA should at least know why they do nothing about it... Bye Fridger |
From: Chris L. <cl...@ww...> - 2002-12-12 16:49:09
|
On Wed, 11 Dec 2002, Fridger Schrempp wrote: > Thanks for the NVIDIA-driver news. The persistent freeze seems to be a task for > Chris.;-) One of his colleagues at NVIDIA should at least know why they do > nothing about it... I'll try and find out from one of them today why the driver is behaving so poorly in this circumstance. Meanwhile, I've been working on getting the positions of the Galilean satellites right. It's still not possible to see the mutual phenomena of the satellites, and I'm fairly certain now that it's because I'm using calculations referred to the B1950 equator of Jupiter. So what does everyone thing about releasing 1.2.5? I think we're ready . . . or does the freezing issue really need to get fixed first? --Chris |
From: Christophe T. <ch...@te...> - 2002-12-12 18:46:41
|
On Thursday 12 December 2002 18:37, Chris Laurel wrote: > On Wed, 11 Dec 2002, Fridger Schrempp wrote: > > Thanks for the NVIDIA-driver news. The persistent freeze seems to be a > > task for Chris.;-) One of his colleagues at NVIDIA should at least know > > why they do nothing about it... > > I'll try and find out from one of them today why the driver is behaving so > poorly in this circumstance. Could that be related to AGP? Apparently the AGP module provided with the driver yields better performance than the kernel agpgart module which is used by default, I'll give it a try today. > Meanwhile, I've been working on getting the positions of the Galilean > satellites right. It's still not possible to see the mutual phenomena of > the satellites, and I'm fairly certain now that it's because I'm using > calculations referred to the B1950 equator of Jupiter. > > So what does everyone thing about releasing 1.2.5? I think we're ready . > . . or does the freezing issue really need to get fixed first? Here is my current bug list: 1 - Eclipse shadows on atmosphere or cloud layer show moving artefacts cel://Follow/Sol:Earth/2002-12-04T07:19:23.06?x=0APkfk92dYDCDA&y=+9GqdsdJJA&z=9YezlefcyDHx/////////w&ow=0.978316&ox=0.150961&oy=0.106951&oz=-0.093109&select=Sol:Earth&fov=45.000000&ts=1.000000&rf=6035&lm=0 2 - Star Flares or Atmospheres off centered at small FOV (except for the Earth) cel://Follow/Sol/2002-12-04T07:20:31.73?x=AACA72iKV3I3GQ&y=CkzQN2tKQ9Jk/////////w&z=VcrQimXV0oK38P///////w&ow=-0.331123&ox=-0.113508&oy=0.935023&oz=-0.056619&select=Sol&fov=0.009317&ts=1.000000&rf=6035&lm=0 3 - Same artefacts as per 1 appearing all over the Earth at small FOV cel://Follow/Sol:Earth/2002-12-04T09:26:27.63?x=AGC3esBo9NHADA&y=6nX88GiwSlAF&z=VcoqXBhlCqQ&ow=0.972462&ox=0.153882&oy=0.076814&oz=0.157279&select=Sol:Earth&fov=0.009317&ts=1.000000&rf=6035&lm=0 4 - Eclipse shadows visible on dark side cel://Follow/Sol:Jupiter/2002-12-04T09:20:28.74?x=4Jl7ILVFrOGJDA&y=qifd1KuNd+I&z=RbL/6qGNM1S+/////////w&ow=0.446501&ox=0.101247&oy=-0.883035&oz=0.103127&select=Sol:Jupiter&fov=45.000000&ts=1.000000&rf=6035&lm=0 The first one is certainly the most visible and annoying of all. If it could be solved before release that'd be nice, but it's not really a show stopper. -- Christophe |