Posted: 01.11.2006, 00:35
I'm going to go lost.
Please tell me if I'm correct. Every object in Celestia already has Its own frame and its own reference frame. Eg. Atlantis -> Earth -> Sol.
The frame is the initial GL matrix associated to the object + the rules for the modification of the matrix along the time (eg. orbit or xyz path + q).
These two elements allows to know the position and orientation of the object at every time.
So I think i should have the following frame hierarchy: rover camera -> rover -> location -> planet -> star. To animate the rover's camera I would like to ask for the rover's frame that is defined elsewhere and define how the object has to be animated. Stop.
In a futuristic data format I would like to define the frames (that are associated to the various types of objects), each frame should be the reference for another and I would like to write in the same file something like:
The system creates a tree of frames related to each other.
Ok ok its too much. I'm a dreamer I know. But in DirectX 5 retained mode the system was designed this way. PLIB-SSG, Ogre and OSG are similar. I don't see many other alternatives.
Of course this potentially changes radically the approach of the internal data structure of Celestia. A unique container of all the frames should allow to manage all the objects in the same way. Perhaps a unique Octree should cull all the objects in a single pass. I don't know which should be the impact on the performance. But IMHO this approach is an intriguing opportunity.
Kind regards
Please tell me if I'm correct. Every object in Celestia already has Its own frame and its own reference frame. Eg. Atlantis -> Earth -> Sol.
The frame is the initial GL matrix associated to the object + the rules for the modification of the matrix along the time (eg. orbit or xyz path + q).
These two elements allows to know the position and orientation of the object at every time.
So I think i should have the following frame hierarchy: rover camera -> rover -> location -> planet -> star. To animate the rover's camera I would like to ask for the rover's frame that is defined elsewhere and define how the object has to be animated. Stop.
In a futuristic data format I would like to define the frames (that are associated to the various types of objects), each frame should be the reference for another and I would like to write in the same file something like:
Code: Select all
Location
{
Name "OpportunityLandingLocationOnMars"
...
}
GenericObject
{
Name "OpportunityRover"
Type "SurfaceMoveable"
# This should allow to add a mechanism to automatically align the
# object with the surface mesh if in a future 3D meshes for planets
# will be implemented. The animation of the rover on the surface
# should be done with a long , lat and compass.
Mesh "OpportunityBase.cmod"
Radious 0.0005
ReferenceFrame "OpportunityLandingLocationOnMars"
Begin [ yyyy mm dd hh mm ss]
Displacement [ xx yy zz ] #initial from the reference frame
Orientation [ xx yy zz ww ] #initial quaternion
SampledPath "opportunityrover.xyz"
SampledOrientation "opportunityrover.q"
}
GenericObject
{
Name "OpportunityCamera1"
Type "Camera"
# This type should allow to assign the current frame of the object to
# the observer
Mesh "OpportunityCamera1.cmod"
Radious 0.00001
ReferenceFrame "Opportunity"
Begin [ yyyy mm dd hh mm ss] #this shoul dbe inherited from the reference frame
Displacement [ xx yy zz ] #initial from the reference frame
Orientation [ xx yy zz ww ] #initial quaternion
SampledOrientation "opportunitycamera1.q"
}
GenericObject
{
Name "OpportunityWheel"
Type "MeshObject"
Mesh "OpportunityWheel.cmod"
Radious 0.00001
ReferenceFrame "" #none
Displacement [ xx yy zz ] #initial from the reference frame to correct cmod if necessary
Orientation [ xx yy zz ww ] #initial quaternion to correct cmod if necessary
SampledOrientation "opportunitywheels.q" #this should be a little bit too much, but all the rotations of the wheels along their axis should be sampled.
}
GenericObject
{
Name "OpportunityWheel1"
Type "ReferenceObject" #this object is only a clone
Reference "OpportunityWheel"
ReferenceFrame "OpportunityRover"
Displacement [ xx yy zz ] # of the wheel 1 against the rover
Orientation [ xx yy zz ww ] #of wheel 1 eg on the left side
SampledOrientation "opportunitywheel1.q" #this should allow to sample the steering.
}
The system creates a tree of frames related to each other.
Ok ok its too much. I'm a dreamer I know. But in DirectX 5 retained mode the system was designed this way. PLIB-SSG, Ogre and OSG are similar. I don't see many other alternatives.
Of course this potentially changes radically the approach of the internal data structure of Celestia. A unique container of all the frames should allow to manage all the objects in the same way. Perhaps a unique Octree should cull all the objects in a single pass. I don't know which should be the impact on the performance. But IMHO this approach is an intriguing opportunity.
Kind regards