Norman Vine <[EMAIL PROTECTED]> said: > Well that is 'allmost' correct in that perhaps one won't get a view :-) > but ... the proposed code will still go through all of the gyrations > of having one ie the global_tile_mgr.update() > will still be called twice unless all you have is a 'fixed view' > ie if there is a acmodel_location then the second pass through > the scenery tiles is made otherwise just the tower tiles are updated. > > This seems backwards to me. for a fixed location all the tiles can > be loaded once when the location is set and there should never be a > need to call the tilemanager.update() EVER AGAIN for this location > as things are 'static' ie we aren't moving ! yet this is the case that is > ALWAYS called in the proposed 'cleanup' !
When the viewer calls the tilemanager.update(), then it can be limited to doing so only if the longitiude and latitude changes. In fact I think that we may be able to avoid calling the tilemanager.update() for every iteration even if it is non-static by ignoring very small changes in location. When the view is at the same location as the acmodel/fdm then it wouldn't repeat the work. Once is enough. Towers are more or less static yes, but they can be moved, so we'll have to allow for that. Basically if we don't keep querying the tilemanager when the location hasn't change in tower views, then the only query will be for the FDM. This means that 99.9999% of the time there will be no more than one tilemgr::update() call. You are right though that there is a problem to be solved here and in some ways going with multiple scenegraphs could help. But I'm not sure. The reason for my concern is that we should I think plan for the possibility of having more than one fdm/acmodel. In other words "multiple non-static locations". Currently the code easily allows for multiple static locations as well. There is no reason that you can't define towers in two, three, or more locations using the xml properties. > Again having several scenery roots one for each dynamic and > one for each static location will allow rendering of the desired > scenery and a 'substantial' shortcut for the static case where the > global_tile_manager is turned into a collection of Sceneries which > and just the 'requested' ones are rendered. notice this is plural > for there is no reason other then that the FGView doesn't use > the ssgContext concept that FGFS doesn't support subviews > ie a 'tower' or 'chase' view subwindow insert. So, do we have an ssgRoot for all of the possible views (multiple static, multiple non-static) that someone could configure? What kinds of problems would we run into doing this? What about all the models, ground/runway lights and such that are added to the scene graph for each tile entry? My apologies for sounding dense here. I'm just trying to understand the concept. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
