Luminaire octree

Hello,

I apologize if this has been asked and answered -- I couldn't find anything searching, though I wasn't sure the best keywords to use.

I am trying to create a luminaire octree, which I will then use with replmarks to place about 20 of these in a larger radiance model. I am modeling a psuedo-indirect exterior fixture that consists of a 19' high pole with essentially 4 arms, each with a lamp aimed straight up at a reflecting panel. I have an IES file that represents one arm of this fixture. I have successfully modeled the fixture with the 4 arms and am now wanting to make an octree out of it, including the application of the 4 ies distributions ( more technically the output from ies2rad -- I have a brightdata primitive, referring to a dat file describing the light distribution, that gets applied to an illum surface, then applied to a box of polygons). However, when I do this (both frozen and unfrozen), I do not see any light sources. Essentially, it seems the brightdata primitive does not get preserved in the octree. My resulting octree has all the physically geometry I wanted, but the glow surface (used to just illuminate fixture geometry) and the IES distribution applied to box of illum polygons does not show up.

When I try to separate the geometry with the IES distribution I also have trouble. I have an octree representing luminaire geometry and then I separately add the 4 distributions (which do overlap the geometry bounding cube) I get some light but definitely not the same distribution of light I'm expecting and began with.

Any help is appreciated. I am hoping to find a more elegant solution than just physically modeling (not replmarking) these 20 fixtures and adding 80 markers for the distributions.

Zack

PS. I can e-mail a rendering if it helps explain the situation (can't post to a website right now)

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

Hi Zack,

In the Radiance reference manual <http://radsite.lbl.gov/radiance/refer/ray.html#Surfaces> it mentions briefly that one of the limitations of instances is that they are not good for light sources. This is because the initialization step in Radiance that discovers light sources does not delve into octree and mesh instances to find potential sources. It could of course, but since the number of sources should be restricted to something reasonable, I didn't think it was a good idea to include instanced objects in the source search.

There is a simple workaround for this. Just take the emitting surface out of your luminaire and instance it separately using xform. You can still apply replmarks by xform'ing a file that looks like this:

# Output of ies2rad
void brightdata ...

... polygon source
...

void instance luminaire_geometry
1 lumgeom.oct
0
# End of luminaire description

Give the above file to replmarks -x, and you'll get a transformed instance and transformed source that Radiance will recognize.

-Greg

···

From: Zack Rogers <[email protected]>
Date: June 23, 2005 1:10:45 AM BDT

Hello,

I apologize if this has been asked and answered -- I couldn't find anything searching, though I wasn't sure the best keywords to use.

I am trying to create a luminaire octree, which I will then use with replmarks to place about 20 of these in a larger radiance model. I am modeling a psuedo-indirect exterior fixture that consists of a 19' high pole with essentially 4 arms, each with a lamp aimed straight up at a reflecting panel. I have an IES file that represents one arm of this fixture. I have successfully modeled the fixture with the 4 arms and am now wanting to make an octree out of it, including the application of the 4 ies distributions ( more technically the output from ies2rad -- I have a brightdata primitive, referring to a dat file describing the light distribution, that gets applied to an illum surface, then applied to a box of polygons). However, when I do this (both frozen and unfrozen), I do not see any light sources. Essentially, it seems the brightdata primitive does not get preserved in the octree. My resulting octree has all the physically geometry I wanted, but the glow surface (used to just illuminate fixture geometry) and the IES distribution applied to box of illum polygons does not show up.

When I try to separate the geometry with the IES distribution I also have trouble. I have an octree representing luminaire geometry and then I separately add the 4 distributions (which do overlap the geometry bounding cube) I get some light but definitely not the same distribution of light I'm expecting and began with.

Any help is appreciated. I am hoping to find a more elegant solution than just physically modeling (not replmarking) these 20 fixtures and adding 80 markers for the distributions.

Zack

PS. I can e-mail a rendering if it helps explain the situation (can't post to a website right now)

Thanks Greg,

This is exactly my problem. Rob G. pointed me to a previous post discussing this as well.

http://radiance-online.org/pipermail/radiance-general/2003-August/000946.html

I will try this approach today.

Thanks!
Zack

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

I have 4 IES files applied to each luminaire octree I want to create, which I think is adding complexity to this issue. I have tried what I think is basically the work-around method outlined. I am testing it with this rad file:

### test_oct.rad
void alias l_room grey_090
!xform scene/l_room.rad

!replmarks -x parts/campo_full.rad l_test_oct scene/l_test_oct.rad
### end file

which refers to
### campo_full.rad
void alias l_reflector grey_090
!xform scene/l_reflector.rad

void alias l_metal stainless_steel
!xform scene/l_metal.rad

void alias l_glow campo_glow
!xform scene/l_glow.rad

!replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad
### end file

The "luminaire/hessamerica+++ca45-71r+++6500.rfl" file is basically the output of ies2rad (rayfrontized) for a single ies file. Since I have 4 of these, and the default ies2rad output is a box centered around the origin, i have this extra replmarks (which has used -x all along) to put these 4 distributions in place relative to the luminaire goemetry ( which is described by the xformed rad files rather than an instanced octree -- does this matter)

I still am getting no light. in my test_oct.rad scene description. What am I still missing? The only octree being made is the final scene octree for "test_oct.rad".

This url shows a low-quality rendering of the fixture I am dealing with:
http://www.archenergy.com/services/sda/tools/campo/

Thanks!
Zack

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

Hi Zack,

It looks like you are getting light in your image. There seems to be a lot of light on the floor. Perhaps it is not working the way you expect?

One thing to do that might help at least verify the spatial location, would be to edit luminaire/hessamerica+++ca45-71r+++6500.rfl and make sure that the light source is "light" rather than "illum." This way you can see its location in the image. Then make a scene that only includes:

!replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad

placed in the room. This way you can see if the distribution is working the way you expect (without the interference of actual fixture geometry). The problem that you might be facing is the size and location of the geometry that the distribution data is applied to vs the size and location of the fixture geometry. You may end up needing to custom build the geometry that represents the sources that the data is applied to. One option to assist in this is to use the -i feature of ies2rad. This produces a sphere with an illum material type applied to it (modified by the distribution function). You can specify the radius of the sphere so that it can enclose the relevant geometry of the fixture.

-Jack

Zack Rogers wrote:

···

I have 4 IES files applied to each luminaire octree I want to create, which I think is adding complexity to this issue. I have tried what I think is basically the work-around method outlined. I am testing it with this rad file:

### test_oct.rad
void alias l_room grey_090
!xform scene/l_room.rad

!replmarks -x parts/campo_full.rad l_test_oct scene/l_test_oct.rad
### end file

which refers to
### campo_full.rad
void alias l_reflector grey_090
!xform scene/l_reflector.rad

void alias l_metal stainless_steel
!xform scene/l_metal.rad

void alias l_glow campo_glow
!xform scene/l_glow.rad

!replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad
### end file

The "luminaire/hessamerica+++ca45-71r+++6500.rfl" file is basically the output of ies2rad (rayfrontized) for a single ies file. Since I have 4 of these, and the default ies2rad output is a box centered around the origin, i have this extra replmarks (which has used -x all along) to put these 4 distributions in place relative to the luminaire goemetry ( which is described by the xformed rad files rather than an instanced octree -- does this matter)

I still am getting no light. in my test_oct.rad scene description. What am I still missing? The only octree being made is the final scene octree for "test_oct.rad".

This url shows a low-quality rendering of the fixture I am dealing with:
http://www.archenergy.com/services/sda/tools/campo/

Thanks!
Zack

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

Hi Jack

It looks like you are getting light in your image. There seems to be a lot of light on the floor. Perhaps it is not working the way you expect?

The image I posted is of the correctly modeled luminaire before trying to replmark it as an octree (1st attempt which seems to be a dead end) or replmark an octree of geometry and separately replmark -x 4 ies files (2nd attempt which did not give any light output - ies markers did overlap geometry octree bounding cube) or replmark -x it as a single .rad file (3rd attempt not giving same light output as the posted image, but some light output nonetheless).

One thing to do that might help at least verify the spatial location, would be to edit luminaire/hessamerica+++ca45-71r+++6500.rfl and make sure that the light source is "light" rather than "illum." This way you can see its location in the image. Then make a scene that only includes:

!replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad

I am pretty sure the distribution is close to correct now, I already did the "light" definition to ensure this. For this fixture, my illum box is 4' x 1'9" x 2'6", encompassing the reflector, supports, and lamp for each arm. The central support arm does pass through this illum box, but most candelas are going forward so I do not think this is causing significant inaccuracies in the resulting distribution. I think the shadow lines on the floor are a little more intense because of this but that's about it. Any issues with applying ies data to such a large illum box?

Thanks for the suggestions! Have you been successful using replmarks -x for light sources in your renderings? I think the double use of replmarks -x (once for the 4 ies files, and then again for my final placement) may be causing my problems now.

Zack

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

Zack Rogers wrote:

The "luminaire/hessamerica+++ca45-71r+++6500.rfl" file is basically the
output of ies2rad (rayfrontized) for a single ies file.

In the standard case, Rayfront will automate all this for you,
including the decision whether to use xform or instances for
the geometry. Just that each of your 4 elements must be treated
as a seperate luminaire, by actually placing 4 markers instead of
just one.

But then, I'm not sure which surface in your example is supposed
to serve as an emitter, so it may be too tricky for the builtin
mechanism to handle it correctly. Is that the reason why you're
trying the manual approach?

-schorsch

···

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

Hi Zack,

We use multiple replmark calls on all kinds of object including lights and fixture geometry. Typically we define the fixture geometry and compile it into an octree that can be instanced around. Any lights (illum/light/glow and associated distribution data) are managed independantly althoughf generally using the same markers used to locate the fixture geometry. In general, the thing to remember is that anything that is a light (eg has the following material types applied: light, illum and glow) must be compiled into the final top level scene octree.

Let's try to back up and consider in a more generic manner what you are trying to do: build a scene that has multiple instances of the campo fixture deployed. To do this, you could do the following (note there are a few different ways and this is just what is coming out as I write):

Note I will assume mats.lib that defines your materials.

BUILD the LIGHT FIXTURE GEOMETRY (no lights, illums or glows) for 1 CAMPO FIXTURE

camp_full_geometry.rad:

    !xform -m grey_090 scene/l_reflector.rad
    !xform -m stainless_steel scene/l_metal.rad

oconv mats.lib campo_full_geometry.rad > campo_full_geometry.oct

BUILD the LIGHT SOURCES for 1 CAMPO FIXTURE

campo_light.rad

    !xform -m campo_glow scene/l_glow.rad
    !replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad

BUILD the SCENE

test_room.rad

    !xform -m grey_090 scene/l_room.rad
    !replmarks -i campo_full_geometry.oct l_test_oct scene/l_test_oct.rad #gives you x instanced octrees of the
    fixture in the scene
    !replmarks -x campo_light.rad l_test_oct scene/l_test_oct.rad #gives you x xformed light
    source groupings in the scene

oconv mats.lib test_room.rad > test_room.oct
rview -ab 1 -av 0 0 0 -vf myview.vf test_room.oct

It looks like the way you have things broken down should be fine, so it is not clear why it is not working the way you expect. My example organizes things a little differently and I think it should work.

Regarding the large illum geometry for the ies data. I think that this should not be a problem, but really depends on whether this is the geometry that gets spit out by ies2rad or is it geometry that you have built yourself. If it is the latter then you need to make sure that the brightdata definition for the ies data includes the proper measure (METERS!) for the box geometry, and also that it uses boxcorr/lboxcorr.

It looks like you have a glow also. You may want to assign the glow a local radius (argument 4) to make sure that things inside the illum geometry get some local lighting.

Hope this helps.

-Jack

Zack Rogers wrote:

···

Hi Jack

It looks like you are getting light in your image. There seems to be a lot of light on the floor. Perhaps it is not working the way you expect?

The image I posted is of the correctly modeled luminaire before trying to replmark it as an octree (1st attempt which seems to be a dead end) or replmark an octree of geometry and separately replmark -x 4 ies files (2nd attempt which did not give any light output - ies markers did overlap geometry octree bounding cube) or replmark -x it as a single .rad file (3rd attempt not giving same light output as the posted image, but some light output nonetheless).

One thing to do that might help at least verify the spatial location, would be to edit luminaire/hessamerica+++ca45-71r+++6500.rfl and make sure that the light source is "light" rather than "illum." This way you can see its location in the image. Then make a scene that only includes:

!replmarks -x luminaire/hessamerica+++ca45-71r+++6500.rfl l_ies scene/l_ies.rad

I am pretty sure the distribution is close to correct now, I already did the "light" definition to ensure this. For this fixture, my illum box is 4' x 1'9" x 2'6", encompassing the reflector, supports, and lamp for each arm. The central support arm does pass through this illum box, but most candelas are going forward so I do not think this is causing significant inaccuracies in the resulting distribution. I think the shadow lines on the floor are a little more intense because of this but that's about it. Any issues with applying ies data to such a large illum box?

Thanks for the suggestions! Have you been successful using replmarks -x for light sources in your renderings? I think the double use of replmarks -x (once for the 4 ies files, and then again for my final placement) may be causing my problems now.

Zack

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

The underside of the curved panel is the emitter. I actually used this
fixture on a museum project a while ago. Zack, you mention that you have
a bounding box for the illum, but you don't mention that you have applied
lboxcorr. Perhaps this is causing problems? Honestly, I haven't use
bounding illums (yet), but I remember reading that this correction must be
applied to non-spherical illum boundaries...

···

On Thu, June 23, 2005 2:49 pm, Georg Mischler said:

Zack Rogers wrote:

The "luminaire/hessamerica+++ca45-71r+++6500.rfl" file is basically the
output of ies2rad (rayfrontized) for a single ies file.

In the standard case, Rayfront will automate all this for you,
including the decision whether to use xform or instances for
the geometry. Just that each of your 4 elements must be treated
as a seperate luminaire, by actually placing 4 markers instead of
just one.

But then, I'm not sure which surface in your example is supposed
to serve as an emitter, so it may be too tricky for the builtin
mechanism to handle it correctly. Is that the reason why you're
trying the manual approach?

--
Rob Guglielmetti
www.rumblestrip.org

Zack, you mention that you have
a bounding box for the illum, but you don't mention that you have applied
lboxcorr.

The bounding box illum was made by ies2rad, so it's been correctly scaled, using boxcorr and everything. So I don't think the problem is related to this.

In the standard case, Rayfront will automate all this for you,
including the decision whether to use xform or instances for
the geometry. Just that each of your 4 elements must be treated
as a seperate luminaire, by actually placing 4 markers instead of
just one.

But then, I'm not sure which surface in your example is supposed
to serve as an emitter, so it may be too tricky for the builtin
mechanism to handle it correctly. Is that the reason why you're
trying the manual approach?

I am using Rayfront for most of this, I just go into the files when needed, ie. to take out the sky when creating the lum geom octree. I tried, within Rayfront (my 2nd attempt), to have 4 markers for each of the ies files + 1 marker for lum_geom (overlap between octree bounding and ies cubes) and did not get any light output.

Thanks for all the feed back. I have alot of alternative methods to play with now. Jack, your example makes sense and seems to be essentially what I tried for my 3rd attempt. I will try reorganizing somewhat and see if I can get it to work.

Thanks!
Zack

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

Zack Rogers wrote:

>But then, I'm not sure which surface in your example is supposed
>to serve as an emitter, so it may be too tricky for the builtin
>mechanism to handle it correctly. Is that the reason why you're
>trying the manual approach?
>
I am using Rayfront for most of this, I just go into the files when
needed, ie. to take out the sky when creating the lum geom octree. I
tried, within Rayfront (my 2nd attempt), to have 4 markers for each of
the ies files + 1 marker for lum_geom (overlap between octree bounding
and ies cubes) and did not get any light output.

It might be easier to treat the geometry for each unit individually
as well (even if that means you need to handle the pole seperately).
If you do this, then Rayfront can position the luminaire geometry
for you, relative to the position of the IES curve.
As I understand by now, the emitting surface is a virtual bounding
box. Rayfront can create that for you as well.

If it works at all (eg. if there's no issue about intersecting
bounding boxes), then it should be possible to get the desired
effect within or without Rayfront. As all of Rayfront, I tried
to design this part so that it would make it easier to handle
than the manual method. Now we'll find out whether that actually
turns out to be the case...

-schorsch

···

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

I am happy to say, after minor brain damage, that I successfully created my luminaire block. My problem, initially, was due to the Radiance limitation that light cannot be included in an instance. My problem with the workaround, any of those discussed I think would work - just different ways of assembling the pieces, was that I was refering to a *.rad file in a my "./parts" directory. However, inside the *.rad file were references to my "./scene" directory which is not a subdirectory of "parts" but at the same level. My RAYPATH definition has the current directory "." as a path and so it was simply not finding the files...a mistake I probably would have noticed sooner had I not been using a Radiance interface (rayfront) and a mistake I probably would have never noticed had I not jumped behind the scenes.

Don't know if this will help anyone, but thought I'd post to resolve this thread. Thanks for all the help!
Zack

BTW- Georg, in Rayfront if people try to create "parts" as rad files rather than octrees and then replmark them I think it will result in the same problem.

···

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

How 'bout posting your new rendering?

Rob F

···

-----Original Message-----
From: Zack Rogers
To: Radiance general discussion
Sent: 6/27/2005 4:49 PM
Subject: [Radiance-general] Luminaire octree

I am happy to say, after minor brain damage, that I successfully created

my luminaire block. My problem, initially, was due to the Radiance
limitation that light cannot be included in an instance. My problem
with the workaround, any of those discussed I think would work - just
different ways of assembling the pieces, was that I was refering to a
*.rad file in a my "./parts" directory. However, inside the *.rad file
were references to my "./scene" directory which is not a subdirectory of

"parts" but at the same level. My RAYPATH definition has the current
directory "." as a path and so it was simply not finding the files...a
mistake I probably would have noticed sooner had I not been using a
Radiance interface (rayfront) and a mistake I probably would have never
noticed had I not jumped behind the scenes.

Don't know if this will help anyone, but thought I'd post to resolve
this thread. Thanks for all the help!
Zack

BTW- Georg, in Rayfront if people try to create "parts" as rad files
rather than octrees and then replmark them I think it will result in the

same problem.

--
Zack Rogers
Engineer / Daylighting Designer
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext.235
fax (303)444-4304

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

Zack Rogers wrote:

BTW- Georg, in Rayfront if people try to create "parts" as rad files
rather than octrees and then replmark them I think it will result in the
same problem.

Any data for use in the "parts" subdirectory should be self
contained. Ideally just one file.

-schorsch

···

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