> ..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 d
On Mon, Mar 21, 2011 at 10:03 PM, Lauri Peltonen
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 textures:
>
It is important
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 instruc
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
non-d
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
> 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
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 compres
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
> > when playing with the Local weather menu, i get the following message
> >
> > Nasal runtime error: setprop() value is not s
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
On Tue, 22 Mar 2011 16:54:52 +0100, Csaba wrote in message
:
> On Tue, Mar 22, 2011 at 5:24 AM, Robert
> 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+at
On Tue, Mar 22, 2011 at 5:24 AM, Robert 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 and replay disabled
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 anot
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
--
Enab
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 a
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
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
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/
>
> Increasing aircraft texture size from 158 kb to 16 MB
> simply isn't viable
I doubt this value- it looks like the wrong mode has been used there.
I tested it yesterday with the BK 117 in developement.
A texture 2048x2048 with approx. 390KB as .png increases to 5.462KB (=5,4 MB).
The values
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
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, which does not lose the alpha
channel. At least what I ca
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
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/
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
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
> vertical
> 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).
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
discipline
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.
> >
>
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 param
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 anima
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
> 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 loadi
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 bas
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 secon
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
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
35 matches
Mail list logo
