Hi,
On Thursday 19 March 2009 12:57:17 gerard robin wrote:
Since i have not followed that topic may be a stupid question:
will that animation longer working
typematerial/type
emission
factor-propcontrols/lighting/instruments-norm/factor-prop
Hi Heiko,
On Thursday 19 March 2009 14:11:30 Heiko Schulz wrote:
what does that mean in future for me as 3d-modeller?
What I have to change when using Blender?
Since I do not know blender too much, I cannot give blender specific hints.
But in general, I would say:
Just go on like you are
Am Donnerstag, den 19.03.2009, 13:11 + schrieb Heiko Schulz:
Hello,
what does that mean in future for me as 3d-modeller?
What I have to change when using Blender?
To get the same results as before you just need to change the Ambient
Value to 1.0. You find it in the Material Buttons
Hi all,
I'm new to devel mailing list.
After 1.9.0 released, some users in FlightGear forum reported that 787
aircraft disappeared from download page.
For more detail, please refer to my post in the forum.
http://www.flightgear.org/forums/viewtopic.php?f=2t=3242#p29432
I guess either of CVS
Hi,
yes, it seems to me, that time was passing real fast since the old plib-days!
I have to wait until I have a new binary, then I will change my models.
Thanks for the helpfull answers
Regards
HHS
Hello,
what does that mean in future for me as 3d-modeller?
What I have to change when using
You could have saved yourself a lot of work by posting a question
before writing all this code.
I don't mind that, because it was just fun to do that. And I wasn't
going to do a temperature model in the first place, but somehow ended
up doing that :)
The code to do all this has existed for
SNIP
- vary callsign TACAN id
- support more than just KC135 and KA6 tanker
- support helicopter refueling (i.e. configurable airspeed)
- fly refueling pattern(?)
- avoid collisions with mountains
m.
The Handley Page Victor K2 is not too far from completion. It already has
the ability to
alex wrote:
- vary callsign TACAN id
- support more than just KC135 and KA6 tanker
- support helicopter refueling (i.e. configurable airspeed)
- fly refueling pattern(?)
- avoid collisions with mountains
m.
The Handley Page Victor K2 is not too far from completion. It already has
* alex -- Friday 20 March 2009:
* * Melchior FRANZ -- Monday 16 March 2009:
- vary callsign TACAN id
That's done. (Even a bit overengineered. ;-)
- support more than just KC135 and KA6 tanker
- support helicopter refueling (i.e. configurable airspeed)
or generally:
- allow aircraft to
This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and why I strongly object. But
In my opinion this planned change would be an incredibly bad
move, and would almost have to be seen as the destruction of
the property system. So let me repeat: I strongly object.
I guess it boils down to whether or not the benefit gained outweighs the
down side.
What benefit does the
Melchior FRANZ wrote:
How will a VEC3 property be written in an XML file? As
foo type=vec3123;341;123/foo? Will then every application
which reads such a file have to have its own (sub)parser for
certain fields, in addition to using an XML parser?
This is my strongest point to be against it.
I don't know much about C++, but in Python people can custom a data type,
it has its own method to be bound with operator.
Like str(), the function a translate an object to a string,
str(theObj) is actually theObj._str()
This might also applied in tim's types such as VEC3.
And it could have its
* Buganini -- Friday 20 March 2009:
IMO, if these compound types are unavoidable, [...]
They are very much avoidable. We've had colors and coordinates since
*ages*. And what next? If we have VEC3, then what about POSITION,
which contains latitude/longitude/altitude, and ORIENTATION with
heading,
Melchior FRANZ wrote:
This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and
* Stuart Buchanan -- Friday 20 March 2009:
I don't see any reason for this to become a flame-war.
Umm, because some people seem to have an auto-responder that
launches a hate-mail every time an email contains my name
and object? :-]
m.
* Melchior FRANZ -- Friday 20 March 2009:
* Stuart Buchanan -- Friday 20 March 2009:
I don't see any reason for this to become a flame-war.
Umm, because [...]
Arghh ... and that should have been a private mail to Stuart,
with tongue in cheek. And now it looks as if *I* am the one
who wants
Sorry for that.
But thanks for the cool idea anyway - let's see how to set it up ;-)
Back to topic - you have strong points against it. Let's wait and see what Tim
has to say. I am sure he has some good pros.
Torsten
On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote:
Melchior FRANZ wrote:
This will probably become a flame-war, but I see no way to avoid
it.
I think you laid out your position in a very well thought out and fair
manner, backed up with many reasonable points and/or questions. If
I just wanted to check on this before I muck it up, now that I finally seem to
have terragear compiled. I've got a couple of 1201X1201 grid cells of raster
data, covering a total of 0.5 deg X 0.5 deg. The extension on the files is
.dem, and according to the details that come with it, the data
Hi,
I hear that for the first time.
On Friday 20 March 2009 16:06:51 Gene Buckle wrote:
I guess it boils down to whether or not the benefit gained outweighs the
down side.
What benefit does the compound property offer?
* You can modify properties in a atomic way.
* We use the property tree
Hi,
On Friday 20 March 2009 16:07:57 Erik Hofman wrote:
This is my strongest point to be against it. The property tree is there
for easy xml file loading and saving. I can see no obvious way to save
those VEC properties to an xml file in a way that is supported by the
xml specification.
Ok.
2009/3/20 Mathias Fröhlich mathias.froehl...@gmx.net:
From my
point of view, the serialization of the objects into xml is just a special
case of that reflection stuff.
Not just the xml, there is MP, the generic i/o stuff and the
telnet/http interface too.
--
Csaba/Jester
Mathias Fröhlich wrote:
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the models/scripting/whatever. From
my
point of view, the serialization of the objects into xml is just a special
case of that reflection stuff. Given
On Fri, 20 Mar 2009, Torsten Dreyer wrote:
I followed your advice and didn't rush ;-)
No problem with the nasal wrapper for the animations.
Do you have a generic interface for the properties for the remote aircraft?
Are they transmitted via the generic multiplayer values?
Hi,
They are
2009/3/20 Mathias Fröhlich wrote:
Ok.
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the models/scripting/whatever. From
my
point of view, the serialization of the objects into xml is just a special
case of that reflection
Hi,
Stuart Buchanan schrieb am 20.03.2009 16:22:
My immediate thought is that one could write some fairly straightforward
code to interpret a given property node with 3 child values as a Vec3. Could
we subvert the property attributes to indicate that a given nodes contains
a Vect3. That way
Maik Justus wrote:
Hi,
Or we do it vice versa. We store the vec3 directly in the property tree,
e.g.. surface/color, but you can access any components over the property
tree in the approved way. (surface/color/red, curface/color/blue, ...).
From telnet, MP, property-browser, etc.
I have the feeling this will become a developers nightmare, give the
number of possibilities to access the property tree..
But if anyone feels brave enough, be my guest.
Erik
I've thought, from time to time, about a units extension to the property
system. I've also thought at times that it
RFC: Vector Types in the Property System
Proposal: Allow vector types as properties in property list XML files
and as properties in the runtime property system. The syntax in an XML
file would look like:
parameters
material
diffuse type=vec4d
.2 .4 .6 1.0
/diffuse
Gene Buckle wrote:
In my opinion this planned change would be an incredibly bad
move, and would almost have to be seen as the destruction of
the property system. So let me repeat: I strongly object.
I guess it boils down to whether or not the benefit gained outweighs the
down side.
Erik Hofman wrote:
Melchior FRANZ wrote:
How will a VEC3 property be written in an XML file? As
foo type=vec3123;341;123/foo? Will then every application
which reads such a file have to have its own (sub)parser for
certain fields, in addition to using an XML parser?
This is my strongest
Melchior FRANZ wrote:
* Buganini -- Friday 20 March 2009:
IMO, if these compound types are unavoidable, [...]
They are very much avoidable. We've had colors and coordinates since
*ages*. And what next? If we have VEC3, then what about POSITION,
which contains latitude/longitude/altitude,
Stuart Buchanan wrote:
I think it would be good for Tim to explain why more complex types are
required, as I'm sure he will do shortly :)
My immediate thought is that one could write some fairly straightforward
code to interpret a given property node with 3 child values as a Vec3. Could
we
Melchior FRANZ wrote:
This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and
Curtis Olson wrote:
On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote:
Melchior FRANZ wrote:
This will probably become a flame-war, but I see no way to avoid
it.
I think you laid out your position in a very well thought out and fair
manner, backed up with many
Erik Hofman wrote:
Mathias Fröhlich wrote:
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the models/scripting/whatever. From
my
point of view, the serialization of the objects into xml is just a special
case of that
Curtis Olson wrote:
2009/3/20 Mathias Fröhlich wrote:
Ok.
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the
models/scripting/whatever. From my
point of view, the serialization of the objects into xml is
Jon S. Berndt wrote:
I have the feeling this will become a developers nightmare, give the
number of possibilities to access the property tree..
But if anyone feels brave enough, be my guest.
Erik
I've thought, from time to time, about a units extension to the property
system. I've also
On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore timo...@redhat.com wrote:
Gene Buckle wrote:
In my opinion this planned change would be an incredibly bad
move, and would almost have to be seen as the destruction of
the property system. So let me repeat: I strongly object.
I guess it
On Sat, Mar 21, 2009 at 1:49 AM, Curtis Olson curtol...@gmail.com wrote:
On the flip side, (just my impression), arguing for this change because the
alternative is a more verbose xml syntax is maybe the weakest argument. xml
is already pretty verbose and a percentage difference in verbosity
41 matches
Mail list logo
