Hi, On Sat, 2009-08-01 at 22:10 -0500, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Sat, 2009-08-01 at 10:27 -0500, Carsten Neumann wrote:
> > What I was getting at, maybe not in the clearest form, is to have the > > same basis for things and going from there. And to separate things > > which I see as not necessarily belonging together. > > that is a goal that is way to reasonable not to agree to ;) ;) ;) > > Concrete, I would like to agree on a way to handle frame functions and > > (global / wall) time. > > is a frame function just something that gets called every frame or is > there more to it? no it would be something like the CSM frame function. I basically would update the wall time and call registered tasks. Why I want to keep the time in there is because it comes handy if you want to make movies (the ones the boss zone likes to have for their ppts ;)), so you can move it at a fixed rate per frame, independent from the real time and without changing anything else. > One direction I would like to stay away from is > providing an actual application frame work, because you can normally > only have one of these (so using OpenSG with VRJuggler would become harder). fully agree, that is one reason why a lot that is in CSM did not make it into core OpenSG, because I wasn't to sure how to avoid these tie-ins ;) At the cost of things being kind of hidden and not easy to find ;) > What would be fine is if there is one function the app has to call per > frame and from there all the rest is triggered, pretty much like we now > have Window::render. agree. > > Similar, I would like to have one set of interpolators. If you need > > them in a different form, no problem to split the current one or find a > > way to extend them by adding simple adaptor classes that only contain > > the cursor into the data along the lines of your design. I could > > even live with two sets if the use the same mechanisms to get there > > inputs and provide their outputs so they tie in with the rest of the > > system. > > ok, makes sense, I need to look a bit more at the things in the CSM to > get a better idea how to unify this. I is basically just vrml. They get the fraction input via connectors from the time sensor and push their results via connectors to the target. Similar bool/trigger events (enable, reset) come in via connectors from for example key sensors. > > And I would like to have the data flow modeling split from it's usage, > > e.g. like it is right now with field connectors not being tied to > > anything particular. But they are currently tied into the changed > > handling so it might be worth thinking of something else. > > hm, sorry I have a bit of trouble following you here (you are saying you > want things separated and the connectors are an example for that, but > then you say they are tied to the changed callback ;) ). yes, but this is so low-level that it is fine in principal. The main problem with being dependent on the changed logic, is that predicting order can be difficult as it depends on how things are recorded in the change list, which through buffering might not be the order one expects. And how do deal with the fact that on creation everything is marked changed, so all connectors will fire during the first frame which can give you some headache it tracking down why one value is not what you expect it to be. > Can you say a bit more about how you want the data flow done (or if its > easier how you > don't want it)? Ideally and if possible I don't want to have the code of the data source contain knowledge where the data is going to and how it gets there. So the connection information and the transport logic should be external or in a very basic base class like FieldContainer. As we only record the beginning of the edit it is a more difficult in 2.x that in 1.x where we had an explicit endEdit. > >> For that case you need to accumulate all input for one bone in > >> some way, either by keeping track if this is the first change to a bone > >> in this frame and making it absolute and all subsequent ones relative or > >> accumulating all changes into a temporary and then set it once all > >> animations are applied. > > > > ok, basically you need something to mix n input streams into one output > > stream. Hmm, ideally I would like to find a general form for this and > > not necessarily tie it to any of the animation classes. > > maybe an N to 1 field connector, that passes on values after all N > sources have fired ? yes, what I'm not sure is should all N be necessary. It is basically an ordering and optimization problem. When do we know we should update the output so we can ensure this happens the minimal amount of times (ideally once per frame). > >> agreed on the dependency. Why does the frame handler need to be > >> extensible (perhaps it must be, I just don't understand the reason yet)? > > > > sorry that was not to clear, it was the other way around, the file > > handler was the extensible thing. > > oh, ok. > > > In VRML we can handle the animation > > nodes not in the main fileIO lib part but in a contrib lib. So currently > > the TimeSensor is aware that it is inside CSM and can directly access > > parts of it. > > how about taking the lazy way here and just create an animation lib and > have file io depend on that? in principal yes and that was the long term plan. As said above I just was not to sure how to avoid unnecessary tie-ins into an application model. kind regards, gerrit ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
