Hello everyone,
I'm the developer of the IAR-80, and before this holidays season I've
managed to get it to a state that I consider as production. I would
like the latest version commited to GIT, if and when anyone has the
time (hopefuly before the new release deadline :) ).
zip package here:
woops: wrong alternate download link in the first mai, it should be this:
http://rapidshare.com/files/438740862/IAR80-v1.0.zip
On 12/28/10, Emilian Huminiuc emili...@gmail.com wrote:
Hello everyone,
I'm the developer of the IAR-80, and before this holidays season I've
managed to get
The intensity of the reflection is controlled by the material shininess and the
alpha channel in the reflect map. In the grayscale map do a color to alpha
with black as the color, if using GIMP.
--
Gaining the trust of
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
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
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
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
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
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
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
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
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
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,
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
On Wednesday 23 March 2011 13:32:25 Lauri Peltonen wrote:
Also one thing point mentioning is that DDS format might not be
supported on older hardware. And I think FG is supposed to support
also older hardware.
I think BC3/DXT5 is pretty well supported by older hardware.
There would be
On Friday 25 March 2011 10:01:33 thorsten.i.r...@jyu.fi wrote:
The main thing that bugs me with the system is that the view frustum
culling
around the edges of the screen is visible, so you continuously see the
clouds being created and disappearing at the edges of the screen as you
turn
On Friday 25 March 2011 11:31:57 thorsten.i.r...@jyu.fi wrote:
Hm, I'm running an nVidia GeForce 8600M GT from linux - unless the mobile
version makes all the difference, that would argue against a graphics card
issue (or maybe I'm missing something, I'm not a hardware specialist
either...).
Or maybe the mobile card's design is a bit different, or a bit newer and might
have better memory specs.(bandwidth, timings, size etc...)
--
Enable your software for Intel(R) Active Management Technology to meet the
Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and see
if that makes a difference.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security
On Friday 25 March 2011 11:57:38 Emilian Huminiuc wrote:
Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and
see if that makes a difference.
Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
memory issue (as in it gets filled up pretty quick
On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote:
Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
memory issue (as in it gets filled up pretty quick with the clouds), as I
caught a glimpse of scenery getting redrawn too.
You may be right - I looked
On Friday 25 March 2011 13:38:38 Emilian Huminiuc wrote:
On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote:
Yep things improve, noticeably. And I'm more convinced it's a lack of
gpu memory issue (as in it gets filled up pretty quick with the
clouds), as I caught a glimpse
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote:
The most efficient way seems to have everything else maxed out, and
selected.
Not always. Asymmetric buffering is good if you fly straight, but very bad
if you circle - for soaring it's completely unsuitable as you'd
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote:
Quick and easy way out, compressed textures for the clouds as in .dds
textures
:D
(sorry about that, couldn't help myself :P)
I doubt it's a general solution since I get 30% framerate reduction for
dds textures. But
Nice white-out or rather gray-out when entering the rainy bit :) . (Not
recommended with a plane that has no interior :P )
As for texture sizes, I think that those that are 6-9/sheet can be converted
to 6-9 textures of 256x256, for the rest I think it depends on their shape,
and of course
On Saturday 26 March 2011 10:16:47 thorsten.i.r...@jyu.fi wrote:
Yes, certainly. I suggest that we pack your /Models/Weather/ then into a
tarball and I host that for the time being as a dds texture patch to Local
Weather so that people can test what works better for them. Once we know
how
On Monday 28 March 2011 14:00:44 henri orange wrote:
Hi Heiko,
My two cents:
About: An aircraft flying in the alps reflecting very visible the ocean
doesn't look realistic.
Won't it be possible to select the reflection according to the terrain
under, it is done with some particule
On Wednesday 30 March 2011 13:57:19 Vivian Meazza wrote:
Yves wrote
Am 28.03.11 00:34, schrieb Vivian Meazza:
If the reflection map path is incorrect you should see only this error
message:
no image file, maybe the reader did not set the filename attribute,
using
white
On Thursday 31 March 2011 12:03:50 Vivian Meazza wrote:
Happens here if I disable and then reenable the shaders with the view-
rendering options.
What happens?
The render bin error.
Also most of the no image file, .. errors go away if I specify paths to
them
in the effect that
On Monday 04 April 2011 01:00:36 Vivian Meazza wrote:
Emilian
On Thursday 31 March 2011 12:03:50 Vivian Meazza wrote:
Happens here if I disable and then reenable the shaders with the
view-
rendering options.
What happens?
The render bin error.
Also most of
On Tuesday 05 April 2011 13:25:44 Arnt Karlsen wrote:
On Tue, 5 Apr 2011 12:09:17 +0300, Emilian wrote in message
201104051209.17330.emili...@gmail.com:
Thanks anyway :). But the problem I was asking you to take a look at
was a bit different :
Problem was in the cockpit, there are
On Tuesday 05 April 2011 14:21:45 Arnt Karlsen wrote:
..er, it's different allright, no Nvidea black paint, instead
I have sunshine-inside-the-cockpit-but-not-outside, livery is
bare metal and way too dark, ATI hw on X.org's radeon, urls:
On Tuesday 05 April 2011 14:21:45 Arnt Karlsen wrote:
..er, it's different allright, no Nvidea black paint, instead
I have sunshine-inside-the-cockpit-but-not-outside, livery is
bare metal and way too dark, ATI hw on X.org's radeon, urls:
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
On Tuesday 05 April 2011 19:07:10 Vivian Meazza wrote:
Actually - it wasn't working correctly - you are using a cube cross texture
with cube map shader - which, much to my surprise works after a fashion.
I'll investigate further.
Vivian
Ooops, I left the cube cross on the fuselage
On Wednesday 06 April 2011 00:48:15 Vivian Meazza wrote:
Emilian wrote
On Tuesday 05 April 2011 19:07:10 Vivian Meazza wrote:
Actually - it wasn't working correctly - you are using a cube cross
texture
with cube map shader - which, much to my surprise works after a
fashion.
On Friday 15 April 2011 17:36:12 syd adams wrote:
Syd, about the fuselage contact points: they are internally
represented as a gear object, only without the compression stuff
and with hardcoded values for static and dynamic friction. I think
using fake gears directly would give a little
On Friday 15 April 2011 21:07:12 syd adams wrote:
Still trying to take off ;) .Very nicely done model ...but a bit too
much detail for my laptop ...I get 10 fps where I'm used to getting
30-40 .
No need to take off :), just raise the gear with the engine running (otherways
it doesn't raise
On Saturday 16 April 2011 15:29:52 Arnt Karlsen wrote:
..more ways to skin this cat: IRL, flying or stalling like this
into the grass, should bend metal or break wood propeller blades,
but the engine should turn another 2/3 to 2 or 3 more revolutions
plowing into the field. At high speed, the
On Saturday 30 April 2011 13:15:30 Thomas Albrecht wrote:
Dear all,
I also tried the textranslate method, but when I put the day/night
textures, say van.png and van_LIT.png each 256 x 256), into one file (512
x 256) and make up an .xml as described in the wiki, both day and night
textures
On Saturday 30 April 2011 14:21:23 Heiko Schulz wrote:
@Emilian:
According to Tim Moore, FGFS's graphic specialists it is recommended to
have large texture files, instead many smalls.
See also here: http://wiki.flightgear.org/Howto:_Improve_Framerates
Cheers
Heiko
Hmm, that depends. If
On another note, for a case like the village house presented in the wiki I
would suggest another aproach:
Better make the windows separate faces, and just give them emission at night
with the material animation. (a couple of extra vertices are way less
resource hungry compared to a 256x256
On Friday 10 June 2011 15:57:53 Frederic Bouvier wrote:
Hi,
the Hudson server has difficulties to clone the flightgear repository
lately, for building the win32 binaries. I tried myself and got :
Frederic@NINJA /m
$ git clone -o origin http://git.gitorious.org/fg/flightgear.git essai.fg
Hello everyone,
Back from an extended holiday (1 month of sightseeing in SW USA :P).
I have setup a gitorious repository for the IAR-80 and also have updated it.
Major changes include the switch of most textures to the .dds format, and an
FDM rewrite.
The change to .dds was done after weighing
On Friday 17 June 2011 07:17:45 xsaint wrote:
Hello Folks...
Was wondering if any nice souls will assist clear this doubt on mine...
In YASIM, what does actionpt really refers to?
Is it the point the engines pull the air through? which the point will
be ahead of the engines or
is it the
On Friday 17 June 2011 08:15:36 xsaint wrote:
Thank you Emilian and Buck
Ok i tested changing the location of the point to ahead of the engine
and also behind the engine, near exhaust.
Irrespective of the location, looking at the results at the Yasim
solver, i do not see much impact.
On Tuesday 12 July 2011 04:18:33 Hal V. Engel wrote:
On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote:
have you tested the script of Pierre NEGRE ? :
http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58)
Where can this be found? The web page is in French (I think)
As the subject is a recurring theme in the forums, and also on IRC, I thought
I should share something I found on OSG and shadows.
This/these guy/guys here : http://www.palomino3d.org
have a working implementation of shadows with OSG:
On Thursday 04 August 2011 11:36:48 Torsten Dreyer wrote:
I wouldn't touch the Vostock right now, it might be taken as an afront
by the author
(*Shrugs*)
Looking at disk size, this list might help making decision.
(from du -ms *|sort -n)
47 an2
47 F-8E-Crusader
48
On Friday 12 August 2011 14:02:16 Tim Moore wrote:
I've started the first phase of trimming down fgdata. I've removed the
an2 from fgdata and put it in its own repository called ac-an2 under
the Flightgear project. I'm going to proceed with moving other
aircraft which haven't been touched in a
On Friday 12 August 2011 14:35:36 Tim Moore wrote:
However, before I start adding repositories for completely
new aircraft, we should think about why new aircraft should be under
the Flightgear project.
Pros: centeralized location for obtaining aircraft, Flightgear seal
of approval
Cons:
On Thursday 18 August 2011 11:36:46 Vic Marriott wrote:
Hi All,
I am not blaming this on the new V 2.4.0, because this problem existed
before. I didn't want to distract anyone working on the new release.
1. I have noticed, that when at EGKA the light is showing from the
wrong direction.
I've noticed that with OSG 3.x, the behaviour of some shaders, especialy in
relation with the alpha channel changed.
Most notable in what is related to this bug:
http://code.google.com/p/flightgear-bugs/issues/detail?id=427
what follows is a copy of my post on that bug report:
Did a bit of
On Tuesday 20 September 2011 23:25:51 Durk Talsma wrote:
Hi all,
In referral to my previous posting: Can anybody tell me (or point me to
documentation) how I can specify new property in an aircraft -set.xml
file, and ensure that any changes to this property are saved in an
aircraft specific
On Thursday 22 September 2011 11:07:48 Jason Cox wrote:
Hi all,
I am having an issue with compiling the lattest git version due to a
lack of a libhal on my system
after check the web site for libhal
(http://www.freedesktop.org/wiki/Software/hal) I found that it now in
maintenance mode and
On Thursday 22 September 2011 22:51:26 Jason Cox wrote:
On Thu, 2011-09-22 at 16:10 +0300, Emilian Huminiuc wrote:
Jason, you might want to use the ebuilds in the gamerlay overlay (layman
-a gamerlay). They're pretty well maintained.
nice to know but I prefer to stay at or near the current
On Thursday 22 September 2011 22:27:18 Durk Talsma wrote:
Hi Vivian, Emilian,
I am currently testing your new texture and I observed two things:
First, I recently committed two additional textures for my ground network
visualizations code, and these don't seem to work any more when using
On Friday 23 September 2011 01:09:25 Durk Talsma wrote:
Erm - you did release the parking brake?
Eeemh, yes. :-) The 777 starts to make awful noises once you forget to
release the parking brake, so you typically want to check that right away.
:-)
Maybe it's just an odd glitch, but I had
On Saturday 24 September 2011 12:48:32 Erik Hofman wrote:
Hi,
Has anything changed in the viewer or sun positioning code in the last
year or so? I've been trying to hunt down why the fog/skydome
brightening effect is misaligned with the sun position and basically
concluded the following
On Friday 14 October 2011 01:29:49 Michael Sgier wrote:
Hmm so what settings to get such? I've checked all but still nothing
close to below:
Because that's a prerendered image (probably done in whatever program the
author modelled it), and not a screenshot from FlightGear
On Sunday 23 October 2011 11:04:53 Anders Gidenstam wrote:
There is one snag: the top-level directory has to be renamed manually.
Cheers,
Anders
That could have been avoided by having the aircraft dir itself in the
repository tree:
aircraft-repository/AIRCraft-name/aircraft-subtree
in
On Monday 24 October 2011 10:46:42 thorsten.i.r...@jyu.fi wrote:
I've also transferred some things into the vertex shaders - I have the
impression that is a bit faster.
Cheers,
* Thorsten
Also there's a bigger issue here. The number of varyings is limited (in fact
it's the most
On Monday 24 October 2011 11:27:11 thorsten.i.r...@jyu.fi wrote:
Yes, doing stuff once per vertex rather than once per pixel is faster,
but also
may lead to poor results. The more stuff you do in the vertex shader the
more
visible the mesh grid will be.
Maybe someone can really
On Monday 24 October 2011 11:27:11 thorsten.i.r...@jyu.fi wrote:
* Thorsten
Forgot to add to my previous message that the new version is much better than
the first, with a couple of issues.
The edge between fog/unfogged areas is too hard now, and it still doesn't
match the horizon.
On Monday 24 October 2011 12:09:33 thorsten.i.r...@jyu.fi wrote:
As for matching the horizon - it did in all my tests which were not at
sunrise/sunset - which combination of visibility-m ground-visibility-m and
ground-haze-thickness are we talking? I have just tried a few realistic
cases
On Monday 24 October 2011 18:48:38 thorsten.i.r...@jyu.fi wrote:
Okay, got it - thanks - mean one.
Basically, you're never looking at the top of the layer, you're looking
about one attenuation length into the layer - but under a shallow angle,
that is essentially the layer top.
Now, the
On Sunday 30 October 2011 23:33:22 Durk Talsma wrote:
Hi Czaba,
On 30 Oct 2011, at 23:18, Csaba Halász wrote:
That should make nasal happy, but whether it does what was originally
intended, I do not know.
Yes, that brings the clouds back. Whether the cloud patterns *look* sensible
is
On Sunday 06 November 2011 21:08:22 Jacob Burbach wrote:
On Sun, Nov 6, 2011 at 7:17 PM, Robert dogg...@googlemail.com wrote:
I hope that all you guys involved in the dds transition use
nvidia-texture-tools because:
1. It is Free/OpenSource and platform independent
2. The compression
While we're on the subject of texture size, I'll expand a bit on the
background issues:
First, there are a couple of technical limitations: power of two sizes,
and a maximum texture size of 4096x4096.
Getting the technical part out of the way we come to the tricky part. My
opinion is that
On Friday 25 November 2011 22:44:47 Michael Sgier wrote:
So AeonWave is a complete replacement for OpenAL? Must be...now could it do
synthetic speech as used for X-Plane's ATC? Thanks
Ever heard of festival? ever read the flightgear manual ? You've got everything
needed already in place.
WOW indeed. That's great Fred.
Words are useless anyway to express the joy/excitement this brings :)
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event
lighting?
Yes, the earthShade factor should affect objects dependent on their
altitude, basically I want glowing high-altitude clouds whereas the
lower
clouds are still dark.
Thought so. That would be yet another nice effect to add :)
On Mon, Jan 9, 2012 at 10:08 AM, Emilian Huminiuc
On Monday 09 January 2012 12:48:25 Emilian Huminiuc wrote:
I know that, that's why I suggested the final position, which should be
actually given by ecPosition.z. (At least for fogging the trees that works
as expected, I assume the trees use roughly the same approach).
Actually meant
On Tuesday 10 January 2012 08:07:08 James Turner wrote:
Hello,
Since it appears I (and presumably others) have a limit of 8 texture units
on my GPU, I am planning to edit the effect files to either remove the
noise texture (if it's unused by the underlying shader, which is the case
in
On Sunday 15 January 2012 12:34:43 Mathias Fröhlich wrote:
Well, I hope that we can get rid of the compression.
Can somebody with the apropriate tools convert the compressed textures to
non compressed ones? That could still be dds, but dds without these
compressions that produce the warning.
On Monday 16 January 2012 11:34:23 thorsten.i.r...@jyu.fi wrote:
I've noticed recently more or less by accident and to my dismay that
model-default.eff is used both by models placed in the scenery and by
typical aircraft 3d cockpits.
This is rapidly looking like a bad idea when a more
On Thursday 19 January 2012 00:14:34 Torsten Dreyer wrote:
Hi,
due to a bug in weather-utility.nas, the wave shader properties were
stuck at a constant value for wind-speed zero.
There was more unfortunate code in that file, so I refactored it as
xml based property rule. This is the
Hmm - actually, the wind properties _are_ interpolated over time if set
from METAR which can be easily verified by observing
/environment/sea/surface in the property browser and changing the
global-weather scenario from, say stormy monday to fair weather.
Despite the fact that the properties
On Friday 20 January 2012 16:16:18 Emilian Huminiuc wrote:
On Friday 20 January 2012 15:01:35 Torsten Dreyer wrote:
The shader scales the texture with windspeed and rotates it to get
the
right orientation, but the actual rate those change is too quick to
look good, and gives
On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote:
Hi All,
- The forest effect doesn't currently use the default fog effect
(include_fog.[vert|frag] etc.).. For consistency with the rest of the
terrain, and
the tree effect, I think it should. Is there any particular reason
why
On Monday 13 February 2012 22:13:04 Stuart Buchanan wrote:
On Sun, Feb 12, 2012 at 1:59 PM, Emilian Huminiuc wrote:
On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote:
Hi All,
- The forest effect doesn't currently use the default fog effect
(include_fog.[vert|frag] etc
On Monday 13 February 2012 22:13:04 Stuart Buchanan wrote:
On Sun, Feb 12, 2012 at 1:59 PM, Emilian Huminiuc wrote:
On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote:
Hi All,
- The forest effect doesn't currently use the default fog effect
(include_fog.[vert|frag] etc
On Tuesday 14 February 2012 21:37:16 Stuart Buchanan wrote:
On Tue, Feb 14, 2012 at 5:19 PM, Emilian Huminiuc wrote:
2. We should remove big-apartment.ac from the urban areas. It's rather
ugly, out of scale and pretty much pops up everywhere :(.
I'll check the scaling, and reduce
On Tuesday 28 February 2012 23:14:18 D-NXKT wrote:
The smoke is particle system based and thus uses a slightly different
mechanism -- is the smoke really still reversed? The steam off the
catapult on the Vinson is correct. Wind heading is typically the direction
the wind is coming from, not
On Monday 05 March 2012 12:02:26 Frederic Bouvier wrote:
Hi Thorsten,
De: thorsten i renk
I agree that we should merge the project rembrandt work sooner
rather than later. However, we should also take some time and
effort to make sure Thorsten's sky/haze/horizon effects are
On Monday 05 March 2012 13:27:00 thorsten.i.r...@jyu.fi wrote:
There is an important issue though, the functions appear to be different
for objects and terrain.
What?? Both model-default.eff and terrain-default.eff refer to
terrain-haze.vert/frag as shaders - how can the fog function be
On Thursday 12 April 2012 11:24:23 Frederic Bouvier wrote:
De: Erik Hofman e...@ehofman.com
On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote:
What is your card brand and model ?
It's a NVidia GeForce 9600GT
I think Emilian has the same card and I don't think he had these
On Friday 13 April 2012 07:05:40 Renk Thorsten wrote:
I know that Vivian and Emilian had the plan to separate fog and light
computations from the shaders and have them in general functions to be
called by all shaders. While this is very elegant and maintenance friendly,
I've come across a
On Friday 13 April 2012 08:45:26 Renk Thorsten wrote:
(*)No it's not bad design, it's a conscious hack around the state that
the environment interface was in when the shader was developed.
Something like a property rule or a Nasal script outside the shader would
have done the trick as
On Friday 13 April 2012 10:09:12 Renk Thorsten wrote:
To be safe you need to limit yourself to 32 float varyings.
Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
Okay thanks, then I am safe. Btw (spotted this while checking) - is there
any particular reason to compute a normal
On Friday 13 April 2012 10:42:48 Renk Thorsten wrote:
Apart that the earth is a sphere and ocean tiles are large pieces
of terrain where the curvature is quite apparent, how whould you
define flat ?
'flat' = 'For any visibility we can actually render, the normal (before wave
noise) is
On Friday 13 April 2012 12:35:57 Frederic Bouvier wrote:
Emilian can testify that the current water shader is extremely
difficult to convert to Rembrandt because it doesn't have a
clear reference frame. It seems to work in object space but
with assumptions on the object-to-world
On Friday 13 April 2012 11:00:14 Renk Thorsten wrote:
'flat' = 'For any visibility we can actually render, the normal (before
wave
noise) is (0,0,1) in model space to such a good approximation that you
won't spot the difference to the actual normal including earth
curvature if
I show
On Sunday 22 April 2012 11:02:46 Renk Thorsten wrote:
After the last related discussion, I've really been thinking a while if I
should bring this up again or not. I don't want to annoy people just for
the sake of it, I know open source development is often a thankless task in
which one
On Thursday 26 April 2012 12:20:36 Renk Thorsten wrote:
I've just created a merge request containing the recent work I've done for
the haze shaders (haze in water shader, dust effect, Mie scattering on
clouds, ...).
The procedure described in the wiki to create a merge request did not work
On Friday 27 April 2012 06:50:22 Renk Thorsten wrote:
Thank you for the info - that's good to know (although admittedly I have to
do some reading trying to understand what 'that' precisely is - the linked
article is a bit opaque for me). Seems there's a lot to learn about the
hidden secrets
On Tuesday 01 May 2012 12:19:27 Renk Thorsten wrote:
Question to Fred (and other Effect people) - is this a bug or am I misusing
the system?
What happens is as follows:
* the code finds a runway and looks first through terrain-default.eff to see
what it should do. It finds, if skydome
1 - 100 of 169 matches
Mail list logo
