alias handling

[Peter_Apian-Bennewi1]

Hi Greg,
(quote of first message added, I'll post this to the dev list)

     there wouldn't be a chance to change the handling of alias in
     3.5 ?
     Like adding 'alias' as a primitive, so rview etc. can display
     the
     material name as it was before aliasing ?
     It means changing stuff at some places, but would help quite a
     bit
     during material editing or selection.

Greg Ward wrote:

Are you sure this is the behavior most people would want? Personally,
I'd rather know (in rview) what material was actually being used,
rather than the pre-alias name. I typically use aliases to reassign
materials, using something generic like "wall_material" on my surfaces,
then aliasing this to something more descriptive, like "beige870".
Having rview tell me that my wall is made of "wall_material" is not
terribly useful.
Can you explain your problem with the current behavior a little better?

It's as you said, may be a bit more ugly in my case:
Most CAD systems have some internal names for materials, which show up in
the exported geometry files. These names are not necessarily user
definable, or if they are, the user has chosen different names (wall_mat1,
wall_mat2, ....) which will get mapped to the same Radiance material. Both
is true in my case. I would imagine the second could be easily true for
AutoCAD. Other CAD exporters may be even weirder in their choice of
material names.
As you said, material names used in the exported geometry have to be
mapped to descriptive names of Radiance materials, which are typically
stored in some sort of library, and this mapping could be a list of dozen
materials for one scene. Alias definitions glue the two together, with
multiple CAD material names mapped to the same Radiance materials.
Currently, alias defines are lost in frozen octrees. One way to get them
is by adding an "OBJECT oalias;" to the OBJREC structure, which is a waste
of memory and breaks with frozen octrees. Reading the alias file
explicitly doesn't ensure that the alias file and the octree are
congruent, and would work only with rshow.
It'll be useful to have access to both the original name and the aliased
material: The orginal name may be out of reach at that moment, but the
mapping is. To change that I'd need the original name displayed in
rview/rtrace/rshow.
any other experiences and views on this matter much appreciated-

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

[Georg_Mischler]

Peter Apian-Bennewitz wrote:

there wouldn't be a chance to change the handling of alias in 3.5 ?
Like adding 'alias' as a primitive, so rview etc. can display the
material name as it was before aliasing ?
It means changing stuff at some places, but would help quite a bit
during material editing or selection.

Somehow I suspect that what you really want is to use
descriptive IDs for the geometry primitive. If I understand your
problem correctly, then you seem to have troubles in certain cases
to identify where an offending primitive actually came from.
That's exactly the purpose of the object ID.

A CAD translator should include as mush useful information in
that ID as possible, as well as making it as unique as possible.
I haven't seen all of your argumentation, but I don't think
that it's a good idea to "reverse engineer" this information
later within Radiance, especially if that sould involve changing
the behaviour of modifiers and aliases even in subtle ways.

The problems you have with rshow rather seem to be related to
the fact that you are using the octree when *modifiyng* the
scene. I can see some of the reasons for that, but I don't
think that's what the octree was designed for, so it may or
may not be a good idea in the long run. Especially frozen
octrees don't look like something that should be "edited".

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Jack_de_Valpine]

Hi Peter, Georg and Greg,

I'll add in my two bits here from a user perspective. As Peter has pointed out and depending on the export tools used the material name that is applied to the exported geometry description may not make a lot of sense from the standpoint of defining/assigning useful materials. Thus alias's are a very handy way to map between useful/identifiable radiance material definitions and the (equally useful) exported geometry. For example (using radout):

in file: abc_c101.rad

abc_c101 polygon abc_c101.0.1
0
12 168.09402 259.4408 86
    168.09402 259.4408 82.416666
    169.92021 268.62171 82.416666
    169.92021 268.62171 86

This geometry is exported with a basename of 'abc' that tells us what building or model the geometry is associated with while c101 tells us the uniquely assigned color associated with the autocad layer that the particular geometry resides on (why export by autocad color vs. layer name is another discussion if anyone wants to get into it).

To assign a material to this geometry we would 'map' via alias a predefined material residing or defined in a higher level library:

in file: mats.generic.lib

void plastic foo.white
0
5 1 1 1 0 0

and then in a separate file that 'maps' the materials from the library for the geometry relating to 'abc' we would see:

in file: mats.abc.rad

void alias abc_c101 foo.white

So from the standpoint of identifying the geometry in a useful manner (via a trace in rview for example), this is a sufficient identifier. But it is not so useful if I am trying to query the material assigned the geometry, since I have to work backward from the file that 'maps' the materials to the actual material name (not that this is that painful of a task).

Now, since the can of worms is open, the problem with using aliases in this way is the use of compound or modified materials. Say in mats.lib we had a brightfunc defined called foo.bf , in order to apply that modifier it needs to occur in mats.abc.rad:

foo.bf alias abc_c101 foo.white

I understand why this is the case, but it would be really nice to able to have fully defined compound material definitions that can just be applied in the fourth position of the alias. So instead, I could do the following:

in mats.generic.lib

void brightfunc foo.bf
2 .5 .
0

foo.bf plastic foo.white
0
5 1 1 1 0 0

in mats.abc.rad

void alias abc_c101 foo.white

where now abc_c101 'inherits' both modifier and material characteristics.

Why???

    * easier management of complex material definitions
    * easier assignment of complex material definitions
    * user does not need to know as much to utilize complex materials,
      i.e. they do not have to understand how modifiers and materials
      relate to each other in order to assign/map/alias a valid
      predefined material to their geometry

I know that there a lot of strategies for how this could be handled in other ways, such as intermediate scripts/interfaces for assigning materials that could equally well mask this from the user. Again, merely my observations on the subject.

Regards,

-Jack

Georg Mischler wrote:

···

Peter Apian-Bennewitz wrote:

there wouldn't be a chance to change the handling of alias in 3.5 ?
Like adding 'alias' as a primitive, so rview etc. can display the
material name as it was before aliasing ?
It means changing stuff at some places, but would help quite a bit
during material editing or selection.
   
Somehow I suspect that what you really want is to use
descriptive IDs for the geometry primitive. If I understand your
problem correctly, then you seem to have troubles in certain cases
to identify where an offending primitive actually came from.
That's exactly the purpose of the object ID.

A CAD translator should include as mush useful information in
that ID as possible, as well as making it as unique as possible.
I haven't seen all of your argumentation, but I don't think
that it's a good idea to "reverse engineer" this information
later within Radiance, especially if that sould involve changing
the behaviour of modifiers and aliases even in subtle ways.

The problems you have with rshow rather seem to be related to
the fact that you are using the octree when *modifiyng* the
scene. I can see some of the reasons for that, but I don't
think that's what the octree was designed for, so it may or
may not be a good idea in the long run. Especially frozen
octrees don't look like something that should be "edited".

-schorsch

[Peter_Apian-Bennewi1]

Georg Mischler wrote:

Peter Apian-Bennewitz wrote:

> there wouldn't be a chance to change the handling of alias in 3.5 ?
> Like adding 'alias' as a primitive, so rview etc. can display the
> material name as it was before aliasing ?
> It means changing stuff at some places, but would help quite a bit
> during material editing or selection.

Somehow I suspect that what you really want is to use
descriptive IDs for the geometry primitive. If I understand your
problem correctly, then you seem to have troubles in certain cases
to identify where an offending primitive actually came from.
That's exactly the purpose of the object ID.

A CAD translator should include as mush useful information in
that ID as possible, as well as making it as unique as possible.

I'm stuck with what I get exported from the CAD, at least in this
scenario. There's no way of accessing any more internal CAD data.

I haven't seen all of your argumentation, but I don't think
that it's a good idea to "reverse engineer" this information
later within Radiance, especially if that sould involve changing
the behaviour of modifiers and aliases even in subtle ways.

Alias are treated quite asymmetric in Radiance, as they are "primitives"
syntactically, but filtered out directly at the time the rad file is read.
Treating them as primitives and thus preserving the information they
contain wouldn't break anything. To the user they would be absolutely
identical. Internally the price is following one additional object lookup,
which would be neglectable, as far as I guess.

The problems you have with rshow rather seem to be related to
the fact that you are using the octree when *modifiyng* the
scene. I can see some of the reasons for that, but I don't
think that's what the octree was designed for, so it may or
may not be a good idea in the long run. Especially frozen
octrees don't look like something that should be "edited".

The alias information is generally lost, but it would be useful. E.g. it
might be handy to get it via rtrace too.
True- whether a scene tool should read octrees or its own scheme of rad
(or other) files is open to taste and preference, but maybe it's a
different subject. I always feel comfortable when checking and analyzing
what's ultimately read by the renderer.
My plea here is, in the octree, not to throw away bits of information
which are useful and cheap in terms of size&speed.

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

[Greg_Ward1]

Peter A-B writes:

Alias are treated quite asymmetric in Radiance, as they are "primitives"
syntactically, but filtered out directly at the time the rad file is read.
Treating them as primitives and thus preserving the information they
contain wouldn't break anything. To the user they would be absolutely
identical. Internally the price is following one additional object lookup,
which would be neglectable, as far as I guess.

Actually, an "alias" primitive does not fit with the syntax of standard primitives at all, in that it doesn't have a variable list of arguments. It has just one argument, which is the alias target.

I checked the code, and it seems I was confused about the current behavior -- rview actually does record and report the ID of the alias, rather than the alias target. So, in my previous e-mail, rview would in fact tell me that my wall was made of "wall_material," rather than "beige870." Isn't this what you're requesting? I'm more confused than ever. The only thing that's really lost when the scene is loaded, is the fact that we had an alias, rather than a modifier that happened to have the same type and arguments as the target. Is this somehow a problem for you?

In checking the code, I noticed that there's a bug in the way aliased objects are freed the same as other objects. Since I just copy the OBJREC oargs struct without duplicating allocated memory, the oargs memory gets freed twice or more in freeobjects(), a real no-no with most malloc implementations. Once we figure out what we want to do with aliases (if anything), I'll be sure to fix this as well.

Jack de Valpine writes:

Now, since the can of worms is open, the problem with using aliases in this way is the use of compound or modified materials. Say in mats.lib we had a brightfunc defined called foo.bf , in order to apply that modifier it needs to occur in mats.abc.rad:

foo.bf alias abc_c101 foo.white

I understand why this is the case, but it would be really nice to able to have fully defined compound material definitions that can just be applied in the fourth position of the alias. So instead, I could do the following:

in mats.generic.lib

void brightfunc foo.bf
2 .5 .
0

foo.bf plastic foo.white
0
5 1 1 1 0 0

in mats.abc.rad

void alias abc_c101 foo.white

where now abc_c101 'inherits' both modifier and material characteristics.

I like this suggestion. However, I don't think using "void" to indicate that the alias should use the same modifiers as the original is a good idea, as one might want to break the modifier chain in creating an alias, and this is a valid use of "void" in the current implementation. However, we could introduce, for this one purpose, a modifier keyword to associate with the alias pseudotype -- let's call it "linked". Then, your example above becomes:

   linked alias abc_c101 foo.white

The "linked" modifier gets replaced with the "foo.bf" modifier from the "foo.white" target. The only problem for backward compatibility would be the unlikely case where someone had chosen "linked" as their modifier in some scene file somewhere. I think we can live with that possibility, or we could come up with an even more obscure but still sensible keyword. (Suggestions? -- "full" was the other keyword that occurred to me.)

-Greg

[Jack_de_Valpine]

Hi Greg and Peter,

Looking back at the earlier messages on the topic, I may be confused myself. Anyhow, check out the following:

void plastic white
0
5 1 1 1 0 0

void alias box.mat white

!genbox box.mat box 1 1 1

If we trace the top of the box in rview, we get the material "box.mat" and the geometry "box.6457", we do not get that the material "box.mat" is really the material "white".

Hope this helps.

-Jack

Greg Ward wrote:

···

I checked the code, and it seems I was confused about the current behavior -- rview actually does record and report the ID of the alias, rather than the alias target. So, in my previous e-mail, rview would in fact tell me that my wall was made of "wall_material," rather than "beige870." Isn't this what you're requesting? I'm more confused than ever. The only thing that's really lost when the scene is loaded, is the fact that we had an alias, rather than a modifier that happened to have the same type and arguments as the target. Is this somehow a problem for you?

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

[Georg_Mischler]

Jack de Valpine wrote:

Hi Greg and Peter,

Looking back at the earlier messages on the topic, I may be confused
myself. Anyhow, check out the following:

void plastic white
0
0
5 1 1 1 0 0

void alias box.mat white

!genbox box.mat box 1 1 1

If we trace the top of the box in rview, we get the material "box.mat"
and the geometry "box.6457", we do not get that the material "box.mat"
is really the material "white".

I must admit that I'm still not completely certain about what the
actual proposal really is. We just jumped into the middle of an
ongoing discussion here. Peter, could you give a short and
complete outline for everybody?

What I seem to understand so far, is a wish that more information
about the modifier tree is preserved when compiling/loading an
octree, so that for the above example, the user could learn that
the box with the modifier "box.mat" actually makes reference to
the material "white". While this trivial example makes that look
straihtforward, let's look at a real life use of modifiers, as
any Rayfront user might create with a few clicks of the mouse.
The following is a glass surface with 1cm wide horizontal strips
of frosting, where the materials frosted_glass and floatglass are
defined in another file:

void mixfunc l_v1-wpane-m+++x+++stripes
4 l_v1-wpane-m+++f l_v1-wpane-m+++b Pz*0.01 .
0
0

void alias l_v1-wpane-m+++b frosted_glass
void alias l_v1-wpane-m+++f floatglass
void alias l_v1-wpane-m l_v1-wpane-m+++x+++stripes
!xform scene/l_glasswall.rad

Which modifier name exactly do want to see when you run a trace
on this geometry in rview? It's still a fairly simple example,
and you already have a choice of 7 names, two of which are
materials (the most desirable choice). Or would you like to spit
out the whole tree?

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Peter_Apian-Bennewi1]

Greg Ward wrote:

Peter A-B writes:
> Alias are treated quite asymmetric in Radiance, as they are
> "primitives"
> syntactically, but filtered out directly at the time the rad file is
> read.
> Treating them as primitives and thus preserving the information they
> contain wouldn't break anything. To the user they would be absolutely
> identical. Internally the price is following one additional object
> lookup,
> which would be neglectable, as far as I guess.

Actually, an "alias" primitive does not fit with the syntax of standard
primitives at all, in that it doesn't have a variable list of
arguments. It has just one argument, which is the alias target.

Since the syntax decoding of 'alias' is done seperately now, one could
still put the data in the internal standard object structure.

I checked the code, and it seems I was confused about the current
behavior -- rview actually does record and report the ID of the alias,
rather than the alias target. So, in my previous e-mail, rview would
in fact tell me that my wall was made of "wall_material," rather than
"beige870."

Amidst the confusion, Jack, you and me agree on that.

Isn't this what you're requesting? I'm more confused than
ever. The only thing that's really lost when the scene is loaded, is
the fact that we had an alias, rather than a modifier that happened to
have the same type and arguments as the target. Is this somehow a
problem for you?

Well, - my point still holds: There's no way to get both information (alias
and orginal).
Only getting the aliased name doesn't tell what material from a library of
materials was chosen. E.g. this makes debugging difficult.

   linked alias abc_c101 foo.white

The "linked" modifier gets replaced with the "foo.bf" modifier from the
"foo.white" target. The only problem for backward compatibility would
be the unlikely case where someone had chosen "linked" as their
modifier in some scene file somewhere. I think we can live with that
possibility, or we could come up with an even more obscure but still
sensible keyword. (Suggestions? -- "full" was the other keyword that
occurred to me.)

certainly useful, IMHO

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

[Greg_Ward1]

Maybe we should put it to a vote. It seems straightforward, but it's actually a fair bit of coding to promote aliases to first class citizens in the object array. I guess I'd end up sticking the target ID in a string argument and do a lookup each time the object function was evaluated. This would result in some overhead that isn't currently there, both in terms of memory (negligible) and execution speed (more significant -- see the lastmod() call). I might be able to get around the execution overhead using the OBJREC os pointer, but I generally don't use this for tiny bits of memory like object references. Is it worth it to be able to trace the list of modifiers in applications like rshow?

Jack's suggestion can be implemented using the current alias handling as well as an OBJREC structure.

-Greg

[Charles_Ehrlich]

In the interest of backward compatibility, I suggest that whatever modifications to aliases happen with a new entity type, perhaps "alias2".
Consider the way Desktop Radiance uses aliases:
in glass_mat.rad:
void glass gl_01
0 0 3 1 1 1
void glass gl_02
0 0 3 1 1 1
in window.rad
void alias glass_mat gl_01
glass_mat polygon gl_0.1
0 0 12 x y z ...
void alias glass_mat gl_02
glass_mat polygon gl_0.2
0 0 12 x y z ...
void alias glass_mat gl_01
glass_mat polygon gl_03
0 0 12 x y z ...

We do this because the geometry coming from AutoCAD sometimes has the same identifier. It works because the alias primitive always uses the latest definition of the material. We switch the particular material to be applied to the next surface as it is read into the scene.

If "alias" must change, what about modifying the geometry's identifier with the id of the original material associated with that surface. For example, a display of the object information for the above scene would show:

hit gl_02_mat polygon glass_mat_gl_0.2
Where the underscore character was used to join the original modifier, "glass_mat" with the polygon's identifier, "gl_0.2".
-Chas

···

==============
Greg Ward <[email protected]> wrote:Maybe we should put it to a vote. It seems straightforward, but it's
actually a fair bit of coding to promote aliases to first class
citizens in the object array. I guess I'd end up sticking the target
ID in a string argument and do a lookup each time the object function
was evaluated. This would result in some overhead that isn't currently
there, both in terms of memory (negligible) and execution speed (more
significant -- see the lastmod() call). I might be able to get around
the execution overhead using the OBJREC os pointer, but I generally
don't use this for tiny bits of memory like object references. Is it
worth it to be able to trace the list of modifiers in applications like
rshow?

Jack's suggestion can be implemented using the current alias handling
as well as an OBJREC structure.

-Greg

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

[Georg_Mischler]

Charles Ehrlich wrote:

In the interest of backward compatibility, I suggest that whatever
modifications to aliases happen with a new entity type, perhaps "alias2".

The proposed modifications wouldn't change the user level semantics
of aliases. They only make it possible to provide more complete
diagnostics to people who lost track of their scene structure,
possibly because they have to use a stupid CAD translator that
doesn't generate unique identifiers.

Whether such diagnostics are critical enough to change the octree
file format, to increase the complexity of the code, and to
possibly slow down the simulations, is an entierly different
question. I can't say that I'm completely convinced at this
point.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Peter_Apian-Bennewi1]

Georg Mischler wrote:

Charles Ehrlich wrote:
> In the interest of backward compatibility, I suggest that whatever
> modifications to aliases happen with a new entity type, perhaps "alias2".

The proposed modifications wouldn't change the user level semantics
of aliases. They only make it possible to provide more complete
diagnostics to people who lost track of their scene structure,
possibly because they have to use a stupid CAD translator that
doesn't generate unique identifiers.

Exactly. They allow verification of any octree, regardless whether generated
by makefiles or by GUI driven interfaces for individuals who don't know
(neither they need to, nor do they want to) what's in their octrees, and who
never get an octree from someone else who uses a different generating
mechanism.

Whether such diagnostics are critical enough to change the octree
file format, to increase the complexity of the code, and to
possibly slow down the simulations, is an entierly different
question. I can't say that I'm completely convinced at this
point.

May I throw-in the thought that we're about to see another primitive anyway,
so the new octree format will have lost backward compatibility already.
As for complexity of the code, the current alias method stands as a singular
exception of rad file processing in the code. Treating it as true primitive
may actually synchronize this with the general flow of logic. If the method
proposed earlier is valid, measured slowdown will be very, very low.

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

[Georg_Mischler]

Peter Apian-Bennewitz wrote:

May I throw-in the thought that we're about to see another primitive anyway,
so the new octree format will have lost backward compatibility already.

There's a point to that.

As for complexity of the code, the current alias method stands as a singular
exception of rad file processing in the code. Treating it as true primitive
may actually synchronize this with the general flow of logic. If the method
proposed earlier is valid, measured slowdown will be very, very low.

Unfortunately, aliases will remain singular as far as rad file
processing is concerned, simply due to their irregular syntax.

In the further processing there never was anything special about
them, since they didn't exist there anymore. They will become a
*new* special case now, because the additional lookups they
generate need to be short circuited as efficiently as possible.

Greg mentioned something how this could be done with almost no
performance penalties. I didn't understand the details, so I
can't say anything smart about that aspect. The ultimate
verification will come through running tests anyway. Isn't that
what CVS branching was invented for?

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

[Peter_Apian-Bennewi1]

Georg Mischler wrote:

> As for complexity of the code, the current alias method stands as a singular
> exception of rad file processing in the code. Treating it as true primitive
> may actually synchronize this with the general flow of logic. If the method
> proposed earlier is valid, measured slowdown will be very, very low.

Unfortunately, aliases will remain singular as far as rad file
processing is concerned, simply due to their irregular syntax.

True. The rad file syntax of "alias" will remain irregular. We're probably stuck
with that until an all-new grammar for the rad file is founded. With the little
use MGF has seen yet (sadly), I don't bet on that happening soon. Maybe I'm wrong
concerning MGF, I just haven't heard of it lately.
The internal processing of "alias" wouldn't be special, it is what happens when
the chain of modifiers is followed during mixfunc and texture/pattern
processing. The difference being that "alias" wouldn't do any calculations. The
cost of mixfunc/textures/patterns results from the processing they do, not from
following the modifier chain.

...
Greg mentioned something how this could be done with almost no
performance penalties. I didn't understand the details, so I
can't say anything smart about that aspect. The ultimate
verification will come through running tests anyway. Isn't that
what CVS branching was invented for?

Yeap, in principle. Technically a tree of branches is both possible and
managable with CVS. Assuming that a branch is expensive in terms of coordination
amongst developpers, developpers-users and amongst users, maybe the "big"
changes like photon-map or Christoph's energy calculations set the bar for
branching.

a nice weekend to all
-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

[Jack_de_Valpine]

Hi Greg, Peter and Georg,

I know that I am jumping in the middle again, so take what I say with whatever sized grain of salt you think is warranted.

Another area where alias handling can be a problem is in the specification of a material for exclusion in the ambient calculation. As things currently stand you must pass the name/id that is actually used to modify the geometry, when in fact it might be preferable in some cases to pass the name of the alias, e.g., if I have a material "black" defined I would rather pass this name for exclusion than some exporter derived name applied to the geometry.

Would the revisions under discussion allow for this?

On the other hand since we tend to use aliasing a lot I would prefer not to slow performance.

-Jack

Georg Mischler wrote:

···

Peter Apian-Bennewitz wrote:

May I throw-in the thought that we're about to see another primitive anyway,
so the new octree format will have lost backward compatibility already.
   
There's a point to that.

As for complexity of the code, the current alias method stands as a singular
exception of rad file processing in the code. Treating it as true primitive
may actually synchronize this with the general flow of logic. If the method
proposed earlier is valid, measured slowdown will be very, very low.
   
Unfortunately, aliases will remain singular as far as rad file
processing is concerned, simply due to their irregular syntax.

In the further processing there never was anything special about
them, since they didn't exist there anymore. They will become a
*new* special case now, because the additional lookups they
generate need to be short circuited as efficiently as possible.

Greg mentioned something how this could be done with almost no
performance penalties. I didn't understand the details, so I
can't say anything smart about that aspect. The ultimate
verification will come through running tests anyway. Isn't that
what CVS branching was invented for?

-schorsch

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction