Dear all,
I'm in the process of converting X-Plane scenery to FG. As far as I
understood, X-Plane uses two separate texture files for day/night lighting.
The FG wiki
(http://wiki.flightgear.org/Howto:_Illuminate_faces#Changing_texture_if_illuminated)
says
This does not work with any version
Heiko, Emilian,
thanks for your answers!
@Heiko: The wiki article correctly describes the textranslate method. What
puzzled me was that it says the previous, two-file solution would no longer
work. Well, apparently it does here...
http://flightgear.org/forums/viewtopic.php?f=5t=11870#p123517
Hey group,
I've come across a problem with FG when many (static) objects are to be loaded
on FG startup.
Usually, on my (faily old) PC FG loads for about 20 seconds, then
says loading scenery for about 6 seconds, and places me in the c172 ready
for takeoff. During all this CPU load is at
Hi Geoff,
thanks for testing! Indeed, I forgot the texture, sorry about that. It is
included in a new package: http://www.mediafire.com/?q99zyzkyu2tw04w
For further testing, I wrote a small python script which fills a rectangular
area at EHLE (because it's mostly flat there, so I can use
Hi Jon!
I've seen something similar before, it's incredibly annoying, and I suspect
you'll eventually track it down to a typo in an stg file.
I've also had typos/missing objects in .stgs before, causing similiar effects.
However, for testing, I'm creating the .stg with a very simple python
Hey Csaba,
hey Geoff,
thanks a lot for looking into this!
void SGPagedLOD::forceLoad(osgDB::DatabasePager *dbp, FrameStamp*
framestamp, ? ? ? ? ? ? ? ? ? ? ? ? ???NodePath path)
{
? ? //SG_LOG(SG_GENERAL, SG_ALERT, SGPagedLOD::forceLoad(
? ? //getFileName(getNumChildren()) ));
And now
I've been playing with populating my home airport's area with buildings derived
from OSM floorplan data. I think having many buildings in the correct place
greatly improves realism over the current random buildings/sparse static
models, especially when you know the area.
However, now the
Hi James,
Thank you for your input! I wasn't aware there is such thing as fgviewer. It's
definately a good starting point, I will have a look at it.
Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be
delighted to discuss what you've done and a whole range of possibilities
Hi Thorsten,
Thank you, too!
This becomes a performance issue eventually - see Paris (France). Random
buildings scale well for memory and performance because they're numerous
instances of the same building, so just the various positions need to be
stored separately - a city full of unique
On a related note, the thread highlights that our tree textures are
rather small, so our trees look quite blocky.
Stuart,
I created new textures for tropical trees a while ago, and I intend to improve
central European tree textures in the near future. Thorsten suggested [1]
separating
Sorry for that HTML-crap. Here's the plain text again.
On a related note, the thread highlights that our tree textures are
rather small, so our trees look quite blocky.
Stuart,
I created new textures for tropical trees a while ago, and I intend to improve
central European tree textures in
Henri,
Thorsten only said, that _if_ you ask him to remove ALS because of
concern for users without good graphics cards, you should aks FredB as
well to remove Rembrandt, because the same argument would apply. Not
doing it just shows that different standards are applied which is simply
Dear shader experts,
Can I have a single-channel lightmap, and still use a vec3d in my model.xml to
end up with green or red (or whatever) light rendered? As in (roughly)
on_screen_color[0] = lightmap-grey-value * vec3d[0] * texture[0]
on_screen_color[1] = lightmap-grey-value * vec3d[1] *
You can do what you want, but not inline in the model.xml file - the
type=vec3d is not recognized anywhere outside an effect and is causing the
error.
Do your effect config in a local .eff file, then inherit from that in your
model.
Thanks Vivian, I wasn't aware of that. Works great now.
Dear list,
in particular Stuart,
please let me 'officially' announce my project osm2city.py [1,2] here. This
python script takes OSM floor plans and generates 3D buildings for use with
flightgear. I'm planning to develop this into a procedural city generator which
would take a street network
James,
Could the floor-plan data be pulled live from OSM servers, or does it need to
be processed offline before hand? We have most of the infrastructure to pull
data from web-services already in place.
Currently data is processed offline before hand. Basically, it parses the OSM
xml,
Hi,
can someone (Mathias?) please enlighten me about fgelev usage? Skimming through
the source, I understand that I need to provide --fg-root and --fg-scenery, but
how do I specify which location to probe?
fgelev --fg-root $FG_ROOT --fg-scenery $FG_SCENERY EOF
13.0
51.0
EOF
doesn't seem to
I'm trying to compile terragear.git on a fresh Manjaro Linux, but linking fails
on gdalchop.cxx with
gdalchop.cxx:(.text+0x4f4): undefined reference to `sgWriteLong(gzFile_s*, int)'
gdalchop.cxx:(.text+0x4ff): undefined reference to `sgWriteInt(gzFile_s*, int)'
gdalchop.cxx:(.text+0x578):
Hi Rebecca,
Thanks for the pointers! Yes, I compile SG myself, but the version TG would
link against might have been compiled on Ubuntu (I'm migrating to Manjaro).
Compiling everything again solved my problem. Most likely an ID-10T error.
Tom
With my python coding for OSM buildings in FG coming along nicely, I recently
thought about creating semi-generic bridges. Is anyone else working on this? Or
is anyone aware of an open source procedural bridge generator? Searching the
net mostly turned out stuff for Houdini etc.
Tom
the first element appears to be an label so
the input format is
label lon lat\n
Thanks Stuart, that works!
Tom
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials
Hi Adrian,
I was thinking to circumvent the Terragear toolchain completely (for now), and
'just' generate 3d bridge models based on OSM data. These could then go into
the scenery DB, perhaps with a tag that indicates they were automatically
generated. I _guess_ the next scenery build will
The Autopilot menu change does make sense (although there may possibly be a
case for keeping such a flight-critical menu rapidly accessed at the top
level?)
I don't see this need. When I'm in a hurry, I use my left hand to enter a
keyboard shortcut, rather than taking my right hand off the
23 matches
Mail list logo
