 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-10-2013 10:22, MichaelJF wrote:
> Thomas de Groot <tho### [at] degroot org> wrote:
>> It might be interesting to experiment with Rune Johansen's Electric and
>> Particle macros. I have had not time to delve deeper in them but -
>> especially - the Electric macro may have some promises for simulating
>> lightning.
>>
>> Note: Rune's site seems to be down at the moment.
>>
>> Thomas
>
> Hi Thomas,
>
> yes, it seems that Rune's site is down. But I have downloaded the electric macro
> just in time some weeks ago. The problem with it is, that it's MegaPov-code and
> one has to convert "glow" to 3.7.
>
> Best regards,
> Michael
>
Not in the version I have. The 'glow' code is commented out and replaced
by Reactor's media. In the demo scene files I just replaced the #version
and all work correctly.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe /I/ adapted the code some time ago, I don't remember. Here is the
electric macro working under version 3.7:
// ELECTRICITY INCLUDE FILE for POV-Ray 3.1
// ****************************************
// Copyright 2001 Rune S. Johansen
//#version unofficial MegaPov 1.1;
// The output is a point that moves from PointA to PointB
// as Value goes from 0.0 to 1.0
#macro LinearPath (PointA,PointB,Value)
(PointA*(1-Value)+PointB*Value)
#end
// The output is a color vector that changes from ColorA to Color B
// as Value goes from 0.0 to 1.0
#macro LinearColor (ColorA,ColorB,Value)
(
vnormalize( ColorA*(1-Value) + ColorB*Value )
*( vlength(ColorA)*(1-Value) + vlength(ColorB)*Value )
)
#end
// This is the Electric macro. It calls the internal _Electric macro
// specified further down.
#macro
Electric(Brightness,Thickness,Fuzzyness,RollSpeed,FlickerSpeed,MinDist)
_Electric(0,1,ElectricPath(0),ElectricPath(1),1,-((ElectricPath(0))+(ElectricPath(1)))*100)
#end
// This macro is used internally only.
// The user do not need to call this macro.
#macro _Electric(ValueA,ValueB,PointA,PointB,Level,Offset)
#local ValueM = (ValueA+ValueB)/2;
#local FlickerClock =
int((clock*FlickerSpeed+vturbulence(0,0,0,Offset+FlickerSpeed*z*clock).y));
#local Turbulence =
vturbulence(0,0,0,Offset-<100*FlickerClock,RollSpeed*clock,0>);
#local PointM = (
(PointA+PointB)/2
+(ElectricPath(ValueM))-((ElectricPath(ValueA))+(ElectricPath(ValueB)))/2
+Turbulence*vlength(PointA-PointB)*Fuzzyness
);
//glow is obsolete in recent versions (3.6+). Replaced by the
following code (Reactor, April 2010 in povray.newusers):
//glow {location PointM type 0 color
ElectricColor(ValueM)*Brightness #if(Thickness>0) radius Thickness #end}
//start new code:
sphere {
<0,0,0>, 1
pigment { color rgbt 1 }
interior {
#local M_samples = 15;
#local M_variance = 1/500;
media {
//intervals 1 //default
samples M_samples
//confidence 1 - M_variance //obsolete
//variance m_variance //obsolete
emission color rgb 1
//method 3 //default
//aa_threshold 0.1 //default
//aa_level 4 //default
//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 ]
//or this? (Alain)
[0.80 color rgb
ElectricColor(ValueM)*Brightness/Thickness ]
[0.90 color rgb <1,1,1>*Brightness/Thickness ]
[1.00 color rgb <1,1,1>*Brightness/Thickness ]
}
}
}
}
hollow
#if(Thickness>0) scale Thickness #else scale 0.50 #end
translate PointM
}
//end new code
#if (vlength(PointA-PointM)>MinDist)
_Electric(ValueA,ValueM,PointA,PointM,Level+1,Offset+pow(3,Level)*x) #end
#if (vlength(PointB-PointM)>MinDist)
_Electric(ValueB,ValueM,PointB,PointM,Level+1,Offset+pow(3,Level)*y) #end
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Maybe /I/ adapted the code some time ago, I don't remember. Here is the
> electric macro working under version 3.7:
>
I would assume this. My download was at the 25. September and the files
contained in the archive are dating from 13. May 2005. With Reactor's media I
got the sample scenes running now too. IIRC the examples at Rune's site looked a
bit better then the images I achieve now.
Meanwhile I have downloaded two of the papers cited by the one mentioned above.
Both a bit older (1984 and 1995), but shedding more light to the issue without
the necessity to understand the physical background. Seems, I have overlooked
the first yesterday.
Many thanks,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-10-2013 15:03, MichaelJF wrote:
> I would assume this. My download was at the 25. September and the files
> contained in the archive are dating from 13. May 2005. With Reactor's media I
> got the sample scenes running now too. IIRC the examples at Rune's site looked a
> bit better then the images I achieve now.
>
> Meanwhile I have downloaded two of the papers cited by the one mentioned above.
> Both a bit older (1984 and 1995), but shedding more light to the issue without
> the necessity to understand the physical background. Seems, I have overlooked
> the first yesterday.
>
I am curious to see what you can achieve. I have not tested Rune's code
in a lightning setting. Maybe it is not good for that. If time allows, I
shall have a few experiments.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
>
>
> I am curious to see what you can achieve. I have not tested Rune's code
> in a lightning setting. Maybe it is not good for that. If time allows, I
> shall have a few experiments.
>
> Thomas
May be I will use them as a comparison later. First I will test the other
approach. If you will try the sample files be sure to add assumed_gamma 1 to the
scene. Without I saw nearly nothing.
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is a possible problem if the variable Thickness is set to zero.
Here a slightly revised code to take care of that possiblility:
> Maybe /I/ adapted the code some time ago, I don't remember. Here is the
> electric macro working under version 3.7:
>
media {
samples M_samples
emission color rgb 1
density {
spherical
poly_wave 1.5
color_map{
[0.00 color rgb 0 ]
#ifdef(Thickness)
#if(Thickness = 0) // To be used with Thickness = 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 ]
//or this? (Alain)
#else // To be used whenever Thickness have been set to a
non-zero value
[0.80 color rgb
ElectricColor(ValueM)*Brightness/Thickness ]
[0.90 color rgb <1,1,1>*Brightness/Thickness ]
[1.00 color rgb <1,1,1>*Brightness/Thickness ]
#end
#else // Fallback if Thickness was not defined
[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 ]
#end
}
}
}
}
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20-10-2013 1:46, Alain wrote:
>
> There is a possible problem if the variable Thickness is set to zero.
> Here a slightly revised code to take care of that possiblility:
>
Yes, I had not gone that far. In fact, the ifdef(Thickness) test in
#macro _Electric() is not necessary as Thickness must always be defined
in the enveloping #macro Electric().
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MichaelJF" <mi-### [at] t-onlinede> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> >
> >
> > I am curious to see what you can achieve. I have not tested Rune's code
> > in a lightning setting. Maybe it is not good for that. If time allows, I
> > shall have a few experiments.
> >
> > Thomas
>
> May be I will use them as a comparison later. First I will test the other
> approach. If you will try the sample files be sure to add assumed_gamma 1 to the
> scene. Without I saw nearly nothing.
>
> Michael
Meanwhile I have implemented the first stage to construct a "leading" bolt (in
2D). The approach is very slow but first results looked promising. But now I
have to find a work around to compensate for the very high epsilon POV uses.
With a 64bit machine 1.69851e-013 is not zero, but POV treats it so. POV-eps
seems to be somewhere at 1.0e-5 or 1.0e-6 which is unacceptable completely
nowadays. I and others have experienced problems with this historical setting in
the past. Most likely one only has to change a constant within a header file but
no one dares to do so. And the problem is known...
Sorry, I'm a little bit frustrated having lost a days work due to this issue.
Take it serious but not too serious ;-) May be there more dependencies I cannot
judge.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "MichaelJF" <mi-### [at] t-onlinede> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>
>>>
>>> I am curious to see what you can achieve. I have not tested Rune's code
>>> in a lightning setting. Maybe it is not good for that. If time allows, I
>>> shall have a few experiments.
>>>
>>> Thomas
>>
>> May be I will use them as a comparison later. First I will test the other
>> approach. If you will try the sample files be sure to add assumed_gamma 1 to the
>> scene. Without I saw nearly nothing.
>>
>> Michael
>
> Meanwhile I have implemented the first stage to construct a "leading" bolt (in
> 2D). The approach is very slow but first results looked promising. But now I
> have to find a work around to compensate for the very high epsilon POV uses.
> With a 64bit machine 1.69851e-013 is not zero, but POV treats it so. POV-eps
> seems to be somewhere at 1.0e-5 or 1.0e-6 which is unacceptable completely
> nowadays. I and others have experienced problems with this historical setting in
> the past. Most likely one only has to change a constant within a header file but
> no one dares to do so. And the problem is known...
>
> Sorry, I'm a little bit frustrated having lost a days work due to this issue.
> Take it serious but not too serious ;-) May be there more dependencies I cannot
> judge.
>
> Best regards,
> Michael
>
>
The epsilon value for 32 and 64 bits CPUs is the same as both have 64
bits FPUs.
The epsilon value used by POV-Ray is larger due to some conciderations,
like the need to raise some values to the third power in several places,
and some times even more, 1e-6^ 3 = 1e-18...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotronca> wrote:
>
> The epsilon value used by POV-Ray is larger due to some conciderations,
> like the need to raise some values to the third power in several places,
> and some times even more, 1e-6^ 3 = 1e-18...
Thanks for the explanation, I feared for that. Meanwhile I remedied my issue
with additional storage and premultiplying all values concerned a little bit. As
far as I can judge so far, this approach can yield a fine result in 2D with POV
but one needs a lot of patience since only a brute force algorithm can be
implemented with POV. In 3D one will need a compiler and pointer structures to
overcome the space and time requirements.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
