|
![](/i/fill.gif) |
> Alain<aze### [at] qwerty org> wrote:
>
>> The glow did not cast light. If you want the spark to cast light, you
>> have two options:
>> 1 - Add several relatively faint light_source at the center of the
>> various medias. All of those light_source also need fade_distance
>> Thickness+0.01 fade_power 2. An intensity of
>> ElectricColor(ValueM)*Brightness is a reasonable starting point but may
>> be to strong as you can have over 100 lights.
>> 2 - Use radiosity with "media on" to enable the media to cast light.
>>
>> Both options will increase the rendering time.
>
> I wanted to stay away from the light_sources method, because I know it can cause
> a substantial increase in render times. What I was thinking of doing is using
> radiosity with spheres or short cylinders that are invisible (using the
> no_image, no_reflection, and no_shadow keywords).
>
> Are you sure merge will be faster? I haven't tested it with this, but in the
> past it is usually slower than a union or not combining the objects. Of course,
> since the difference in render times wasn't very large, merge is a very good
> option for avoiding the max_trace issue.
>
> -Reactor
>
>
Usualy, with opaque objects, a merge is slower than an union. That's
caused by the bounding. With an union, all component are bounded
separetly. With a merge, the various objects can't be bounded that way,
you get a single bounding box for the whole merge.
BUT, when you have many transparent objects, even if they are totaly
transparent, you have to compute every surfaces that the rays encounter.
With an union, every surfaces that are inside the compound object are
still there and have to be computed. Then, if you encounter to many
surfaces, you may not even be able to exit the object and can get black
spots.
With a merge, those surfaces are removed, and you no longer have to
evaluate them. You also don't need to increase max_trace_level as much.
Alain
Post a reply to this message
|
![](/i/fill.gif) |