Hi, On Fri, 2003-10-17 at 05:34, Dirk Reiners wrote: > Hi, > > On Thu, 2003-10-16 at 01:53, Gerrit Voss wrote: > > > > Well not really, my understanding is that you add a core which holds the > > to be instantiated subgraph root node and puts this node in the child > > list to be traversed. The problem is you will only get the hierarchy > > dependent informations of the original subtree not the local ones with > > the exception of traversal based mechanisms which resolve the path > > problem of multi parents anyway. But as with other problems you can push > > this partially to the application by just stating that there is this > > instantiate core but if you use it be aware of the constraints in terms > > of to world information et al. > > so the idea is that the actual sharing part is really hidden in the > InstanceCore then? Thus for an unsuspecting app the tree would appear to > end at the InstanceCore, just when traversing the tree using the Actions > (whichever version) the shared subtree would be traversed.
One of my main arguments would be, there is no unsuspecting app, either the app explicitly wants this feature and than should be able to deal with it properly or it leaves this feature alone. How we communicate this to the loaders is a still to be looked at question different ;-) I see bigger problems on the contrib side were feature are written app independent ;-). > I'm a little torn about this. In a sense it's consistent, as the tree > that's visible is still single-parented. But it feels like a dirty > trick, and I'm not sure if that's really that useful. It would allow you > to do the multi-parent sharing things, but... > > > For most of the OpenSG traversals this > > should be transparent but we would have to check how exactly the graph > > ops and the new actions react ;-) but most of them should jump over core > > based indexing it might not be that complicated and hopefully does not > > require changes everywhere inside the system. > > Well, as long as the called functions don't call any of the *World* Node > methods things should be fine. For performance reasons I think none of > the RenderAction methods do that, but Intersection might be a problem. > It is a non-obvious restriction for any action callbacks that everybody > needs to be aware of. I really have to have a detailed look at which points which callbacks can occur and how we interface it to this kind of core before I'm really sure it is feasible ;-). One nice thing I see about using a core is that a traversal can either start inside the original tree or above the instantiate core which means from the traversals point of view the multi parent situation never occurs at the starting point, so we probably have the chance to propagate certain information without ambiguity. But this needs some more analysis. For the current actions, the render actions for sure accumulate the matrices by themselves and normally I would expect the intersect action to be happy with local information only, but only during traversal, the result might need a closer look. What I did not look at in detail are graph-ops, especially if you start optimizing your graph I expect that having it shared might impose some restriction too ;-). > > I don't see it necessary to derive from node, reason, see above ;-) > > > > It might be worth a try ;-) > > Yeah, it might work. I still feel I need to wash my hands after writing > this mail, though. ;) I never said I'm really happy with it but it appears to me to be the least invasive way to appease the ever occurring wishes for this kind of feature ;-) gerrit ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
