S Andreason wrote:
One more thing, the trees are still very dark, especially noticeable in
daylight and sunny skies.
looking at Models/Trees/deciduous-tree.ac for example,
MATERIAL NoName rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi
2 trans 0
Is the specularity supposed to be
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?
Erik Hofman wrote:
This should now be fixed in simgear/scene/sky/oursun.cxx
Thank you!
It is fixed.
The only remaining problem with space is, it is not black above 300,000
ft. But I understand that is not really a bug, but is a lack of definition.
Ctrl-Shift-click on the . entry in the property browser fires all the
listeners of the parent node.
Each property can have multiple listeners tied to it. There are various
types of listeners (read, write) and various modes of operation.
When a listener's trigger conditions are met, it then
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
On Tue, 2009-04-07 at 10:31 -0500, Curtis Olson wrote:
Ctrl-Shift-click on the . entry in the property browser fires all
the listeners of the parent node.
Each property can have multiple listeners tied to it. There are
various types of listeners (read, write) and various modes of
* Ron Jensen -- Tuesday 07 April 2009:
And when the gentleman who has been responsible for
building and maintaining that complexity stands up and cries out:
That wouldn't be me, though. That's mostly David MEGGINSON's work,
with contributions by Erik, Fred, Csaba, Mathias and me (and probably
a
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
33 matches
Mail list logo
