[Radiance-general] New Radiance Website

Tue Mar 6 14:54:44 PST 2012

Yes those example models are still in there, and we rely on them being
there for testing our builds, so I'd hate to see those ones get moved...

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. robert.guglielmetti at nrel.gov

On 3/6/12 3:03 PM, "Lars O. Grobe" <grobe at gmx.net> wrote:

>Hi Andy,
>
>I agree that there is a demand for sharing models. Besides what you
>mentioned, it is great for educational purpose and for validation. It may
>even reduce the downloads - if we could remove example scenes from the
>auxiliary files (errr are they still in there?) and have a makefile not
>only running oconv and rpict, but fetch model data when needed from a
>known URL.
>
>For integrating my FAQ-start, I'd be happy to support this. Maybe the
>formatting would need to be sent through your CSS. Sharing accounts
>should be rather easy, there are lots of interfaces available in times of
>social networks (opened? Huuuuh big brother Radiance ;)...). I think we
>can discuss this off-list (with everyone included who is interested).
>
>For those starting to play around now - please forgive the
>user-unfriendliness (you may also call it rudeness) of the site in its
>current stage. I did not plan to make it public yet and posted the
>address more as a contribution to the discussion. I will do some
>polishing in the coming days, until then expect it to behave as what it
>is - still experimental ;)
>
>Cheers, Lars.
>
>--
>Dipl.-Ing. Architect Lars O. Grobe
>
>On Mar 6, 2012, at 19:22, Andy McNeil <amcneil at lbl.gov> wrote:
>
>> HI Lars,
>> 
>> I think your comments regarding FAQ's are spot on.  I don't want to
>>duplicate effort, so I'd like to let you continue to develop your FAQ
>>and will replace the stub on with a redirection to your site.  It would
>>be nice to integrate the two, at least using the same login/passwords.
>> 
>> I agree that models are generally less useful than objects, but I would
>>contend that in the research community there are desires to share and
>>use standard models.  I have some Radiance models for DOE prototype
>>buildings that others might like to use.  And HMG has 61 models of
>>existing buildings that many have already asked for them to share.
>> 
>> But regardless, we can let users decide which is worth sharing.  And
>>taking the lead from your FAQ, we could get rid of the formal categories
>>and instead using tags.  If you want to simulate a daylight redirecting
>>system you would probably want to see results for both a cal file and a
>>model of the system.
>> 
>> I'll end by saying -  please help!
>> 
>> Andy
>> 
>> 
>> 
>> 
>> On Mar 5, 2012, at 3:56 PM, Lars O. Grobe wrote:
>> 
>>> Hi Andy, hi list!
>>> 
>>> 
>>> This is a nice framework for an appealing site! I especially like the
>>> fact that the design of the "good old" site could be adopted.
>>> 
>>> I started setting up something related recently. Not based on Plone but
>>> Drupal, not a complete "Radiance Website" but a concept focussing on
>>> just having a working FAQ one day. You may get an idea here:
>>> 
>>> http://radiance.larsgrobe.de
>>> 
>>> The only part of interest on the site is the FAQ for now. I have spent
>>> some time on thinking how to organize a FAQ, and abandoned the idea of
>>> having single categories per question. I believe a tag-system being
>>>much
>>> more appropriate, e.g. a question/answer pair on mkillum might be
>>> related to "commands", "diffuse indirect calculation", "complex
>>>glazing"
>>> and "optimizations". One day one might decide to also tag the content
>>>on
>>> user levels, so a tag "advanced user" might be added. Browsing the
>>> mailing lists, there is such a vast amount of information that I tend
>>>to
>>> pay a lot of attention on the topic of marking it. Once a certain
>>>amount
>>> of content is available, tag clouds (which may occur in alphabetical
>>> order - I do not rely like the fancy cloud displays typically rendered
>>> with lots of formatting) may be of more help then a fixed hierarchy.
>>> 
>>> One feature that I spent some time on was to integrate tex notation
>>>into
>>> the content management. I added a test on the start page. You can embed
>>> any Latex code in the content, which will be rendered into inline
>>> images, but also be available as pdf downloads. The need to display
>>> formulas and algorithms seams to be of importance. I am going to add
>>> support for describing geometry in the content management, too -
>>> basically I want to keep content descriptive and avoid bitmap images as
>>> far as possible, so that content can be reused (e.g. for copying the
>>> Latex source into a formula editor when writing an article),
>>>reformatted
>>> and extended at any time.
>>> 
>>> 
>>> 
>>> On sharing: I think that sharing models is an interesting part of a
>>> community website, though I am not sure that much model content will
>>> become available. Most Radiance models are case-studies - buildings,
>>> rooms, facades. Objects to be shared are more like furniture and other
>>> decorative stuff, not bound to a specific use case - which is already
>>> available on the internat. Similar is true for textures.
>>> 
>>> 
>>> 
>>> I see a need for sharing of cal-files. This would require an interface
>>> where I could check the parameters and get a preview of the results -
>>> downloading the cal-file is easy, using it makes things difficult.
>>> 
>>> 
>>> The gallery is a must....
>>> 
>>> 
>>> A Radiance material library would be great and is a topic on its own. I
>>> started a concept of holding material data in a database, with several
>>> interfaces to access it. I would prefer the data to be independent of
>>> the software using it, so e.g. I would want spectral resolutions
>>> supported beyond the three RGB channels natively supported by Radiance.
>>> 
>>> Extracting a Radiance material from this could be implemented in the
>>> interface - combining the measured data from the database with the
>>> assumptions to be made when using it in Radiance (e.g. I would need to
>>> know that the data from the spectrometer are to be used with a plastic
>>> modifier). So a material record could contain a table "models", where I
>>> could add proposed models for various software tools. So querying the
>>> model-table for "Radiance" for this material would return "plastic",
>>> while querying for "MyOtherRenderer" could return
>>>"lambertianReflection".
>>> 
>>> 
>>> 
>>> I decided not to publicly announce this project so far, as there is
>>> little content right now. Maybe there is some potential for combining
>>> efforts, so I add this to the discussion.
>>> 
>>> Cheers, Lars.
>>> 
>>> _______________________________________________
>>> Radiance-general mailing list
>>> Radiance-general at radiance-online.org
>>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>> 
>> 
>> _______________________________________________
>> Radiance-general mailing list
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>_______________________________________________
>Radiance-general mailing list
>Radiance-general at radiance-online.org
>http://www.radiance-online.org/mailman/listinfo/radiance-general