mkillum useage with large scenes

Hi group,

while I have been using mkillum for a while now, I need your advice on
its application again.

I have a large scene, and so far, I had an external file containing only
the illums. So I could use the external file as mkillum's input and run
it with the (large) scene's octree:

mkillum large_scene.oct < only_illum_faces.rad > only_illum_sources.rad

than, later

oconv large_scene.rad only_ilum_sources.rad > full_scene.oct

(eh, I could have used oconv -i large_scene.oct only_illum_sources.rad >
full_scene.oct, right?)

But now I have to change the structure of my scene a bit, and it gets
difficult to keep the illums in an external file. So, given that
large_scene.oct is made of large_scene.rad, could I equally use

mkillum large_scene.oct < large_scene.rad > only_illum_sources.rad

given that I set the right -i=illummodifier at the beginning of
large_scene.rad? Will this use much more ressources? As I understand,
the only difference should be file access, as the full file will be sent
to mkillum instead of only the faces that are to be converted.

If you wonder why I do not simply try, it is because my model is build
by some scripts I have to change, and I wonder if it is worth it and
possible at least.

TIA+CU, Lars.

P.S.: Concering the link I sent, now I know that I REALLY missed what I
should have seen on the workshop :frowning:

Hi Lars,

I have a large scene, and so far, I had an external file containing only
the illums. So I could use the external file as mkillum's input and run
it with the (large) scene's octree:

mkillum large_scene.oct < only_illum_faces.rad > only_illum_sources.rad

than, later

oconv large_scene.rad only_ilum_sources.rad > full_scene.oct

(eh, I could have used oconv -i large_scene.oct only_illum_sources.rad >
full_scene.oct, right?)

(Yes.)

But now I have to change the structure of my scene a bit, and it gets
difficult to keep the illums in an external file. So, given that
large_scene.oct is made of large_scene.rad, could I equally use

mkillum large_scene.oct < large_scene.rad > only_illum_sources.rad

given that I set the right -i=illummodifier at the beginning of
large_scene.rad? Will this use much more ressources? As I understand,
the only difference should be file access, as the full file will be sent
to mkillum instead of only the faces that are to be converted.

You would have a line such as:

#@mkillum i=illummodifier

in your file. However, this would output your entire scene, only modifying the surfaces with that modifier. You could have to take the entire output of mkillum in this case as the input to your new octree. There are ways around this using the o= setting, but they're complicated.

-Greg

Hi!

Thank you for the help, mkillum is somehow still one of the radiance
secrets.

Ok, I am trying that now. I am curious about the "complicated way" using
-o settings for mkillum. Still, now I want it to work first :wink:

One question arised now. I had been filtering my scene for the
mkillum-faces' modifier, replacing it by void, and than run mkillum with
-i=void. I would prefer not to filter, but still, I need a modifier that
will actually never be used to define my mkillum-faces. Can I define an
alias to void for that? E.g. void alias mkillum_faces void? So that
before I run mkillum, these faces just are not visible, but I can still
run oconv on the scene? Or should I better use a dummy material for them
(e.g. a glass with 100% transmittance? So far I like to be able to run
rvu on the scene before using mkillum, so I prefer not to have some
thousand of these faces with a dummy modifier, but I guess that alias to
void could cause problems?

Thank You, CU Lars.

Hi Lars,

The alias type demands a valid (previously defined) identifier, and will not accept "void" in the current version.

You are introducing too many artificial constraints, such as requiring your scene files to have everything intermingled, with illum surfaces visible beforehand then invisible afterwards, etc., etc. Separating the surfaces you want to render and treat differently in separate files is by far the easiest way to go. You are making life unnecessarily difficult by bundling it all together in one stream.

-Greg

ยทยทยท

From: "Lars O. Grobe" <[email protected]>
Date: March 19, 2006 8:29:32 AM PST

Hi!

Thank you for the help, mkillum is somehow still one of the radiance
secrets.

Ok, I am trying that now. I am curious about the "complicated way" using
-o settings for mkillum. Still, now I want it to work first :wink:

One question arised now. I had been filtering my scene for the
mkillum-faces' modifier, replacing it by void, and than run mkillum with
-i=void. I would prefer not to filter, but still, I need a modifier that
will actually never be used to define my mkillum-faces. Can I define an
alias to void for that? E.g. void alias mkillum_faces void? So that
before I run mkillum, these faces just are not visible, but I can still
run oconv on the scene? Or should I better use a dummy material for them
(e.g. a glass with 100% transmittance? So far I like to be able to run
rvu on the scene before using mkillum, so I prefer not to have some
thousand of these faces with a dummy modifier, but I guess that alias to
void could cause problems?

Thank You, CU Lars.