Thread: [Celestia-developers] XYZ clipping bug?
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Grant H. <gra...@bl...> - 2004-06-12 12:13:01
|
I've just built an xyz for NEAR-Shoemaker's orbits around Eros - Selden is kindly hosting it at http://www.lns.cornell.edu/~seb/celestia/hutchison/near-orbit.html. With spacecraft orbits turned on the orbits are visible from afar but disappear as you move closer to Eros, undergoing what looks like some sort of clipping effect during the approach. Grant |
From: Fridger S. <fri...@de...> - 2004-06-12 13:37:05
|
I think , I have reported this issue in another manifestation already long ago. >> 2) After switching on the 'partialtrajectories' flag in the >> start.cel script, the partial orbit rendering is fine when e.g. >> Cassini is sufficiently far away from the observer. After zooming in >> more, the orbit rendering vanishes suddenly... Bye, Fridger > But nobody seemed to take notice. Bye Fridger Grant Hutchison wrote: >I've just built an xyz for NEAR-Shoemaker's orbits around Eros - Selden is >kindly hosting it at >http://www.lns.cornell.edu/~seb/celestia/hutchison/near-orbit.html. With >spacecraft orbits turned on the orbits are visible from afar but disappear >as you move closer to Eros, undergoing what looks like some sort of clipping >effect during the approach. > >Grant > > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the >one installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Celestia-developers mailing list >Cel...@li... >https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Grant H. <gra...@bl...> - 2004-06-14 16:34:28
|
Fridger: > I think, I have reported this issue in another manifestation already > long ago. The problem certainly predates the introduction of partial trajectories ... I'm still using the pre8 package, and I also see the same problem back as far as 1.3.1pre11, which I happen to still have on my machine. Grant |
From: Fridger S. <fri...@de...> - 2004-06-14 18:15:01
|
Grant, what shall we make out of this? What about furnishing cel://url's about your and my "trajectory vanishing" to this list? I cannot refer to a particular "pre x" version, since I rebuild the CVS code both for Linux and Windows, whenever something has changed. Bye Fridger ----------------------------- Grant Hutchison wrote: >Fridger: > > >>I think, I have reported this issue in another manifestation already >>long ago. >> >> >The problem certainly predates the introduction of partial trajectories ... >I'm still using the pre8 package, and I also see the same problem back as >far as 1.3.1pre11, which I happen to still have on my machine. > >Grant > > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the >one installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Celestia-developers mailing list >Cel...@li... >https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Chris L. <cl...@ww...> - 2004-06-15 18:18:03
|
Lately, I've been working on finishing up cmod file support in Celestia. I've implemented a binary version of the format, and added classes that can write both the binary and ASCII formats. The model writer classes aren't used by Celestia itself, but by two applications which use the Celestia libraries: 3dstocmod and cmodfix. The code and makefiles for these applications are in src/tools/cmod. 3dstocmod accepts a 3DS mesh file as input and writes and ASCII cmod to standard out. As part of the conversion process, it will generate vertex normals for the cmod (since these aren't stored in the 3Ds file--one of the format's shortcomings.) cmodfix accepts a binary or ASCII cmod as input, performs some operations on it, then writes out the modified file. The command line is: cmodfix [options] [input file [output file]] Options are: --binary or -b : output a binary file --ascii or -a : output an ASCII file --uniquify or -u : collapse identical vertices Uniquify is especially useful after normal generation, which tends to produce a lot of duplicate vertices. In fact, I may integrate the uniquify function into Celestia: it will slightly slow down the loading of 3DS models, but they should render much more quickly without all the extra vertices. I plan to add a couple other features to cmodfix, including tangent space basis generation from texture coordinates (for bump mapping) and vertex welding (to eliminate the ugly seams found in most of the 3DS asteroid models.) Once this work is done, it will be easy to convert most of the remaining 3DS models in the base distribution into binary cmod files. --Chris |
From: Grant H. <gra...@bl...> - 2004-06-15 22:51:13
|
Fridger: > what shall we make out of this? What about furnishing cel://url's about > your and my "trajectory vanishing" to this list? I'm not sure a cel://url is required for "my" bug. You just load the NEAR orbit and go to Eros ... first there's an orbit, then there isn't. Grant |
From: Chris L. <cl...@ww...> - 2004-06-18 00:17:49
|
On Tue, 15 Jun 2004, Grant Hutchison wrote: > Fridger: > > what shall we make out of this? What about furnishing cel://url's about > > your and my "trajectory vanishing" to this list? > I'm not sure a cel://url is required for "my" bug. You just load the NEAR > orbit and go to Eros ... first there's an orbit, then there isn't. I think it's a clipping problem. Celestia is assuming that all orbits are roughly thousands of kilometers in size, and sets the front clipping plane to something like 100km. This has bad consequences for the very small (relative to other orbits) Eros-centered near orbit. --Chris |
From: Selden E B. Jr <se...@le...> - 2004-06-22 23:49:14
|
Chris, I've been trying out the 3dstocmod tool and seem to have found a problem. As best I can tell, the materials index that it generates for trilists is 1 too big. Materials are referenced in Celestia starting with index #0. When I converted a model that has two mirror imaged surfaces, when 3dstocmod generated the cmod file, it listed two materials. The first trilist specifies material #1. It should reference #0. The second trilist specifies material #2, which does not exist. When I converted a 2nd model that has only one material (#0), the only trilist in the output specifies material #1. I can provide a zip file with the models, if you want. Selden |
From: Chris L. <cl...@ww...> - 2004-06-23 00:52:02
|
Selden, Thanks for testing 3dstocmod. I'll take care of the material index problem tonight; I'm not surprised that there's a bug in that code. Have you tried cmodfix yet? With my check in last night, it's now actually useful for cleaning up and optimizing meshes generated by 3dstocmod. I'll write up an explanation of what the various command line options do. Until then, you can try this: cmodfix --weld --normals --smooth 60 --uniquify <input cmod> <output cmod> That will take the input cmod file, eliminate seams, generate normals with a smoothing angle of 60 degrees, remove duplicate vertices, and produce an ASCII cmod file as output. --Chris > Chris, > > I've been trying out the 3dstocmod tool and seem to have found a > problem. As best I can tell, the materials index that it generates > for trilists is 1 too big. > > Materials are referenced in Celestia starting with index #0. > > When I converted a model that has two mirror imaged surfaces, > when 3dstocmod generated the cmod file, it listed two materials. > The first trilist specifies material #1. It should reference #0. > The second trilist specifies material #2, which does not exist. > > When I converted a 2nd model that has only one material (#0), > the only trilist in the output specifies material #1. > > I can provide a zip file with the models, if you want. > > Selden > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Selden E B. Jr <se...@le...> - 2004-06-23 09:33:15
|
Chris, I'm sure you'll be glad to know that cmodfix seems to work ok! I used the command you suggested and applied it to a spherical model that I'd created. The two objects looked the same in Celestia. cmodfix added some vertices, going from 703 to 847, but I didn't see any obvious differences when I looked at the two models next to one another in Celestia's wireframe mode. When I inspected the two cmod files, I found that all of the surface normals were different in the new file. (I hadn't tried to get the normals right in the original. The resulting object looked OK, so I just set them all to be 0 1 0 ) The new vertices had been added at the same positions as previously existing vertices, but with different normal vectors. I had used several tristrips, one for each circle of latitude of the model. It was easier for me to understand how to create them that way. cmodfix merged them all into a single trilist. Do you expect to be able to create tristrips at some point? Or would that have to be a separate optimizer? Thanks! Selden |
From: Chris L. <cl...@ww...> - 2004-06-23 20:16:49
|
On Wed, 23 Jun 2004, Selden E Ball Jr wrote: > Chris, > > I'm sure you'll be glad to know that cmodfix seems to work ok! > > I used the command you suggested and applied it to a spherical model > that I'd created. The two objects looked the same in Celestia. > > cmodfix added some vertices, going from 703 to 847, but I didn't see any > obvious differences when I looked at the two models next to one another > in Celestia's wireframe mode. > > When I inspected the two cmod files, I found that all of the surface > normals were different in the new file. > (I hadn't tried to get the normals right in the original. > The resulting object looked OK, so I just set them all to be 0 1 0 ) > The new vertices had been added at the same positions as previously > existing vertices, but with different normal vectors. > > I had used several tristrips, one for each circle of latitude of the > model. It was easier for me to understand how to create them that way. > cmodfix merged them all into a single trilist. > > Do you expect to be able to create tristrips at some point? > Or would that have to be a separate optimizer? Normal generation can introduce new vertices at creases--edges shared by two triangles with surface normals that form an angle greater than the smoothing angle. Vertices at either end of a crease have to be duplicated, with one getting the normal of the first triangle, and the other the normal of the second. When there's not a crease, the vertex isn't split and it's normal is the average of the triangle normals. Creating new vertices changes the vertex connectivity so that tristrips and trifans must be converted to simple triangle lists. A separate optimization step--either built in to cmodfix or available as another program--could recreate the tristrips, but I haven't written code to do that. It sounds like you can just skip the normal generation, in which case cmodfix will preserve your tristrips. --Chris |
From: Selden E B. Jr <se...@le...> - 2004-06-23 20:27:34
|
Chris wrote, quoting me, [...] > > I had used several tristrips, one for each circle of latitude of the > > model. It was easier for me to understand how to create them that way. > > cmodfix merged them all into a single trilist. > > > > Do you expect to be able to create tristrips at some point? > > Or would that have to be a separate optimizer? > Normal generation can introduce new vertices at creases--edges shared by > two triangles with surface normals that form an angle greater than the > smoothing angle. I think the next thing I need to learn how to do is to create correct surface normal vectors :-) > Vertices at either end of a crease have to be > duplicated, with one getting the normal of the first triangle, and the > other the normal of the second. When there's not a crease, the vertex > isn't split and it's normal is the average of the triangle normals. > Creating new vertices changes the vertex connectivity so that tristrips > and trifans must be converted to simple triangle lists. A separate > optimization step--either built in to cmodfix or available as another > program--could recreate the tristrips, but I haven't written code to do > that. > It sounds like you can just skip the normal generation, in which case > cmodfix will preserve your tristrips. OK, I'll give that a try next, possibly some time this evening. Thanks! Selden |
From: Chris L. <cl...@ww...> - 2004-06-26 07:32:44
|
Celestia has always had trouble rendering objects with overlapping bounding spheres--one of them is always rendered completely in front of the other, often resulting in very obvious visual errors. The problem is very noticeable with the Cassini and Huygens spacecraft: depending on the position of the camera, Huygens will often appear to be obscured by Cassini even when it's closer to the camera. I believe a similar problem appeared in some of the add-ons with the Space Shuttle docking with ISS. My most recent checkin almost completely fixes the problem. I say 'Almost' because you can still create pathological cases that simply can't be rendered correctly with a finite precision depth buffer. I'd appreciate any further testing of the fix. Grant, I compiled an EXE if you'd like to try it out: http://www.shatters.net/~claurel/celestia/file/celestia-win32-1.3.2pre9-exe.zip --Chris |
From: Fridger S. <fri...@de...> - 2004-06-26 15:12:42
|
The latest 5.02 version of the Lua library can recently been found as a RPM also with SuSE. According to SuSE standards, the installation is in the following dirs: /usr/bin/lua /usr/bin/luac /usr/lib/liblua.a /usr/lib/liblualib.a And notably the INCLUDES are in /usr/include/lua /usr/include/lua/lauxlib.h /usr/include/lua/lua.h /usr/include/lua/lualib.h With the above header location, all current Linux CVS versions produce an error upon compiling celx.cpp, since the lua headers are not found (obviously!) . My main point is that this is not changed if one uses ./configure ....--with-lua --with-lua-includes=/usr/include/lua So we do need some adaptation here, since more distributions might chose different locations for the headers. In celx.h we simply have and another similar include in celx.cpp: extern "C" { #include "lua.h" } The configure.in script does not produce the necessary -I/usr/include/lua in the respective CFLAGS . So things are buggy here... Bye Fridger Chris Laurel wrote: >Celestia has always had trouble rendering objects with overlapping >bounding spheres--one of them is always rendered completely in front of >the other, often resulting in very obvious visual errors. The problem is >very noticeable with the Cassini and Huygens spacecraft: depending on the >position of the camera, Huygens will often appear to be obscured by >Cassini even when it's closer to the camera. I believe a similar problem >appeared in some of the add-ons with the Space Shuttle docking with ISS. >My most recent checkin almost completely fixes the problem. I say >'Almost' because you can still create pathological cases that simply can't >be rendered correctly with a finite precision depth buffer. > >I'd appreciate any further testing of the fix. Grant, I compiled an EXE >if you'd like to try it out: > >http://www.shatters.net/~claurel/celestia/file/celestia-win32-1.3.2pre9-exe.zip > >--Chris > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Celestia-developers mailing list >Cel...@li... >https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Pat S. <pa...@su...> - 2004-06-26 17:03:27
|
Fridger Schrempp wrote: > With the above header location, all current Linux CVS versions produce > an error upon compiling celx.cpp, since the lua headers are not found > (obviously!) . My main point is that this is not changed if one uses Hi Fridger, I've been strangely busy with things other than Celestia recently, but it is number one on my todo list. We need a release fairly soon! I looked at how lua50 is packaged. It looks like SuSe did the "correct" thing with this latest release, since lua40 was supposed to be in /usr/include/lua40 by default. I now turn you to: http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=liblua50-dev&version=testing&arch=i386 This is the Debian package listing. You'll note the lua50.pc file, which is a pkgconfig file. The configure script should be updated to use that, since pkgconfig is already required by the configure script anyway. Can you confirm you have this .pc file? You can also use: pkg-config --list-all | grep lua The --with-lua-includes should be fixed too, though. --Pat |
From: Fridger S. <fri...@de...> - 2004-06-26 19:17:46
|
Hi Pat, no I don't have that package file. Why should I? SuSE did not provide that *.pc file with their Lua package, so... I am trying to build an application based on *configure, which is a classical Unix tool*. Why should I support pkg-config in addition?? I still tend to think independently of specific packages;-)... If configure.in is correctly written, things should work. I already know where the bug is. Also the problem is common to Celestia-KDE, Celestia-Gnome and Celestia-Gtk.. Bye Fridger Pat Suwalski wrote: > Fridger Schrempp wrote: > >> With the above header location, all current Linux CVS versions >> produce an error upon compiling celx.cpp, since the lua headers are >> not found (obviously!) . My main point is that this is not changed if >> one uses > > > Hi Fridger, > > I've been strangely busy with things other than Celestia recently, but > it is number one on my todo list. We need a release fairly soon! > > I looked at how lua50 is packaged. It looks like SuSe did the > "correct" thing with this latest release, since lua40 was supposed to > be in /usr/include/lua40 by default. > > I now turn you to: > http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=liblua50-dev&version=testing&arch=i386 > > > This is the Debian package listing. You'll note the lua50.pc file, > which is a pkgconfig file. The configure script should be updated to > use that, since pkgconfig is already required by the configure script > anyway. > > Can you confirm you have this .pc file? You can also use: > > pkg-config --list-all | grep lua > > The --with-lua-includes should be fixed too, though. > > --Pat > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2004-06-26 22:32:43
|
Fridger Schrempp wrote: > no I don't have that package file. Why should I? SuSE did not provide > that *.pc file with their Lua package, so... You should, since it comes with the package. Lua, from lua, that is. > I am trying to build an application based on *configure, which is a > classical Unix tool*. Why should I support pkg-config in addition?? I > still tend to think independently of specific packages;-)... If > configure.in is correctly written, things should work. I already know > where the bug is. Also the problem is common to Celestia-KDE, > Celestia-Gnome and Celestia-Gtk.. Why should you support pkg-config? Because lua is designed to work with it. pkg-config is the tool that allows you to put includes in a location other than /usr/include and /usr/local/include. In other words, if a package has .h files that in a subdirectory of /usr/include, and it does not include them itself from a file in /usr/include, then it comes with a .pc file. It is by design, in this case, so that you can have lua 4.x and 5.x without them conflicting. The reason you should support it is that with pkg-config, you don't need to specify locations of all your development pieces, they happen automatically. So if you want, you can have your includes in /opt/lua/include, and as long as the .pc file is in $PKG_CONFIG_DIR (or whatever), then things just work. It just makes sense. It allows for that package independence you speak of. That said, the old method should work too, and must be supported. Why would SuSe rip out the .pc file? I hope Novell cleans them up, because SuSe is the least consistent distro I can think of. --Pat |
From: Fridger S. <fri...@de...> - 2004-06-26 22:56:33
|
Pat, Pat Suwalski wrote: > Fridger Schrempp wrote: > >> no I don't have that package file. Why should I? SuSE did not provide >> that *.pc file with their Lua package, so... > > > You should, since it comes with the package. Lua, from lua, that is. > This I cannot confirm. I have the Lua 5.0 /original/ tarball here and could not see anywhere a *.pc file. SuSE for that reason and for the reason that they do almost not support Gnome do not have a *.pc file either. Are you sure that you are not "dreaming" here about Gnome architecture issues? At least pkg-config I have downloaded always in /Gnome download/ dirs! I basically deny supporting further distribution dependent stuff since that deepens only the /desktop-dependent/ distinctions between distributions. I have always come along well with configure. It is designed to support both Gnome and KDE based distributions. >> I am trying to build an application based on *configure, which is a >> classical Unix tool*. Why should I support pkg-config in addition?? I >> still tend to think independently of specific packages;-)... If >> configure.in is correctly written, things should work. I already know >> where the bug is. Also the problem is common to Celestia-KDE, >> Celestia-Gnome and Celestia-Gtk.. > > > Why should you support pkg-config? Because lua is designed to work > with it. pkg-config is the tool that allows you to put includes in a > location other than /usr/include and /usr/local/include. In other > words, if a package has .h files that in a subdirectory of > /usr/include, and it does not include them itself from a file in > /usr/include, then it comes with a .pc file. It is by design, in this > case, so that you can have lua 4.x and 5.x without them conflicting. > Excuse me, but configure is just such a tool that allows me to do exactly that. Since years, in fact, provided it is handled correctly;-) It represents a very widespread GNU-UNIX standard. > The reason you should support it is that with pkg-config, you don't > need to specify locations of all your development pieces, they happen > automatically. So if you want, you can have your includes in > /opt/lua/include, and as long as the .pc file is in $PKG_CONFIG_DIR > (or whatever), then things just work. It just makes sense. It allows > for that package independence you speak of. Yes I know how PKG config works in principle, thanks. > That said, the old method should work too, and must be supported. > > Why would SuSe rip out the .pc file? > > I hope Novell cleans them up, because SuSe is the least consistent > distro I can think of. > > --Pat Bye Fridger |
From: Pat S. <pa...@su...> - 2004-06-27 17:30:26
|
Fridger Schrempp wrote: > This I cannot confirm. I have the Lua 5.0 /original/ tarball here and > could not see anywhere a *.pc file. SuSE for that reason and for the > reason that they do almost not support Gnome do not have a *.pc file > either. Are you sure that you are not "dreaming" here about Gnome > architecture issues? At least pkg-config I have downloaded always in > /Gnome download/ dirs! I basically deny supporting further distribution > dependent stuff since that deepens only the /desktop-dependent/ > distinctions between distributions. I have always come along well with > configure. It is designed to support both Gnome and KDE based > distributions. You're right, there is no .pc file from the original source. Debian was nice enough to put one in. But you are not correct in saying that pkg-config is a Gnome thing. It is GNU-sanctioned and is standard, for all the reasons I listed before. Here is proof: kdelibs depends on two things: qt and its own arts (it's just the say it is). Here is the configure script for arts: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/arts/configure.in.in?rev=1.103&content-type=text/x-cvsweb-markup If you search for pkg-config in that, you get: dnl Check for pkg-config AC_PATH_PROG(PKG_CONFIG, pkg-config, no) if test "$PKG_CONFIG" = "no"; then AC_MSG_ERROR([ This package requires pkg-config. ]) fi So to use any part of KDE you need kdelibs, which means you need arts, which means that as a KDE developer you need pkg-config. It cannot be considered a Gnome thing, those guys just put it to good use first. > Excuse me, but configure is just such a tool that allows me to do > exactly that. Since years, in fact, provided it is handled correctly;-) > It represents a very widespread GNU-UNIX standard. Which is why I'm adamant that we don't break that functionality. Is there anything in the configure.in that would indicate why that lua-include directive isn't working? Just browsing through it, it looks okay. --Pat |
From: Fridger S. <fri...@de...> - 2004-06-26 20:19:01
|
Pat, I wonder whether in your Celestia-Gnome there is a key-shortcut or otherwise, to hide that menue bar!? In KDE the menue bar is toggled ON|OFF with CTRL-M. This would allow to emulate nicely a full-screen Celestia-Gnome display in FVWM2 without fully subscribing to Gnome... Bye Fridger Pat Suwalski wrote: > Fridger Schrempp wrote: > >> With the above header location, all current Linux CVS versions >> produce an error upon compiling celx.cpp, since the lua headers are >> not found (obviously!) . My main point is that this is not changed if >> one uses > > > Hi Fridger, > > I've been strangely busy with things other than Celestia recently, but > it is number one on my todo list. We need a release fairly soon! > > I looked at how lua50 is packaged. It looks like SuSe did the > "correct" thing with this latest release, since lua40 was supposed to > be in /usr/include/lua40 by default. > > I now turn you to: > http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=liblua50-dev&version=testing&arch=i386 > > > This is the Debian package listing. You'll note the lua50.pc file, > which is a pkgconfig file. The configure script should be updated to > use that, since pkgconfig is already required by the configure script > anyway. > > Can you confirm you have this .pc file? You can also use: > > pkg-config --list-all | grep lua > > The --with-lua-includes should be fixed too, though. > > --Pat > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2004-06-26 22:33:27
|
Fridger Schrempp wrote: > I wonder whether in your Celestia-Gnome there is a key-shortcut or > otherwise, to hide that menue bar!? In KDE the menue bar is toggled > ON|OFF with CTRL-M. This would allow to emulate nicely a full-screen > Celestia-Gnome display in FVWM2 without fully subscribing to Gnome... I shall add it to the ToDo list. --Pat |
From: Selden E B. Jr <se...@le...> - 2004-06-26 16:28:19
|
Chris, Thanks for fixing that overlapping bug! It makes many views a lot more stable. Unfortunately, it also reveals prolems caused by how eclipse shadows are generated. I seem to recall you mentioning that they're created as cylinders surrounding the object casting the shadow. It seems that this cylinder projects from the object toward the light source as well as from the object away from the light source. It'd be nice if the lightward half of that volume could be eliminated. One of the first places I encountered the overlap bug was in another (fixed long ago) bug when the far future moon "crashed" into the earth. For my amusement, I defined a lunar orbit with a semi-major axis the same as the Earth's radius. The moon happened to be positioned near the terminator, casting a dark shadow toward the Sun, onto the sunlit side of the earth. Here's a link to a thumbnail http://www.lns.cornell.edu/~seb/celestia/moonshadow.jpeg and to a 1600x1200 image http://www.lns.cornell.edu/~seb/celestia/moonshadow.jpg Selden |
From: Selden E B. Jr <se...@le...> - 2004-07-04 18:05:41
|
Gentle folk, Chris' recent fix for overlapping objects makes it possible for planets to have multiple and alternative cloud layers rotating at different velocities. Here's a link to an 87KB 1600x1200 screenshot of Jupiter with two additional cloud layers: http://www.lns.cornell.edu/~seb/celestia/cloud-layers.jpg and to a much smaller thumbnail: http://www.lns.cornell.edu/~seb/celestia/cloud-layers.jpeg The implementation might be considered somewhat of a hack, since each layer has to be defined as a separate object orbiting the Sun with the same orbital parameters as the planet rather than being defined as an element of the clouded planet. (Of course, clouds of moons would orbit the moon's planet.) The tetures I used are just quick, stylized sketches. Generating more accurate multiple cloud decks would be a bit of a research project. Since Celestia interprets alpha channels as specularity for its built-in spheres, I created relatively crude cmod spheres to carry the texture image files, using the alpha channel for opacity. It'd be nice if there were an Alpha SSC declaration, perhaps Alpha "opacity" and Alpha "specularity" with "specularity" the default. This would make it possible to use Celestia's builtin spheres and all of their features, like oblateness and VTs, for enhanced cloud layers. Selden |