Since the idea hasn't really caught with modelers yet, I've tried to get a more
practical demo of the virtue of a grain texture and tried to put a grain effect
on the Vinson flightdeck (I've always felt that the homogeneous grey color
doesn't justice to the details of the model otherwise).
Thorsten wrote
Sent: 25 June 2013 10:14
To: FlightGear developers discussions
Subject: [Flightgear-devel] Grain texture for models - a demo
Since the idea hasn't really caught with modelers yet, I've tried to get a
more
practical demo of the virtue of a grain texture and tried to put a
I looked at this possibility already. The carrier deck is made up of a
number of odd-shaped areas, for historical reasons. I don't think that a
complete rebuild of the flight deck is worth it for this very nice
eye-candy
(just too much work). Alexis might think differently.
Do you really
Interesting! Any way we can see this example live? I'd love to experiment
with it in the 744's cockpit, but that'll have to wait till after next weeks
exams...
If you want to do the same detail level using conventional texturing, you
need a texture resolution of 25600x6400 (I'm guessing no
Interesting! Any way we can see this example live? I'd love to
experiment with it in the 744's cockpit, but that'll have to wait till
after next weeks exams...
I'll be happy to let you have the files - but the Vinson can't go to GIT
because it doesn't really work due to the uv-mapping,
Terrasync.exe is not in the Jenkins 64-bit build. Isn't this an error?
Haven't checked the 32-bit build.
Seems to me that if you start off with FG using on;y Git it needs to be
there.
Nigel
--
This SF.net email is
Hi Stuart,
Ah yes. I remember you mentioning this before, me saying I'd add it
to my TODO list, and then failing to do so. Sorry. I've now added it
to my wiki TODO list so I don't forget again. Are you thinking about
the sprinkling of lights that we put over the terrain, the VASI/PAPI
Hi,
I'm failing to build SimGear on 64bit linux:
EffectGeode.cxx:83:136: error: no matching function for call to
‘osg::Geometry::setVertexAttribArray(int, osg::Geometry::ArrayData)’
OSG is stable 3.0.1 from svn (same with OSG trunk)
SimGear is git next from today
Yes, I rm-rf'ed previous
Hi Torsten,
2013/6/25 Torsten Dreyer tors...@t3r.de:
I'm failing to build SimGear on 64bit linux:
EffectGeode.cxx:83:136: error: no matching function for call to
‘osg::Geometry::setVertexAttribArray(int, osg::Geometry::ArrayData)’
OSG is stable 3.0.1 from svn (same with OSG trunk)
SimGear
Hi Thorsten
I can also give you the extra lines for the Citation Bravo with hires stains
That would be appreciated. Emilian already reminded me of the normalmap
feature, so it'd be interesting to compare the two and see which one I prefer.
But don't hurry; better not send it to me before
How far off is the aircraft placement - how much is the jump? Is it
many hundreds of meters, or on the order a meter or two, or just
centimeters?
Jon
Several meters!
Or more precise:
first: lat= 47.306263 lon= 11.379070
jump to: lat= 47.3062060567 lon= 11.3790703145
It really smells like a double - float conversion somewhere in the
pipeline (more than a geocentric / geodetic conversion or something like
that).
Curt.
On Tue, Jun 25, 2013 at 2:01 PM, D-NXKT d_n...@yahoo.de wrote:
How far off is the aircraft placement - how much is the jump? Is it
many
On Mon, Jun 24, 2013 at 10:41 PM, Torsten Dreyer wrote:
Collecting the arguments from this discusson, I can see good points for
a 3.0.0 release. Most convincing was Stuarts comparison against 2.0.0
and the progress we made since that version.
My suggestion is, we dare to call the 2013 summer
On Tue, Jun 25, 2013 at 4:48 PM, Stuart Buchanan stuar...@gmail.com wrote:
Having thought about this a bit more I'm going to propose we do 2.12.0 now
and
pre-announce 3.0 as the Feb 2014 release to give us just a little more
time
to prepare and make the 3.0 as polished as possible. After
A few years ago, I helped squash a bug that occurred when reading in data with
generic IO (I think that my patch was included in the code). At the time, it
was reading in just a float. So, when using it to read in position, the
doubles for lat/long were being cut (rounded or truncated?) and
JJ:
The mirror would be great, but the scenery isn't finished - it's just the
underlying scenery data.
Plus, because it's 'better' scenery, the question of how do we distribute the
scenery once it is generated becomes an issue.
I know Martin's working on a potential solution, so I'll be
16 matches
Mail list logo
