Re: [Flightgear-devel] RFC: graphics effects files
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 asked about this in one of my earlier posts but if anyone answered I must have missed their replies. 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 raw C++ values that could be set by a property system tie are protected members and not accessible. Currently a big performance hit is the need to run an update callback on every state set involved in a material animation (not to mention on every animation). It might not seem like this could be expensive, but the need to traverse the big scene graph every frame is expensive in terms of what is costly on today's hardware: pointer chasing, cache misses, etc. If we can move away from update callbacks, we will see a gain. Ok - seems fair enough. However, if the individual components of the values in question exist independently in the property tree and can be set individually, this greatly complicates the bookkeeping needed to avoid update callbacks, or forces us to just use update callbacks. It seems to me then, that if the data is updated in the tree, update callbacks will be required. If just a single property node is updated then just a single update callback will be required but if three nodes are needed to be read, when perhaps only one has been updated, then three update callbacks will be needed. However, even though using a single node results in just a single update callback instead of three, whatever is updating that data will still need to work with the individual values and so will not only need to parse the node to extract the three values before it works with them, but also re-form the compound data item when it wants to write it back to the node. It seems then, that there will be an overhead whichever way we look at it; if the overhead is removed from the OSG point of view, it's just added to whatever other subsystem is updating the data. How often is this data likely to be updated, and does this data really need to be exposed in the property tree anyway? As for the idea that the new datatypes should be adopted on the principle that if they do turn out to cause problems they can be fixed later, well, no offence intended Durk, but that just seems extremely foolhardy to me. Planned development? - we've heard of it. Agile development is the new hotness :) Tim To me, Agile development just seems to be the latest developer-centric buzzword for an approach to software development that puts the importance of the introduction of new features over maintaining software quality, and to be honest, I think FG has enough problems with quality as it is. To be fair, in many respects FG is still seeking solutions to problems i.e. get it working before worrying about making it perfect. The thing is though, are the solutions actually being refined and de-bugged adequately once they've been got working? I would have to say not, because I've been watching the cvs updates come through, specifically looking for fixes to a number of problems that have been reported, but which show no signs of being dealt with. To coin an old Windows joke, rather than FG just working, FG works, just, and agile development is going to do nothing to improve this state of affairs. LeeE -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 accommodate others in this, whatever the outcome. I very much appreciate it. I agree. And not just that, it separates this discussion from the configurable shader animation code which is a good step. Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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't work or would be worse. Again: the whole discussion is not (or shouldn't be) about whether we want progress, whether we want shader effects, and whether they should be configurable via XML. The question is, if this *very* intrusive approach is the way to go. Some of the vector property supporters don't seem to know a lot about all the internals and haven't thought about the side effects. Some even need to have secret private discussions with Tim to form an opinion. Why can't we discuss openly?! m. Excercises of the day: How should a vector property type be displayed on the HUD? All values in one line, rather than one line per element? Or is this really the begin of a two-class property system, where some propertyes are just no longer meant for inspection and public use, but internal only? How do you imagine we would write a condition that checks for a color's alpha value? -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 hadn't choose the maybe (?) possible second way, if it would be worse. And there are more people than you who are long enough developing hard code for FGFS - so I think they know what could be the side effects. He even showed the code changes in his git repo and made it public so everyone can try it and discuss it. But I couldn't see that anyone really tried this code and reported. Quote by Syd Adams: One thing I do note though is that Tim DID put it here for discussion , where standard practice seems to be commit , then explain how things need to be done differently now. and Quote by M.F. Some even need to have secret private discussions with Tim to form an opinion. Why can't we discuss openly?! That we can't discuss openly is- well, this is mostly the effect of your childish behavior! I was following the IRC-Chat and I was really pretty bad surprised 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. I still wonder if there are other reasons for you you don't want to tell, and the current reasons are only pretended. At least it was nasty, ungentlemen-like and not professional. This and your absolutly childish behavior with anouncing your menaces to retire (but keeping your CVS-rights) keeps people from discussing openly these things here on the list afraid of beeing flamed again by you. ( we all could see that on your answers of Tim's postings). But you are right- it doesn't makes it better if it is discussed privately. So I have to agree to Syd, Tim didn't commit it, he put it in here as proposal for discussion and I'm pretty sure, that Tim wouldn't give up and throw in the sponge but look for another solution if at the end everyone are disagree. So we should clear first if this is really the way to go, and if so, why it is the best way to go - in a grown-up way I hope! Regards HHS -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 frame rate? - 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!) - turn off the replay system (which really is a hog) - turn off 3D clouds and trees That brings a lot of frames. Now, would we gain a lot by adding vector property types? That's hard to say. Nobody knows, I assume. But have you noticed that many subsystems use the property system in the slowest possible way? var f = fgGetDouble(/some/longish/property/path); Every time the property is read, a hash value of the path is made, and looked up in the node's hash table. OK, hashes are fast, but that's no reason to waste cycles. (One vector property supporter seems to prefer this slow method. ;-) Nobody seems to care about that (apart from me), while ruining the property system to gain some cycles seems perfectly acceptable. Did you know that Nasal code in bindings is read in, parsed and translated to the interal code, and then executed *every* *time* the binding is called? Every time you move the js throttle? Andy said that parsing is very fast. Nevertheless, I wrote a patch that cached all Nasal bindings. I didn't commit it, because the improvement wasn't that big and not worth the added complexity. (I saved the patch away in my git repo, and maybe one day it might come in handy.) There are definitely many parts of fgfs that could be made faster. I wouldn't start with adding vector property types. I wouldn't even if it didn't come with all the disadvantages! m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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. I really care! :-P m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 merging of changes in one branch to another so Tim, or whoever, can transfer changes from the main branch to the controversial array branch. If git or CVS cannot do that, swith to subversion that does support simple merging of changes between branches. Maybe it is time to consider a fork ... and let the users decide who the winner should be. I'd personally select the project that delivers best user experience NOT developer experience. I tried to stay out of this but as Heiko I couldn't, Jari Heiko Schulz wrote: 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 hadn't choose the maybe (?) possible second way, if it would be worse. And there are more people than you who are long enough developing hard code for FGFS - so I think they know what could be the side effects. He even showed the code changes in his git repo and made it public so everyone can try it and discuss it. But I couldn't see that anyone really tried this code and reported. Quote by Syd Adams: One thing I do note though is that Tim DID put it here for discussion , where standard practice seems to be commit , then explain how things need to be done differently now. and Quote by M.F. Some even need to have secret private discussions with Tim to form an opinion. Why can't we discuss openly?! That we can't discuss openly is- well, this is mostly the effect of your childish behavior! I was following the IRC-Chat and I was really pretty bad surprised 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. I still wonder if there are other reasons for you you don't want to tell, and the current reasons are only pretended. At least it was nasty, ungentlemen-like and not professional. This and your absolutly childish behavior with anouncing your menaces to retire (but keeping your CVS-rights) keeps people from discussing openly these things here on the list afraid of beeing flamed again by you. ( we all could see that on your answers of Tim's postings). But you are right- it doesn't makes it better if it is discussed privately. So I have to agree to Syd, Tim didn't commit it, he put it in here as proposal for discussion and I'm pretty sure, that Tim wouldn't give up and throw in the sponge but look for another solution if at the end everyone are disagree. So we should clear first if this is really the way to go, and if so, why it is the best way to go - in a grown-up way I hope! Regards HHS -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 some others and dont see the apocolypse coming :) Syd pretty well summarized my own stance on this. Let me just add a few thoughts: Just the fact that a few extensions of the existing property types can have a positive impact on rendering speed, as I judge from Tim's original proposal should be enough to at least allow us to experiment with this. I presume that if we really run into trouble somewhere down the line, we can always fix the offending parts in the process, or switch over to something more along the lines of the current architecture. 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 but if anyone answered I must have missed their replies. As for the idea that the new datatypes should be adopted on the principle that if they do turn out to cause problems they can be fixed later, well, no offence intended Durk, but that just seems extremely foolhardy to me. Planned development? - we've heard of it. Secondly, the fact that we do have additional property types certainly doesn't mean we have to use them in situations were the existing solution would suffice. It seems to me that Tim has adequately addressed any potentials concerns raised in this area. Cheers, Durk Is there going to be anything to stop people from using them where the existing solution would suffice or will we be able to use either format in any situation when we want to specify linked data? For example, if we can specify RGB values using a vec3 datatype, will we be able to use that datatype for XYZ values? If we can't, what will happen when, and not if, someone someone tries to do so? If the new datatypes cannot be used everywhere, is there going to be somewhere in the documentation that lists exactly where it can and can't be used, baring in mind that it is normal to add new branches and nodes to the tree as required? LeeE -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 the graphics code, as far as I can tell. The code involved in animating the traffic already starts running as soon as you get within approx 100 nm of the AI model in question. But, you won't notice a significant drop in performance until you actually start getting into a range where the traffic actually becomes _visible_. It looks like this is something to do with culling / bounding boxes, or paging in objects. Most performance drops usually happen when you turn toward an area containing a lot of visible code. I've tested this on several systems, including some with relatively modest CPUs, and the pattern is more or less the same. Given that, you can probably imaging that I, for one, would welcome any improvement in _rendering efficiency_ possible. If you really think the traffic manager code is inefficient: Please prove it instead of passing around user experiences that I don't believe are based on any scientific investigations. Cheers, Durk -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 this generic approach wouldn't work or would be worse. 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. And I do think diffuse-atomic red.2/redgreen.3/greenblue.4/blue /diffuse-atomic blows compared to diffuse.2 .3 .4/diffuse but perhaps that's just me. Again: the whole discussion is not (or shouldn't be) about whether we want progress, whether we want shader effects, and whether they should be configurable via XML. The question is, if this *very* intrusive approach is the way to go. Some of the vector property supporters don't seem to know a lot about all the internals and haven't thought about the side effects. Some even need to have secret private discussions with Tim to form an opinion. Why can't we discuss openly?! Better not tell anyone about our secret correspondence on the issue. Oh. Whoops. Seriously, suggesting that individual conversation among colleagues and friends is secret and suspect is beyond the pale, even for you. Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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. Also, just dropping features will always speed up code, that's easy. As I said, that wasn't to criticize the AI code, but to put things into proportion. Disabling some features gives tow-digit framerate improvements, or almost doubling. Introducing vector properties, OTOH, will probably not even bring you what is now wasted with inefficient use of properties. (We use the sprintf() path creation method in doubly nested loops at FDM frequency, for example.) m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 from telnet. In almost all cases it would be done from C++ or Nasal via wrapper functions, so not exactly manual either. And I do think diffuse-atomic red.2/redgreen.3/greenblue.4/blue /diffuse-atomic blows compared to diffuse.2 .3 .4/diffuse but perhaps that's just me. But that's again the XML representation argument. As I said before, while I'm not thrilled about it, it's not what worries me. You could have a custom XML reader read that into three separate properties without problems. Just look at YASim's XML reader or the AI code's. What I find bad is the aggregate property type. Better not tell anyone about our secret correspondence on the issue. Oh. Whoops. Seriously, suggesting that individual conversation among colleagues and friends is secret and suspect [...] 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 only Curt should know about it, of course. ;-) m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 bothered to explain why this generic approach wouldn't work or would be worse. 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 accommodate others in this, whatever the outcome. I very much appreciate it. -Stuart -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 but if anyone answered I must have missed their replies. 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 raw C++ values that could be set by a property system tie are protected members and not accessible. Currently a big performance hit is the need to run an update callback on every state set involved in a material animation (not to mention on every animation). It might not seem like this could be expensive, but the need to traverse the big scene graph every frame is expensive in terms of what is costly on today's hardware: pointer chasing, cache misses, etc. If we can move away from update callbacks, we will see a gain. However, if the individual components of the values in question exist independently in the property tree and can be set individually, this greatly complicates the bookkeeping needed to avoid update callbacks, or forces us to just use update callbacks. As for the idea that the new datatypes should be adopted on the principle that if they do turn out to cause problems they can be fixed later, well, no offence intended Durk, but that just seems extremely foolhardy to me. Planned development? - we've heard of it. Agile development is the new hotness :) Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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/alpha separately, without costing anything extra.) And you need to poll the values for atomic changes? Maybe you could use the READ flag for that? No need to do it manually, of course. All wrapped in functions. That's just checking if the parent (color) node is read-protected, and if not, use the values. Otherwise re-use the previous ones. A setter would just clear that bit before writing the values, and set it again afterwards. Done by a function, of course, not manually. Unless I missed something, which could well be. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 stuff that only Curt should know about it, of course. ;-) Geeze, that's an easy one to throw out there ... accuse me of being secretive. Of course I exchange personal email with FlightGear developers from time to time on a whole range of subjects. I also have a few FlightGear facebook friends and I communicate once in a while over there using that secretive web site. Come on Melchior, you aren't making friends around here with this kind of crap ... Why don't you list all your gripes in life along with everything else and make this thread completely useless. If you keep this up, all our poor European friends are going to have to pay an entertainment tax just to read this mailing list. (And probably us too in the USA by years end ...) I've been trying to be fair, trying to spend the extra time to actually understand people's points. I may not get everything that everyone says, but I've been taking this discussion seriously. But if you fill up your messages with this kind of accusational crap, it becomes harder and harder to give your side serious consideration. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 raw C++ values that could be set by a property system tie are protected members and not accessible. Currently a big performance hit is the need to run an update callback on every state set involved in a material animation (not to mention on every animation). It might not seem like this could be expensive, but the need to traverse the big scene graph every frame is expensive in terms of what is costly on today's hardware: pointer chasing, cache misses, etc. If we can move away from update callbacks, we will see a gain. However, if the individual components of the values in question exist independently in the property tree and can be set individually, this greatly complicates the bookkeeping needed to avoid update callbacks, or forces us to just use update callbacks. Well, yes, the atomicity of setting of properties is preserved with that change. And yes this will help to move some animations into the cull step and make them asyncronous. Is this where you are heading to? I would like to move the animations having a transform node into this direction. So we could hopefully narrow the sub trees that need the update visitor. Greetings Mathias -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 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 converted to a float or integer? My best guess is returning a NaN which is not very elegant (and which doesn't work for integers). Another way is to just ignore the node if a non-compatible type is requested. 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 based on our own experience rather than on theoretical assumptions. Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 about the cleanliness, universality and power of the architecture. Prettiness does now have top priority, while a strong foundation was moved down the list. This will bite you all in the butt later on, but you were warned! :-P His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. 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, I'm convinced that this *is* decided. FlightGear's architecture will be sacrificed to Tim's dislike of the verbosity of XML (a format that was chosen on purpose). Tons of code will be added everywhere to make the change kind-of work out. You'll never see any advantages, but some things will stop working. But then again: what do I lose? I will continue using fgfs, and I will continue hacking my private copy of fgfs. 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 much a sad time for me, but mainly for FlightGear. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 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 converted to a float or integer? My best guess is returning a NaN which is not very elegant (and which doesn't work for integers). Another way is to just ignore the node if a non-compatible type is requested. 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 based on our own experience rather than on theoretical assumptions. 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? No doubt all these issues were addressed in the past (after all arrays arent a recent invention, and our predecessors weren't idiots :-)). I rather suspect that arrays are a bad idea based on this notion alone. However, Tim is only proposing that arrays are used in the new effects code. Thus, although it might break the homogeneity of the existing Property Tree, the downside must be minimal. Indeed, had he committed it, I rather doubt that anyone, apart from Melchior that is, would have noticed. I think that Tim should make this code available as soon as it is ready, subject only to the tidying up of the worst of the other Property Tree/xml inconsistencies. Then we can all see what the advantages/disadvantages are in practice, rather than arguing about the theory. Vivian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 much a sad time for me, but mainly for FlightGear. Do we have to start paying entertainment tax for reading this thread ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 improvement). A node with 3 or 4 float numbers can be converted into a vector class internally in C++ code without the new vector format inside an XML tag. I've explained before why this is approach is messy and has performance implications in OSG. If you want to see this strategy in action, look at scene/model/SGMaterialAnimation.cxx and the hundreds of lines of code that are needed to bridge the difference between colors represented as discrete properties and vector colors in OSG. Moreover, the new vector format doesn't improve the usability at all. a user-defined text format inside an XML tag is not recommended since it decreases the readability unless you give a comment, which is way not better than using tags. If we really need more concise format that improves usability, then we need to throw away our current xml files and make new files in our own new format, which I believe is nonsense. This is the COBOL and Java idea that locally simple, self documenting syntax improves readability. I simply don't buy it because the resulting loss of abstraction means that the total amount that a user needs to absorb in order to understand a program increases dramatically. Now, it may be a lost cause to try to improve an XML-based file format, but I feel that it is worthwhile to try. The new format also needs a parser, property browser changes, and converter(s) that don't help us improve any usability or performance at runtime, I guess. If such new format gives us some usability or performance improvement, I can accept it even if some extra work is required, but this is not the case. These changes are very small, as can be seen in my code. If they weren't, I wouldn't have been tempted to mess with the property system. The JSBSim's table format, which I believe, also lacks the readability. It ,however, gives aircraft developers some usability like easier to copy and paste some table data from external tools like javaprop or excel. I know some helper script can create a well- formatted XML tags, but it could be true that many aircraft developers like simple copy-paste things while tweeking prop/engine things tons of times a day. Nevertheless to say, these tables don't need converters or browser changes since these are only read at launch time, and are not readable from the property browser or telnet. So comparing JSBSim table and the vector format doesn't seems fair to me. My proposed usage is just as local, except that eventually I want to change effects properties from Nasal code. I hope many people understands what Melchior said on the property system. His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. It's not a civil way to participate in a collaborative project. Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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/desirable, and they give a damn about the cleanliness, universality and power of the architecture. Prettiness does now have top priority, while a strong foundation was moved down the list. This will bite you all in the butt later on, but you were warned! :-P I do care deeply about cleanliness, universality and architecture too, as you well know. Prettiness too. His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. 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, I'm convinced that this *is* decided. FlightGear's architecture will be sacrificed to Tim's dislike of the verbosity of XML (a format that was chosen on purpose). Tons of code will be added everywhere to make the change kind-of work out. You'll never see any advantages, but some things will stop working. But then again: what do I lose? I will continue using fgfs, and I will continue hacking my private copy of fgfs. 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 much a sad time for me, but mainly for FlightGear. 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? Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 while the other would be a single value (an array value like our string values, if you wish). IMHO it would be better to talk about the proposed vec4d as 4-tuple rather than an array - as I understood it values of that type would be read and written as a single unit. I'd very much like to keep tuples away from the property tree and instead let the tree structure itself describe how the simple data values relate to each other. OTOH I do see Tim's point regarding the value in being able to set the entire value of the structure in one go in the shader case. 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? Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 additional thoughts on atomicity: we have several levels of setting a bunch of values in one go in FlightGear: 0. All subsystems can (potentially) see inconsistent state while the update is in progress. E.g. setting a set of properties from the telnet interface (IIRC the commands will be processed on at the time with potentially several frames occuring between them). 1. Only listeners/getters/setters triggered by the updates can see inconsistent state. This is (AFAIK) the case when setting several properties from a piece of Nasal code. Other subsystems can't see the intermediate states since we (AFAIK) don't interrupt Nasal code. 2. Atomically updating of a set of properties. AFAIK we don't have that today. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 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 converted to a float or integer? My best guess is returning a NaN which is not very elegant (and which doesn't work for integers). Another way is to just ignore the node if a non-compatible type is requested. My proposal, and code, returns a default value in this case. The default value is 0 for scalar types, the empty string, or a vector of zeros for vector types. 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 based on our own experience rather than on theoretical assumptions. As I mentioned in my proposal, the changes are available in git://repo.or.cz/simgear/timoore.git and git://repo.or.cz/flightgear/timoore.git in the topic/property branch. Tim Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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, I'm convinced that this *is* decided. For what it's worth, I'm still undecided on this. I can see advantages for reading tables from XML files (like for instance for JSBSim) but I also see disadvantages in type conversion. Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 since we have a property tree! Here's an array of strings: array entryalpha/entry entrybravo/entry entrycharly/entry entrydelta/entry /array Guess what happens when you read that in in Nasal? var array = props.globals.getNode(array).getValues().entry; debug.dump(typeof(array), array); Output: #0 'vector' #1 ['alpha', 'bravo', 'charly', 'delta'] The problem is: it's verbose XML, which doesn't fit in TimGear. Because the 10 shader XML files must not be as verbose as the other thousands of XML files, and they should look like being from OGRE or something, not from FlightGear. So why do you care if entry and /entry are replaced by ' '? An honest technical question: how do you set one of the property entries from Nasal? Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 tree! Here's an array of strings: array entryalpha/entry entrybravo/entry entrycharly/entry entrydelta/entry /array Guess what happens when you read that in in Nasal? var array = props.globals.getNode(array).getValues().entry; debug.dump(typeof(array), array); Output: #0 'vector' #1 ['alpha', 'bravo', 'charly', 'delta'] The problem is: it's verbose XML, which doesn't fit in TimGear. Because the 10 shader XML files must not be as verbose as the other thousands of XML files, and they should look like being from OGRE or something, not from FlightGear. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 doubles and a string? Some additional thoughts on atomicity: we have several levels of setting a bunch of values in one go in FlightGear: 0. All subsystems can (potentially) see inconsistent state while the update is in progress. E.g. setting a set of properties from the telnet interface (IIRC the commands will be processed on at the time with potentially several frames occuring between them). 1. Only listeners/getters/setters triggered by the updates can see inconsistent state. This is (AFAIK) the case when setting several properties from a piece of Nasal code. Other subsystems can't see the intermediate states since we (AFAIK) don't interrupt Nasal code. 2. Atomically updating of a set of properties. AFAIK we don't have that today. We should also think about atomicity in terms of multithreading and what it would take to guarantee that different threads see a consistent view of the property system. I realize that could be (unsatisfactorily) solved by a lock, whereas insuring that listeners get fired after a consistent set of changes is a slightly different problem. Perhaps we should take another look at the brittle hack :) I'd be willing to explore that approach if it could be guaranteed that child properties could only be written in a context where only one listener event would be fired on the parent. Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 converted to a float or integer? My best guess is returning a NaN which is not very elegant (and which doesn't work for integers). Another way is to just ignore the node if a non-compatible type is requested. My proposal, and code, returns a default value in this case. The default value is 0 for scalar types, the empty string, or a vector of zeros for vector types. Which is basically saying: this node doesn't exist. Now the next problem, what if the requester asks to create a new node if one doesn't exists? Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 under circumstances
where speed actually matters? The XML shader files are read just once
when the model is loaded, no?
What other cases are there where reading three individual properties
is a problem, but reading one vector property isn't? And you can
easily write a small helper function that does the reading, so it's
in no way more annoying.
Atomicity is almost never an issue. Data set in the tree doesn't magically
affect c/c++ code, anyway. This has to be coded, in one of three ways:
tying, polling, listening. (Neither of them is thread-safe, no matter
if vector types exist or not. So this is IMHO not a criterion for the
decision.)
But apart from that you can have atomicity already now, as I've said
earlier. What's more natural than a color node where you can access all
components individually (e.g. attach a GUI slider to the red element):
color
red0.1234/red
green0.431/green
blue0.2341/blue
alpha1/alpha
/color
... and when you are finished with manipulating the color, you
validate the color change by updating the color node. After
all the color node stands for color branch with its elements.
A listener on the color node copies the *atomar* color to the
GUI/material, etc. This only looks tedious if you ignore that it
can all be hidden in a few simple helper functions, like fgSetColor().
It's not like vector data types wouldn't also require lots of new
functions to work.
This approach is logical, generic, and doesn't break anything. You
can use the same technique on a font/{name,size,slant} aggregate,
or even a nested one: font/{name,size,slant,color/{red,green,blue}}
You don't have to change a core library for applying the same
principle to other aggregate types. You can implement it in Nasal only,
or C++ only, or mixed.
Implementing a color or vec3 property is only picking out very
special cases and pretending they are in some way generic, while
ignoring all the other possible aggregate types. This is needlessly
extending a very functional, generic system instead of just *using*
it.
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 array, but how would a multi-element array be converted to a float or integer? My best guess is returning a NaN which is not very elegant (and which doesn't work for integers). Another way is to just ignore the node if a non-compatible type is requested. My proposal, and code, returns a default value in this case. The default value is 0 for scalar types, the empty string, or a vector of zeros for vector types. Which is basically saying: this node doesn't exist. Now the next problem, what if the requester asks to create a new node if one doesn't exists? Isn't this analogous to what happens in the existing system when you ask for the numeric value of a string that is composed entirely of characters? The result is ill defined so we just return 0. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 we repeatedly set/read under circumstances
where speed actually matters? The XML shader files are read just once
when the model is loaded, no?
No. Material animations will set the effects properties.
What other cases are there where reading three individual properties
is a problem, but reading one vector property isn't? And you can
easily write a small helper function that does the reading, so it's
in no way more annoying.
Atomicity is almost never an issue. Data set in the tree doesn't magically
affect c/c++ code, anyway. This has to be coded, in one of three ways:
tying, polling, listening. (Neither of them is thread-safe, no matter
if vector types exist or not. So this is IMHO not a criterion for the
decision.)
But apart from that you can have atomicity already now, as I've said
earlier. What's more natural than a color node where you can access all
components individually (e.g. attach a GUI slider to the red element):
color
red0.1234/red
green0.431/green
blue0.2341/blue
alpha1/alpha
/color
... and when you are finished with manipulating the color, you
validate the color change by updating the color node. After
all the color node stands for color branch with its elements.
A listener on the color node copies the *atomar* color to the
GUI/material, etc. This only looks tedious if you ignore that it
can all be hidden in a few simple helper functions, like fgSetColor().
It's not like vector data types wouldn't also require lots of new
functions to work.
You've used the GUI slider on red example before as a case that would
be inconvenient with colors stored as vector properties. So what would you
do to signal the update?
This approach is logical, generic, and doesn't break anything. You
can use the same technique on a font/{name,size,slant} aggregate,
or even a nested one: font/{name,size,slant,color/{red,green,blue}}
You don't have to change a core library for applying the same
principle to other aggregate types. You can implement it in Nasal only,
or C++ only, or mixed.
How / where do you document that a parent node requires this explicit
listener activation?
Implementing a color or vec3 property is only picking out very
special cases and pretending they are in some way generic, while
ignoring all the other possible aggregate types. This is needlessly
extending a very functional, generic system instead of just *using*
it.
Some people want general arrays a property values :)
Tim
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 additional property types, and I've always made it clear that I'd object to that and why. This does *not* come as a surprise. And you knew my arguments. Even back then you didn't counter any of them IIRC, but rather concentrated on the wouldn't-it-be-nice? aspect. I think I have the IRC backlog from then, so looking it up shouldn't be be a problem. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 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? foo2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346/foo There goes the nicety. As long as this is only an XML markup question, the disadvantages are: - higher failure probability - one has to know about the order and meaning of elements; they are not self-describing - it's a bastardized format: it's a custom format *within* XML - XML tools can only treat the entry as a whole, but not the elements. For example: a *.dtd file cannot validate the entries (http://en.wikipedia.org/wiki/Document_Type_Definition; not that I have any experience with that) - XML editors might not support such conglomerates (ok, weak argument ... who on earth uses an XML editor?! ;-) If you find proper PropertyLists so disgusting, then you could just use the XML parser directly, like Durk did it for some airport data (parking/traffic), or yasim to read its config files. Just write a shader XML file reader. You don't need to read them into the tree, I guess. I think it would be a bad idea, but I could live with it. (I've multiple times complained about such custom (non-PropertyList) files in fgfs, because they made it impossible to load the taxiing files into the tree, for manipulating or visualizing the route points. I spent several hours for writing Nasal's parsexml() built-in function and io.readxml/io.writexml, only to allow that!) But that's all just XML representation. As soon as this thing ends up being stored in the property tree as new vec4, color etc. nodes, the fun is over: foo = '2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346' (vec4) background = '0.12332975 0.123784967 0.28375891205 0.127456582302' (color) Should we make the property browser full-screen, so that one can still handle the entries? But that's only the response to your question: | So why do you care if entry and /entry are replaced by ' '? The other issues are much more problematic. See the other messages for that. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 be a possibility. After all, just like in the case of -ft or -m suffixes, it's only meant for the human user or coder, so that s/he knows how to handle the type. The code itself knows it, because it's written that way. The listener of the color-at (or color-atomar) node knows it without looking at the node name. That's just business as usual, not a new challenge. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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? foo2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346/foo There goes the nicety. Long ugly numbers or long ugly numbers. We can split them up and they are slightly more readable, abut they are still long ugly numbers. We've made things slightly longer, and slightly less ugly, but I don't know if we've improved the overall score. It depends how we weight our priorities. foo entry2345.1239878725027/entry entry235.237926028973/entry entry558.1283745628374/entry entry9.123242342346M/entry /foo As long as this is only an XML markup question, the disadvantages are: - higher failure probability Why is there a higher probability of failure? If I want to stretch to make a point, I could suggest that forcing a developer to type in more xml tags also increases the probability of making a typo. But I think this whole point is very weak. - one has to know about the order and meaning of elements; they are not self-describing You could call the property name something like foo-rgba, then it is self describing much like altitude-meters or longitude-radians is self describing. And often order is implied and standard and the same all through project. rgb or rgba for colors, xyz for 3d positions, etc. This point is highly weak, and doesn't seem to help support your case. Forcing programmers to keep track of the order of elements within the arrays they define ... would that be an argument for eliminating arrays from all of the computer world and replacing them with records of named fields instead? I'm now starting to feel very sorry for all those programmers out there who keep losing track of the order of their array elements ... getting their colors and vectors and matrix elements all mixed up ... :-) I know it sounds better to list 5 reasons rather than 1 or 2, but you need to be careful if several of them are meaningless filler. - it's a bastardized format: it's a custom format *within* XML If I was scoring your argument here, this would be the first real point you have to make. - XML tools can only treat the entry as a whole, but not the elements. For example: a *.dtd file cannot validate the entries (http://en.wikipedia.org/wiki/Document_Type_Definition; not that I have any experience with that) This is actually a continuation of the previous point ... although if external tools just maintain the contents between tags verbatim when they can't understand the structure any further, then this doesn't lead to overall harm, just a situation where external tools can't deal with the individual elements. Maybe bad? Maybe not bad? Can you cite an example where this would be bad? - XML editors might not support such conglomerates (ok, weak argument ... who on earth uses an XML editor?! ;-) Ok, so by my score, you have scored 1.5 out of 5 bullet points assuming we score weak arguments as 0.5 and filler material as zero. Although mentally I parsed your bullet points into an array so I might have got the order confused and miscounted the score. :-) But that's all just XML representation. As soon as this thing ends up being stored in the property tree as new vec4, color etc. nodes, the fun is over: foo = '2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346' (vec4) background = '0.12332975 0.123784967 0.28375891205 0.127456582302' (color) Should we make the property browser full-screen, so that one can still handle the entries? But that's only the response to your question: I diverge from Tim in one sense that I don't support adding specific vec4 or color aggregates to the property tree as atomic elements. I would much rather support arbitrary length arrays of float or double or int (or even boolean.) However, I asked Tim about this and he said you reacted even more strongly against arbitrary arrays then specific color3f, color4f, color3d, color4d, vec3f, vec3d, vec4f, or vec4d types. Was this a clever move? Because it's much easier to argue against a adding random and highjly specific aggregate types versus generic arrays? If so, +1 for cleverness on your part. :-) So by my understanding, you have steered Tim away from generic arrays into specific aggregate types in earlier IRC/email discussion. Let me ask a question to those that are concerned that the property browser would be unable to handle the new types. Does this concern presuppose that the property browser can currently be used to perform any and all desired manipulations on the property tree as it exists now? Then I could understand some concern if the new types would break that existing orthogonality. In that case, let me ask this: Is it possible to create a new node in the
Re: [Flightgear-devel] RFC: graphics effects files
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 angle? Beats me, but I'm not the one claiming that the property list format is self-documenting. Adding a suffix would be a possibility. After all, just like in the case of -ft or -m suffixes, it's only meant for the human user or coder, so that s/he knows how to handle the type. The code itself knows it, because it's written that way. The listener of the color-at (or color-atomar) node knows it without looking at the node name. That's just business as usual, not a new challenge. Right, so it's (mostly) the Nasal programmer who would have to know the suffix. Tim -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 self-documenting. Well, it is. The answer to my two questions is: suffixes! We know heading is in degree, because its name is heading-deg. We know a value is normalized, because its name is position-norm. And we'd know that a branch is atomic, because its name could be whatever-atomic (or something shorter). But that's just optional. Right, so it's (mostly) the Nasal programmer who would have to know the suffix. No. Any human who gets in contact with the property. For example, someone browsing the tree in the browser dialog. Or someone using it in nasal, or writing it from an fgcommand binding. The property tree is just data storage for IPC purposes. Writing to most nodes doesn't have an effect *at all*, without giving you *any* hint about that. You don't get any feedback on writing. You just have to know if you can expect an effect or not. Only some properties are polled or have listener callback functions attached, or are tied to functions. And a suffix could tell you that writing to a child alone doesn't have an effect either (like for most other nodes), but that the whole branch is evaluated in an atomic way if you trigger the parent node. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 based on our own experience rather than on theoretical assumptions. I can live well with that. To state more clear: I would vote for the array solution. since I read in this discussion that this appears to show up as a route that is sufficient for Tim and where most of us can live with. Greetings Mathias -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 discussion , where standard practice seems to be commit , then explain how things need to be done differently now. Thanks Tim , even if I dont quite follow the drama , its nice to know what's in the works . Cheers -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 the comma. What about this? foo2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346/foo There goes the nicety. Long ugly numbers or long ugly numbers. We can split them up and they are slightly more readable, abut they are still long ugly numbers. We've made things slightly longer, and slightly less ugly, but I don't know if we've improved the overall score. It depends how we weight our priorities. foo entry2345.1239878725027/entry entry235.237926028973/entry entry558.1283745628374/entry entry9.123242342346M/entry /foo As long as this is only an XML markup question, the disadvantages are: - higher failure probability Why is there a higher probability of failure? If I want to stretch to make a point, I could suggest that forcing a developer to type in more xml tags also increases the probability of making a typo. But I think this whole point is very weak. I know better then contribute to this discussion but foo 2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346 /foo Looks best to me Norman -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 pretty well summarized my own stance on this. Let me just add a few thoughts: Just the fact that a few extensions of the existing property types can have a positive impact on rendering speed, as I judge from Tim's original proposal should be enough to at least allow us to experiment with this. I presume that if we really run into trouble somewhere down the line, we can always fix the offending parts in the process, or switch over to something more along the lines of the current architecture. Secondly, the fact that we do have additional property types certainly doesn't mean we have to use them in situations were the existing solution would suffice. It seems to me that Tim has adequately addressed any potentials concerns raised in this area. Cheers, Durk -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 numbers can be converted into a vector class internally in C++ code without the new vector format inside an XML tag. Moreover, the new vector format doesn't improve the usability at all. a user-defined text format inside an XML tag is not recommended since it decreases the readability unless you give a comment, which is way not better than using tags. If we really need more concise format that improves usability, then we need to throw away our current xml files and make new files in our own new format, which I believe is nonsense. The new format also needs a parser, property browser changes, and converter(s) that don't help us improve any usability or performance at runtime, I guess. If such new format gives us some usability or performance improvement, I can accept it even if some extra work is required, but this is not the case. The JSBSim's table format, which I believe, also lacks the readability. It ,however, gives aircraft developers some usability like easier to copy and paste some table data from external tools like javaprop or excel. I know some helper script can create a well- formatted XML tags, but it could be true that many aircraft developers like simple copy-paste things while tweeking prop/engine things tons of times a day. Nevertheless to say, these tables don't need converters or browser changes since these are only read at launch time, and are not readable from the property browser or telnet. So comparing JSBSim table and the vector format doesn't seems fair to me. I hope many people understands what Melchior said on the property system. His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. He might be sometimes brutal in his written words, but I really like his software architecture related comments. These are almost always right, at least to me. I don't say anything on his other comments though :-p Tat p.s. I've moved and my network connection is limit only to iphone until at the end of this month. Sorry for my vry slow response, especially to Mac users. - Tatsuhiro Nishioka On 2009/04/06, at 5:33, Erik Hofman e...@ehofman.com wrote: 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 have been cautious about including it, this setup does tend to result more errors than laying it down is separate xml nodes. Also, the JSBSim configuration files are often generated by a script (aeromatic in this case) first and then altered. This minimizes human error. That said, it looks to me the best way to eliminate all concerns is to make sure that subsystems that are going to use array-properties use a detached property tree (not attached to the root tree as shown in the property manager). It looks to me that would be no problem for the shader subsystem since it (like JSBSim) only uses the property tree to read the configuration file. After it has been read there would probable little or no need to adjust the individual properties using the property manager, or to send them over the network, anyhow. Erik --- --- --- - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). I'm very sorry you feel that this is such a critical issue that you wish to stop making your contributions to the project. You obviously feel very strongly about this issue, otherwise you wouldn't be considering such a drastic step. While I'm not convinced by Tim's arguments, I accept Curt's comment that this is new function that won't break anything that already exists. I'm prepared to wait and see what this means in terms of actual code, XML and properties. We already have some XML files that aren't completely part of the property system (IIRC, AI traffic, JSBSim configuration, materials.xml), and this is at least going to be part of that. Plus, it is a significant step forward from our current shader support, where the shaders are hardcoded into the source code, and difficult to use (which is at least partly my fault!). Finally, FG will always be a work in progress, and this decision isn't set in stone. If we find that we really need to split up these RGB value, I'm sure someone will be able to produce a patch. Therefore I'm not going to get too worked up about it - there are plenty of other things for me to worry about. FlightGear is, of course, a collaborative project and that means giving up some control in return for the benefits that it brings. Inevitably sometimes the project will go in directions you don't agree with. Personally, I feel that the benefits far outweigh the disadvantages. Feel free to respond to this on- or off-list. Best regards, -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 there isn't any documentation for the graphics portion of these files. The example is intended only to motivate the property list discussion. Tim I guess it is a bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! Regards HHS-- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and extension-supportedGL_ARB_shader_objects/extension-supported extension-supportedGL_ARB_shading_language_100/extension-supported extension-supportedGL_ARB_vertex_shader/extension-supported extension-supportedGL_ARB_fragment_shader/extension-supported /and /or /predicate pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular shininessusematerial/shininess/use/shininess /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit texture-unit texture2dusetexture1/texture2d/use/texture2d /texture-unit shader-program uniform namebumpHeight/name typefloat/type usebump-height/use /uniform uniform namepatternRotation/name typevec4d/type usepattern-rotation/use /uniform vertex-shader Shaders/util.vert /vertex-shader vertex-shader Shaders/foo.vert /vertex-shader fragment-shader Shaders/foo.frag /fragment-shader /shader-program /pass /technique technique pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit /pass /technique /effect /PropertyList Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 have is that initially it sounded that the red, geen and blue properties would be *replaced* with a vector based one. I don't like that principle as a modeller. Therefore I've asked Tim if that's the case.And if it is I still object. Adding shader support using xml files is not something I would object to. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 has also always supported character arrays. 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 of a string like you could if it were an array. The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? Will input fields in remote applications (instructor) have to write special validators for VEC3 properties, rather than just having three fields that accept a number? How will we input VEC3 properties via the property browser? As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. 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. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. Melchoir has done much to enhance the usability and elegance of most of our systems. Initially I was not a fan of all the nasal code, but I have come to greatly appreciate its functionality and power. 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. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But
Re: [Flightgear-devel] RFC: graphics effects files
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 types. The property system has also always supported character arrays. 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 of a string like you could if it were an array. The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear- de...@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? Will input fields in remote applications (instructor) have to write special validators for VEC3 properties, rather than just having three fields that accept a number? How will we input VEC3 properties via the property browser? As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. 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. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. Melchoir has done much to enhance the usability and elegance of most of our systems. Initially I was not a fan of all the nasal code, but I have come to greatly appreciate its functionality and power. 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. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I
Re: [Flightgear-devel] RFC: graphics effects files
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 questions after reading this: 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. 2. As I see this now this is a way to define custom (not hardcoded) effects. This means only a small number of these configuration files will be created and probably only by developers who know what they are doing. Am I right? That's hard to predict. We'll probably have a set of standard effects that modelers will use most often, but if someone wants to write their own shader program, they would write an effects file too. I hope that, because of effects file inheritance, most files will be shorter than this example. Tim If both answers are 'yes' then I see no problem with adding it, otherwise there's still gonna be a bit of discussion I guess. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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. I guess it is a bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! True, but there are tow ways of doing it; * hardcode the effects that are needed * add the ability to make custom, configurable effects files. To be honnest, I don't expect that many custom effects files will be created and the ones that are created are going the be used by almost all modellers. This sounds like hardcoded will be just fine. I don't think so. Artists and modelers like to play with shaders, even if initially they might not understand the programming behind him (the shader might come from a shader generation tool, for example). Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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, just don't seem in line with long-standing and proven FlightGear conventions or the modular design and implementation of the original property tree code in the first place. This applies in particular because all of the desirable functionality can apparently be implemented by using existing infrastructure and conventions, as has been demonstrated by various postings illustrating viable alternative and even better approaches using the existing API and conventions. But also because this proposal doesn't seem to really directly improve or benefit any other FlightGear components, which raises the question if implementing support for new primitive types in the global, system-wide property tree really is a good solution in this case? This also seems questionable because it introduces changes (namely new primitive types) to the property tree system that appear highly subsystem-specific, and irrelevant to or even incompatible/unsupported with the rest of FlightGear? Wouldn't these properties be highly specific to just one component and use in FlightGear (unlike any other feature of the property tree)? Wouldn't this create additional baggage in the property tree code that is not even remotely useful in other areas of FlightGear? Wouldn't they create yet another way of doing things [no matter how concise]? So it really appears to boil down to enhancing a proven and central FlightGear component with support for new types in order to accommodate the needs of one particular FlightGear system. The most often cited reasons I could find were: I find the sytntax way too verbose for simple aggregate properties like colors. More concise syntax for aggregate values I think XML is way too verbose I just want to evolve the very useful property system to support the syntax I like It seems, all previously posted technical arguments (atomicity of updates and performance considerations) were shown to be addressable by using a more conventional approach, using listeners and tied memory? So is this really not just about syntactical sugar? What real technical advantages are there (apart from the more concise syntax), advantages that are not just specific to one specific feature or component and that are not addressed by any of the previously suggested alternatives? regards -hfitz -- Get even more from your private email hosting service. Visit the pages of Zoner Software and download your free copy of the Zoner Photo Studio 11 program today! Learn more - www.zoner.com. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 vectors as stated, the less concerned I am. FlightGear uses properties pretty much for data input as far as I can tell. JSBSim does that, but also generates properties on the fly and connects them up at runtime and performs specified function operations (of any complexity) on them. Having to handle type checking on anything other than the double which is assumed might complicate things. If the new changes are backwards compatible in code, then it may not end up being a problem. JSBSim uses some elements of simgear (properties and xml handling), and if the props.[ch]xx code (for instance) gets changed a lot, I'm concerned that it may negatively impact our operations. I understand that it should not impact us, and that we should be OK. But, sometimes in coding there are side effects and unintended consequences, and given the magnitude of the proposed change, I'm sure we'll proceed with due diligence. JB -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 outermost concern you could tie each of the
components of a double vec[4] to properties, e.g.
color/{red,green,blue,alpha}. That would make it possible for the internal
C++ code to use the vector representation while still preserving a nicely
structured and typed property tree for external access.
The relevant values in OSG are protected members, accessed through getters and
setters, so you can't tie the value to be set directly. Uing a tie like this
just pushes
the problem downstream a bit; one would still need to jump through the hoops I
detailed
before in terms of pushing the new value(s) to OSG.
Tim
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 get this in. But I agree with all your points. That's fair, I've been disregarding pretty much everything you've said in this discussion ;) This does also not make sense to me: vertex-shader Shaders/util.vert /vertex-shader Why should any part of fgfs (or external apps) have to deal with stripping quotes around strings? Should be: vertex-shaderShaders/util.vert/vertex-shader or probably even better vertex-shader-path. Yep, that's a bug; quotes shouldn't be part of the syntax. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
I can't really imagine all possible uses, but people are clever
with animations, and one could imagine a fair number being changed
every frame.
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. 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.
No intrusive changes with multiple bad side effects needed.
Sounds like a very brittle hack to me when the update would
just happen if the property were a vector.
Tim
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). So essentially since you may not get your way, you're going to take your ball and go home? WTF? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. OpenQM - A Multi-Value database for the masses, not the classes. http://gpl.openqm.com - Get it _today_! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 way. I am not taking anything with me. I'm just going home, because the others have changed the game from football to throwing in windows. And that's not what I want to take part in. All you need for that is a spine. Nothing evil. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 something away so that others can't continue enjoying the game, only because one doesn't have his way. I am not taking anything with me. I'm just going home, because the others have changed the game from football to throwing in windows. And that's not what I want to take part in. All you need for that is a spine. Nothing evil. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 the nth character of a string like you could if it were an array. I'm not sure I agree there ... while the facts you state are true, it is also true that the property system can be used to store arrays of characters. Is Tim's proposal to add arrays of float's along with a full set of operations on the individual elements? The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? Let me say a couple things here. How is floating point input handled right now? All these interfaces input the new value as a character array and then based on previous knowledge of the data type, convert that string to the appropriate type. If there's no other indication of the data type, the value is left in the form of a character array. How would it be any different in this case? We would need some code to parse the string into the appropriate data type if the property has been typed as a float array. Likewise, the telnet/web interface need to convert the numeric values to strings before outputting them. Again, in the case of a floating point array, how would this be any different? Slightly more complex, but if some conventions are chosen (like putting a space between the numbers as Tim has proposed, then this can be done unambiguously and consistently.) I don't want to be dismissive of this concern, but it seems pretty minor to me? Am I missing something here? Can you suggest a case where this would be confusing or would break something? Will input fields in remote applications (instructor) have to write special validators for VEC3 properties, rather than just having three fields that accept a number? How will we input VEC3 properties via the property browser? By Tim's proposal you would do this like this: 0.1 2.4 -3.0 1.0 As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. A big problem here (in my view) is that neither side is being as clear as they need to be with this discussion. We can't just assert there will be a problem and leave it at that. I'm still hoping someone can list a specific example of how these interfaces will break. Or am I the only one in the room who doesn't see the obvious cases? 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. I hate to put words in people's mouths, but let me try to do this fairly The primary reason I heard from Jon, is that he was thinking this will require a huge expansion in creating operators that manipulate these vectors ... and do all the different vector math operations. I think that's a misconception, but maybe I missed something in Tim's proposal? If true, then I agree with Jon's conclusion, but I think this is a misconception with the proposal. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. If these folks are speaking from a modeler's perspective and expecting that this proposal will require them to redo all the color and vector properties in all their modeling work, along with rewriting all the corresponding nasal code, then yes, this would be a horribly unnecessary thing to force on the FlightGear community. But again, I hope Tim can respond when he has a chance, because I think this is a misconception with Tim's proposal. If these modelers have correctly interpreted Tim's proposal, then I'd side with the modelers, but I suspect this is a misinterpretation of the proposal. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) Can anyone point to any place within the FlightGear project where we don't use RGBA? And if so, why does the code need to do it differently? If we write out the color components in random orders and inconsistenly throughout the code, then this could be a point, but I can't think of one
Re: [Flightgear-devel] RFC: graphics effects files
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. 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. And it still is. I hate to put words in people's mouths, but let me try to do this fairly The primary reason I heard from Jon, is that he was thinking this will require a huge expansion in creating operators that manipulate these vectors ... and do all the different vector math operations. I think that's a misconception, but maybe I missed something in Tim's proposal? If true, then I agree with Jon's conclusion, but I think this is a misconception with the proposal. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 remains backwards compatible – which, I’m sure, is a given. It can be useful to look at past history as precedence to give some context when evaluating some new situation. In light of that we should notice that JSBSim supports arbitrary vectors and tables of floating point data within it's xml file syntax and has done so since it's very earliest days. This is only part of the picture because as far as I know they don't have a way to store these tables in their property system, but it's interesting to observe that JSBSim has gone partway already in doing something similar to what Tim is proposing. 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? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 have been cautious about including it, this setup does tend to result more errors than laying it down is separate xml nodes. Also, the JSBSim configuration files are often generated by a script (aeromatic in this case) first and then altered. This minimizes human error. That said, it looks to me the best way to eliminate all concerns is to make sure that subsystems that are going to use array-properties use a detached property tree (not attached to the root tree as shown in the property manager). It looks to me that would be no problem for the shader subsystem since it (like JSBSim) only uses the property tree to read the configuration file. After it has been read there would probable little or no need to adjust the individual properties using the property manager, or to send them over the network, anyhow. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 this: 1. Will ambient/r, ambient/g and ambient/b still be supported in other locations besides xml embedded effects en techniques? 2. As I see this now this is a way to define custom (not hardcoded) effects. This means only a small number of these configuration files will be created and probably only by developers who know what they are doing. Am I right? If both answers are 'yes' then I see no problem with adding it, otherwise there's still gonna be a bit of discussion I guess. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! True, but there are tow ways of doing it; * hardcode the effects that are needed * add the ability to make custom, configurable effects files. To be honnest, I don't expect that many custom effects files will be created and the ones that are created are going the be used by almost all modellers. This sounds like hardcoded will be just fine. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 reasons! m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 all your points. This does also not make sense to me: vertex-shader Shaders/util.vert /vertex-shader Why should any part of fgfs (or external apps) have to deal with stripping quotes around strings? Should be: vertex-shaderShaders/util.vert/vertex-shader or probably even better vertex-shader-path. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 variance=dynamic attribute that indicates that a parameter can be animated and that graphics state that depends on it may need to be updated. Many people seem unconvinced by my arguments for new property types. That's fine; I'm still convinced that they are desirable :) One implementation reason that I would like to treat values like colors as vectors is that the underlying OSG type is a vector, so if the components are individual properties that can be written individually, the implementation choices for updating the OSG state are unattractive: 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. 2) Update all effects with dynamic components every frame. We have a lot of material animations, and their management is currently eats a lot of time in the update phase, so I'd like to avoid this. On the other hand, we may be updating most animations every frame anyway. 3) Record which effects have been changed, then update their OSG state. Complicated bookkeeping... 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. ?xml version=1.0 encoding=utf-8 !-- An effect consists of parameters and techniques. The parameters section of an effect is a tree of values that describe, abstractly, the graphical appearence of objects that use the effect. Techniques refer to these parameters and use them to set OpenGL state or to set parameters for shader programs. Parameters can be declared to have a dynamic variance, which means that if their value is changed the corresponding value in the technique will be changed too. A technique can contain a predicate that describes the OpenGL functionality required to support the technique. The first technique with a valid predicate in the list of techniques is used to set up the graphics state of the effect. A technique with no predicate is always assumed to be valid. A technique can consist of several passes, which are run in sequence. One feature not fully illustrated in the sample below is that effects can inherit from each other. The parent effect is listed in the inherits-from form. The child effect's property tree is overlaid over that of the parent. This means that effects that inherit from the example default effect below could be very short, listing just new parameters and adding nothing to the techniques section; alternatively, a technique could be altered or customized in a child, listing (for example) a different shader program. Material animations will be implemented by creating a new effect that inherits from one in a model, overriding the parameters that will be animated. -- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and
Re: [Flightgear-devel] RFC: graphics effects files
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? -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. 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.
No intrusive changes with multiple bad side effects needed.
m.
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. 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.
No intrusive changes with multiple bad side effects needed.
As I see it this proposal would satisfy the many who want to retain the
red green etc. tags and would appear to meet the requirements of OSG.
But I sure there are other solutions, or I might be getting it totally
wrong.
I hope the best is not getting in the way of good enough.
Vivian
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. 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.
No intrusive changes with multiple bad side effects needed.
m.
I too think the that the real issue here is the representation in
the property tree, not functionality. As long as the data is
available in the property tree it shouldn't affect the
functionality at all because it'll be trivial to convert from the
current property tree representation of the data to the form
required by OSG.
I still can't see a good reason to make changes to the way the
property tree represents data unless the overhead of accessing
three or four property tree nodes, instead of just one, has a
significant impact on performance.
How frequently does this data need to be accessed?
LeeE
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 configuration and all the things we can do with nasal.
With all due respect to Melchior, I don't think he has presented a strong
case against adding vectors into the property system. The examples he
listed early in this discussion really did not carry a lot of strength and
several of his points could be easily dismissed. If there is a strong case
to be made, I don't think it has been made yet.
With all due respect to Tim, slightly more compact xml representation for a
couple small parts of a couple files isn't a strong argument for adding new
complicated code.
Arrays of like elements have been part of computer programming every since I
saw my first computer program in 1983 ... probably well before that even.
Right now, I find it really hard to see why we would absolutely refuse a
submission that adds functionality without changing existing functionality.
FlightGear is full of example of this sort of thing. I just don't see why
the heels are dug so far in on this one
So in my view if we are discussing the addition of a feature that is
immediately useful for some developers, and it does not harm existing code
or features, but simply adds functionality, then this is right in line with
typical FlightGear development procedure.
If there is any one who doesn't want this particular code added, I think the
burden is on them to put forth a very strong case for why not. What
specifically is harmed? What specifically will break? What specific corner
are we painting ourselves into? And if a legitimate concern is raised,
then hopefully Tim can come back and address that. But so far I haven't
seen any concern that hasn't been reasonably addressed already by Tim.
If we say that we won't allow new code if there is already some way to do
most of what the new code does in some other way, then we might as well get
rid of nasal, because we can already do everything that nasal does in C++.
And why would we have migrated to C++ since we could already do everything
we wanted in C. Why would we add a menu and dialog system when we can
already do everything with command line options and keystrokes? Why make a
Mac version when there is already a windows version? I can think back to
early in the project when adding the property system itself was a highly
controversial move. The clear answer to why we've added much of our code
and features is convenience; ease of use ... and maybe only for a few
developers or end users ... not necessarily for everyone.
So after hearing all the discussion (maybe I'm forgetting something, but I
can't think of what that might be) I am having a really difficult time
seeing why we would prevent the addition of new code that simply adds
functionality without harming or changing or removing existing
functionality.
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.
Best regards,
Curt.
On Sat, Apr 4, 2009 at 11:14 AM, LeeE l...@spatial.plus.com wrote:
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 have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. 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.
No intrusive changes with multiple bad side effects needed.
m.
I too think the that the real issue here is the representation in
the property tree, not functionality. As long as the data is
available in the property tree it shouldn't affect the
Re: [Flightgear-devel] RFC: graphics effects files
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 tie each of the
components of a double vec[4] to properties, e.g.
color/{red,green,blue,alpha}. That would make it possible for the internal
C++ code to use the vector representation while still preserving a nicely
structured and typed property tree for external access.
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.
If you really must have it, please put it in a subtype.
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* 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 can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). Good luck m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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, and will do so as often as it is brought up again. And for all the same reasons! Hi Melchior, Let me ask this on the list. 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 has also always supported character arrays. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. 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. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But if someone makes an assertion I don't understand, or supports it with reasons that don't make sense to me, I have trouble buying that assertion. I've always had that problem, and it's my own personal failing I know. I think it's a good thing I didn't sign up for military duty here when I was a kid because of that. But at the end of the day here, I haven't seen why Tim's contribution is unreasonable, or what makes it so different from other contributions that have added functionality to the code base. I'm trying to guess here at what it might be and haven't stumbled on anything I can point to. Really, why is it so unacceptable? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
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 cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! Regards HHS-- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and extension-supportedGL_ARB_shader_objects/extension-supported extension-supportedGL_ARB_shading_language_100/extension-supported extension-supportedGL_ARB_vertex_shader/extension-supported extension-supportedGL_ARB_fragment_shader/extension-supported /and /or /predicate pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular shininessusematerial/shininess/use/shininess /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit texture-unit texture2dusetexture1/texture2d/use/texture2d /texture-unit shader-program uniform namebumpHeight/name typefloat/type usebump-height/use /uniform uniform namepatternRotation/name typevec4d/type usepattern-rotation/use /uniform vertex-shader Shaders/util.vert /vertex-shader vertex-shader Shaders/foo.vert /vertex-shader fragment-shader Shaders/foo.frag /fragment-shader /shader-program /pass /technique technique pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit /pass /technique /effect /PropertyList Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
