Erik Hofman wrote:
>> Why wait for a NASA Shuttle? There already exist several models to see
>> the /interesting/ effects at altitude, some which have changed with the
>> new ambient values.
>>
>
> For good or for bad?
> (and if for bad what exactly, or as precise as possible).
>
>
Bad, o
hf...@inmail24.com wrote:
>> Except for a few inconsistencies in xml style that already have been
>> mentioned I think it's worth adding it then.
>
> Maybe I am misunderstanding this issue, but I have been involved in
> using FlightGear at work for a number of simulation related projects
> during
Curtis Olson wrote:
> I agree that the property system is for generic data ... so adding
> color_vectors or position_vectors is really out of the scope of what it
> should be intended for. This is too specific and I agree that it
> creates a mess and there's then no good place to draw the line whe
Curtis Olson wrote:
> I agree that the property system is for generic data ... so adding
> color_vectors or position_vectors is really out of the scope of what it
> should be intended for. This is too specific and I agree that it
> creates a mess and there's then no good place to draw the line whe
Anders Gidenstam wrote:
> Hi,
>
> This small patch makes water dropped from Gerard's nice PBY Catalina
> extinguish wildfires.
>
> http://www.gidenstam.org/FlightGear/misc/WildFire/PBY-Catalina.diff
Committed, thanks.
-Stuart
---
Curtis Olson wrote:
> This isn't an argument for or against Tim's proposal in and of itself,
> but it's at least interesting to observe other real world cases that
> are at least partially similar. Has JSBSim run into any problems with
> it's journey down this path?
This has been one reason why
On Sun, Apr 5, 2009 at 2:21 PM, Jon S. Berndt wrote:
> The part that I was unsure about was to what extent FlightGear used
> relationships between and amongst properties (operations). If properties are
> used on the FlightGear side for input/storage only, then I’m OK with it as
> long as the code
The part that I was unsure about was to what extent FlightGear used
relationships between and amongst properties (operations). If properties are
used on the FlightGear side for input/storage only, then I’m OK with it as long
as the code remains backwards compatible – which, I’m sure, is a given.
On Sun, Apr 5, 2009 at 2:44 AM, Ron Jensen wrote:
> To claim the property system supports character arrays is wrong, and
> somewhat disingenuous. The property system supports strings as atomic
> units. You can not access the nth character of a string nor can you
> change only the nth character
S Andreason wrote:
> Hi Vivian,
>
> Why wait for a NASA Shuttle? There already exist several models to see
> the /interesting/ effects at altitude, some which have changed with the
> new ambient values.
For good or for bad?
(and if for bad what exactly, or as precise as possible).
One proble
I agree that the property system is for generic data ... so adding
color_vectors or position_vectors is really out of the scope of what it
should be intended for. This is too specific and I agree that it creates a
mess and there's then no good place to draw the line when the next person
comes alon
Sorry- no one yet has thrown in any windows. And I don't see that Tim want's
to do that.
Yes, maybe it could be problematic what he wants to introduce- but is far away
from destroying several things as I can understand here!
>You don't seem to understand this comparison. It's about taking
>s
Vivian Meazza wrote:
>> Melchior FRANZ wrote:
>>
>> Alright I've updated the ambient table (multiplied all values by 2.5)
>> Let me know what you all think with the CVS version of src/Time/light.cxx
>>
>
>
> Looks nice here, I hope others will agree.
>
>
I agree. Looks _very_ good now
Hi Vivian,
Why wait for a NASA Shuttle? There already exist several models to see
the /interesting/ effects at altitude, some which have changed with the
new ambient values.
One of said aircraft _is_ in CVS.
I am getting requests to make spaceships for Flightgear, faster than I
can possibly ma
* Gene Buckle -- Sunday 05 April 2009:
> So essentially since you may not get your way, you're going
> to take your ball and go home?
You don't seem to understand this comparison. It's about taking
something away so that others can't continue enjoying the game,
only because one doesn't have his w
On Sun, 5 Apr 2009, Melchior FRANZ wrote:
> * Curtis Olson -- Sunday 05 April 2009:
>> Without seeing anything so far that I would consider a compelling
>> argument against, I vote for giving Tim the green light here.
>> Developer convenience has almost always been a good enough reason
>> in the p
Melchior FRANZ wrote:
> * Heiko Schulz -- Saturday 04 April 2009:
>> How would it be better, and would all what Tim wants to do,
>> be still possible?
>
> The features that Tim is talking about (effects and stuff), and
> the XML and property tree representation do IMHO not have much
> to do with
Melchior FRANZ wrote:
> * Vivian Meazza -- Saturday 04 April 2009:
>> ?
>> , . ?
>> material/ambient ?
>
> I did't even look at that. The vector properties (that have already
> been rejected before) were enough for me to reject the whole second
> attempt to get this in. But I agree with all your p
Anders Gidenstam wrote:
> On Sat, 4 Apr 2009, Tim Moore wrote:
>
>> 1) Write the full vector every time a component is changed. This means
>> potentially 4 times the memory traffic to change a color, and leaves the
>> values stored in OSG in an inconsistent state for a time.
>>
>
> If efficienc
> Except for a few inconsistencies in xml style that already have been
> mentioned I think it's worth adding it then.
Maybe I am misunderstanding this issue, but I have been involved in using
FlightGear at work for a number of simulation related projects during the last
couple of years, and to
> Count me in as "some people" From the e-mail traffic on this list,
> "some people" also include some very talented developers:
>
> ?Jon Berndt:
> "I always came back to the conclusion that (vectors) would be a really
> bad idea. And it still is."
The more information I get about the proposal t
Good morning,
this is yet another mail in support of rethinking the current proposal:
All the mentioned features regarding XML based shaders support are indeed very
much desirable in FlightGear, but the proposed changes and approach, as well as
the posted snippet of XML effects in particular, j
Vivian Meazza wrote:
> Wow! Complicated or what? I can live with the colour stuff - just. But I
> think there's stuff there which will for ever catch me out:
I think it has about the same complexity as Ogre material scripts, with a
couple of
exceptions:
* The OpenGL features is more complicated.
Erik Hofman wrote:
>
> Heiko Schulz wrote:
>> Hi,
>> Well, for someone who don't have any ideas or knowledge about shaders, it
>> looks really complicated at the first sight. On the other site, it looks a
>> bit like the .osg-files, and with a bit diggin in, it would be
>> understandable for me
Erik wrote
> Vivian Meazza wrote:
>
> > I've now amended the table to reflect the static offset, and I'm happy
> with
> > the result.
>
> Even at midnight?
> I was worried the ambient might be too light with a static offset.
>
> > Do you want proceed with this, or just drop it?
>
> Lets get
Timothy Moore wrote:
> Erik Hofman wrote:
>> 1. Will ambient/r, ambient/g and ambient/b still be supported in other
>> locations besides xml embedded effects en techniques?
> That's my plan.
Ok, that's good to hear.
I think this will eliminate many of the objections.
Except for a few inconsist
Erik
>
>
> Melchior FRANZ wrote:
> > * Vivian Meazza -- Saturday 04 April 2009:
> >> This is how I think it should look,
> >
> > Does indeed look much better here (on my *still* quite bad monitor ;-).
>
> Alright I've updated the ambient table (multiplied all values by 2.5)
> Let me know what y
Vivian Meazza wrote:
> I've now amended the table to reflect the static offset, and I'm happy with
> the result.
Even at midnight?
I was worried the ambient might be too light with a static offset.
> Do you want proceed with this, or just drop it?
Lets get it right this time.
Erik
-
Erik Hofman wrote:
> Tim Moore wrote:
>> If people really don't like the effects syntax, I might be willing to hold
>> my nose
>> and use the existing property implementation. I'm also not committed to
>> having the
>> effects properties be of class SGPropertyNode; they might be a subtype.
>
> I
Erik wrote
> Vivian Meazza wrote:
>
> > I'm doing a small adjustment in light.cxx - seems to work:
> >
> > float ambient = _ambient_tbl->interpolate( deg ) + (0.25 + 0.75 *
> > visibility_inv/10);
> >
> > Not sure that I fancy tinkering around in Data/Lighting/ambient -
> someone
> > has ob
Melchior FRANZ wrote:
> * Vivian Meazza -- Saturday 04 April 2009:
>> This is how I think it should look,
>
> Does indeed look much better here (on my *still* quite bad monitor ;-).
Alright I've updated the ambient table (multiplied all values by 2.5)
Let me know what you all think with the CV
Ron Jensen wrote
>
> On Sat, 2009-04-04 at 20:54 -0500, Curtis Olson wrote:
> > Since the beginning of time, computers have included the concept of
> > arrays.
> >
> > Since the birth of the property system in FlightGear, it has supported
> > booleans, integer, floating point, and double floating
On Sat, 2009-04-04 at 20:54 -0500, Curtis Olson wrote:
> Since the beginning of time, computers have included the concept of
> arrays.
>
> Since the birth of the property system in FlightGear, it has supported
> booleans, integer, floating point, and double floating point types.
> The property sys
Curtis Olson wrote:
> I don't have time to follow along with IRC so I can only see what is
> posted to the mailing list, so I very well could be missing key parts of
> this discussion. But honestly, I am really having trouble understanding
> the objection here.
The biggest problem that I wou
Heiko Schulz wrote:
> Hi,
> Well, for someone who don't have any ideas or knowledge about shaders, it
> looks really complicated at the first sight. On the other site, it looks a
> bit like the .osg-files, and with a bit diggin in, it would be understandable
> for me at least.
>
I'm sorry tha
Hi Melchior,
Melchior FRANZ wrote:
> * Curtis Olson -- Sunday 05 April 2009:
> > Without seeing anything so far that I would consider a compelling
> > argument against, I vote for giving Tim the green light here.
> > Developer convenience has almost always been a good enough reason
> > in the pa
36 matches
Mail list logo
