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.
bdiscoe: yes
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!
bdiscoe: yes?
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: heh!
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: ok
rogerjames99: Bye....
bdiscoe: feel free to submit as often as you like so we avoid big merges
rogerjames99: OK
bdiscoe: i'll be looking at the OGR option