On Thu, Nov 5, 2009 at 6:52 PM, Tom P wrote:
> Hi Martin, Vivian & team
>
> This is an honest question, trying to understand the direction where we can
> evolve FG.
>
> Currently the models in data/Models seem to serve two purposes, and I'm
> wondering if they can be divided (kept in different repositories) based on
> the purpose?
>
> 1) static objects populating the scenery, are bound to a fixed location
> (buildings, structures, ...).
> Samples are contained in these directories:
> - Agriculture
> - Airport
> - Boundaries
> - Bridges
> - Buildings
> ...
>
> 2) Models for vehicles, ships, *crafts and anything movable:
> - Aircraft
> - Maritime/Civilian (with a few exceptions)
> - Maritime/Military
> - Transport (with a few exceptions)
>
> The fact that this last group is placed statically is, forgive my
> simplification, an accident of history.
> Any of these could be under AI or user control, and could be added
> dynamically to the scenery (any scenery, within certain constraints).
>
> So, in other words, would it make sense to split the location where we keep
> the models based on the criteria whether the model is:
> - truly static (buildings / structures / ...),
> http://scenemodels.flightgear.org/modelbrowser.php
> - or movable (vehicles / crafts / ships)
> http://cvs.flightgear.org/viewvc/data/Models/
>
> The dream is to have all the movable ones under AI or user control one day.
>
This may sound a little strange, but there's really nothing different about
'static' models such as buildings or radio towers or smoke stacks that would
prevent them from moving around ... other than it doesn't make a lot of
conceptual sense to do that. But there's nothing in how a model is created,
represented, etc. that limits it to non-movable versus movable.
Also in either case (movable vs. non-movable) an object could have animation
components. For instance a wind turbine with blades that spin and turn into
the wind, a lift bridge, an airport beacon with light beams that spin at
night, a smoke stack that emits smoke, etc.
So it may be worth discussion an organizational structure that separates
object into likely function or usage, but as far as I know, there's nothing
inherent in how the model is defined and represented that would force it
into one category or the other ... other than if I see buildings chasing
each other around I'd probably think that was a little weird.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
