Hi,
There seems to be a limit to the number of materials that can be listed in a file for use with the -aE option. It looks like it is 128 lines. Is this fixed? Can it be adjusted at compile time? Can multiple exclude files be used?
-Jack
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack,
yes, the number of materials in the ambient exclude/include list ist currently limited to 128.
if you want to augment it (at compile time) change
1) in rpict.c the declaration char* amblist[128]
2) to be on the safe side
in ambient.c : augment the #define MAXASET 511
3) also to be on the safe side
in wordfile.c (src/common) augment the #define MAXFLEN 8192
steps 2 and 3 are probably not necessary, the business is a bit weird because the hierachyless input format allows the occurence of several material instances with the same name, but different object number (that's why the MAXASET (511) is greater than the name list maximum (128))
as usual, I don't give any guarantee if this is enough or right or if I've still forgotten something ...and AFAIK you can only specify one exclude file, 'cause there's only one list internally which is checked
-cb
PS it's funy, in fact I've already waited for something like this to happen, i.e. someone running against this border 
Hi Carsten,
Thanks for the follow-up. Is there a way to determine what MAXASET and MAXFLEN should be set to relative to amblist[]. For example if I double amblist to amblist[256] do I need to double the other values. Also I note that amblist occurs in rtrace.c and rview.c. Wouldn't it make sense if amblist was defined in one place (eg some header file) so that it could be uniformly applied? Also is there some hidden downside to increasing these values?
FYI, as to hitting the border. The exclude file that I have is really to serve as a default list so that if certain objects (trees, plants) are used in the scene then their geometry is excluded from the ambient calculation (that is that I do not have to think about it). I was trying to add some more and encountered the problem. It is not that I currently have more that 128 items that are actually being excluded.
-Jack
PS, I really need to set some time aside to work with radzilla and play with all the features you implemented!
Carsten Bauer wrote:
Hi Jack,
yes, the number of materials in the ambient exclude/include list ist currently limited to 128.
if you want to augment it (at compile time) change
1) in rpict.c the declaration char* amblist[128]
2) to be on the safe side
in ambient.c : augment the #define MAXASET 5113) also to be on the safe side
in wordfile.c (src/common) augment the #define MAXFLEN 8192steps 2 and 3 are probably not necessary, the business is a bit weird because the hierachyless input format allows the occurence of several material instances with the same name, but different object number (that's why the MAXASET (511) is greater than the name list maximum (128))
as usual, I don't give any guarantee if this is enough or right or if I've still forgotten something ...and AFAIK you can only specify one exclude file, 'cause there's only one list internally which is checked
-cb
PS it's funy, in fact I've already waited for something like this to happen, i.e. someone running against this border
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack
again, the following holds as far as I understood it ..
The matter is this: you can write e.g.
void plastic blue
0
0 ..blablabla
blue sphere b_sphere
0
4 ...
void plastic blue
0
...
blue polygon b_polygon
0
..
then the sphere will be made of the first blue, the polygon out of the second. You have only one time the name blue, but two material objects which are affected if 'blue' is to be excluded.
Now no one would do this in the way I described it, but think of putting together a scene by xforming several inputfiles together. A typical case are luminaire description files, usually you have a 'brightdata', a brightdata-modified 'light', and then the geometry, say a 'ring' or a 'polygon'. If you model a 10 times 10 array of these luminaires on a ceiling, and xform luminaire.rad a hundred times into your scene, you will have 100 instances of the 'brightdata' and the 'light' material also, i.e. a hundred 'light' material objects with the same name.
So the amount by which MAXASET needs to be bigger than the name list is in fact not determined, but depends upon how often the same material name appears in your input files. And the MAXFLEN sets the file size for the exclude list, and thus depend a bit on your names (there is another limit, a name string can be maximal 128 characters long, so the current MAXFLEN allows e.g 64 128-character long words
(who names materials with 128 character words ???) .
In other words, if you specify a material name only once in your scene input, you needn't bother about MAXASET and MAXFLEN, only augment the amblist length.
Yes, it would be easier if this max. list length could be set by one define somewhere. But I guess the topic simply was considered of minor importance, as in 99.99% of all cases maybe one or two materials are excluded. The weird thing about all this is that this minor detail causes some headache on the programming side...
The downside from a longer list is probably negligible. You have to search a longer list on input. The number of name occurences in the input files determine the list which is checked during rendering, so if you 'pro forma' exclude a material which doesn't appear in your scene anyway, you won't notice it at all.
-cb
Hi Carsten,
Sorry to be dense-headed here.
1. amblist[128] - is this the number of names possible in the list?
2. MAXASET - the comments indicate this is the maximum number of
elements in the ambient set, what does this mean? Is a scene
limited to 511 names of materials assigned directly to geometry?
3. MAXFLEN - Does the type of compile make a difference? I have a new
opeteron system which I am compiling with -m64? I must admit I am
a bit confused about the 64 v 32 bit stuff (all I really care
about is performance!) The exclude file is well under 8K in size.
So the question still remains (mostly because I still getting my head around it), if I want to increase the number of names that can be included in the exclude list, what do I need to change?
I believe that I can add the following to the rmake file:
-DMAXASET=a_new_value -DMAXFLEN=b_new_value
I have done this for -DMAXOBJBLK=131071 at compile, so I assume this would work for the others
Can I do something similar to set amblist[] at compile rather than editing the files?
Thanks for all your help.
-Jackl
Carsten Bauer wrote:
Hi Jack
again, the following holds as far as I understood it ..
The matter is this: you can write e.g.
void plastic blue
0
0 ..blablablablue sphere b_sphere
0
4 ...void plastic blue
0
...blue polygon b_polygon
0
..then the sphere will be made of the first blue, the polygon out of the second. You have only one time the name blue, but two material objects which are affected if 'blue' is to be excluded.
Now no one would do this in the way I described it, but think of putting together a scene by xforming several inputfiles together. A typical case are luminaire description files, usually you have a 'brightdata', a brightdata-modified 'light', and then the geometry, say a 'ring' or a 'polygon'. If you model a 10 times 10 array of these luminaires on a ceiling, and xform luminaire.rad a hundred times into your scene, you will have 100 instances of the 'brightdata' and the 'light' material also, i.e. a hundred 'light' material objects with the same name.
So the amount by which MAXASET needs to be bigger than the name list is in fact not determined, but depends upon how often the same material name appears in your input files. And the MAXFLEN sets the file size for the exclude list, and thus depend a bit on your names (there is another limit, a name string can be maximal 128 characters long, so the current MAXFLEN allows e.g 64 128-character long words
(who names materials with 128 character words ???) .In other words, if you specify a material name only once in your scene input, you needn't bother about MAXASET and MAXFLEN, only augment the amblist length.
Yes, it would be easier if this max. list length could be set by one define somewhere. But I guess the topic simply was considered of minor importance, as in 99.99% of all cases maybe one or two materials are excluded. The weird thing about all this is that this minor detail causes some headache on the programming side...
The downside from a longer list is probably negligible. You have to search a longer list on input. The number of name occurences in the input files determine the list which is checked during rendering, so if you 'pro forma' exclude a material which doesn't appear in your scene anyway, you won't notice it at all.
-cb
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Carsten,
Poking around a bit more, I see that there is:
#define AMBLLEN 128 /* max. ambient list length */
in ray.h
This looks like it might be closer to what I need?
This is used to set the length of amblist in raycalls.c, why not in the other locations where amblist is used?
-Jack
Jack de Valpine wrote:
Hi Carsten,
Sorry to be dense-headed here.
1. amblist[128] - is this the number of names possible in the list?
2. MAXASET - the comments indicate this is the maximum number of
elements in the ambient set, what does this mean? Is a scene
limited to 511 names of materials assigned directly to geometry?
3. MAXFLEN - Does the type of compile make a difference? I have a
new opeteron system which I am compiling with -m64? I must admit
I am a bit confused about the 64 v 32 bit stuff (all I really
care about is performance!) The exclude file is well under 8K in
size.So the question still remains (mostly because I still getting my head around it), if I want to increase the number of names that can be included in the exclude list, what do I need to change?
I believe that I can add the following to the rmake file:
-DMAXASET=a_new_value -DMAXFLEN=b_new_value
I have done this for -DMAXOBJBLK=131071 at compile, so I assume this would work for the others
Can I do something similar to set amblist[] at compile rather than editing the files?
Thanks for all your help.
-Jackl
Carsten Bauer wrote:
Hi Jack
again, the following holds as far as I understood it ..
The matter is this: you can write e.g.
void plastic blue
0
0 ..blablablablue sphere b_sphere
0
4 ...void plastic blue
0
...blue polygon b_polygon
0
..then the sphere will be made of the first blue, the polygon out of the second. You have only one time the name blue, but two material objects which are affected if 'blue' is to be excluded.
Now no one would do this in the way I described it, but think of putting together a scene by xforming several inputfiles together. A typical case are luminaire description files, usually you have a 'brightdata', a brightdata-modified 'light', and then the geometry, say a 'ring' or a 'polygon'. If you model a 10 times 10 array of these luminaires on a ceiling, and xform luminaire.rad a hundred times into your scene, you will have 100 instances of the 'brightdata' and the 'light' material also, i.e. a hundred 'light' material objects with the same name.
So the amount by which MAXASET needs to be bigger than the name list is in fact not determined, but depends upon how often the same material name appears in your input files. And the MAXFLEN sets the file size for the exclude list, and thus depend a bit on your names (there is another limit, a name string can be maximal 128 characters long, so the current MAXFLEN allows e.g 64 128-character long words
(who names materials with 128 character words ???) .In other words, if you specify a material name only once in your scene input, you needn't bother about MAXASET and MAXFLEN, only augment the amblist length.
Yes, it would be easier if this max. list length could be set by one define somewhere. But I guess the topic simply was considered of minor importance, as in 99.99% of all cases maybe one or two materials are excluded. The weird thing about all this is that this minor detail causes some headache on the programming side...
The downside from a longer list is probably negligible. You have to search a longer list on input. The number of name occurences in the input files determine the list which is checked during rendering, so if you 'pro forma' exclude a material which doesn't appear in your scene anyway, you won't notice it at all.
-cb
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction------------------------------------------------------------------------
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack,
First, thanks to Carsten for fielding Jack's questions -- I learned a bit about my own code from your exchange. For one, I didn't realize that I hadn't used the AMBLLEN macro I defined in rt/ray.h everywhere I should have. I just increased this value from 128 to 512, allowing for override at compile time. (Before, there wasn't an enclosing #ifdef around it.) I did the same for the MAXFLEN macro. Before, it wouldn't work to add -DMAXFLEN=?? to the compile script. Now, it will. I also doubled the value from 8192 to 16384 for MAXFLEN. These changes will appear in tonight's HEAD, or can be downloaded individually through the CVS interface.
Oh -- just got your e-mail about AMBLLEN not being used consistently. Bingo.
I also increased the maximum number of excluded/included modifiers (MAXASET) to 2047. This may not be enough if you have some object you've transformed all over the place as Carsten described, so you may also want to override this in your compile, which I've enabled as well. An argument against making this too large is that the method for determining whether to exclude a surface or not from the interreflection calculation involves a binary search of this list. In other words, you pay a penalty for having a list that increases as the log(N), where N is the number of included/excluded surfaces. Since you pay this penalty every time you need an ambient value, you can in effect spend more time searching the list than you do computing interreflections. I don't know when this crossover occurs, but I imagine it would be a very large number for N.
-Greg
Hi Greg,
Thanks for the additional input and again also to Carsten to getting the conversation to this point! So just to confirm it looks like if I grab the following from CVS I will be ok:
* rtrace.c
* rview.c
* ambient.c
* ray.h
* rpict.c
Correct?
-Jack
Greg Ward wrote:
Hi Jack,
First, thanks to Carsten for fielding Jack's questions -- I learned a bit about my own code from your exchange. For one, I didn't realize that I hadn't used the AMBLLEN macro I defined in rt/ray.h everywhere I should have. I just increased this value from 128 to 512, allowing for override at compile time. (Before, there wasn't an enclosing #ifdef around it.) I did the same for the MAXFLEN macro. Before, it wouldn't work to add -DMAXFLEN=?? to the compile script. Now, it will. I also doubled the value from 8192 to 16384 for MAXFLEN. These changes will appear in tonight's HEAD, or can be downloaded individually through the CVS interface.
Oh -- just got your e-mail about AMBLLEN not being used consistently. Bingo.
I also increased the maximum number of excluded/included modifiers (MAXASET) to 2047. This may not be enough if you have some object you've transformed all over the place as Carsten described, so you may also want to override this in your compile, which I've enabled as well. An argument against making this too large is that the method for determining whether to exclude a surface or not from the interreflection calculation involves a binary search of this list. In other words, you pay a penalty for having a list that increases as the log(N), where N is the number of included/excluded surfaces. Since you pay this penalty every time you need an ambient value, you can in effect spend more time searching the list than you do computing interreflections. I don't know when this crossover occurs, but I imagine it would be a very large number for N.
-Greg
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack,
You should also pick up wordfile.c from the common directory, and that should be it.
-G
From: Jack de Valpine <[email protected]>
Date: November 5, 2004 9:57:53 AM PST
Hi Greg,
Thanks for the additional input and again also to Carsten to getting the conversation to this point! So just to confirm it looks like if I grab the following from CVS I will be ok:
• rtrace.c
• rview.c
• ambient.c
• ray.h
• rpict.c
Correct?
-Jack
P.S. A correction to my previous e-mail. I wrote:
In other words, you pay a penalty for having a list that increases as the log(N), where N is the number of included/excluded surfaces
I meant the number of included/excluded MODIFIERS, not surfaces. An important distinction for most scenes....