Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Saturday 11 July 2009 09:28:21 Tim Moore wrote: Vote against. You will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects Note that I said and its cousins. I had thought that TR1 includes boost's intrusive_ptr, but now I see that it doesn't. No matter; it is in boost and available. This wouldn't replace your implementation of SGReferenced or osg::Referenced, but simplifies access to them by clients who wouldn't have to care about the specific type of the reference-counted object. The only thing in tr1 is the shared_ptr/weak_ptr. I am Not sure what tr2 includes. What I am missing in the intrusive pointer is a thread safe implementation of the weak_ptr. Note that we already have that in simgear ... Not yet thought about that, but is there any chance to implement the weak_ptr semantics together with the intrusive_ptr? Again, I'm not proposing getting rid of SGReferenced; I'd just like a unified way to use different pointer implementations. Ok, I see. But, at least to me it was never a big problem to distinguish between fg/sg classes and scenegraph classes. So scenegraph means osg::ref_ptr and fg/sg means SGSharedPtr. And from an abstraction point of view osg* usage should not be visible too much. Those places where this rule is broken is something I do not like either. As already told, I believe that it is not a good idea to tie a simulation to a viewer framework. And a scenegraph is nothing more than that ... Greetings Mathias -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Mathias Fröhlich wrote: Hi Tim, On Sunday 05 July 2009 22:51:32 Tim Moore wrote: We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. Vote against. You will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects Note that I said and its cousins. I had thought that TR1 includes boost's intrusive_ptr, but now I see that it doesn't. No matter; it is in boost and available. This wouldn't replace your implementation of SGReferenced or osg::Referenced, but simplifies access to them by clients who wouldn't have to care about the specific type of the reference-counted object. that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of. Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make raw pointer based apis if required. I'm not a big fan of std::shared_ptr either. So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would like to have. The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have that available. This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation. Again, I'm not proposing getting rid of SGReferenced; I'd just like a unified way to use different pointer implementations. Tim -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Sunday 05 July 2009 22:51:32 Tim Moore wrote: We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. Vote against. You will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of. Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make raw pointer based apis if required. So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would like to have. The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have that available. This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation. Greetings Mathias -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Mathias Fröhlich wrote: Hi Tim, On Thursday 25 June 2009 23:58:42 Tim Moore wrote: Mathias Fröhlich wrote: Hi Tim, Seriously, I didn't realize that reducing dependencies on OSG in simgear is a design goal. That's fine, but I would really prefer to not think about whether I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... I see you point. I would not tell that a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL. Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all. I already did so when I started to switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application ... I understand the desire, it's just that I thought of simgear as a glue layer between OSG and flightgear, and thus OK to use OSG datatypes everywhere. I'll be more restrained in the future. Anyway, I screwed around a bit with making the SGVec types more directly compatible with OSG functions. Conversion operators don't help much; making osg::Vec types be public superclasses of SGVec helps a lot of course, but I can understand if you don't want to go that route. In the end, I can live with the status quo for my purposes. Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible. More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ... What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there. We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. Just to be more flexible with extensions in this area we might need, I would like to have our own stuff. So I do not need to introduce a change to Robert and then wait a few months before I can rely on people having that change available in flightgear ... I can find many more benefits of this stuff we have already. The rule of thumb when to use what is simple: If you are in the scene graph most probably osg::... might be a good thing to use. If you are in the simulation, network, input system, property system, wherever not scene graph dependent, use simgears own classes. So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term. Sounds reasonable. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Thursday 25 June 2009 23:58:42 Tim Moore wrote: Mathias Fröhlich wrote: Hi Tim, On Thursday 25 June 2009 10:22:54 Tim Moore wrote: OK, but in case you hadn't noticed, libsgmath depends on OSG. Yes I have noticed that change in the quaternion/matrix. If you mean the methods in SGGeod that return osg::Matrix, I wrote them that way because the values get plugged directly into the scene graph. Sure, no problem or offense here. I just might replace that with something that removes that dependency. I believe that we should get rid of that. And yes, the vector storage is from osg. But it is a few line change to get rid of that. That was designed for that :) And then you can change the ~100 uses of '.osg()' to access that storage. :) Yes, I know. The read from SG write to osg portion is easy to handle. The other way was to ease the transition and will be way less to change if one needs to... If you want to I can change that so that we *are* independent instead of being nearly independent. Seriously, I didn't realize that reducing dependencies on OSG in simgear is a design goal. That's fine, but I would really prefer to not think about whether I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... I see you point. I would not tell that a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL. Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all. I already did so when I started to switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application ... Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible. More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ... What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there. Just to be more flexible with extensions in this area we might need, I would like to have our own stuff. So I do not need to introduce a change to Robert and then wait a few months before I can rely on people having that change available in flightgear ... I can find many more benefits of this stuff we have already. The rule of thumb when to use what is simple: If you are in the scene graph most probably osg::... might be a good thing to use. If you are in the simulation, network, input system, property system, wherever not scene graph dependent, use simgears own classes. So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Curtis Olson wrote: 2009/6/23 Mathias Fröhlich Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg. ... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... This is an interesting point. I also use simgear and the property system in a variety of other projects, so whatever we do, we shouldn't make these low level libraries depend on OSG (which isn't available for instance on my little embedded UAV controller.) OK, but in case you hadn't noticed, libsgmath depends on OSG. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Thursday 25 June 2009 10:22:54 Tim Moore wrote: OK, but in case you hadn't noticed, libsgmath depends on OSG. Yes I have noticed that change in the quaternion/matrix. I believe that we should get rid of that. And yes, the vector storage is from osg. But it is a few line change to get rid of that. That was designed for that :) Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Mathias Fröhlich wrote: Hi Tim, On Thursday 25 June 2009 10:22:54 Tim Moore wrote: OK, but in case you hadn't noticed, libsgmath depends on OSG. Yes I have noticed that change in the quaternion/matrix. If you mean the methods in SGGeod that return osg::Matrix, I wrote them that way because the values get plugged directly into the scene graph. I believe that we should get rid of that. And yes, the vector storage is from osg. But it is a few line change to get rid of that. That was designed for that :) And then you can change the ~100 uses of '.osg()' to access that storage. :) Seriously, I didn't realize that reducing dependencies on OSG in simgear is a design goal. That's fine, but I would really prefer to not think about whether I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Saturday 20 June 2009 19:46:50 Tim Moore wrote: Actually, I am using osg::Vec3d and osg::Vec4d. I tend to view the SGVec types as redundant, but that's a personal preference. I don't mind using SGVec in the property system, but if I do that I would like to add an operator to SGVec* to provide a conversion to its internal OSG type. Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg. ... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... Yeah, but we do that in the OSG update phase, which is exactly when these updates are supposed to happen. Nothing that alters the scene graph can run during the cull and draw phases, but we have to be able to alter the scene graph at some point. Note that I distinguish between the application step, which happens before the update step and the real update step which is the update visitor's traversal. And in the mid term, we may run the application step in parallel to the cull draw step. So we will just have a very short serial update step. So, in this model - where I am heading to in the mid/longer term, this listener usage hurts. The point is well taken, but the property listeners would be on properties that are directly tied to the effect structures and are not in the main property tree. For the foreseeable future they will be set from C++ material animation code, but I don't see a real problem in setting them from nasal code. It's true that accessing the scene graph safely from multiple threads is going to be an interesting challenge... May be that does not hurt currently. But if there is a way around that kind of issue I would prefer to take that. May be we will make more use of a more distributed simulation system. In this case the listeners in the viewer would not be an issue anymore, but if you can see a way that would allow the simulation step to run in parallel with cull/draw, it would be good I think. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
2009/6/23 Mathias Fröhlich Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg. ... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... This is an interesting point. I also use simgear and the property system in a variety of other projects, so whatever we do, we shouldn't make these low level libraries depend on OSG (which isn't available for instance on my little embedded UAV controller.) 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] property system extensions redux
Hi Curt, Tim, On Friday 12 June 2009 20:10:17 Curtis Olson wrote: I have one concern that I may not have voiced clearly before. Well, I believe that I have to contribute here :) I tend to think about these design choices in terms of what is often called orthogonality. The idea stems from the world of vectors. The idea of orthogonality is if you want to represent any point in 3d space, you can do it by some combination of x, y, z components. The x, y, and z axes are arranged orthogonal or at right angles to each other. Each axis is completely independent from the other axes. You could imagine some other space where the axis go in odd skewed directions that aren't at right angles to each other, and you could still represent point locations, but the numbers would be odd and hard to deal with, hard to add and subtract and manipulate. So an orthogonal (at right angles, or said another way, completely independent) components are an ideal way to represent a point in 3d space. So if you translate that concept over to computer languages, or computer API's, I believe strongly that these things also work best when they are orthogonal. In other words, we want a minimal set of independent components we can use to specify or accomplish what we want. This makes for clear and understandable and maintainable code. I totally agree here! BTW, what I try to do in some cleanup stuff currently is to regain that kind of orthogonality in the implementation where we have already too much mixed up. Going back to the 3d point example. If we start adding components like a curving axis in some random direction, or points that are only valid on the 2nd tuesday of every month, you wind up with a huge mess of special cases. You lose the ability to perform simple functions (like + or -) on individual components. Basic principles like 0 * x = 0 and 1 * x = x may no longer be true. And if you have points that are only valid on the 2nd tuesday of every month, it probably doesn't make sense to define a special data type for that with mixed interdependent components, instead it makes sense to think about what independent components we can use to build what we want. So as you speak of adding Vec3 and Vec4 types to the property system, I immediately have orthogonality concerns. We seems to be adding a specialized core type that is only good for one purpose along with the specialize code to handle just that particular type, and we are moving against the concept of orthogonality (which I feel is highly important when designing api's, computer languages, vector spaces, etc.) This is where I start to disagree! Vectors are such an abstract thing that I have no orthogonality concerns at all. So a vector is just a tuple of n scalars that can be added and scalar multiplied. That is so far the mathematical definition. So introducing such an abstract type is nothing more special than introducing an other abstract type like a double for example. For the property system the data type could be reduced to a tuple of n scalar values. You do not need to know something about the arithmetics from the property system. Curt, I am not voting for your example of 'Tims-best-datatype' stuff of things to the properties, but given he wants to add tuples of scalars so often called vectors, that is a concept that is almost as general like a floating point value, I have to say that I would love to have that ... Now, just to show you how fair I am, there is another side to this discussion that is also just as important to consider. Languages and API's often develop idioms and short cuts for things that are heavily used. It makes life more complex in the sense that now you have to learn the idioms that don't necessarily have any obvious literal meaning, but once you learn the short cuts, you have a much more efficient way to do something or express some particular idea. That can be very useful and very practical for things you might do quite often. So as I see it, the debate breaks down to practicality versus orthogonality. Do we permit some idioms to develop for commonly used operations or commonly used structures? That doesn't have to be a bad thing in my view. But orthogonality is a really good thing, so we should strive to maximize orthogonality and minimize idioms (to mix langauge and math terminology in the same sentence.) We need to set a pretty high threshold before allowing new idioms to be added, and especially when adding the first idiom to a purely orthogonal system. Speaking figuratively, what it looks like to me is that we will be adding two more axes to our beloved X, Y, Z (figurative) system. The Tim1 axis and the Tim2 axis ... both point directly to your two specific points in space. That may be ok from a notational stand point, but I can understand the resistance to poluting the well loved and well understood traditional X, Y, Z space just because one person
Re: [Flightgear-devel] property system extensions redux
Mathias Fröhlich wrote: On Friday 12 June 2009 20:10:17 Curtis Olson wrote: So as you speak of adding Vec3 and Vec4 types to the property system, I immediately have orthogonality concerns. We seems to be adding a specialized core type that is only good for one purpose along with the specialize code to handle just that particular type, and we are moving against the concept of orthogonality (which I feel is highly important when designing api's, computer languages, vector spaces, etc.) ... Curt, I am not voting for your example of 'Tims-best-datatype' stuff of things to the properties, but given he wants to add tuples of scalars so often called vectors, that is a concept that is almost as general like a floating point value, I have to say that I would love to have that ... Yes! This has been my belief from the beginning. ... May be I should look closer at Tims actual implementation! But having a vector in the property system will not introduce OpenGL nor osg dependencies. At least my understanding of this is to use SGVec* for that. osg and OpenGL should not show up in the property system. But a generic vector can show up Actually, I am using osg::Vec3d and osg::Vec4d. I tend to view the SGVec types as redundant, but that's a personal preference. I don't mind using SGVec in the property system, but if I do that I would like to add an operator to SGVec* to provide a conversion to its internal OSG type. What strikes me with the property system is the lack of composed datatypes that in some cases need to set in an atomic way. The scalar world of the current property system where we have scalar accessors for the components of a composed datatype, we have several partial updates that will leave the object that is accessed by the property system in an partially updated state until the last update happened. Having compound atomic types like a vector for example solves that problem. Yes! This is exactly what I've been talking about too. Tim, what I am also concerned about is the use of property listeners to work on osg's datastructures. I believe we should not intermix code paths that can happen during the application/update phase with the osg scenegraph structures. Think of the multithreaded viewer we are talking about with Curt. I would prefer to separate these steps in a way that we could also streamline the data flow somehow. With these listeners we change things in the viewer directly from the application step I guess. Yeah, but we do that in the OSG update phase, which is exactly when these updates are supposed to happen. Nothing that alters the scene graph can run during the cull and draw phases, but we have to be able to alter the scene graph at some point. I believe that we better think of such a simulation as a pipeline that starts with the users inputs (joystick and such) the data is put into the simulation (FDM, instrument simulations, etc ...) the data is then put into the viewer's scengraph, which itself is used to render things that appear on the screen. Separating these steps with clear points in this pipeline where data is moved from one stage to the next would provide the ability to do these steps mostly in parallel (even more, we could do independent simulation entities in parallel). But fiddling with listeners here can make the first pipeline steps modify the data of the last pipeline step - which adds the need for either locks or if we do not lock, we stick even tighter to an application step that cannot run in parallel to the viewer stages. The point is well taken, but the property listeners would be on properties that are directly tied to the effect structures and are not in the main property tree. For the foreseeable future they will be set from C++ material animation code, but I don't see a real problem in setting them from nasal code. It's true that accessing the scene graph safely from multiple threads is going to be an interesting challenge... Tim -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Curtis Olson wrote: Hi Tim, I have one concern that I may not have voiced clearly before. I tend to think about these design choices in terms of what is often called orthogonality. The idea stems from the world of vectors. ... So if you translate that concept over to computer languages, or computer API's, I believe strongly that these things also work best when they are orthogonal. In other words, we want a minimal set of independent components we can use to specify or accomplish what we want. This makes for clear and understandable and maintainable code. ... So as you speak of adding Vec3 and Vec4 types to the property system, I immediately have orthogonality concerns. We seems to be adding a specialized core type that is only good for one purpose along with the specialize code to handle just that particular type, and we are moving against the concept of orthogonality (which I feel is highly important when designing api's, computer languages, vector spaces, etc.) You've talked before about wanting to support general array data in properties; that is not a big step from what I've done with Vec3D and Vec4D. If I support that and don't have Vec3D and Vec4D I would need to do some extra work to hook those values up to their OSG counterparts, but nothing major. However, this is admittedly a distraction from getting effects and shadows working, and I would rather start with the vector types and arrays later. Some will suggest that all this surgery on the property system is the distraction, and the point is well taken. This might come as a very late suggestion, but would it be able to derive a new class using SGPropertyNode as the base (maybe call it SGPropertyNodeExt) and then add your new types to the derived class? I supose then you wouldn't be able to use the same xml reader/writer code. I've noodled around with this a couple of months. The xml I/O is a major block, but the more general refactoring job seems like a huge waste of time if the option of restricting the use of extended features via the reader is acceptable. I'm very conflicted on this one. It is messy. So far I haven't seen a slam dunk argument either way. We are trying to balance convenience and ease of use against well conceived design. Typically we try to build more complex structures out of simpler base structures. But this is a case where the interdependencies of our property system, xml reader/writer code, and opengl/osg seem to force a cascading sequence where one change implies another which implies another and we are right back to specific vec3 and vec4 types and it's really hard to create an optimized and convenient system that is more generalized and maintains pure principles of orthogonality. I mostly agree with this, though I continue to maintain that the new types are fully in the spirit of the property system, moreso than array types would be. I'd also suggest that no one here knows the right answer to this question, making the option of playing with the new features in a playground off to the side attractive. Tim -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Tim Moore wrote: I mostly agree with this, though I continue to maintain that the new types are fully in the spirit of the property system, moreso than array types would be. I'd also suggest that no one here knows the right answer to this question, making the option of playing with the new features in a playground off to the side attractive. After reading the proposal I'm starting to get comfortable with it; add the support code but don't use it anywhere but in configuration file parsing code (where the properties don't end up in the main property tree). Such a case seems perfectly acceptable to me and seems to solve most (if not all) arguments I've seen against including it. Erik -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
On 12 Jun 2009, at 17:39, Tim Moore wrote: So, I propose to add an argument to readProperties that controls whether or not the new property types are recognized. By default they are not, so only code that explicitly calls for them will be able to use them. Seems entirely reasonable to me. James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
On Friday 12 Jun 2009, Tim Moore wrote: [snip...] ... I simply don't want to write files that use the more verbose alternative... [snip...] I must commend your honesty. LeeE -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, I have one concern that I may not have voiced clearly before. I tend to think about these design choices in terms of what is often called orthogonality. The idea stems from the world of vectors. The idea of orthogonality is if you want to represent any point in 3d space, you can do it by some combination of x, y, z components. The x, y, and z axes are arranged orthogonal or at right angles to each other. Each axis is completely independent from the other axes. You could imagine some other space where the axis go in odd skewed directions that aren't at right angles to each other, and you could still represent point locations, but the numbers would be odd and hard to deal with, hard to add and subtract and manipulate. So an orthogonal (at right angles, or said another way, completely independent) components are an ideal way to represent a point in 3d space. So if you translate that concept over to computer languages, or computer API's, I believe strongly that these things also work best when they are orthogonal. In other words, we want a minimal set of independent components we can use to specify or accomplish what we want. This makes for clear and understandable and maintainable code. Going back to the 3d point example. If we start adding components like a curving axis in some random direction, or points that are only valid on the 2nd tuesday of every month, you wind up with a huge mess of special cases. You lose the ability to perform simple functions (like + or -) on individual components. Basic principles like 0 * x = 0 and 1 * x = x may no longer be true. And if you have points that are only valid on the 2nd tuesday of every month, it probably doesn't make sense to define a special data type for that with mixed interdependent components, instead it makes sense to think about what independent components we can use to build what we want. So as you speak of adding Vec3 and Vec4 types to the property system, I immediately have orthogonality concerns. We seems to be adding a specialized core type that is only good for one purpose along with the specialize code to handle just that particular type, and we are moving against the concept of orthogonality (which I feel is highly important when designing api's, computer languages, vector spaces, etc.) Now, just to show you how fair I am, there is another side to this discussion that is also just as important to consider. Languages and API's often develop idioms and short cuts for things that are heavily used. It makes life more complex in the sense that now you have to learn the idioms that don't necessarily have any obvious literal meaning, but once you learn the short cuts, you have a much more efficient way to do something or express some particular idea. That can be very useful and very practical for things you might do quite often. So as I see it, the debate breaks down to practicality versus orthogonality. Do we permit some idioms to develop for commonly used operations or commonly used structures? That doesn't have to be a bad thing in my view. But orthogonality is a really good thing, so we should strive to maximize orthogonality and minimize idioms (to mix langauge and math terminology in the same sentence.) We need to set a pretty high threshold before allowing new idioms to be added, and especially when adding the first idiom to a purely orthogonal system. Speaking figuratively, what it looks like to me is that we will be adding two more axes to our beloved X, Y, Z (figurative) system. The Tim1 axis and the Tim2 axis ... both point directly to your two specific points in space. That may be ok from a notational stand point, but I can understand the resistance to poluting the well loved and well understood traditional X, Y, Z space just because one person is solving a problem that involves a bunch of points that line up on some other arbitrary axis. This might come as a very late suggestion, but would it be able to derive a new class using SGPropertyNode as the base (maybe call it SGPropertyNodeExt) and then add your new types to the derived class? I supose then you wouldn't be able to use the same xml reader/writer code. I'm very conflicted on this one. It is messy. So far I haven't seen a slam dunk argument either way. We are trying to balance convenience and ease of use against well conceived design. Typically we try to build more complex structures out of simpler base structures. But this is a case where the interdependencies of our property system, xml reader/writer code, and opengl/osg seem to force a cascading sequence where one change implies another which implies another and we are right back to specific vec3 and vec4 types and it's really hard to create an optimized and convenient system that is more generalized and maintains pure principles of orthogonality. I want to support this. I want a nice, flexible, convenient system for defining fancy graphical effects that leverage more and more of the
