On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote:
A lot of stuff, mostly deflecting the discussion to other irelevant points
* Thorsten
While I should know better than to answer to this, as it will again get
deflected to other areas, let's imagine ourselves a simple scenario:
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote:
It's a fact that the distances out to which we draw trees and buildings are
considerably less than how far we potentially draw terrain (120 km max.) So
these things are separated even now - we don't attempt to render random
On Saturday, February 23, 2013 11:51:55 Stefan Seifert wrote:
The solution is not to give crude tools like limiting visibility to the
user. The solution is to fix FG to be consious about how much memory is
available and make the best use of it. Yes, many games simply limit
visibility if
On Saturday, February 23, 2013 13:09:29 Stefan Seifert wrote:
Why do you want the user to have to repeatedly press a key after starting
the sim instead of setting the maximum visibility once and for all in the
advanced weather dialog? In other words: why should the user press a key
_n_ times
On Thursday, February 21, 2013 12:33:17 Renk Thorsten wrote:
I was talking about the 16km value (sorry for not being more clear about
that) and see below for the huge value.
Let me get this straight. You state that the 16 km are a pretty sane value.
The proposal being discussed is to load
On Wednesday, February 20, 2013 08:44:24 Renk Thorsten wrote:
.
1) Black skies: This may either be skydome unloading which I can't reproduce
(but we should have a property preventing that, I don't know if it's set
only by Advanced Weather, if not then this is a Basic Weather problem, not
On Thursday, February 21, 2013 10:31:18 Renk Thorsten wrote:
I was not referring to a frame rate issue, but FG running out of memory.
http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p17739
2
It is rare to see that happening using the current scenery, but here if I
On Thursday, February 21, 2013 11:13:21 Renk Thorsten wrote:
Why should those users be forced to give up on those goodies just
because one
part of the rendering scheme doesn't want to play by the rules? Even
more so when there's no indication that happens...
The default max
I was talking about the 16km value (sorry for not being more clear about
that)
Sorry this should have read:
I was talking about the 16km value (sorry for not being more clear about that)
and see below for the huge value.
On Tuesday, February 05, 2013 08:17:43 Renk Thorsten wrote:
2) Flickering in water
http://www.flightgear.org/forums/viewtopic.php?f=68t=18924start=15#p176001
With the sun in the back, under some conditions a strange flickering in the
water can be observed. Dialling down the amount of
On Tuesday, February 05, 2013 11:12:14 Renk Thorsten wrote:
Cannot reproduce here on today's GIT.
Given the intermitent nature of it, I have a possible culprit (but
you're not
going to like it):
-try with the texture fetches outside of the conditionals, see if you
(or the reporter)
-combined-deferred.eff and
ubershader.vert/frag) has not been introduced by myself but by Frederic
Bouvier and Gijs de Rooy with major additions and revisions by Emilian
Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader
requires to insert generate tags into each model which
On Thursday, January 17, 2013 13:16:03 Renk Thorsten wrote:
I've recently come across the idea of using one generic sand or rock texture
and selecting the particular hue desired by multiplying every pixel value
with an (rgb) vector - so rather than two different-colored sands, we'd
just store
Also see here for uniforms:
https://www.opengl.org/wiki/Uniform_(GLSL)
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with
On Friday, January 11, 2013 12:07:27 Renk Thorsten wrote:
I was wondering if anyone has experience with the stereoscopic view modes of
FG. Coming with my new laptop were very fancy NVidia IR synchronized LCD
shutter glasses for 3D vision, and I've used them to have a look at some 3D
movie
On Thursday, January 10, 2013 08:03:39 Renk Thorsten wrote:
Which reminds me - is there a performance penalty for using many uniforms?
My impression is not, at least I've never seen any, but it'd be good to
have this confirmed. Also, can be declare uniform vec 3 in the effect
files, and if
The DR400 Guide (Aircraft/DR400/DR400 Guide.pdf)
commited in this has a non-GPL compatible license (All rights reserved).
I think this situation needs to be fixed
(either the guide removed, or a proper GPL version of the guide is pushed)
I think it would be a good idea if contributors would
On Sunday, December 16, 2012 19:37:37 James Turner wrote:
On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
I'm surprised there's any benefit to using a very low resolution texture
set. Surely the normal textures are already loaded by OSG and it's
cheaper just to refer
to those rather than
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote:
On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote:
Aw, that looks bad... I've never seen anything like, so my first guess
would be that it's one of these NVIDIA vs. ATI issues (which are really
tough to
understand from my side
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote:
On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote:
Aw, that looks bad... I've never seen anything like, so my first guess
would be that it's one of these NVIDIA vs. ATI issues (which are really
tough to
understand from my side
On Friday, December 14, 2012 12:33:52 Renk Thorsten wrote:
Thorsten, from discussion on irc, it seems you're assigning to a varying
in
the fragment shaders. See this log: http://dpaste.com/845317/
Most likely the other errors will go away once you fix that.
Thanks, the log was very
On Friday, December 14, 2012 13:28:08 Renk Thorsten wrote:
Those are fixed, but you still have some implicit casts/coversions in
there,
those are tolerated by the nvidia compiler but not by other drivers:
http://dpaste.com/845842/
Aw, a forgotten decimal point - that's picky. Okay, how
On Wednesday, November 28, 2012 08:17:56 Renk Thorsten wrote:
Um... what should I do with this? I've gotten one comment pointing to a
problem with the urban shader, but I can reproduce the same problem on a
pristine master branch, so it's not
Hi,
You might want to take a look here:
http://ubuntuforums.org/showthread.php?s=92e1641ae03fc09b4a10e772e569987bt=1478192page=2
I'm not sure if the settings suggested there still work with current drivers,
but it's a start.
Cheers
Emilian
Hi Thorsten
The atmospheric rendering scheme should not be affected by this change.
All I did was to add /sim/rendering/shaders/quality-level to the techniques
that had a single check on /sim/rendering/shaders/$shader.
The atmospheric rendering related techniques, and the Rembrandt ones, have
Hi all,
I've pushed a change to the effect files that makes sure that shaders are
disabled when /sim/rendering/shaders/quality-level is 0 or non existant.
Previously this relied on gui.nas to set the individual shader levels to 0,
and fgviewer had no easy way to disable them.
This will change
On Thursday, October 18, 2012 06:43:32 Renk Thorsten wrote:
Speaking of which - it'd be nice to have local north as well defined
direction as well - that would allow for things like the snowline
being higher on south slopes ...
In the Northern hemisphere ;-)
Quite so - but once you
On Thursday, October 18, 2012 07:58:14 Renk Thorsten wrote:
Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude.
There are some issues with that one, but only in custom terrain generated
after 2009, which you're not interested in supporting anyway.
FYI, I fixed the
On Thursday, October 18, 2012 08:58:43 Renk Thorsten wrote:
In any case, since the 'additional computations' are subtracting one number
from another number, I can just about live with the performance degradation
caused by the operation, given that it provides backwards compatibility to
On Thursday, October 18, 2012 09:31:27 Renk Thorsten wrote:
And the matrix transform is for free...?
Oh, I forgot, a useless matrix transform is ok to be run on milions of
vertices, but one that actualy has a use, and runs on tens or maybe
hundreds at most, is killing performance
A
On Saturday, October 06, 2012 23:34:13 Stuart Buchanan wrote:
Hi All,
I've just added a trivial enhancement to the rendering options dialog
to allow in-sim selection of the materials.xml file. This is limited
to those available in the base package (regions, default, dds).
I've used the
On Sunday, October 07, 2012 07:44:53 Renk Thorsten wrote:
I've had a look at this in Scotland, where it is a bit too bright based
on my own experience, so I'd like to leave this change so it only applies
to South America. Obviously I could do the opposite and make some
specific materials
On Sunday, October 07, 2012 11:28:24 Renk Thorsten wrote:
First I get this when opening the shader settings dialog:
Nasal runtime error: non-objects have no members
at $FG_ROOT/Nasal/props.nas, line 181
called from: __dlg:shaders-lightfield, line 32
and the slider is off to
On Thursday, October 04, 2012 06:42:30 Renk Thorsten wrote:
You know that rendering a transparent object twice alter its
transparency.
Of course, you can avoid to render it in the color buffer using write
mask in one pass.
What I do with the trees is render just the opaque bits early on
On Monday, October 01, 2012 19:16:09 Alan Teeder wrote:
James
I have just run a very quick check on a few aircraft. My apologies, but I
should have used the word opaque and not translucent.
F22 (jsbsim) has an opaque HUD, Mirage F1 has an opaque cockpit. They are
both transparent when
Hi,
I've just pushed a change to fgdata that modifies the model-combined and model-
combined-deferred effects when running under Rembrandt.
This was done in order to be able to provide the same effects that are
available for transparent surfaces in the clasical pipeline for transparent
Hi,
Another change, hopefuly after this things will be clearer.
With previous change I forgot the case of the model shader being disabled,
thus transparent surfaces would lose transparency and be rendered wrong.
I've commited a new effect, Effects/model-combined-transparent, which should be
On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote:
Just stumbled across this one:
Effects/water.eff now declares png textures for reflection and nose to avoid
dds. The relevant commit changed the effect file and water_sine.frag but
didn't change the corresponding lines in
On Friday, August 03, 2012 15:43:45 Emilian Huminiuc wrote:
On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote:
Just stumbled across this one:
Effects/water.eff now declares png textures for reflection and nose to
avoid dds. The relevant commit changed the effect file
On Monday 30 July 2012 16:29:28 Curtis Olson wrote:
I am in no way picking on any single committer here. This just happens to
be the most recent commit message that came through while I was thinking
about this (sorry Gijs, we do really love you. I'm mean, not really really
really love, but
On Saturday 14 July 2012 06:22:06 Renk Thorsten wrote:
In case we want to remove those, the corresponding *.ac files have to be
changed. Is there an opinion on that question either way?
* Thorsten
This should be fixed too, as of now, in GIT.
Hopefuly, warning messages (if left enabled)
On Thursday 05 July 2012 15:21:24 Viktor Radnai wrote:
1. When the aircraft is parked with no parking brake, it will usually
start to roll slowly backwards -- pushed by the wind and maybe the
runway slope. If I start the engine on idle, the thrust generated by the
idle prop might stop this
On Saturday 30 June 2012 10:44:46 James Turner wrote:
I happen to have a spare 8800GT (512MB, 64k rom - NOT suitable for Mac use)
First person to say they want it for something useful gets it. Ideally you'd
PayPal me the price of posting it to wherever you are in the world.
If something
On Friday 29 June 2012 12:13:31 Edheldil wrote:
On 06/28/2012 05:31 PM, Heiko Schulz wrote:
I have no idea how to communicate it or present it.
That's why I hoped that we maybe can have all three skydome variants
selectable. So we would have the default skydome, the skydome shader and
the
On Wednesday 27 June 2012 16:37:11 Heiko Schulz wrote:
Is there a way we can have all three possibilities (default, skydome shader,
Thorstens atmospheric light scattering) selectable?
Cheers
Heiko
Not quite, since both terrain-default and model-default effects have a
separate set of
On Wednesday 27 June 2012 18:39:30 Heiko Schulz wrote:
Hello all,
I think the problem now is that the nice scatter effect sky dome no longer
works correctly with any render mode in the git version. The scatter
effect sky dome will give you very pretty skies -- especially in
combination
On Wednesday 13 June 2012 12:05:42 Renk Thorsten wrote:
Now, random vegetation seems to increase vertex count a lot, and this may
well be not doable by just taking the code and applying it to the
vegetation (it didn't work with clouds either). So it probably needs a
dedicated approximation
On Tuesday 19 June 2012 12:29:34 Renk Thorsten wrote:
There is a simple solution to that. Move the work in the fragment
shader. You
won't be scene complexity bound, and you'll also have the correct depth
available as (...)
Right... but I need the projection of the vertex position into
On Monday 11 June 2012 07:25:44 syd adams wrote:
hi all.
I updated the Citation-II to use model-combined-deferred , but it
originally used reflect.eff.Try as i might i cant seem to get the
reflectmap section to work.Is this a bug? Ive tried greymaps and alpha
maps but see no effect . I get a
On Friday 08 June 2012 09:53:58 Renk Thorsten wrote:
tie to some yet unknown master switch?
Who has a plan?
* Thorsten
There's no master switch anymore. There's a property that's checked by some
nasal to set the quality of the shaders, but there's no master switch
available for effects.
On Wednesday 23 May 2012 10:23:12 Renk Thorsten wrote:
Using the default random building density, the tiles that are loaded
initially when sitting on the runway generates ~ 340k random
buildings.
We might be generating too many buildings then?
The greater Los Angeles area has between
On Wednesday 23 May 2012 12:10:16 Stuart Buchanan wrote:
Actualy the Geater LA + Inland Empire area should use more somewhat small
buildings, as the overwhelming majority of the residential buildings in
that area are individual houses, all the way E to San Bernardino.
So, are these
On Wednesday 23 May 2012 14:16:02 Emilian Huminiuc wrote:
So, are these areas defined as Urban, or Suburban/Town in our global
scenery?
-Stuart
Just by looking at how the terrain is textured in FG, I can say they are
defined as Urban.
And the mapserver seems to agree
On Wednesday 23 May 2012 11:20:28 Renk Thorsten wrote:
We're not talking a regionalized building placement concept here... we're
doing an order of magnitude case study for our average US-themed city.
* Thorsten
No, I think you're extrapolating from a particularly bad case of mismatch
On Wednesday 23 May 2012 12:05:05 Renk Thorsten wrote:
No, I think you're extrapolating from a particularly bad case of mismatch
between reality and simulation. I wasn't talking about regionalized
building
placement, I was talking about bad landclass representation in that
particular
On Saturday 12 May 2012 21:49:46 Stuart Buchanan wrote:
Unfortunately, it appears to no longer work when the lightfield shader
is enabled - the buildings all lose their textures.
I've had a look at the hierarchy of effects files, but can't see any
obvious problem. Do you have any idea what
On Friday 11 May 2012 22:19:43 syd adams wrote:
Hi guys,
Is it just me or has the model-combined shader stopped reflecting ?
Moving the model slider seems to have no effect now .
Syd
Hi Syd,
Any specific aircraft you're refering to? I've just tested it and it works.
(777-200ER and IAR80)
No, you got the system wrong.
When an effect inherits from another it rewrites those parts that are common
between the two xml files, keeping the parts that are different. Thus if
runway inherits from terrain the actual runway effect as seen by flightgear
gets a technique 4 of its own
On Wednesday 02 May 2012 07:55:19 Renk Thorsten wrote:
No, you got the system wrong.
When an effect inherits from another it rewrites those parts that are
common
between the two xml files, keeping the parts that are different.
Yes, but what's wrong with making that conditional based on
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote:
The default effects usually specify their techniques with higher numbers to
allow any inheriting effect to insert their own techniques below them,
techniques that get activated by the same condition.
Actualy this should read
On Wednesday 02 May 2012 10:53:31 Frederic Bouvier wrote:
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote:
The default effects usually specify their techniques with higher
numbers to allow any inheriting effect to insert their own
techniques below them, techniques that get
On Wednesday 02 May 2012 09:07:57 Renk Thorsten wrote:
So far we had: start with skydome shader on and landmass set to 4:
- models appear black and are not shaded properly
Click on landmass slider without changing the value:
- modelss jump to proper shading
I've made one more
On Wednesday 02 May 2012 12:13:23 Emilian Huminiuc wrote:
Using tied properties as uniforms?
http://code.google.com/p/flightgear-bugs/issues/detail?id=445
This is easily solvable using a property-filter (check
Environment/metarinterpolator.xml), that writes the properties to some other
place
On Wednesday 02 May 2012 09:18:15 Renk Thorsten wrote:
Using tied properties as uniforms?
I don't think so, because the same parameters do get updated per frame just
fine when shading the terrain.
* Thorsten
Hmm, that would be really strange, and a legitimate bug then.
Worth a try with
Sorry, was looking at the wrong shader. You don't assign the terminator to an
uniform in the technique n=5 in the model-default.eff.
Adding the correct entry fixes it here:
uniform
nameterminator/name
typefloat/type
What I think happens, is that, without the detail option on, the same shaders
are used for terrain and models (terrain-haze), thus they get the terminator
assigned from the teerain-default.eff. Once you enable the detailed shading
for the terrain, that uniform is no longer assigned, since in
On Wednesday 02 May 2012 10:08:07 Renk Thorsten wrote:
Sorry, was looking at the wrong shader. You don't assign the terminator
to an
uniform in the technique n=5 in the model-default.eff.
I'll be buggered... you're right. How embarrassing...
* Thorsten
I'll push a hot-fix then.
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote:
Fred,
One small question, what's with the multiple passes/ shader overrides and al
sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It
looks like a real mess.
I wanted to clear out the unneeded include_fog.vert
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
On Tuesday 01 May 2012 15:33:36 Emilian Huminiuc wrote:
The runway effect parameters override any parameters it has in common with the
terrain-default effect (since it inherits from it), it is not a bug, that's
how the system is supposed to work.
This is fixable by changing the snow texture
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
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
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.
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 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
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
1 - 100 of 169 matches
Mail list logo
