rogerjames99: Did you get the new "wodge" I sent you... I still have some probs with the lighting on roofs I could do with help on.
bdiscoe: yes i got it. it's next in the queue.
tasks keep popping up to get in the way. like today, i suddenly have to figure
out what the heck http://www.landxml.org/ is
rogerjames99: That's good... how are you on my suggestions about a layer "type".
bdiscoe: i'm not sold yet on the necessity for a layer type but when i look at your code and ponder the cases, i might have to agree
rogerjames99: It makes implementing a "basement layer" very easy. I have done that and now have buildings that sit in the terrain neatly.
bdiscoe: can't we just make a 'plinth' level which pushes the building up, without having to tag it as a specific 'type' of level?
rogerjames99: I think you have made my case. By naming
a "plinth" level you are effectively saying that you have a different algorithm
for the level which takes the parameters and generates the geometry in a
slightly different way. I am just arguing a bit further a saying that the level
type should "name" a piece of "design" that encompasses both the algorithm and
its parameters. Very much like the asn.1 "any defined by" type.
Oops sorry about the typos.
bdiscoe: ur, no... a 'plinth' level can be described perfectly well with the
given parameter set of the level. unless there's something i'm missing.
there's nothing about calling a level a 'plinth level' that would influence how
it is constructed, beyond that of the level parameters
rogerjames99: Sorry, I thought you meant the height of the level would be generated by the algorithm according to the terrain where an instance was placed.
bdiscoe: if the user wants the height to be generated from the slope etc.,
that would be design-time algorithmic option, e.g. in VTBuilder, without
saddling the representation with another parameter
e.g. design time, not storage or construction time
A VTBuilder "Add Plinth" command would contain all the smarts (and be able to
ask the user for details) rather than putting that logic into the geometry
construction code.
Now, a case where we might need an additional param would be if the construction
code needs it.
rogerjames99: Aha... I see that is where our difference lies.. I can see your point about making it (terrain) design time. My counter argument is that that ties together a building description with a terrain.
bdiscoe: E.g. if it can't tell what kind of roof to make without a hint, e.g.
"Felkel roof", then such a hint would be unavoidable.
However, i think that it can look at the current representation and determine
what kind of roof to make.
My reason for wanting to keep the representation as simple as possible is
multifold, but an important reason is adoption. The simpler a representation is,
the easier is it for other people (i.e. non-VTP) to adopt it or to convert
to/from)
E.g. the don't have to decide whether to label their basements and foundations
as 'plinths' or not when they write VTST. They just spit out a set of levels
which physically describe their building.
rogerjames99: I keep coming back to real world stuff.
Lots of builders have "standard" plans for houses. But when they build one they
make a real world plan. They know that when they look at the generic plan they
will have to fit it into the local site terrain. So in a way there is a hidden
"piece if design" that says this is so.
A good generic plan is one that has all the information "design algorithms" in
it that enable it to be used in the real world.
bdiscoe: Agreed, a good building plan is one that includes construction information. My view is that this kind of algorithm would complicate the storage format too much, so it belongs in the code above the representation level.
rogerjames99: Yep .. it just where you draw the line.
:-) I get hold of good generic plan for a house. It has note next the the
footings saying "you will have to dig footings to different depths to achieve a
consistent level for the building". This is algorithmic information stored on
the plan. So maybe,,, we need to look at how our "representation" of the storage
of the plan can achieve this.
.. I see I have brow beaten you into submission.. sorry :-)
bdiscoe: oh, yes. that's a good question. Physically, there is a need to
relate the base level to the terrain in an objective way.
I'm not sure of a good way to do that. numerically, it could be expressed as a
single (meter) value: offset between the lowest level and the terrain
but it's complicated, because: which point on the terrain is it relative to?
rogerjames99: I see that as just one of many potential
algorithmic pieces of design that need to be captured.
Express it as an algorithm rather than a parameter.
bdiscoe: I see it as just another <float> element needed for physical
description
If the representation contains a "algorithm type", then whoever reads the file
has to implement that algorithm. that's a big barrier to adoption.
It's better to encode just what is needed to physically, literally represent the
object
preferably in terms of meters, degrees, etc.