Hi,
On Fri, 2006-08-18 at 16:13 +0200, Marcus Lindblom wrote:
> Gerrit Voss wrote:
> > Hi,
> >
> > On Thu, 2006-08-17 at 14:33 +0200, Marcus Lindblom wrote:
>
> >> The problem with all systems is that you need to handle ordering of
> >> update dependencies somehow. I.e. first update transforms from time &
> >> data, then compute skinning and/or setup shader constants. Adding
> >> normalization/tangent space and other derived data to this makes it even
> >> trickier. Usually, we solve such things by create a directed graph from
> >> each objects dependency and sorting that to get an update order (this is
> >> only done when the ordering is dirty.)
> >
> > just my 0.02$. As OpenSG keeps track of what changed a light, observer
> > based approach might be not so uninteresting.
>
> Yup. As long as one could trigger when those observers are being
> notified of all changes since last time, it would perhaps work.
that would be the basic idea (in the 2.x context), though you might
loose triggers if the same field is changed more than once between
the points where we have a chance to call the observer. I'm not
sure right know how much problems this behaviour might cause.
> Having it done automatically would probably lead to severe performance
> problems. (I've heard some stories on that being tried way back with
> disastrous effects. Of course, we might afford that now.)
> Observers is a good patterns for small things, I've never seen them work
> out well when things go complex. (but someone else might have managed to
> solve that?)
counting callbacks and bouncing up the inheritance hierarchy (kind of
self observer) as the most simple form and changelist based triggers as
another simplified option than at least our internal vrml like engine
runs on observer 'based' patterns for all its dynamic data movement. And
this part (excluding the triggered computations) never showed up
anywhere near the top of the timing sheets. And IIRC other people doing
similar things never reported problems along these lines.
> However, one must be vary of cycles in the dependency graph anyway and
> having the graph explicit makes it easier to detect, and given the
> complexity you can run into I think it makes sense to try to be a bit
> more intelligent in managing this.
my approach would be to keep it as simple as possible inside the core
parts of OpenSG (aka boost::function based changed callback) and allow
the next level, which usually are some kind of core vr system libs,
to control how much intelligence is needed. Which does not mean that
nothing of that sort should be inside OpenSG but my feeling would be
to have it on a contrib level, so a user can use it or build his own version.
regards,
gerrit
PS: For the big future discussion I'm still sorting things
inside my head, so there will be an answer ;-)
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
