Hi Greg et al.,
Given an instance of an EPNODE struct defining a function, is there a way to find the name of the .cal file the function was defined in?
I’m particularly interested in doing this for EPNODEs in the MODCONT struct that stores modifiers for rcontrib, because the user might have multiple .cal files that give functions the same name but different definitions.
Thanks,
Nathaniel
Radiance avoids name collisions between same-named variables by giving each .cal file its own name space based on the file name. For example, “wood.cal” would append the context “wood” to every variable that is defined therein. So, if you examine the linked variable name, you should see the base file name context in those variables. Does this make sense?
Hi Greg,
I’m not sure I follow. For example, if I query the bin value expression “rbin” from reinhartb.cal:
MODCONT *mp;
fprintf(stderr, "%s\n", mp->binv->v.ln->name);
The result I get is:
rbin`RC.
Is `RC. a shorthand for reinhartb.cal? Or am I missing something here?
Nathaniel
What I said is true for variables defined in *.cal files loaded via Radiance primitives. The “rbin” parameter is defined on the rcontrib command line, so it gets the special name space defined by RCCONTEXT in rcmain.c, which is “RC.” Variables and functions in rayinit.cal and func.c are the only “global” names that are accessible from all contexts.
I see. So because the function is called from the command line, which could have several .cal files loaded by the -f command, all of those .cal files need to share the same namespace. Then if several of these .cal files use the same variable names, the most recently loaded one takes precedence?
I’m getting around this currently by assuming that the user provides a -f argument to rcontrib before each relevant -m argument, similar to how -p, -b, and -bn work. This seems consistent with what rfluxmtx does, but I guess there’s nothing to stop a user from putting all their -f arguments at the beginning when calling rcontrib directly.
Nathaniel
Yes, all defintions on the rcontrib command-line share the same context.
However, the later -f file arguments and -e expressions will override the earlier ones, usually with a warning if -w+ is set. It will not simply take the “most recent” definition on the command-line, since expressions are evaluated dynamically at run-time. To have different definitions for different rcontrib modifiers, you must use the -p option, and this is why I created it. It doesn’t take general expressions, only variable assignments. That way, you can have the same .cal file serve slightly different purposes by playing with -p parameters. This is how I handle left-handed coordinate systems in the various Klems and Reinhart bases for example.