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 specifically
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 to
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
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
* 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
* 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.
Yes.
* 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
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
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
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 in
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 why
* 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.
* 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 or
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 even
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 posts
* 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.
On Wed, Apr 8, 2009 at 3:02 PM, Melchior FRANZ mfr...@aon.at 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
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 the
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 with his
* 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
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 something that
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 not so
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 (performance
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
On Tue, 7 Apr 2009, Tim Moore wrote:
So why do you care if entry and /entry 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
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
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 something that
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
actually,
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 arrays
* 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
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 not 3
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
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
* 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
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 a one element
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 block would
* 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
about
* Tim Moore -- Tuesday 07 April 2009:
Melchior FRANZ wrote:
array
entryalpha/entry
entrybravo/entry
entrycharly/entry
entrydelta/entry
/array
So why do you care if entry and /entry are replaced by ' '?
Well, so far the samples usually looked something
* 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
On Tue, Apr 7, 2009 at 9:34 AM, Melchior FRANZ wrote:
Well, so far the samples usually looked something like this:
ambient0.2 0.4 0.1 0.5/ambient. Doesn't look *that* bad, indeed.
But in reality floats don't usually have just one digit after the
comma. What about this?
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), not an
* 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
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
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
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:
ambient0.2 0.4 0.1 0.5/ambient. Doesn't look *that* bad, indeed.
But in reality floats don't usually have just one digit after
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 :)
Syd
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
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 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 past.
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 that
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 would
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 system
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 point
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 have two
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
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 at least.
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,
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 to support
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 efficiency is of the
Melchior FRANZ wrote:
* Vivian Meazza -- Saturday 04 April 2009:
less-equal?
texture0, texture1. ?
ambientusematerial/ambient/use/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
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 each
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 past.
* 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
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
On Sun, Apr 5, 2009 at 2:44 AM, Ron Jensen w...@jentronics.com 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
.
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 idea
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
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 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 reading
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 it is a
* 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
* Vivian Meazza -- Saturday 04 April 2009:
less-equal?
texture0, texture1. ?
ambientusematerial/ambient/use/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
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 have a
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?
* 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
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 other.
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 not
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
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 could
* 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, Apr 4, 2009 at 3:05 AM, Melchior FRANZ mfr...@aon.at 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,
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
82 matches
Mail list logo
