 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Guys,
This is my first post so go easy on me. I'm trying to create a scene with a bolt
of "energy" jumping between two points. Similar to this:
http://runevision.com/3d/include/
The link above is for an electricity.inc file which works with megapov. Despite
my best efforts I can't get megapov working properly on this machine. It
grunbles that it can't find files and when I remedy that it grumbles about code
within the include files.
Does anyone know how I might achieve this or something similar just using
POVRAY? I have a feeling this is a non-trivial question but I figure if you
don't ask then you don't get.
Thanks in advance,
Marc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi Guys,
>
> This is my first post so go easy on me. I'm trying to create a scene with a bolt
> of "energy" jumping between two points. Similar to this:
This is the newusers forum after all...
>
> http://runevision.com/3d/include/
>
> The link above is for an electricity.inc file which works with megapov. Despite
> my best efforts I can't get megapov working properly on this machine. It
> grunbles that it can't find files and when I remedy that it grumbles about code
> within the include files.
The main problem, is that electric.inc use "glow" athmospheric effect
witch is a removed feature that was replaced with media when version 3
was introduced.
The current version of megapov have been aligned to POV-Ray 3.6 and no
longer support that discontinued feature.
>
> Does anyone know how I might achieve this or something similar just using
> POVRAY? I have a feeling this is a non-trivial question but I figure if you
> don't ask then you don't get.
>
> Thanks in advance,
>
> Marc
>
>
For that, you need to use emissive media.
Define your "spark" verticaly around the origin with a cylinder of the
desired lengt.
Make that cylinder hollow and give it texture{rgbt 1} The cylinder is
now totaly invisible.
Add an interior block to it.
Fill it with emissive media.
Give the media a cylindrical pattern.
The cylindrical pattern have a value of 1 around the Y axis that falls
to zero at a radius of 1.
Then add a good amount of turbulence.
Lastly, rotate and translate the cylinder to where you want it.
Be sure that you add any rotation and translation only at the end of the
cylinder's definition. You want to affect the cylinder AND the media.
Sample:
cylinder{10*y, -10*y, 2
// the turbulence will about double the width of the pattern
pigment{rgbt 1}
hollow
interior{media{
emission 1
density{cylindrical color_map{[0.1 rgb 0][0.85 rgb<0,0,1>][1 rgb
10]}turbulence 1}
samples 30
// need a good sampling due to the turbulence
// DON't change intervals!
}
}
rotate -60*z
translate 10*z
}
This will give a white chaotic "spark" with a blue outer area that
twists a lot.
You can render that sample as it is, it use the default camera and don't
need any light.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwerty org> wrote:
> For that, you need to use emissive media.
> Define your "spark" verticaly around the origin with a cylinder of the
> desired lengt.
>
> Make that cylinder hollow and give it texture{rgbt 1} The cylinder is
> now totaly invisible.
> Add an interior block to it.
>
> Fill it with emissive media.
>
> Give the media a cylindrical pattern.
> The cylindrical pattern have a value of 1 around the Y axis that falls
> to zero at a radius of 1.
>
As it turns out, since the glows were originally spherical in shape, one may
also use a unit sphere with emission media and a spherical density pattern as a
replacement for the glow statement within the macro. This would allow you to
use it with official versions of povray, but the output may be slightly
different. I'm going to play with this a bit and see if I can get a more
correct output and I encourage you to do so also.
If you are very new to povray, note that scenes intended strictly for megapov
have the "#version unofficial" directive. If you are modifying such a scene to
work with an official version, those version directives must be changed or
removed entirely in addition to any features not supported by the official
version (in this case, the glow statement on line 39 in electric.inc).
I replaced the glow statement with the sphere below:
//-------------------
sphere{ <0,0,0>, 1 pigment{ color rgbt 1 }
interior{
#local M_samples = 15;
#local M_variance = 1/500;
media
{
intervals 1
samples M_samples
confidence 1 - M_variance
variance m_variance
emission color rgb 1
method 3
aa_threshold 0.1
aa_level 4
//jitter 0.5
density{
spherical
poly_wave 1.5
color_map{
[0.00 color rgb 0 ]
[0.80 color rgb ElectricColor(ValueM)*Brightness*2 ]
[0.90 color rgb <1,1,1>*Brightness*75 ]
[1.00 color rgb <1,1,1>*Brightness*200 ]
}
}
}
}
hollow
#if(Thickness>0) scale Thickness #else scale 0.50 #end
translate PointM
}
//-------------------
Note that this is a very quick and dirty hack job that suffers from several
problems:
*The media quality (as controlled by the samples parameter) is simply a
placeholder number - you should be able to set the sample count via the macro.
*The density statement needs work to achieve matching image output -
particularly with the Brightness values. The way media behaves when scaled
means that the Brightness value must be taken into account when the in scene
diameter (controlled by the Thickness parameter in the original macro) is very
large or very small.
*Depending on the number of objects and the view, you may have artifacts if the
max_trace_level is hit.
*The above version does not cast any light.
Almost all of those problems can be addressed, but it'll probably take me a few
days. Also, I believe Rune still posts on here occasionally, and I'm sure he'd
be interested in extending the functionality by making it compatible with
current versions.
HTH,
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks guys that's great.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I replaced the glow statement with the sphere below:
>
>
> //-------------------
> sphere{<0,0,0>, 1 pigment{ color rgbt 1 }
> interior{
> #local M_samples = 15;
> #local M_variance = 1/500;
> media
> {
> intervals 1
> samples M_samples
> confidence 1 - M_variance
> variance m_variance
> emission color rgb 1
> method 3
> aa_threshold 0.1
> aa_level 4
> //jitter 0.5
> density{
> spherical
> poly_wave 1.5
> color_map{
> [0.00 color rgb 0 ]
> [0.80 color rgb ElectricColor(ValueM)*Brightness*2 ]
> [0.90 color rgb<1,1,1>*Brightness*75 ]
> [1.00 color rgb<1,1,1>*Brightness*200 ]
> }
> }
> }
> }
>
> hollow
> #if(Thickness>0) scale Thickness #else scale 0.50 #end
> translate PointM
> }
>
> //-------------------
>
> Note that this is a very quick and dirty hack job that suffers from several
> problems:
> *The media quality (as controlled by the samples parameter) is simply a
> placeholder number - you should be able to set the sample count via the macro.
> *The density statement needs work to achieve matching image output -
> particularly with the Brightness values. The way media behaves when scaled
> means that the Brightness value must be taken into account when the in scene
> diameter (controlled by the Thickness parameter in the original macro) is very
> large or very small.
> *Depending on the number of objects and the view, you may have artifacts if the
> max_trace_level is hit.
> *The above version does not cast any light.
>
> Almost all of those problems can be addressed, but it'll probably take me a few
> days. Also, I believe Rune still posts on here occasionally, and I'm sure he'd
> be interested in extending the functionality by making it compatible with
> current versions.
>
> HTH,
> -Reactor
>
>
For the density, you can divide Brightness by Thickness. That way, the
density will change invertly to the dimention and keep the same apparent
brightness.
To prevent the max_trace_level isue, bind the whole thing in a merge.
This will remove the internal surfaces. In this case, it will also
render faster, as you are ignoring many superfluous surfaces.
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.
The following media settings are no longer needed (obsolete):
confidence, variance
The followings are all at default values and can be skipped:
intervals 1, method 3, aa_threshold 0.1, aa_level 4
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> To prevent the max_trace_level isue, bind the whole thing in a merge.
> This will remove the internal surfaces. In this case, it will also
> render faster, as you are ignoring many superfluous surfaces.
>
This looks like: merge{ Electric( 0.010, 2, 0.2, 6, 10, 0.5 )}
You can also remove the texture or pigment from the include and apply it
to the merge:
merge{ Electric( 0.010, 2, 0.2, 6, 10, 0.5 )pigment{rgbt 1}}
This will save some memory and possibly render a little bit faster.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwertyorg> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Alain<aze### [at] qwertyorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor wrote:
> I wanted to stay away from the light_sources method, because I know
> it can cause a substantial increase in render times.
It was actually this thread which triggered me to
propose the fade_cutoff_distance in p.general.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Reactor wrote:
>
> > I wanted to stay away from the light_sources method, because I know
> > it can cause a substantial increase in render times.
>
> It was actually this thread which triggered me to
> propose the fade_cutoff_distance in p.general.
Neat! Though, thinking about that, it seems more like some for of light_source
folding or combining would be a better - a very bright spark could behave more
like a small area light or a regular point light for distant objects, and more
like the full group of lights for nearby objects. Of course, at that point it
starts to touch light_group territory, but I like the idea of a light_source
having a fade_cutoff_distance and perhaps a way of defining the cutoff behavior
(another light_source definition or nothing).
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
