Hi,
I had a busy week, so sorry for the delay.
On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote:
I have not had time to consider the proposal carefully, but I agree that
the ocean tiles are problematic in the old (old) scheme if you have
object directories with overlapping objects
On 24 Mar 2012, at 08:54, Mathias Fröhlich wrote:
This question is motivated by the scenegraph structure we currently generate.
I can imagine improovements to scenery paging with this kind of change. What
I
want to try is not put individual model files into own level of detail nodes
or
Hi,
On Saturday, March 24, 2012 09:29:41 James Turner wrote:
Tangental, but, yes please!
This and a few other similar options, like generating a low-detail terrain
node 'automatically' for distant tiles, were some ideas I considered last
year to allow further draw distances.
Yes, the spt
Hi Jon,
On Tuesday, March 20, 2012 17:27:52 Jon Stockill wrote:
Except a bunch of scenery developers pointing out it completely breaks
their method of working.
Merging the work into an existing tree isn't really an option - the
ability to completely erase a tree and rebuild by script
I fully agree with Jacob. I thought that is why we have seperate
Terrain/Object/Airport folders in the first place...
Eric
On 03/17/2012 11:15 PM, Jacob Burbach wrote:
On Sat, Mar 17, 2012 at 4:57 PM, Martin Spottmartin.sp...@mgras.net wrote:
Anders Gidenstam wrote:
While the
On Thu, 15 Mar 2012, Mathias Fröhlich wrote:
Good Evening,
Ok, no feedback to my comments here except Martin who tells me that the
current checked in version behaves as expected.
Hi,
I have not had time to consider the proposal carefully, but I agree that
the ocean tiles are problematic
Anders Gidenstam wrote:
While the (old) new behaviour is as Martin expects it is not what most
that has read Docs/README.scenery would expect (I'd think). However, I
would not consider Docs/README.scenery a normative source (i.e. not how
it should be but rather how it was) - but Martin's
On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott martin.sp...@mgras.net wrote:
Anders Gidenstam wrote:
While the (old) new behaviour is as Martin expects it is not what most
that has read Docs/README.scenery would expect (I'd think). However, I
would not consider Docs/README.scenery a normative
Good Evening,
Ok, no feedback to my comments here except Martin who tells me that the
current checked in version behaves as expected.
I personally can understand that people want to have a local seperated
directory for their own personal additions. Let it be additions to the scenery
that are
Mathias Fröhlich wrote:
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
Hi,
On Sunday, March 11, 2012 21:07:37 Martin Spott wrote:
Mathias Fröhlich wrote:
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.
Hi Mathias,
I know a lot of users who use this kind of organisation about scenery folder,
and these users aren't scenery developpers. I think your change will breaks a
lot of users configuration with the next release (2.8.0)
I'm convinced that your change is a good improvement (if I understand
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.
The current item in the scenery path may be defined either by having
the requested
On Thu, 8 Mar 2012 23:13:56 +0100, Clement de l'Hamaide wrote:
I've encountered a problem about this change but I fixed it. Some
explanation :
I use 5 sceneries folders and some of them add some data to the
precedent scenery folder.
I use this argument :
On Thu, 8 Mar 2012, Mathias Fröhlich wrote:
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing
problems with modelss that appear to have
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
Hi,
On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote:
Without this little tweaks the tile can't be loaded. In conclusion, with
your change we need to associate Object AND Terrain folder. It's just a
feedback of my experience, don't take it as a critics ;)
That's fine.
Have
Hi Jon,
On Friday, March 09, 2012 10:43:55 Jon Stockill wrote:
Can you explain exactly how the loading now works, and if it's still
possible to use extra local objects trees in the way I describe?
Thanks for the response.
Well, I guess this hits the same problem that I try to solve now with
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing problems
with
modelss that appear to have z-fighting. This change should not harm and
19 matches
Mail list logo
