Hi All,
I've just committed to simgear/next and fgdata/master code to allow
the placement and rotation of random objects and vegetation to be
masked based on a bitmap.
So we can now control the placement and rotation of random objects
precisely to match the underlying terrain texture. So, for far
On Sun, Feb 5, 2012 at 12:50 PM, Thorsten Renk wrote:
> I haven't really seen any guidelines about efficient shader coding, but
> I've come across a few statements here and in the forum now and then,
> which I so far assumed to be true. I've now spent the last few days
> benchmarking my lightfield
On Mon, Jan 23, 2012 at 8:08 AM, Thorsten Renk wrote:
> Stuart Buchanan wrote:
>> BTW, if this change is merged into the 2.6.0 branch, we should also include
>> commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes
>> a now-redundant reference to the local_weather_til
On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote:
> And I just pushed that to FGDATA. "Global Weather" and "Local Weather"
> is dead. Long live "Basic Weather" and "Advanced Weather" :-)
Thanks Torsten. That looks great.
BTW, if this change is merged into the 2.6.0 branch, we should also inc
On Fri, Jan 20, 2012 at 12:21 PM, Stuart Buchanan wrote:
> Also, I noticed that there's another local_weather.xml dialog under
> gui/dialogs
> that appears to be obsolete. Can you confirm that it can be deleted?
Scratch that - I've just noticed this is used in the D
On Fri, Jan 20, 2012 at 9:59 AM, Thorsten Renk wrote:
>
> My GIT is now a week old, but in all likelihood this hasn't changed and is
> in the release branch:
>
> In reaction to concerns about a confusing menu structure, I moved all
> relevant configurations to
>
> /gui/dialogs/local_weather_tiles.x
On Sun, Dec 18, 2011 at 9:31 PM, Stuart Buchanan wrote:
> On Sun, Dec 18, 2011 at 8:18 PM, Torsten Dreyer wrote:
> I suggest we default the impostors to be switched off by default.
> That's a trivial
> change to line 72 of cloudfield.cxx. I don't know if that impacts the
&g
On Mon, Jan 16, 2012 at 10:40 AM, Thorsten Renk wrote:
>> This behaviour is hardcoded, as there needs to be a default fallback
>> effect/shader when none is specified in the model and shaders are turned
>> on.
>
> Yes, I know that - but can you somehow catch that it's a cockpit you're
> loading rat
On Fri, Jan 13, 2012 at 9:28 AM, Thorsten Renk wrote:
>> ***
>>
>> weather_tiles.nas, line 1004;
>>
>> var alt = spread * 400.0 +
>> local_weather.cloud_vertical_size_map["Nimbus"]
>> * 0.5 * m_to_ft;
>>
>> has an obsolete altitude correction in and should just be
>>
>> var alt = 400.0;
>>
>> to ge
On Wed, Jan 11, 2012 at 9:16 AM, Thorsten Renk wrote:
>> Rather than passing in the eye position as a uniform, why not
>> pass in the cloud altitude instead? Is this simply to avoid
>> needing to modify the C++ code?
>
> I thought uniforms are things which are per frame constant in the scene
> and
On Wed, Jan 11, 2012 at 8:09 AM, Thorsten Renk wrote:
> I have now a scheme that does seem to do the trick - high stuff and stuff
> towards the sun glows properly before lower stuff and stuff away from the
> sun.
>
> http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=15#p147240
Ver
On Tue, Jan 10, 2012 at 5:14 PM, Eric van den Berg wrote:
> Is indeed JSBSIM and that did the trick. Engine running!
Great. Will you be committing a fix to fgdata, or do you need
someone else to do that?
-Stuart
--
Write
On Tue, Jan 10, 2012 at 4:36 PM, Eric van den Berg wrote:
> On current Git the Mig-15 engine cannot be started. I routed the problem
> to a missing "/engines/engine[]/out-of-fuel" property that is there on 2.4.
> Checking revealed this is the same for the c172p (not sure with what
> effect), but no
On Mon, Jan 9, 2012 at 10:00 AM,
>> I don't think the Model matrix will help you much either, as IIRC
>> (0,0,0) is the center of the earth spheroid.
>
> Hm, the line is
>
> gl_Position = gl_ModelViewProjectionMatrix * gl_Position;
>
> Doesn't gl_ModelViewProjectionMatrix transform things into 2
Hi Thorsten,
No, I don't think gl_Vertex.z will give you the cloud altitude. That's
just the vertex position relative to the sprite center. glColor is
used to pass in the sprite location relative to the cloud center, and
the Model Matrix places the cloud relative to the rest of the scene.
I don't
On 6 Jan 2012, at 06:34, Tuomas Kuosmanen wrote:
> Just a random thought: does (could) it have both hPa and InHg scale in the
> baro window? Would be very practical. Those exist in real life, there sre
> just two baro scale windows on opposite sides of the gauge face.
An alternative way to do t
On Tue, Jan 3, 2012 at 12:54 PM, Stuart Buchanan wrote:
> On a related note I noticed that the menu option to change the lat/Lin format
> has been removed. Given how useful it is to have a decimal degrees read out
> for scenery development that seems somewhat strange. Was this in
Hi Stephan,
On Wed, Jan 4, 2012 at 8:07 PM, Stephan Bourgeois wrote:
> Hello everybody,
>
> I have a new Altimeter ready for the c172p cockpit. However, I have a few
> questions regarding the panel illumination.
>
> 1. All the current instruments, except the AI (gyro) have illuminated knobs.
> S
On Wed, Jan 4, 2012 at 12:08 AM, Gijs de Rooy wrote:
> menu option is greyed out when MP is not enabled on startup (via
> commandline/fgrun).
> maybe add a note like "Individual servers can be down"? Could even add a
> button to open
> the mpstatus website. People don't Read That Fine Manual, so we
On Wed, Jan 4, 2012 at 9:51 AM, James Turner wrote:
> Right now setting an empty host is the way to disconnect it. A separate
> 'connect' boolean input to the code could be arranged, which triggers
> connection & disconnection when set - but obviously this also needs to keep
> compatibility with
On Tue, Jan 3, 2012 at 10:40 PM, James Turner wrote:
>
> On 3 Jan 2012, at 21:34, Stuart Buchanan wrote:
>
>> OK. I'll make the appropriate hardcoded changes for the moment and
>> update The Manual to describe using the dialog for connecting to the
>> MP environment
On Tue, Jan 3, 2012 at 1:36 PM, James Turner wrote:
>
> On 3 Jan 2012, at 12:54, Stuart Buchanan wrote:
>
>> I noticed the MP Settings dialog which I'm sure has been there for ages
>> without me seeing it. Should this now be documented as the standard way to
>>
On Tue, Jan 3, 2012 at 4:44 PM, Thorsten Renk wrote:
> Does this contain the impostor functionality already or not?
No - the Impostor function will be committed after the 2.6.0 release.
-Stuart
--
Write once. Port to ma
Hi All,
I'm going through the GUI to update the Manual with the correct menu items for
the upcoming release.
I noticed the MP Settings dialog which I'm sure has been there for ages without
me seeing it. Should this now be documented as the standard way to enable MP,
abs should there be a che
On Wed, Dec 28, 2011 at 3:45 PM, Stuart Buchanan wrote:
> On Wed, Dec 28, 2011 at 3:04 PM, >> 4) Clouds now appear to be loaded in discrete lumps when they come into
>>> visual range rather than gradually be faded in via transparency which
>>> looks a bit ugly from high
On Wed, Dec 28, 2011 at 3:04 PM,
> Local Weather is now (almost) in the shape I would like to see in the
> release, and I've worked quite a bit through the list of issues:
Great!
>> 4) Clouds now appear to be loaded in discrete lumps when they come into
>> visual range rather than gradually be
On Tue, Dec 20, 2011 at 9:16 PM, Stuart Buchanan wrote:
> Hi All,
>
> I'm investigating
> http://code.google.com/p/flightgear-bugs/issues/detail?id=526, which
> appears to be a long-standing bug that after fuel starvation it isn't
> possible to restart YASim engines.
&
On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote:
> I've already managed to use a second texture to mask where trees are
> placed. The following screenshot shows a golf course where I've used
> a mask so that the random trees are only placed in the rough.
>
>
On Mon, Dec 26, 2011 at 12:07 AM, Martin Spott wrote:
> There are different ways to prevent a service outage. Setting up a
> second machine is just one of various different methods and you're
> well-advices to have a precise look at the bigger picture, evaluate the
> benefit against the drawbacks b
Hi All,
The rating system
(http://wiki.flightgear.org/Formalizing_Aircraft_Status) has now been
in place for some time, and a number of aircraft are rated.
Additionally Fred B. has added rating information to FGRun, which is excellent.
A question for Curt - would it be possible to include the ai
On Wed, Dec 21, 2011 at 5:53 PM, Torsten Dreyer wrote:
>> Agreed - that's a mistake in my checkin. I will correct it.
>>
>> -Stuart
>
> OK - one more.
>
> velocity including the propulsion induced
> velocity.
>
> velocities/u-aero-fps
> propulsion/engine/prop-induced-velocity_fps
>
On Wed, Dec 21, 2011 at 11:00 AM, Torsten Dreyer wrote:
>>
>> I prefer manually syncing and checking that the changes are valid, rather
>> than
>> blindly over-riding what we've already got.
>
> Hi Stuart,
>
> this
> -
> - aero/alpha-rad
> -
On Wed, Dec 21, 2011 at 9:51 AM, Martin Spott wrote:
> Stuart Buchanan wrote:
>> On Mon, Dec 19, 2011 at 10:07 AM, Martin Spott wrote:
>>> Ron Jensen wrote:
>>>
>>>> I just noticed the c172p.xml (FDM) in FGData doesn't match the one in
On Wed, Dec 21, 2011 at 9:40 AM, Stuart Buchanan wrote:
> I've not committed these changes to the FG c172p FDM.
Sorry, that should be "I've _now_ committed these changes to
the FG c172p FDM"
-Stuart
On Mon, Dec 19, 2011 at 10:07 AM, Martin Spott wrote:
> Ron Jensen wrote:
>
>> I just noticed the c172p.xml (FDM) in FGData doesn't match the one in JSBSim.
>
> What's your conclusion ?
Conclusion is that the FG c172p FDM is out of date and doesn't include
the latest changes
that Ron made to "Add
Hi All,
I'm investigating
http://code.google.com/p/flightgear-bugs/issues/detail?id=526, which
appears to be a long-standing bug that after fuel starvation it isn't
possible to restart YASim engines.
The problem appears to be in fuel.nas line 25, which drops out from
making any fuel calculations
On Sun, Dec 18, 2011 at 8:18 PM, Torsten Dreyer wrote:
>> One question for the release managers: Do performance improvements such as
>> these count as bug fixes or features? Should we try to get this into
>> the 2.6.0 release, or wait until 2.8.0?
>
> For me, 3d clouds are currently mostly unusable
2011/12/18 Mathias Fröhlich wrote:
> Good to see!
> And in fact without testing too much I think we are on the right track.
> Just starting and comparing the frame rates with and without the changes gives
> a 3x performance boost on my setup!
Excellent.
> So, since you do not see that huge differ
On Sun, Dec 18, 2011 at 5:06 AM, Patrick Callahan wrote:
> What can be said about the flight dynamics of the C172P model?
> Is it accurate? If not, how could it be improved?
It's currently got a "3" rating. It matches some of the PoH numbers
(cruise speed, rate of climb) for an aircraft fitted wi
On Fri, Dec 16, 2011 at 2:34 PM, Adrian Musceac wrote:
> On Friday, December 16, 2011 14:57:24 Olivier wrote:
> Type's already done (sort of), but the foam I have no clue how to get rid of
> it other than a different model.
> Some images near Amsterdam harbour:
> http://i.imgur.com/gNBqS.jpg
> htt
2011/12/15 Stuart Buchanan wrote:
> I made the changes you suggested last night so that there is a single
> geometry per cloud instead of one per sprite. That should have reduced
> the number of draws by a factor of 10.
>
> The code isn't ready to be checked in (I've still
2011/12/15 Mathias Fröhlich wrote:
> On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote:
>> 2011/12/14 Mathias Fröhlich wrote:
>> > But, the question is how many cloud drawables do we have? The render Bin
>> > sorting bottleneck - if we run into this
On Wed, Dec 14, 2011 at 4:52 PM, Fernando García Liñán wrote:
> Hello Stephan,
>
> It looks nice so far! But someone has already improved it, you can find more
> info here: http://flightgear.org/forums/viewtopic.php?f=14&t=10187
The changes Fernando refers to were applied before the 2.4.0 release,
2011/12/14 Mathias Fröhlich wrote:
> But, the question is how many cloud drawables do we have? The render Bin
> sorting bottleneck - if we run into this - is O(log(n)*n) with the n= number
> depth sorted drawables. Which means we need to have a huge amount of cloud
> drawables that this effect domi
On Mon, Dec 12, 2011 at 8:19 AM, Erik Hofman wrote:
> This reminds me that vegetation uses a texture strip with 8 different
> trees at a size of 256x64 pixels whereas clouds use one texture for
> every cloud (puff) using 256x256 pixels. Maybe that makes a difference?
It varies by cloud definition,
On Wed, Dec 14, 2011 at 10:35 AM, Thorsten R. wrote:
> Thanks to Hooray who helped me setting up the CMake environment and the
> guys at Infocare who finally managed to fix heat management of my
> computer, I am now back on the devel tree. I've done a few tests yesterday
> and identified a list of
On Thu, Dec 8, 2011 at 10:47 AM,I wrote:
> 2011/12/8 Mathias Fröhlich wrote:
>> If I do not respond to list mails when you need some response, fell free to
>> contact me directly. I just miss some mails every now and then ...
>
> Thanks for the offer. Will do.
I've had a look, and I think I can ch
2011/12/8 Mathias Fröhlich wrote:
> The cloud code changes its internal data structures in the draw call?
> Or are these lists per context data structures?
> This is kind of proboblematic for two reasons:
> 1. draw happens in paralell in all configured multi viewer contexts. So I fear
> concurrent
2011/12/6 Mathias Fröhlich wrote:
> As usual, I did not take the time to really look into the code. So please
> excuse more or less obvious questions about the current implementation.
The relevant code is newcloud.[c|h]xx and CloudShaderGeometry.[c|h]xx
in simgear/scene/sky/
It's entirely possibl
On Mon, Dec 5, 2011 at 12:32 PM, Vivian Meazza wrote:
> Emilian and I noticed that the "local" cloud effect files are using render
> bin 10 - thus competing with all other transparent objects, while the
> "global" clouds use render bin 9 - the dedicated cloud bin. We have tried
> moving all the clo
On Mon, Dec 5, 2011 at 8:26 AM, Thorsten Renk wrote:
> Since according to the newsletter Stuart's current ongoing quest is to get
> better performance for 3d clouds, here are some of my observation:
Thanks very much for the observations. Lots of food for thought :)
As an FYI, the investigations
On Sun, Dec 4, 2011 at 1:08 PM, kreuzritter2000wrote:
> And Vadym Kukhtin wrote:
>> Can you use low-bit gray (or index) mask, to indicate not only placed
>> or not, but also rotate angle? Then it will be possible to align
>> buildings along main streets.
>
>
> AFAIK Microsoft used the textures its
On Thu, Dec 1, 2011 at 8:07 AM, James Turner wrote:
> - I don't think you need to worry about a cuboid per floor - only define
> some (irregular) trapezoids for the floor plans, and simply extrude them to a
> height - with suitable random generation of the heights.
I was thinking I'd need a cub
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on .ac models, plus the Urban shader.
The former are limited in that performanc
On Tue, Nov 29, 2011 at 10:14 PM, Arnt Karlsen wrote:
> On Tue, 29 Nov 2011 10:26:10 -0600, Curtis wrote in message
>> On Tue, Nov 29, 2011 at 8:35 AM, Stuart Buchanan wrote:
>>
>> > I came across the FS Break podcast (http://www.fsbreak.net/) just
>> > the
Hi All,
I came across the FS Break podcast (http://www.fsbreak.net/) just the
other day, which discusses flight simulation - mainly FS-X and
X-Plane.
I think it would be worth arranging some interview/announcement for
when the 2.6.0 release comes out.
I'm happy to run this, but thought it would
On Sat, Nov 26, 2011 at 8:45 PM, Martin Spott wrote:
> Stuart Buchanan wrote:
>
>> I'm working on it right now...
>
> Note, it's having sister-pages "Speyside" and "Western Isles",
Yup, got that. Fortunately the writer had a very systematic numbe
On Sat, Nov 26, 2011 at 7:51 PM, Martin Spott wrote:
> Stuart Buchanan wrote:
>
>> I will be treating myself to a small glass of Balvenie as a reward :)
>
> Btw, while we're at it, I'm looking for a volunteer to retrieve the
> coordinates from this website so we can
On Mon, Nov 21, 2011 at 11:41 AM, Martin Spott wrote:
> Stuart Buchanan wrote:
>
>> I don't think there is any particularly good reaon for the
>> dependency, for either the trees or the clouds. I'm away at the
>> moment but will look at uncoupling them later in
On 20 Nov 2011, at 22:19, "Vivian Meazza" wrote:
> I can’t see any reason for the dependency
> between 3d clouds and Material Shaders,
> but Stuart might enlighten us.
I don't think there is any particularly good reaon for the dependency, for
either the trees or the clouds. I'm away at the mom
On Sat, Nov 12, 2011 at 10:05 AM, Frederic Bouvier wrote:
>> See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
>
> And what about this one ?
> http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png
Of the two, I prefer the stars. Great work.
Out of interest, what are you pl
On Fri, Nov 11, 2011 at 7:54 PM, Frederic Bouvier wrote:
> See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
Great work Fred. Thanks!
Now, does anyone want to take on modifying the Download Aircraft page
to allow filtering based on rating?
I think that would make a huge difference i
Hi All,
As part of some work that Jorg (jomo) is doing to improve the manual,
I've spent a little time trying to improve the HTML output of our
Latex toolchain by getting my head around the htlatex package.
The first results are here:
http://www.nanjika.co.uk/flightgear/getstarthtml/getstart.htm
On Wed, Oct 19, 2011 at 10:19 AM, Cedric Sodhi wrote:
>> other developers may take care of your work when you're not around,
>> others will feel responsible to provide support if they can,...).
>
> I think we have sufficiently seen how other people's work is taken care
> of after they leave. And ho
On Tue, Oct 18, 2011 at 5:33 PM, Stuart Buchanan wrote:
> On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
>> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
>> they are programmed to expect their own data files to be found in
>> FGDATA. These airpl
Good work guys. Thanks.
On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
> they are programmed to expect their own data files to be found in
> FGDATA. These airplanes will give you an error if you put them outside
> of F
On Thu, Oct 13, 2011 at 9:23 AM, Thorsten Renk wrote:
> Hi Stuart,
>
> after some testing of the new scheme, I have two minor and one major
> comment. Minor stuff first:
>
> * how is the cloud density slider supposed to influence the clouds
> generated by add-cloud? Heiko claims that he gets to see
On Sat, Oct 8, 2011 at 6:53 PM, I wrote:
> On Sat, Oct 8, 2011 at 7:56 AM, Stuart Buchanan I wrote:
>> Thanks for the reports. I suspect something has gone wrong
>> with my merge. Unfortunately I wont be able to look at it until tonight.
>>
>> Sorry for breaking the bu
On Sat, Oct 8, 2011 at 7:56 AM, Stuart Buchanan wrote:
> Thanks for the reports. I suspect something has gone wrong with my merge.
> Unfortunately I wont be able to look at it until tonight.
>
> Sorry for breaking the build.
>
> -Stuart
I've identified what's g
Thanks for the reports. I suspect something has gone wrong with my merge.
Unfortunately I wont be able to look at it until tonight.
Sorry for breaking the build.
-Stuart
On 7 Oct 2011, at 23:35, syd adams wrote:
> Me too , with ATIMobility Radeon HD 4250
>
> On Fri, Oct 7, 2011 at 11:55 AM
On Wed, Oct 5, 2011 at 10:36 PM, I wrote:
> Yes - I've managed to repro the problem. My previous fix was insufficient.
>
> I've got another fix, that I think solves the problem, but unfortunately I've
> got a bunch of simgear merge requests stacked up on gitorious right
> now, so it may be some ti
On Thu, Oct 6, 2011 at 8:22 AM, Thorsten Renk wrote:
> Some observations I've made in the last couple of days:
>
> * hardcoded terrain presampling: This seems to have died on me after the
> last pull (probably even earlier?) - currently all I get out is zero
> everywhere. Since geodinfo() is now 5
On Mon, Oct 3, 2011 at 1:03 PM, Thorsten Renk wrote:
>>> What's the status of the flat layer on curved Earth problem by the way?
>
>> This should have been fixed since September 12th in git.
>>
>> https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6
>>
>> Are you still
On Mon, Oct 3, 2011 at 11:08 AM, Thorsten Renk wrote:
> What's the status of the flat layer on curved Earth problem by the way?
This should have been fixed since September 12th in git.
https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6
Are you still seeing the prob
On 1 Oct 2011, at 11:25, Thorsten Renk wrote:
> I see. So what do I do when I want to change the wind and want the clouds
> to follow the new setting? Simply do a setprop for the layer height
> setting it to the same value it was?
For the moment, Yes.
At some point in the future we should fix it
On Mon, Sep 12, 2011 at 3:55 PM, Thorsten Renk wrote:
>>> 3) Antishading
>
>> If you can provide the parameters of a cloud that is exhibiting the
>> problem, that would be most useful.
>
> Okay, I've decided over the weekend that I'll make my current code
> available this week, because there's so m
On Sat, Sep 17, 2011 at 4:37 PM, Durk Talsma wrote:
> Hi All,
> I just added some new code to src/Main/fg_init.cxx that allows FlightGear's
> airport dynamics functions to give you a valid parking position without
> having to bother about the details of whether the parking is of hte right
> type, w
On Sat, Sep 17, 2011 at 6:29 PM, Citronnier - Alexis Bory wrote:
> Hi,
>
> Unfortunately I'm stuck at the same point with no idea on how to solve
> this one. Here the error with my own paths:
> CMake Error at
> /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70
> (MESSAGE):
>
On Wed, Sep 14, 2011 at 12:33 PM, Andreas Gaeb wrote:
> Am 14.09.2011 11:43, schrieb Erik Hofman:
>> I've been pushing this behavior various times and scenery objects should
>> always be positioned at the same location over and over again.
> To clarify things up a bit, not all is broken:
> - Houses
On Wed, Sep 14, 2011 at 12:58 PM, James Turner wrote:
>
> On 14 Sep 2011, at 12:00, Stuart Buchanan wrote:
>
>> OK. We've got something similar already in the C code for exactly this
>> purpose. Might be more efficient to simply expose that over Nasal, but
>>
On Wed, Sep 14, 2011 at 11:18 AM, Thorsten Renk wrote:
>> Thorsten Renk - If this something we need to be thinking about for the
>> Local Weather as well?
>
> We've been tossing the idea around in the forum that Local Weather stops
> using the rand() function from Nasal and uses its own internal r
On Wed, Sep 14, 2011 at 10:31 AM, Jörg Emmerich wrote:
> 1) Writer, Poet, Engineering, Marketing, etc.
> Most of those surely do not want to be bothered with the final looks of
> their design - but surely some do (and then run into problems).
(I think the Marketing person here is part of the secon
On Wed, Sep 14, 2011 at 10:43 AM, Erik Hofman wrote:
> Is this broken.. again?
> Sigh.
>
> I've been pushing this behavior various times and scenery objects should
> always be positioned at the same location over and over again.
This may just be broken in the default 3D clouds code. I'll take a lo
2011/9/12 Mathias Fröhlich :
> On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote:
>> My error was in SimGear, and your fix was for FlightGear, it I'm correct.
>> So, I'm not sure if that would fix it.
> Hmm, then probably not...
> ... but I have done the same change in the identical file in
On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote:
>> I'd really like the 3D cloud infrastructure to be used for all the
>> clouds, so
>> if there are features missing we should address them.
>>
>> Would it be possible to modify the 3D clouds so that they can be used for
>> the rain texture as
On Sat, Sep 3, 2011 at 8:15 AM, Thorsten Renk wrote:
> 1) placement in flat layer instead of curved
OK. I'll get the fix for this committed as soon as I get the
chance.
> 2) clouds don't obscure some objects (newly discovered)
This may be a problem related to the rendering order of objects
wit
On Mon, Sep 5, 2011 at 2:45 PM, I wrote:
> More comments when I get the time once I'm back.
Hi Jomo,
I finally got the time to look at your work in detail. I think there's
a lot of really good work here, and it obviously represents a lot of
time and effort. Thanks again.
I _really_ like a number
On 6 Sep 2011, at 09:12, Jörg Emmerich wrote:
> Thank you both very much for your interest and encouragement
No problem. It is great that someone is interested in the docs. Unfortunately I
think you could have saved yourself a lot of effort if you'd posted 6 months
ago :(
As you'll see from my
On 1 Sep 2011, at 08:37, Jörg Emmerich wrote:
> I wanted to introduce that outcome about end of this month to the
> dev-team, to see especially whether the "Originators of the getstart"
> still find their share in what I did, and concur to this change. I hope
> nobody feels offended by my partly dr
On Wed, Aug 17, 2011 at 3:52 PM, I wrote:
> Yes, it's a bug in the cloud positioning code which is placing the clouds
> in a completely flat layer rather than curved.
>
> Fixing this may be a bit tricky.
I've got a fix for handling this on intial placement, but I've still to extend
the fix to hand
On Tue, Aug 16, 2011 at 8:17 AM, wrote:
> ... and yet another issue:
>
> On a first long-range test yesterday, I observed that the cloud base of my
> convective layer was continuously rising. At takeoff the clouds were
> exactly as specified, later still plausible given terrain, but by the time
>
On Sat, Aug 13, 2011 at 12:02 PM, Thorsten Renk wrote:
> Thanks. I have to take a look at the max-cloud-height-m - currently I'm
> only setting min-cloud-height-m for the following reason:
>
> It seems to me that the cloud *center* gets placed at (alt-ft +
> layer_altitude), such that (0.5 * clou
On Fri, Aug 12, 2011 at 10:52 AM, Thorsten Renk wrote:
>> Yes, the sprite is selected from the sheet randomly on the x-axis and
>> based on it's height in the cloud on the y-axis for precisely this
>> reason.
>>
>> The behaviour isn't switchable at present though it could be.
>>
>> For the relativ
On Thu, Aug 11, 2011 at 9:29 AM, Thorsten Renk wrote:
>
> Some progress and minor issues:
>
> I am in the process of redoing textures and cloud definitions for Cu
> layers (the toughest nut), about halfway through converting all available
> cloud types.
>
> I have implemented tested tile managemen
2011/8/7 Mathias Fröhlich wrote:
>
> Hi Stuart,
>
> I have checked in a version of the ground intersection routines that
> just use the bvh trees in the scenegraph.
> This should improove the run time behaviour for the ground queries.
> That should be even faster than the variant you tried since it
2011/8/7 Mathias Fröhlich wrote:
> I have now seen that this has overlapped a question from yours form yesterday
> evening. I just got up today morning, took a look outside - still no summer in
> mid europe - and decided to hack something. Then I just thought that this
> change might be good to hav
On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote:
>> We should change the maximum to whatever you feel is sensible
>> (40km?), and leave the default as it is (20km).
>
> I think my current maximum is 45 km, and for much more one needs a
> different tile structure anyway, so if we could get 45 k
On Sun, Aug 7, 2011 at 1:03 PM, Thorsten wrote:
>> I think the problem is that you are expecting the cloud height to
>> indicate the location
>> of sprite centers, wherease the code is expecting it to be the height
>> of the actual
>> cloud.
>>
>> The code actually _subtracts_ the minimum texture h
On Sun, Aug 7, 2011 at 11:24 AM, Thorsten Renk wrote:
> Upon further reflection - could it be the problem that I'm trying to
> assemble a layer rather than fill a volume?
>
> The bottom shading in 3dcloud.vert is controlled by a combination of
> 'shade' and 'cloud_height'. Your Nasal interface doe
2011/8/7 Mathias Fröhlich:
> I have checked in a version of the ground intersection routines that
> just use the bvh trees in the scenegraph.
> This should improove the run time behaviour for the ground queries.
> That should be even faster than the variant you tried since it avoids the
> extra com
301 - 400 of 1047 matches
Mail list logo
