On 22.03.2011 00:08, HB-GRAL wrote:
I just noticed though, that a number of wiki pages again returned to
recommend the use of latest OSG-svn*sigh*. I don't know why people keep
recommending that...
Because it is valid;-) Maybe not trunk, thats always dangerous, but
2.9.9 seems to work
On 22.03.2011 05:24, Robert wrote:
Ingame (insim) I notice a small stutter that happens once every second.
Did anybody of you guys notice the same thing?
What can we do about it?
I thought it might be something like a timed task. (reading from hard
disc + malloc)?
Please, could someone tell
On Mon, 2011-03-21 at 17:50 -0600, syd adams wrote:
Interesting.I just did my own quick test ... converted 1 out of 3
livery (png) files to a dds with Gimp plugin .Had to flip the image
vertically before converting. I changed liveries with the dialog , and
the 2 png files took several seconds
On Mon, 2011-03-21 at 15:04 +0100, Holger Wirtz wrote:
Hi all,
sorry - a little bit off-topic (in fact not so much as you might think,
it's for a third-party software for FG):
Has anyone some hints/websites/programs for debugging C -based multi
threaded programs (exactly: glib based C
Well that's exactly what I was proposing you to test, split the big
texture
into 9 smaller ones, thus making 1texture/model. If the graphic engine is
somehow being stupid and forgets that it has already loaded that
texture we
should see a dramatic improvement in performance and loading
On Tuesday 22 March 2011 10:33:19 thorsten.i.r...@jyu.fi wrote:
Interesting.I just did my own quick test ... converted 1 out of 3
livery (png) files to a dds with Gimp plugin .Had to flip the image
vertically before converting. I changed liveries with the dialog , and
the 2 png files
On Tue, 2011-03-22 at 10:33 +0200, thorsten.i.r...@jyu.fi wrote:
these numbers hardly change - I go to 11 fps and my loading time is
unchanged. Somewhat surprisingly, all the matrix operations inside the
shader are apparently a non-issue here. From past experience I know that a
range
I'd Certainly make a case at least for using .dds files with bc5 compression
for normalmaps. We lose(?) the alpha channel in the normalmap, but the
quality difference is huge.
This needs a small tweak to the shader code: the normal extracted from the
normalmap needs to be flipped.
Maybe a
Emilian wrote
On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote:
Nope, doesn't work.
But this does:
Map the .png file onto the AC3D model as usual - convert the .png into
.dds in XnView - load the .dds into AC3D
No flipping of vertical required.
Perhaps XnView flips
Hi Curt,
thanks for your comments to multi threading. I noticed that I am not
doing everything wrong with my current approach for debugging. It seems
that I have to go one (or more) steps back to fix the problems.
I think that multi-threaded applications need _very_ much more coding
Hmm, I'd say it's rather critical when in place of one highly detailed
airplane you can have about four with the same level of detail in the
texture
;)., or a texture with doubled dimensions, thus having more detail
;)(since,
as Gary said .dds files get loaded compressed in video RAM).
On Tuesday 22 March 2011 11:29:04 Vivian Meazza wrote:
Vivian,
OK - here's what I have discovered:
XnView converts to .dds, and doesn't require flipping, but AFAIKS it
doesn't generate mipmaps either.
The Gimp (with the dds plug-in) does require that the image is flipped
vertically, but
On Tuesday 22 March 2011 11:43:06 thorsten.i.r...@jyu.fi wrote:
Increasing aircraft texture size from 158 kb to 16 MB simply isn't viable
- if that roughly scales, it means that FGData would go from 4 GB to 400
GB (!) - I barely have the harddisk to store that, having access to a
university T3
Hi Erik,
thanks for responding!
On 03/22/11 08:47, Erik Hofman wrote:
On Mon, 2011-03-21 at 15:04 +0100, Holger Wirtz wrote:
Hi all,
sorry - a little bit off-topic (in fact not so much as you might think,
it's for a third-party software for FG):
Has anyone some hints/websites/programs for
On Tue, 2011-03-22 at 11:20 +0100, Holger Wirtz wrote:
I tried the same thing with the glib-pthreads wrappers, but
pthread_mutex_lock blocks until the mutex is unlocked. Perhaps this
should work with pthread_mutex_trylock()?
It depends on the mode but you could also test prior to locking if
On Tuesday 22 March 2011 14:12:45 Heiko Schulz wrote:
Hi,
I'd Certainly make a case at least
for using .dds files with bc5 compression
for normalmaps. We lose(?) the alpha channel in the
normalmap, but the
quality difference is huge.
So much as I know is there a mode available,
Hi,
Heiko
There is bc3n, but so far I haven't managed to make it
behave... :(
With Gimp there is Alpha exponent (DXT5) available. The file opened in Gimp
shows that transparency is perectly kept, but in FGFS it is not.
Maybe just an issue with .dds by OSG?
Where are our OSG/ Graphic
On Tuesday 22 March 2011 14:36:12 Heiko Schulz wrote:
Where are our OSG/ Graphic specialists when we need them?
Probably scared of the coup we're trying to stage here :P...
.. whoops, I've revealed our supa' sikrit plan :D
Heiko Schulz wrote:
Where are our OSG/ Graphic specialists when we need them?
Hehe, that's a matter of 'housekeeping': If you're in need of
specialists, make sure to care for them, don't scare them away ;-)
Have fun,
Martin.
--
Unix _IS_ user friendly - it's just selective about who
Hi,
With latest GIT (21 march) there are still some serious fuel issues with a lot
of aircraft.
Especially the ones with nasal-based fuelsystem are affected like all aircraft
by Syd, the bo105, ec135, ...
With a decent load of fuel, properties: consumables/fuel/total-fuel-x are
all zero
Am 22.03.11 13:36, schrieb Heiko Schulz:
Where are our OSG/ Graphic specialists when we need them?
Just found:
http://www.mail-archive.com/osg-submissions@lists.openscenegraph.org/msg06199.html
Cheers, gral
--
Enable
I fixed the issue with the S76c , it consumes fuel again ;).My own
fuel consumption nasal code was causing a problem with the recent
changes ... once i removed it and just supplied a running
/engines/engine/fuel-consumed-lbs calculation with nasal it works fine
again . I guess i'll have to add
On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com wrote:
Ingame (insim) I notice a small stutter that happens once every second.
Did anybody of you guys notice the same thing?
Yes I also see it on both of my machines (amd+ati, intel+nvidia)
I have AI local traffic, traffic manager
On Tue, 22 Mar 2011 16:54:52 +0100, Csaba wrote in message
aanlktiksitdwffpudx_vjnuk+8npwhemwbfofoik7...@mail.gmail.com:
On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com
wrote:
Ingame (insim) I notice a small stutter that happens once every
second. Did anybody of you guys
Okay, to summarize what I take from the discussion and all the tests:
1) Texture types: png seems to be best for load-once, then-keep problems
because it has the smallest filesize, but takes a lot of time to load. dds
seems to work well for some problems, possibly those involving opaque
textures
Sorry what do you mean with
(= tick the option box). ?
however just try to modify the wind kt within the local weather tile gui,
iget nasal error
Cheers
2011/3/21 thorsten.i.r...@jyu.fi
when playing with the Local weather menu, i get the following message
Nasal runtime error: setprop()
I think there are a couple more points to consider with .dds format:
a) you can pregenerate the lower mip-map levels using a higher quality
algorithm than the simple box-filter OSG provides when it generates them on
the fly. This can often lead to noticeably better looking models.
b) The
Sorry what do you mean with
(= tick the option box). ?
The menu 'local weather tiles' has an option called 'debug output', if
that is ticked, a log is written to the console.
however just try to modify the wind kt within the local weather tile gui,
iget nasal error
I don't.
So in
Linux users are about to get yet another toy: overlayfs. It's a
union fs that can be used to virtually merge a global read-only
FG_ROOT (lower dir) and a personal overlaid read/write fg-data
(upper) dir, e.g.:
$ mount -t overlay -olowerdir=$FG_ROOT,upperdir=$FG_HOME/data overlay
~/fgfs/data
I'm working on updating some of my software here and notice that OSG-2.9.11
is available. I used to be able to run ./configure --prefix=/some/path to
configure the OSG install location, but that doesn't appear to work any
more. Is there a new/official way to instruct OSG to install into a
Curtis Olson wrote:
I'm working on updating some of my software here and notice that OSG-2.9.11
is available. I used to be able to run ./configure --prefix=/some/path to
configure the OSG install location, but that doesn't appear to work any
more. Is there a new/official way to instruct OSG
On Mon, Mar 21, 2011 at 10:03 PM, Lauri Peltonen
lauri.pelto...@gmail.com wrote:
Hi.
Inspired by the talk in the dds thread about cloud performance and other
things, I did some quick grepping through the source about textures. I
found out FG/SG has at least 5 different way of storing
..maybe Robert can tell us the FG command line etc recipe
he uses to provoke the 1Hz stuttering?
My machine specs are:
Athlon64 X2 5200+
Samsung HDD
Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues)
Debian unstable/experimental
Kernels tested: 2.6.32 to 2.6.38 (no
33 matches
Mail list logo
