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 marking
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 v
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
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
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
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 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).
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 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
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 difference
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?
>
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,
>
>
> > >
>
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.)
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_Flight
> 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 .
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
> >
> &g
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 wor
>
> 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)
> -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:5
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
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?
> >
> > Vi
>
> 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=4&t=7225&start=135#p118570
--
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
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
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 .d
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 densi
> 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 c
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
>
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
> 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 i
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 be
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
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 requires
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
t
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 >wi
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 origi
> 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
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 yo
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 o
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
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 int
A while ago I posed the question:
"What I have been wondering is the following: Currently I am using *.rgb
textures. I have noticed that the filesize can be reduced by a factor 2 or
so by going to *.png textures. However, what is the format which would
most efficiently into the scenery? If *.png
53 matches
Mail list logo
