bdiscoe: what's up?
rogerjames99: I just been talking to the planning department at Kendal. I had built them a quick model of the town as you know. They have come back with some requests. It is all in areas we have discussed before. I just wanted to bounce them off you, see what you think.
rogerjames99: They want to use vtp in community communication projects around new developments. On major area will be visual impact. They want me to convince them that we can find a way of getting reasonably accurate eave and roof heights in the model if they give us the data. To me this means tying the zero point in the current footprint to a known survey height and position. The will apply to structure instances as well.
rogerjames99: Sri "this" will apply. It looks like the new gml format can handle this?
bdiscoe: sounds good, sounds doable
bdiscoe: yes we can add a field for absolute elevation of ground floor
bdiscoe: it's not a commonly known value, but if they've got it, then great
rogerjames99: Does that lead to vertical datum issues. Do we need a composite co-ord system specified?
bdiscoe: i don't expect vertical datum issues. what matters is that the elevation grid and the building absolute elevations are in synch. if both data come from the same source, then this is not a problem.
rogerjames99: Good enough. I thought that would be the answer. The vertical datum is implied to be the same, so it is a documentation issue. Ok that leads us back to plinths!
rogerjames99: I now agree that this all an import time issue. It was just my pig headedness that would not allow knowledge of the elevation grid to be available at import time. My feeling is that if you want to place the buildings on a different grid (maybe only diff projection) then you re-import or convert. OK?
bdiscoe: yes, placement of the building is done at scenery construction time
bdiscoe: very little is left to do at runtime
bdiscoe: so, plinths are like any other level
bdiscoe: they begin at the building's stated elevation, and go up
rogerjames99: Sri... exactly what do you mean by scenery construction time. Is that in vtBuilder?
bdiscoe: that elevation can either be derived from the heightfield at runtime (lowest point on footprint, as currently done)
bdiscoe: or absolute (with the field we can add)
bdiscoe: Yeah, scenery construction is VTBuilder (or any other tool or app anyone wants to write that works with VTST files...)
rogerjames99: Close, but I think they go down if we have an absolute height. Because that will most likely be a real ground level surface point we are just adding the plinth to look pretty. Maybe terminology should ground elevation datum or something like?
rogerjames99: what about "local ground level"
bdiscoe: i think of it as the "base elevation" of a building
rogerjames99: Suits me!
bdiscoe: "level" would confuse with the "levels" of the building
rogerjames99: No maybe I was too quick on that. My Kendal guys are surveyors architects, planners, etc. To them its ground level!
bdiscoe: well, the foundation can actually go underground, so it's "below" ground level
bdiscoe: just a sec, on the phone
rogerjames99: What about "Vertical Datum" i.e. the base of the local co-ordinate system elevation expressed in global co-ordinates?
rogerjames99: I guess it doesn't matter, as it should be hidden behind an explanatory UI.
rogerjames99: On the plinths I suggest . 1. if we don't have a local vertical then build a single story plinth downwards from the highest intersection point of the ground with the 3D projection of the footprint as far as the lowest ipofgwt3potf..
rogerjames99: If we do have a datum the build down from it to the lowest ipotgwt3potf...
rogerjames99: Some other points. How about selectable templates to use as defaults for building import. Should work as just an ordinary structure file and use the first building/instance/linear .etc as the relevant template.
bdiscoe: sorry still on phone....
rogerjames99: To communicate effectively I definitely need facades. e.g. a simple per edge texture. I have already implemented this!
rogerjames99: ok I will carry on dumping thoughts!
rogerjames99: One other thing they noticed was a radical slow down in the nav speed as more textures were added, but only when spinning on a point! This needs looking into.
rogerjames99: I need to bottom out the problem of the lighting effects on the roof. The normal code looks OK to me!
rogerjames99: Selectable default building materials palettes would be neat.
rogerjames99: The really big one I will have to add is the light occlusion stuff. Need to get sun paths etc. My idea is to be able to define windows that one can look out of and watch the sun path. also calculate the percentage light occlusion over time. etc.. sound fun!
rogerjames99: Thought I would plug in my webcam
bdiscoe: whew! off the phone
bdiscoe: webcam, cool!
rogerjames99: back again
bdiscoe: ok, what's a ipofgwt3potf?
rogerjames99: "intersection point of the ground with the 3D projection of the footprint" ...I just could not be bothered
bdiscoe: re: plinths, yes, that's the current default behavior in VTB: from highest intersection point of the ground to the lowest point on the footprint.
bdiscoe: re: building templates. Sure, it would not be difficult. I would wait until we have a real data source that could make use of the feature.
rogerjames99: a cannot remember do you check at the vertices of along all the lines?
bdiscoe: re: facades. It's certainly not difficult to implement, but we'd have to think of a way to add it to the data model without making it murky and complicated.
bdiscoe: re: check, only at the vertices of the footprint
rogerjames99: I just added an optional to the edge in the xml.
bdiscoe: Hmmm. But if the edge has it as e.g. an XML attribute, then that overrides all the EdgeElements....
bdiscoe: as well as the Material and Color attributes, although those are good to have as a LOD fallback for e.g. when you don't need to draw the facade at a distance
rogerjames99: Thought so ... I was thinking it would be cool to knock up a algorithm to check all around the projection of the 2d polygon into a cylinder... It must be element then.. its the individual edge. The LOD thing probably explains some of the performance hit. But only on turning
bdiscoe: re: default building materials palettes, what do you mean?
bdiscoe: some kind of VTB feature?
rogerjames99: Yep but also in Enviro to save mem. Just the ability to have a different set of materials. e.g. lakleland slate, accrington brick, etc.
bdiscoe: ?? these are things that can be described in the existing framework, or no?
bdiscoe: perhaps they are higher-level, like templates, e.g. "apply this set of materials to this whole structure"
rogerjames99: yes we could just make a bigger list of materials, but at some time it may make sense to have different default sets to avoid running out of texture mem.
bdiscoe: well, the only texture memory used it for what's on-screen, so that's not so big a problem.
bdiscoe: (with modern graphics cards)
rogerjames99: I was not thinking that complex. e.g. for the Kendal model 90% of the buildings are local sandstone with slate roofs. I should of said memory for textures.. but I suppose with most PCs it not a problem either?
bdiscoe: yup, shouldn't be a problem
rogerjames99: So If I send you a whole set of new textures. You know how good I am at making textures.......not!
bdiscoe: go ahead and send anything you might have, i can clean it up etc.
bdiscoe: if you take some nice clean orthogonal pictures of walls, that would be fine even
rogerjames99: Sounds good!!
rogerjames99: I better go now.. I will try and hack up some of the things we discussed and send you the results. As soon as I get v2.0 of Felkel going
bdiscoe: feel free to submit as often as you like so we avoid big merges
bdiscoe: i'll be looking at the OGR option