Hi,
On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
> This change breaks my setup. I consider it a feature that FG used
> to load objects from all scenery directories visited up until the first
> one that contains terrain for the tile. It made it possible to have
> scenery object directories with extra objects by just putting them early
> in the path (useful not least for keeping work-in-progress object
> placements separate from terrasync data). It appears you removed that.
>
> Can you clarify what the new behaviour is?
>
> Is the first object .stg found for a tile the only one that is loaded now?
The problem with accumulating all stg files' content is that you get duplicate
models.
So the situation that I was trying to fix is as follows:
Assume you have the base package installed and assume you have terragears
scenery installed. Terragear has some improoved models from buildings included
where the older models already are contained in the from the base package.
What you would observe are models that are technically just needlessly drawn
twice and if the models are not identical or may be placed at different
altitudes because of the base tile providing a sightly different ground
elevation you will at best see some kind of z fighting between the two models
and at worst two shifted models in each other with occasionaly z fighting.
You can see this with a lot of buildings in San Francisco.
Now you might argue that I should omit the FG_ROOT/Scenery from FG_SCENERY
since it already contains all that the base package contains. Then I take an
other example with reversed coverage of the scenery:
I have terragear worldwide and the nice innsbruck scenery. And both include
some of the hangars at the airport. You will in this case see that described
z-fighting for the tyrolean writing on the wall of one of the most east airport
buildings.
For the uglyness in the scene and for the needles model duplication for draw I
do not think that we want that.
Ok, the lookup for stg files is as of today:
for path in FG_SCENERY
probe tiles files in path/{Objects,Terrain}/<id0>/<id1>/<id2>.stg
if one is there, stop probing.
end
Why do I stop at the first found file/file pair:
I got told that some scenery tiles do contain sea tiles there we only have an
Objects directory with offshore windmill models for example. If I do not want
them in the same way duplicated like described above you need to stop at some
point.
With the windmill example I tend to say, ok, let's just duplicate them. We do
not have so much models on the sea. So then we could start accumulating all up
to the point where we find either a base tile or run out of serach path.
But I think a complex oil drilling platform on the northsea breaks this
argument a little.
Ok, I get an idea:
The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for
example) with models never contain a base tile line where we could know when
to stop seraching the FG_SCENERY directory sequence.
So for this kind of tiles we could probably place someting into the stg file
that signals that we should stop seaching here and finish with a sea tile.
May be we could place a
OBJECT_BASE <id>.seatile
into the above drilling platform stg tile example to terminate the search.
An other alternative might be to also probe for a Devel directory structure
for a given scenery path extending the search to
for path in FG_SCENERY
path/{Devel,Objects,Terrain}/<id0>/<id1>/<id2>.stg
...
An third alternative could be that we explicitly flag stg files that should not
terminate the FG_SCENERY search. So you could just put that flag into your
development stg files.
The first alternative would require modifications to those scenery files, but
it
works today as good/bad as it worked yesterday and it works fine if the
terminating OBJECT_BASE is inserted.
The second one would be a code only change.
The third one would be a change only for those people that develop scenery.
Does this match your concerns? Would it solve? Thoughts?
And sorry for breaking at first ...
Mathias
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
