On Wednesday 08 April 2009, Tim Moore wrote:
> LeeE wrote:
> > I've been following this but I don't remember anyone, in either
> > camp, pointing out where it brings a significant performance
> > increase, or where the failure to adopt it will result in a
> > significant performance drop. I specif
Stuart Buchanan wrote:
> Tim Moore wrote:
>> I'm trying to give your generic approach a chance.
>
> I may be mis-interpreting your words, but if this means you're actively
> investigating coding your new changes without vectors, then you deserve
> many heartfelt thanks for putting extra effort
Hi Tim,
On Wednesday 08 April 2009 22:25:49 Tim Moore wrote:
> Here's the theory: the values in question, such as material colors
> or vector parameters for a shader, must be set in a vector operation
> in OSG. The values are set at startup and also at runtime by material
> animations. Typically
Hi again,
On 2009/04/07, at 21:04, Tim Moore wrote:
> Tatsuhiro Nishioka wrote:
>>
>> As Melchior alrwady said, the new format has nothing to do with what
>> Tim really wants (performance improvement). A node with 3 or 4 float
>> numbers can be converted into a vector class internally in C++ code
On Wed, Apr 8, 2009 at 3:02 PM, Melchior FRANZ wrote:
> It's just that Curt referred to what you told him in private conversation
> apparently as a base for his opinion about the matter. And I think that
> others could use that same information as well to form theirs. Unless
> there's stuff that
* Tim Moore -- Wednesday 08 April 2009:
> Here's the theory: the values in question, such as material
> colors [...]
OK, so on the OSG side it will always be a function call. There
can by no tying (no matter which property types). On the fgfs
side you can tie to memory, I assume. (red/green/blue/
Tim Moore wrote:
> Melchior FRANZ wrote:
> > Nobody wants to see fgfs stagnate. But that doesn't justify every
> > approach, no matter which bad side effects. There is an alternative
> > solution with *no* bad side effects, but all the same possibilities.
> > None of the vector-property supporters
LeeE wrote:
>
> I've been following this but I don't remember anyone, in either
> camp, pointing out where it brings a significant performance
> increase, or where the failure to adopt it will result in a
> significant performance drop. I specifically asked about this in
> one of my earlier
* Tim Moore -- Wednesday 08 April 2009:
> I'm trying to give your generic approach a chance. I think a system
> where you have to explicitly trigger a listener is a poor substitute
> for one where the listener is fired automatically.
But you'd only have to do it manually from the property browser
* Durk Talsma -- Wednesday 08 April 2009:
> The actual drop in frame rate observed by adding lots of traffic lies
> somewhere in the graphics code [...]
> If you really think the traffic manager code is inefficient: Please
> prove it [...]
N! I don't think that, and I have no clue about that
Melchior FRANZ wrote:
> Nobody wants to see fgfs stagnate. But that doesn't justify every
> approach, no matter which bad side effects. There is an alternative
> solution with *no* bad side effects, but all the same possibilities.
> None of the vector-property supporters even bothered to explain wh
On Wednesday 08 April 2009 20:10:48 Melchior FRANZ wrote:
> - turn off the traffic manager! (I'm sure you aren't just wasting
> cycles there, and there just *is* a lot to do. That's not meant
> as criticism!)
>
The actual drop in frame rate observed by adding lots of traffic lies
somewhere i
On Wednesday 08 April 2009, Durk Talsma wrote:
> On Tuesday 07 April 2009 21:28:34 syd adams wrote:
> > This is getting over my head ... but I'd prefer not to see FG
> > stagnate because of fear of the unknown ... it sounds like an
> > interesting idea but I dont understand the code as well as
* Melchior FRANZ -- Wednesday 08 April 2009:
> But have you noticed that many subsystems use the property system in
> the slowest possible way?
>
| double f = fgGetDouble("/some/longish/property/path");
No, wait! The slowest possible way is to build the property path
first with sprintf(), althou
Hi all,
I am a programmer and I also have a hard time to understand the impact
of the suggested changes. What I understand though is that strong egos
are battling it out on this mailing list.
There is a source code repository that supports branches. Use that! I am
sure git supports simple mer
* Melchior FRANZ -- Wednesday 08 April 2009:
> var f = fgGetDouble("/some/longish/property/path");
Oops. Make that double f = ...
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative E
* Heiko Schulz -- Wednesday 08 April 2009:
> I don't think that Tim has not enough expertise [...]
No, of course he has that. And so has Mathias.
> to see at the next morning that you slamed this proposal code
> changes before Tim even announced his proposal and put in here
> for discussion.
Y
* Durk Talsma -- Wednesday 08 April 2009:
> Just the fact that a few extensions of the existing property types
> can have a positive impact on rendering speed, [...]
I wonder if it's worth to add a lot of complexity for that, though.
Do you know what users are usually told to do to increase the
I'm not a programmer, so I don't understand what influences this changes takes
and what could be the side-effects. But I can read ;-) and can see that in the
moment 50% of the main developers are for this changes and 50% are against.
I don't think that Tim has not enough expertise that he had
Nobody wants to see fgfs stagnate. But that doesn't justify every
approach, no matter which bad side effects. There is an alternative
solution with *no* bad side effects, but all the same possibilities.
None of the vector-property supporters even bothered to explain why
this generic approach wouldn
On Tuesday 07 April 2009 21:28:34 syd adams wrote:
> This is getting over my head ... but I'd prefer not to see FG stagnate
> because of fear of the unknown ... it sounds like an interesting idea
> but I dont understand the code as well as some others and dont see the
> apocolypse coming :)
S
On Apr 7, 2009, at 11:16 AM, Curtis Olson wrote:
On Tue, Apr 7, 2009 at 9:34 AM, Melchior FRANZ wrote:
Well, so far the samples usually looked something like this:
0.2 0.4 0.1 0.5. Doesn't look *that* bad, indeed.
But in reality floats don't usually have just one digit after the
comma. What ab
This is getting over my head ... but I'd prefer not to see FG stagnate
because of fear of the unknown ... it sounds like an interesting idea
but I dont understand the code as well as some others and dont see the
apocolypse coming :)
One thing I do note though is that Tim DID put it here for di
Hi,
On Tuesday 07 April 2009 09:28:07 Erik Hofman wrote:
> Maybe it's a good idea to let Tim include the code to support
> array-nodes without using it anywhere yet (or provide a patch). That way
> we can look (and feel) how it is going to work. do some small tests
> ourselves and make decisions
* Tim Moore -- Tuesday 07 April 2009:
> Melchior FRANZ wrote:
> > How/where do we document that the heading is in degree, not radian?
> >
> > How/where do we document that a value is normalized (0-1), not an
> > angle?
> >
> Beats me, but I'm not the one claiming that the property list format is
Melchior FRANZ wrote:
> * Tim Moore -- Tuesday 07 April 2009:
>> How / where do you document that a parent node requires this explicit
>> listener activation?
>
> How/where do we document that the heading is in degree, not radian?
>
> How/where do we document that a value is normalized (0-1), no
On Tue, Apr 7, 2009 at 9:34 AM, Melchior FRANZ wrote:
> Well, so far the samples usually looked something like this:
> 0.2 0.4 0.1 0.5. Doesn't look *that* bad, indeed.
> But in reality floats don't usually have just one digit after the
> comma. What about this?
>
> 2345.1239878725027 235.23792
* Tim Moore -- Tuesday 07 April 2009:
> How / where do you document that a parent node requires this explicit
> listener activation?
How/where do we document that the heading is in degree, not radian?
How/where do we document that a value is normalized (0-1), not an
angle?
Adding a suffix would
* Tim Moore -- Tuesday 07 April 2009:
> Melchior FRANZ wrote:
> >
> > alpha
> > bravo
> > charly
> > delta
> >So why do you care if and are replaced by ' '?
Well, so far the samples usually looked something like this:
0.2 0.4 0.1 0.5. Doesn't look *that* bad, inde
* Tim Moore -- Tuesday 07 April 2009:
> Is it fair to say that you never wanted a discussion, but instead
> wanted to assemble people to yell at me to not make this change?
No, it's not fair! May I remind you that we've had this same
discussion a few times(!) on IRC? You asked me what I think
abou
Melchior FRANZ wrote:
> * Anders Gidenstam -- Tuesday 07 April 2009:
>> Some additional thoughts on atomicity: we have several levels of "setting
>> a bunch of values in one go" in FlightGear:
>
> The whole discussion is still much too detached from any actual use case.
> What aggregate data bloc
On Tue, Apr 7, 2009 at 7:54 AM, Erik Hofman wrote:
>
>
> Tim Moore wrote:
> > Erik Hofman wrote:
> >> There is still something that isn't addressed with his proposal.
> >> At this time all types can be converted to all other types. It would be
> >> easy to convert any float/doubles or integers to
* Anders Gidenstam -- Tuesday 07 April 2009:
> Some additional thoughts on atomicity: we have several levels of "setting
> a bunch of values in one go" in FlightGear:
The whole discussion is still much too detached from any actual use case.
What aggregate data block would we repeatedly set/read u
I wonder if there has been some confusion on what's input using XML, what's
stored in properties, and what can be done at runtime amongst them. I've
been limited on time to read this entire thread in detail, so I probably
missed that part of the discussion.
Jon
-
Tim Moore wrote:
> Erik Hofman wrote:
>> There is still something that isn't addressed with his proposal.
>> At this time all types can be converted to all other types. It would be
>> easy to convert any float/doubles or integers to a one element array,
>> but how would a multi-element array be
Anders Gidenstam wrote:
> On Tue, 7 Apr 2009, Anders Gidenstam wrote:
>
>> Can we find a better/more general solution to that problem (i.e. setting
>> the value of a subtree or a set of properties),
>> because someone might need to set a 3 doubles in one go at some point, or
>> 7 doubles or why no
On Tue, 7 Apr 2009, Anders Gidenstam wrote:
> Can we find a better/more general solution to that problem (i.e. setting
> the value of a subtree or a set of properties),
> because someone might need to set a 3 doubles in one go at some point, or
> 7 doubles or why not 3 doubles and a string?
Some
On Tue, 7 Apr 2009, Tim Moore wrote:
> So why do you care if and are replaced by ' '?
There is a world of difference! One is a structured XML subtree while the
other is a homogeneous data blob. In the property tree the former would be
a subtree with a property for each element while the other
Melchior FRANZ wrote:
> * Tatsuhiro Nishioka -- Tuesday 07 April 2009:
>> I hope many people understands what Melchior said on the property
>> system.
>
> They don't. They are already drooling over the awaited shader
> changes. They fell for the argument that this change is in any
> way required
Tatsuhiro Nishioka wrote:
> Hi,
>
> I agree with those who are against the proposed new vector format even
> though I like Tim's basic idea that improves vector calculation
> performance.
>
> As Melchior alrwady said, the new format has nothing to do with what
> Tim really wants (performanc
Melchior FRANZ wrote:
> * Vivian Meazza -- Tuesday 07 April 2009:
>> There is no doubt that the introduction of arrays in the Property
>> Tree has both advantages and disadvantages. Not least we should
>> ask ourselves, if they are such a good idea, why aren't they in
>> it already?
>
> We've had
Erik Hofman wrote:
>
> Mathias Fröhlich wrote:
>> Catching up with an already heated up discussion.
>>
>> IMO:
>> Tim should go on and include arrays into the property system.
>> I even believe that aggregates and more sophisticated types will be
>> something
>> good to have.
>
> There is still
Melchior FRANZ wrote:
> * Tatsuhiro Nishioka -- Tuesday 07 April 2009:
>> I hope many people understands what Melchior said on the property
>> system.
>
> They don't. [...] I'll just not
> commit any code to FlightGearTNG. I'll just be one of the bo105
> developers (together with Maik). It's no
Melchior FRANZ wrote:
> My announcement to leave was in response to Curt's "green light"
> and vote, to his opinion that the arguments against the change
> weren't strong enough. Had I assumed that this isn't decided yet,
> then I would neither have made the announcement, nor given up. But
> actu
* Vivian Meazza -- Tuesday 07 April 2009:
> There is no doubt that the introduction of arrays in the Property
> Tree has both advantages and disadvantages. Not least we should
> ask ourselves, if they are such a good idea, why aren't they in
> it already?
We've had arrays since we have a property
Erik wrote
> Mathias Fröhlich wrote:
> > Catching up with an already heated up discussion.
> >
> > IMO:
> > Tim should go on and include arrays into the property system.
> > I even believe that aggregates and more sophisticated types will be
> something
> > good to have.
>
> There is still some
* Tatsuhiro Nishioka -- Tuesday 07 April 2009:
> I hope many people understands what Melchior said on the property
> system.
They don't. They are already drooling over the awaited shader
changes. They fell for the argument that this change is in any
way required/desirable, and they give a damn a
Mathias Fröhlich wrote:
> Catching up with an already heated up discussion.
>
> IMO:
> Tim should go on and include arrays into the property system.
> I even believe that aggregates and more sophisticated types will be something
> good to have.
There is still something that isn't addressed wit
Hi,
I agree with those who are against the proposed new vector format even
though I like Tim's basic idea that improves vector calculation
performance.
As Melchior alrwady said, the new format has nothing to do with what
Tim really wants (performance improvement). A node with 3 or 4 float
Hi,
Catching up with an already heated up discussion.
IMO:
Tim should go on and include arrays into the property system.
I even believe that aggregates and more sophisticated types will be something
good to have.
But anyway. Tims change gets my vote.
Greetings
Mathias
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
.
Jon
From: Curtis Olson [mailto:curtol...@gmail.com]
Sent: Sunday, April 05, 2009 1:47 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] RFC: graphics effects files
Jon Berndt:
"I always came back to the conclusion that (vectors) would be a really
bad
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
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
* 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
> 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
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 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
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
On Sat, Apr 4, 2009 at 3:05 AM, Melchior FRANZ wrote:
> * Tim Moore -- Saturday 04 April 2009:
> > A couple of weeks ago I was asked for a sample of an effects file
> > that uses my proposed changes to the property system;
>
> And a few weeks later I still object to these property changes, and
>
* 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 past.
OK. Unfortunately, this is a route that I
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 efficiency is of the outermost concern you co
Let me jump in with my thoughts of the day.
Typically in the FlightGear project we have welcomed additive changes (aka
new features.)
We do not seem to be averse to complicated systems, complicated code,
complicated configuration files. Just look at some of the things we can do
with the gui conf
On Saturday 04 April 2009, 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
Melchior
>
> * 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 each oth
* Melchior FRANZ -- Saturday 04 April 2009:
> Of course, triggering the parent
> would have to be done manually in the property browser or via
> telnet, but that's certainly not the main use case and is IMHO
> acceptable.
It's also easy to support from Nasal, in form of a new
props.Node method:
* 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 each other.
How can separate val
>And a few weeks later I still object to these property changes, and
>will do so as often as it is brought up again. And for all the same
>reasons!
>m.
How would it be better, and would all what Tim wants to do, be still possible?
-
* 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 points.
This does also not make sen
Tim Moore
> Hello,
> A couple of weeks ago I was asked for a sample of an effects file that
> uses my
> proposed changes to the property system; here it is. The syntax differs
> from
> current property system syntax in two ways: it uses vector types for some
> properties, and some properties can h
* Tim Moore -- Saturday 04 April 2009:
> A couple of weeks ago I was asked for a sample of an effects file
> that uses my proposed changes to the property system;
And a few weeks later I still object to these property changes, and
will do so as often as it is brought up again. And for all the same
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 guess i
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 have two questions after rea
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 guess it is a bump map for the towns and c
Hello,
A couple of weeks ago I was asked for a sample of an effects file that uses my
proposed changes to the property system; here it is. The syntax differs from
current property system syntax in two ways: it uses vector types for some
properties, and some properties can have a variance="dynamic"
87 matches
Mail list logo
