Is anyone investigating or developing an (xml2rad) import tool to read the xml schema?
Terrance McMinn
On 28/10/11 3:00 AM, Dan Glaser wrote:
Hi Everyone,
I recently heard that gbXML is being updated:http://www.gbxml.org/currentschema.php
They are accepting comments and suggestions until November 4th (with
a final release of Nov 18th). Is anyone from the Radiance development
community participating in this discussion?
Thanks,- Dan
The OpenStudio SketchUp plug-in has preliminary import of gbXML with an
expanded edition expected to be released soon. Conversion of OpenStudio
models to Radiance is currently possible through a set ruby scripts and
better integration with the SketchUp plug-in is planned for the near
future. Contact me if you want details on how to use our existing
functionality immediately or check back later as features are continuously
added to the plug-in (http://openstudio.nrel.gov/downloads).
Rob
Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
1617 Cole Blvd MS:RSF202
Golden, CO 80401
T. 303.275.4319
F. 303.630.2055
E. [email protected]
On 10/27/11 8:18 PM, "Terrance Mc Minn" <[email protected]> wrote:
Is anyone investigating or developing an (xml2rad) import tool to read
the xml schema?Terrance McMinn
On 28/10/11 3:00 AM, Dan Glaser wrote:
Hi Everyone,
I recently heard that gbXML is being updated:http://www.gbxml.org/currentschema.php
They are accepting comments and suggestions until November 4th (with
a final release of Nov 18th). Is anyone from the Radiance development
community participating in this discussion?
Thanks,- Dan
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Dear Rob,
Thanks for letting us know that there is an effort by the Open Studio Team to read gbXML models.
Are there aspects of a Radiance model that cannot be expressed well in gbXML unless you extend it (e.g. mirrors, .cal files, bsdf's (which has its own xml), etc.)? If not, are there any ongoing efforts by the Radiance community to develop a complete, standardized XML language that can form the basis of creating a Radiance project?
Thanks,
- Dan
On 10/28/2011 10:19 AM, Guglielmetti, Robert wrote:
The OpenStudio SketchUp plug-in has preliminary import of gbXML with an
expanded edition expected to be released soon. Conversion of OpenStudio
models to Radiance is currently possible through a set ruby scripts and
better integration with the SketchUp plug-in is planned for the near
future. Contact me if you want details on how to use our existing
functionality immediately or check back later as features are continuously
added to the plug-in (http://openstudio.nrel.gov/downloads).Rob
Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
1617 Cole Blvd MS:RSF202
Golden, CO 80401
T. 303.275.4319
F. 303.630.2055
E. [email protected]On 10/27/11 8:18 PM, "Terrance Mc Minn"<[email protected]> wrote:
Is anyone investigating or developing an (xml2rad) import tool to read
the xml schema?Terrance McMinn
On 28/10/11 3:00 AM, Dan Glaser wrote:
Hi Everyone,
I recently heard that gbXML is being updated:http://www.gbxml.org/currentschema.php
They are accepting comments and suggestions until November 4th (with
a final release of Nov 18th). Is anyone from the Radiance development
community participating in this discussion?
Thanks,- Dan
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
LF logo Daniel C. Glaser, PhD, LEED AP BD+C, IES
Principal
Light Foundry, LLC
T: 510.387.8890
www.lightfoundryllc.com <http://www.lightfoundryllc.com>
Hi Dan, hi list subscribers,
it is possible to encode a Radiance scene in XML. I tried it some years
ago. I did some extra work trying to do almost all conversions from/to
XML using only xml stylesheets, to have no extra code. This still
implies adding two lines to the end and the beginning of a non-XML file,
so that a stylesheet can be applied. Still, it was nice to use existing
parsers instead of writing new ones.
At the time, I was mostly interested to investigate getting a nice
development environment for writing scenes. E.g. validation. Even
information on some physical boundaries might be included into a schema,
leading to a warning when writing a funny trans definition using an XML
editor. Or avoiding those errors due to polygons with a missing vertex.
Validation during authoring is nice sometimes. Of course it gets
difficult when working with cal-files and similar stuff leading to
variable parameter lenghts.
Some caveats are to be considered though. Radiance's scene language is
very 'linear'. It is allowed (and sometomes useful) to have a material
name with very different properties. Radiance will apply the properties
to objects referring to that material until the material is redefined.
So one material name can mean very different material properties, only
depending on the position in a scene file (or a stream of scene data, as
even commands may get expanded in a scene). This is one example where
Radiance may not follow what folks using XML may expect - unique ID's
get available only once the scene is read in, they do not exist in the
scene description. Another question may be how to treat expanded
commands. There are very good reasons to write a command into a scene
file, not the output of the command (e.g. to make modifications easier
or to improve readability). However, XML as an exchange format would
typically not rely on a command but make a scene file a complete dataset
(which then e.g. could simply be translated into a x3d file using a
stylesheet, no Radiance binaries).
In the end, a lot about Radiance has always been performance and
efficiency. My initial interest being authoring support in text-based
environments, having gigabytes of scene data was not an issue. Huge
scenes may have more efficient representations then XML though. Another
question arising is about databases. XML has been developed to exchange
data in between databases (and all the validation techniques where ment
to avoid havin a database messed up when importing someone else's data
in the end). However, in Radiance, we have no database concept. Maybe
this would be something to think about - a database interface. Than we
could access unique objetc and modifier id's, could connect to e.g.
library databases, prevent some locking problems... but - do we really
need it, and does it match the requirements of what is basically a
raytracing code???
Cheers, Lars.
its own xml), etc.)? If not, are there any ongoing efforts by the
Radiance community to develop a complete, standardized XML language that
can form the basis of creating a Radiance project?
Thanks,
- Dan
While not necessary for the raytracing work, it becomes very important in
the context of a broader simulation workflow where you're trying to
integrate Radiance in/output with other tools, such as EnergyPlus or
whatever. And, in a massively parallel simulation stream, for
optimizations and the like, accountability is critical. You need to be
able to go back and have a reliable account of what was simulated.
OpenStudio has a RunManager application that manages packing up models
into "jobs", that can be parceled out to a cluster and all the results are
merged back to the OpenStudio project. We're just now integrating Radiance
with the RunManager application, but we hope that it will be very useful
for large parameter spaces.
- Rob
On 10/30/11 12:09 PM, "Lars O. Grobe" <[email protected]> wrote:
... However, in Radiance, we have no database concept. Maybe
this would be something to think about - a database interface. Than we
could access unique objetc and modifier id's, could connect to e.g.
library databases, prevent some locking problems... but - do we really
need it, and does it match the requirements of what is basically a
raytracing code???
Hi!
... However, in Radiance, we have no database concept. Maybe
this would be something to think about - a database interface. Than we
could access unique objetc and modifier id's, could connect to e.g.
library databases, prevent some locking problems... but - do we really
need it, and does it match the requirements of what is basically a
raytracing code???While not necessary for the raytracing work, it becomes very important in
the context of a broader simulation workflow where you're trying to
integrate Radiance in/output with other tools, such as EnergyPlus or
whatever. And, in a massively parallel simulation stream, for
optimizations and the like, accountability is critical. You need to be
able to go back and have a reliable account of what was simulated.
OpenStudio has a RunManager application that manages packing up models
into "jobs", that can be parceled out to a cluster and all the results are
merged back to the OpenStudio project. We're just now integrating Radiance
with the RunManager application, but we hope that it will be very useful
for large parameter spaces.
Ok so lets translate this into the next question. Would we need a
database interface in Radiance? Or do we need it in other applications
which may call Radiance processes? My guess is that there may be nice
aspects in having a unified database layer, but that it would mean a
heavy piece of code.
On the other hand, we already can expand commands in scenes, and noone
prevents us from using commands querying databases, or from piping
output into some toold transating our calculation results' rows into
inserts into a result table. I never counted the amount of files called
illuminance.dat on my hard drive. Probably it would be much nicer to
have a illuminance table, each with a row of illuminance values and a
key pointing to a row of position coordinates and one of direction vectors.
When it comes to holding scene data, still my doubts are about the very
flexible way Radiance is treating modifier and object names and any
concept working with unique id's. Of course, noone says that these are a
must in databases or in XML - but a relational database somehow gets all
its power from these id's and the capability of linking between them.
So, maybe Radiance is already powerful enough to live in a
database-backed environment, with naming conventions that can be used as
IDs, with connections to databases and all the nice features of XML as a
transfer format. And still, people may use the same software in other
environments, where only processing speed counts, or all is about how
scene data is generated, without any such conventions. Maybe it makes
sense to develop some common schema for using Radiance in
database-backed environments, to allow others to interface to it, but
being aware that this will not be able to hold all possible scenes
impressed in files not following such conventions. And maybe it may be
nice to have some commodity tools preventing users to find the exact
command line for their database to query and insert?
Cheers, Lars.
On 31.10.2011 19:24, Guglielmetti, Robert wrote:
On 10/30/11 12:09 PM, "Lars O. Grobe" <[email protected]> wrote:
Dear Rob, Lars, and other list subscribers,
My original question was if the current gbXML schema can fully expresses a Radiance model or project. To summarize from www.gbxml.org:
The Green Building XML (gbXML) open schema helps facilitate the transfer of building properties stored in 3D building information models (BIM) to engineering analysis tools. Today, gbXML has the industry support of leading 3D BIM vendors... gbXML has become the defacto industry standard schema.
I think it is important that a Radiance specification can be included in this standard since it will make many more models available to run in Radiance without having to potentially "kludge" data types between file formats. For example, Revit a popular modeling/BIM package supports exporting gbXML directly. There are a few workarounds to get a Revit project into Radiance that have been discussed on these boards, but often the Radiance project that is created still needs augmentation to be built correctly.
Can people with experience encoding and decoding this specific XML (gbXML) please speak up about their experiences about what parts of gbXML translate into Radiance models/projects and what parts are missing?
gbXML 5.0 is under review until November 4th and will be finalized shortly after. I know that one of the issues that was brought up at the Radiance workshop this past summer was to see increased adoption of Radiance and I think this standard can help support this goal.
Thank you.
- Dan
On 10/31/2011 12:45 PM, Lars O. Grobe wrote:
Hi!
On 31.10.2011 19:24, Guglielmetti, Robert wrote:
On 10/30/11 12:09 PM, "Lars O. Grobe"<[email protected]> wrote:
... However, in Radiance, we have no database concept. Maybe
this would be something to think about - a database interface. Than we
could access unique objetc and modifier id's, could connect to e.g.
library databases, prevent some locking problems... but - do we really
need it, and does it match the requirements of what is basically a
raytracing code???While not necessary for the raytracing work, it becomes very important in
the context of a broader simulation workflow where you're trying to
integrate Radiance in/output with other tools, such as EnergyPlus or
whatever. And, in a massively parallel simulation stream, for
optimizations and the like, accountability is critical. You need to be
able to go back and have a reliable account of what was simulated.
OpenStudio has a RunManager application that manages packing up models
into "jobs", that can be parceled out to a cluster and all the results are
merged back to the OpenStudio project. We're just now integrating Radiance
with the RunManager application, but we hope that it will be very useful
for large parameter spaces.Ok so lets translate this into the next question. Would we need a
database interface in Radiance? Or do we need it in other applications
which may call Radiance processes? My guess is that there may be nice
aspects in having a unified database layer, but that it would mean a
heavy piece of code.On the other hand, we already can expand commands in scenes, and noone
prevents us from using commands querying databases, or from piping
output into some toold transating our calculation results' rows into
inserts into a result table. I never counted the amount of files called
illuminance.dat on my hard drive. Probably it would be much nicer to
have a illuminance table, each with a row of illuminance values and a
key pointing to a row of position coordinates and one of direction vectors.When it comes to holding scene data, still my doubts are about the very
flexible way Radiance is treating modifier and object names and any
concept working with unique id's. Of course, noone says that these are a
must in databases or in XML - but a relational database somehow gets all
its power from these id's and the capability of linking between them.So, maybe Radiance is already powerful enough to live in a
database-backed environment, with naming conventions that can be used as
IDs, with connections to databases and all the nice features of XML as a
transfer format. And still, people may use the same software in other
environments, where only processing speed counts, or all is about how
scene data is generated, without any such conventions. Maybe it makes
sense to develop some common schema for using Radiance in
database-backed environments, to allow others to interface to it, but
being aware that this will not be able to hold all possible scenes
impressed in files not following such conventions. And maybe it may be
nice to have some commodity tools preventing users to find the exact
command line for their database to query and insert?Cheers, Lars.
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
LF logo Daniel C. Glaser, PhD, LEED AP BD+C, IES
Principal
Light Foundry, LLC
T: 510.387.8890
www.lightfoundryllc.com <http://www.lightfoundryllc.com>