Re: logging

[Seth Teller <seth@graphics.lcs.mit.edu>]

exciting.  this is very cool.

the info content is high, the tabular format is well-thought-
out and effective.  this really gives a useful snapshot of
the run.  some comments follow.  (other bmg'ers, please follow
up with comments as well.)

perhaps the "whole building" phases -- DL and assembly ? --
should be labeled prominently and arranged in chronological
order (right now you have DL stats after all the pipeline
steps, even though DL happens first, which is confusing).

another idea:  for the "walls" pass, include it as the last
row of the generated table, spanning all N columns.  you can
report run time, file size etc. in the tabular format the
same way the per-floor runs are reported above.

is there a way to visualize all the file sizes as simple 2D
graphics, rather than as numbers?  for example can you
write an html function that produces a filled disk whose
area is proportional to the file size, and place that in
the table (instead of the numbers you have there now)?  you
could make it so that mousing over each disk would bring up
some floating text (e.g. "1.0.iv -- 765434 bytes").  this
would allow one to see any gross discrepancies in file sizes
across a column, at a glance.

another possibility would be bars (as in bar graphs), but
i think these wouldn't work as well with the format you have.

regarding the pipeline stages:  how about using an offline
inventor renderer (invokable in batch mode, produces an .rgb
image which can then be impcopy'ed to jpg etc.) to generate a
thumbnail of the result at each stage?  this would be a nice
visual record of the progress of the data.  and each thumbnail
could be clickable to bring up the corresponding VRML.

of course to do this you'd need to define some sort of
canonical view for each 2D/3D model to be rendered.  for 2D
an ortho view framing the bbox is probably the right thing.
for 3D you might construct an elevated, oblique view looking
(e.g.) at/through the center of the bbox and framing the bbox.

we have good code to do inventor off-line rendering in the
G lab, checked in to one of the source trees.  i'll track it
down.

the failure cases (e.g. dejunk 50.1) are of course of
significant interest, so those table entries should be
linked to a log of the offending command line, any
useful diagnostic info, etc.  (btw, notice the aberrant
file sizes in the column below the 50.1 fail tag -- they
are all too small, of course, but you don't (at least i
didn't) notice this until after seeing the fail tag.)

why are their "n/a"'s for UG sizes for mezzanines (e.g. 54.1M)?
is this because the UG has been incorporated into some main floor
by convention?

at the bottom of the log (and perhaps linked from the very top,
even though it won't exist until the end of each run) it would
be good to have the summary statistics:  how many things of
each type fetched, built, succeeded, failed, how many bytes
etc., how much CPU time used.  in fact perhaps you could issue
this as a one-liner after each completed building, as sort of
a running tally, so viewers can see that e.g.

   17 of 81 buildings (348 of 802 floorplans, X bytes) processed so far

again, michael, very nice work.  looking forward to seeing
this grow even more comprehensive.

prof. t.

Michael Craig wrote:
> here's a link to the latest logging output:
> 
> http://city.lcs.mit.edu/bmg/log/
> 
> it's running on glint right now, and the updates are flushed after every
> building is done. the vrml files aren't online right now--i still need to
> get certs. working right-- but the stats are there. it's still somewhat
> rudimentary i'd say, but all the info should be on the page.
> 
> 
> michael
> 
>