Thread: [Celestia-developers] Locations bug in 3ds
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Grant H. <gra...@bl...> - 2003-12-28 17:57:44
|
The behaviour of Locations in 3ds objects continues to cause headaches - Bob Hedgewood has recently been pulling his hair out trying to write a script involving Amalthea. The following applies only to the Phil Stooke models - Scott Hudson's use Z for their rotation axis and need some work to rotate them towards the orientation standard of the other Celestia objects. (I fixed them a while ago using Orientation, but I'm planning to rebuild them to match the Celestia standard.) 1) All Phil Stooke's models default to an orientation 180 degrees of longitude out of register with the orientation of spherical objects: they need an Orientation [ 180 0 1 0 ] instruction to bring their prime meridians into line with the Celestia coordinate system, but thereafter Goto Object produces the correct lat lon position, and RotationOffsets produce the correct orientation. No big problem, and I mention it only because it may have a bearing on what follows. 2) In 3ds models, locations plot 180 degrees of longitude away from the stipulated coordinates. This is *independent* of the Orientation state of the model, since locations seem to track the model itself, not the coordinate system. Thus, I've been forced to label surface features on 3ds objects using longitude+180 to get the labels in the right place. No problem if the user simply admires the labels, and doesn't ponder the content of the locations ssc too much. But problems occur if: a) a particular location is selected, and the user then tries to go to it - the locations ssc coordinates are used, and the user ends up 180 longitude degrees away from the correct location. b) the user tries to mark a location - again, the marker ends up 180 degrees of longitude from the location. Hope this is enough information to permit a fix. Grant |
From: Don G. <do...@do...> - 2003-12-30 00:50:58
|
Howdy Grant, This one is a bit confusing to me. Is this a 3ds model "author" problem; a Celestia Location Label problem only with 3ds models; or ??? What exactly needs to be "fixed"? Thanks, -Don G. ----- Original Message ----- From: "Grant Hutchison" <gra...@bl...> To: "Chris Laurel" <cl...@ww...> Cc: "Celestia Developers" <cel...@li...> Sent: Sunday, December 28, 2003 10:57 AM Subject: [Celestia-developers] Locations bug in 3ds > The behaviour of Locations in 3ds objects continues to cause headaches - Bob > Hedgewood has recently been pulling his hair out trying to write a script > involving Amalthea. > > The following applies only to the Phil Stooke models - Scott Hudson's use Z > for their rotation axis and need some work to rotate them towards the > orientation standard of the other Celestia objects. (I fixed them a while > ago using Orientation, but I'm planning to rebuild them to match the > Celestia standard.) > > 1) All Phil Stooke's models default to an orientation 180 degrees of > longitude out of register with the orientation of spherical objects: they > need an Orientation [ 180 0 1 0 ] instruction to bring their prime meridians > into line with the Celestia coordinate system, but thereafter Goto Object > produces the correct lat lon position, and RotationOffsets produce the > correct orientation. No big problem, and I mention it only because it may > have a bearing on what follows. > > 2) In 3ds models, locations plot 180 degrees of longitude away from the > stipulated coordinates. This is *independent* of the Orientation state of > the model, since locations seem to track the model itself, not the > coordinate system. Thus, I've been forced to label surface features on 3ds > objects using longitude+180 to get the labels in the right place. No problem > if the user simply admires the labels, and doesn't ponder the content of the > locations ssc too much. > But problems occur if: > a) a particular location is selected, and the user then tries to go to > it - the locations ssc coordinates are used, and the user ends up 180 > longitude degrees away from the correct location. > b) the user tries to mark a location - again, the marker ends up 180 > degrees of longitude from the location. > > Hope this is enough information to permit a fix. > > Grant > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Grant H. <gra...@bl...> - 2003-12-30 01:46:58
|
Don: > This one is a bit confusing to me. Is this a 3ds model "author" > problem; a Celestia Location Label problem only with 3ds models; or > ??? This is something Chris and I discussed briefly when Locations were first introduced - that Locations plotted incorrectly (180 degrees of longitude out of alignment) on 3ds objects. At the time, Chris suggested it might be an "author" problem - ie, something we could fix by manipulating the 3ds objects. I played around a little with the 3ds models, but couldn't find a solution that both gave correct latitude and longitude readouts *and* placed locations correctly. So in order to place the labels properly, I had to "trick" Celestia by giving locations coordinates 180 degrees away from the correct coordinates. This was fine so long as everyone admired the labels and no-one fretted too much about the numbers. But now Bob has started writing scripts that try to mark the locations on 3ds objects, with the result his markers are popping up 180 degrees away from the locations they mark! Meanwhile, I've convinced myself that I can't produce a well-behaved 3ds object that'll accept locations correctly, so I'm batting the ball back into Chris's court ;-) I think it's a bug of some sort in Celestia's *handling* of the objects, rather than in the objects themselves. (May be wrong, of course.) Chris, on the topic of 3ds: I'm keen to do a complete revision of Celestia's collection of 3ds asteroids and moons. I've just flipped Scott Hudson's shape models into alignment with what's effectively the Celestia standard - the orientation of Phil Stooke's models, which at least have their rotation axis aligned with Celestia's Y axis. A further 180-degree Y-axis twist for all the models (Stooke and my modified Hudson) would now dispose of the need for the instruction "Orientation [ 180 0 1 0 ]" before every model - the prime meridians on 3ds bodies would automatically align with an equivalent spherical body defined in Celestia. I've also experimented with flipping the models for the retrograde rotators like Ida and Toutatis so that their north poles are Celestia (=rotational) rather than IAU (=ecliptic). This means that they behave like standard spherical retrogrades with regard to applied textures and long/lat operations. Eliminating a whole class of "special considerations" in this way seems like it can only be useful in terms of Celestia development. Worries at present are: 1) I don't want to go too far down this road without knowing what the resolution to the above-mentioned "locations problem" might require. 2) The 3ds manipulation tools I have at present steadfastly refuse to produce smoothed models, so I'm reliant on Praesepe's help to produce the final articles. He's busy at present, and I don't know how he'll respond to an avalanche of models arriving in his mailbox. I've already broached the topic with him, though, and I'll wait to hear what he says. Grant |
From: Pat S. <pa...@su...> - 2003-12-30 04:59:24
|
Grant Hutchison wrote: > This is something Chris and I discussed briefly when Locations were first > introduced - that Locations plotted incorrectly (180 degrees of longitude > out of alignment) on 3ds objects. At the time, Chris suggested it might be > an "author" problem - ie, something we could fix by manipulating the 3ds > objects. I played around a little with the 3ds models, but couldn't find a ... Damn... all this time I could have sworn Toronto was in the middle of Siberia... But seriously, rather than changing the data files by 180 degrees, why not add 180 to the value inside the Celestia core code? This would be 50% clean, no? --Pat |
From: Don G. <do...@do...> - 2003-12-30 07:30:53
|
Thank you Grant. -Don G. ----- Original Message ----- From: "Grant Hutchison" <gra...@bl...> To: "Don Goyette" <do...@do...>; "Chris Laurel" <cl...@ww...> Cc: "Celestia Developers" <cel...@li...> Sent: Monday, December 29, 2003 6:46 PM Subject: Re: Locations bug in 3ds > Don: > > This one is a bit confusing to me. Is this a 3ds model "author" > > problem; a Celestia Location Label problem only with 3ds models; or > > ??? > This is something Chris and I discussed briefly when Locations were first > introduced - that Locations plotted incorrectly (180 degrees of longitude > out of alignment) on 3ds objects. At the time, Chris suggested it might be > an "author" problem - ie, something we could fix by manipulating the 3ds > objects. I played around a little with the 3ds models, but couldn't find a > solution that both gave correct latitude and longitude readouts *and* placed > locations correctly. So in order to place the labels properly, I had to > "trick" Celestia by giving locations coordinates 180 degrees away from the > correct coordinates. This was fine so long as everyone admired the labels > and no-one fretted too much about the numbers. But now Bob has started > writing scripts that try to mark the locations on 3ds objects, with the > result his markers are popping up 180 degrees away from the locations they > mark! > Meanwhile, I've convinced myself that I can't produce a well-behaved 3ds > object that'll accept locations correctly, so I'm batting the ball back into > Chris's court ;-) I think it's a bug of some sort in Celestia's *handling* > of the objects, rather than in the objects themselves. (May be wrong, of > course.) <trimmed> > Grant |