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
