IM chat 2003.03.18

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  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.