On Friday 25 March 2011 17:27:34 Rob Dosogne wrote:
Just wanted to add that transparency is working with Alpha Exponent
(DXT5) for me.. I'm using the latest Hudson build (Win7 x64) with
fgdata cloned last night. I converted the F-16 liveries to DXT5, and
used Alpha Exponent for the markings
Just wanted to add that transparency is working with Alpha Exponent
(DXT5) for me.. I'm using the latest Hudson build (Win7 x64) with
fgdata cloned last night. I converted the F-16 liveries to DXT5, and
used Alpha Exponent for the markings (which are mostly transparent).
It looks ugly in the dds
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
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
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
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
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
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
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
On Mon, 2011-03-21 at 13:15 +0200, thorsten.i.r...@jyu.fi wrote:
... and the winner is: The rgb format.
To be honest I was expecting this but didn't have proof for it. Remember
that the RGB format was developed by Silicon Graphics to be used for
OpenGL and it probably resembled at least the
On 21 Mar 2011, at 11:15, thorsten.i.r...@jyu.fi wrote:
rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps
png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21
fps
dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps
I have
I've been doing some tests with dds textures too, only in the airplane models,
and there's an increase in both performance and quality.
Take the IAR-80 for example, changing liveries with .png textures takes ~6
seconds, while with the dds texture it takes ~2seconds.
The increase in file size is
woops sorry, link was to the last post instead of the right one:
http://flightgear.org/forums/viewtopic.php?p=118547#p118547
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for
Maybe you already did this, but this needs a 'average of 3' (or 5)
tests, because I would be very surprised if the input file format
changes the final frame-rate after loading - it's all uncompressed to
the same format in GPU memory, as far as I know.
Yes, I checked it (I couldn't believe
Here is one thing to consider when dealing with texture files, OpenGL, and
scene graphs (like OSG or PLIB.)
OpenGL has a concept called mip-mapping. When a texture is loaded,
successively smaller versions are generated automatically using a simple box
filter. So if you start with a 256x256
Hello,
Where this can lead to problems is with textures that have transparency
(i.e. an alpha channel.) The box filter scheme of generating successively
smaller versions of the texture doesn't work well with the alpha layer. The
transition from fully opaque to fully transparent gets wider
On Mon, Mar 21, 2011 at 9:52 AM, Heiko Schulz wrote:
So this is the explanantion of decreasing fps with textures with
transparency?
Comparing with other games/sims I'm surprised that it is so much noticeable
in FGFS.
No, this is another issue I believe. When the opengl system draws a
Just to add to the fun, .dds has an added benefit that I didn't see
mentioned here-- unlike other formats, .dds has the ability to store
textures compressed in memory, not just on disk. This can result in a
considerable savings of graphic card RAM. Most .dds formats are lossy
though, which
Regarding mipmaps, all the pictures in the post on the forum are done without
mipmaps in the dds (-nomips option in nvcompress).
Just done a couple more tests, this time with pregenerated mipmaps, and
texture loading time when switching liveries is 1s, with instant swithcing in
subsequent runs
Hi,
So much of the texture loading time is in
fact spent by the gpu
(or cpu?) in genertaing mipmaps from the texture.. time we
can spend just once
when creating the texture.
(This is done with a big 4096x4096 texture ;) )
Yep, texture size is higher at the end, but perfomance is better.
With the clouds issue, I have this feeling that something is amiss with
the
way clouds are generated, but i can't put my finger on it.. :(.
Thorsten, have you done the same test with individual textures instead
of a
big one ?
Huh? Not sure what you mean, I don't think I have a single
On Monday 21 March 2011 19:53:36 thorsten.i.r...@jyu.fi wrote:
With the clouds issue, I have this feeling that something is amiss with
the
way clouds are generated, but i can't put my finger on it.. :(.
Thorsten, have you done the same test with individual textures instead
of a
big one
Hello,
I don't know what that has to do with xml - it seems
generic that if I
increase the number of objects to render, the framerate
drops. I can see
the same thing with trees (which to my knowledge are not
xml-wrapped
models) - if I increase tree density by a factor 10, I see
my
Hmm... I did not have found time for a detailed table of fps
comparement, but it seems to me that some of your clouds are decreasing
fps more than the default 3d-clouds. It looked different to me at the
beginning, but making some videos showed me this.
If you use default settings, you're
Heiko wrote,
I don't know what that has to do with xml - it seems
generic that if I
increase the number of objects to render, the framerate
drops. I can see
the same thing with trees (which to my knowledge are not
xml-wrapped
models) - if I increase tree density by a factor
Vivian,
I'm right in the middle of texturing a new model. .dds is
not an option
because it looks as if the loader has some co-ordinate
issues. It looks OK
in AC3D, but when loaded in FG it's wrong. Should I revert
to .rgb rather
than use .png?
Vivian
You have to flip the .dds-texture
Heiko,
-Original Message-
From: Schulz [mailto:aeitsch...@yahoo.de]
Sent: 21 March 2011 20:35
To: vivian.mea...@lineone.net; FlightGear developers discussions
Subject: Re: [Flightgear-devel] Adventures in dds
Vivian,
I'm right in the middle of texturing a new model. .dds
On Monday 21 March 2011 23:02:18 Vivian Meazza wrote:
A simple vertical flip doesn't seem to work - it looks a bit more like a
scaling issue here.
Perhaps I need some tool?
Use nvcompress from the nvidia-texture-tools:
i.e. nvcompress -bc3 -repeat your-flipped-texture.png your-texture.dds
If
A simple vertical flip doesn't seem to work - it looks a
bit more like a
scaling issue here.
Perhaps I need some tool?
Vivian
Maybe this helps you:
http://www.flightgear.org/forums/viewtopic.php?f=4t=7225start=135#p118570
Heiko,
Vivian,
I'm right in the middle of texturing a new model. .dds is
not an option
because it looks as if the loader has some co-ordinate
issues. It looks OK
in AC3D, but when loaded in FG it's wrong. Should I revert
to .rgb rather
than use .png?
Vivian
You have to
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
Here's the AC3D version:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
And here's what I see in FG:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
Vivian
That's exactly what me
-Original Message-
From: Emilian Huminiuc [mailto:emili...@gmail.com]
Sent: 21 March 2011 22:00
To: vivian.mea...@lineone.net; FlightGear developers discussions
Subject: Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
Here's
That's exactly what me and Heiko were saying, you need to
flip the texture
vertically, BEFORE converting it to a .dds.
I meant BEFOR but did say after... My fault. Oops!
--
Enable your software for Intel(R)
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
Vivian,
Here's the AC3D version:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
And here's what I see in FG:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
Vivian
The workflow
I wrote:
-Original Message-
From: Emilian Huminiuc [mailto:emili...@gmail.com]
Sent: 21 March 2011 22:00
To: vivian.mea...@lineone.net; FlightGear developers discussions
Subject: Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote
The workflow would be like this, you map the model onto a
.png texture. You
finish drawing the texture, and before loading it into
flightgear these two
steps should be the last ones:
You flip that texture verticaly (in gimp for example), then
you convert the
flipped texture to .dds.
Emilian,
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
Vivian,
Here's the AC3D version:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
And here's what I see in FG:
ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
Hi,
Makes no difference flipping before conversion or after -
Looks OK in AC3D,
but not in FG. So it doesn't look like .dds is a proper
option without
further work.
Vivian
You must doing something wrong.
here for Gimp, assumed that you have the plugin needed already:
1.) UVmap
Heiko,
-Original Message-
From: Schulz [mailto:aeitsch...@yahoo.de]
Sent: 21 March 2011 22:32
To: vivian.mea...@lineone.net; FlightGear developers discussions
Subject: Re: [Flightgear-devel] Adventures in dds
Hi,
Makes no difference flipping before conversion or after
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 it for us?
Vivian
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 to change , the dds changed
instantly.I saw no
50 matches
Mail list logo
