 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
some days ago we discussed a lightning issue at one of Thomas entries here
(Aftermath revisited). He used an older code by Tom Melly to create the
lightning bolt. I didn't state it explicitelly, but I wasn't really convinced by
Tom Melly's work. The bolts are very angular, forking at to high angles and the
surrounding has not the emission real bolts have. Than I found a scientific
paper about this isuue:
http://scholar.google.de/scholar_url?hl=de&q=http://luaav.mat.ucsb.edu/Publications/tkim_lightning_tvcg_2007.pdf&sa=X&s
cisig=AAGBfm3PHvzJ93M1S5RpGGVWPezcycGhkw&oi=scholarr&ei=UVhhUpDJEuPS0QWTl4Fo&ved=0CC0QgAMoADAA
If you look at their final figure 15, they state that their result (to the left)
is rendered with POV. They give a source and a windows binary for 2-dimensional
lightning-objects (as far as I understand it). The main part of the paper deals
with implemtation issues one cannot achieve with POV since we have no pointer
structures. But has someone of you an idea what they are doing within their
section 4? May be one can go the hard way nowadays. Most likely it is to trivial
to them to explain details about the Lagrange equation and their solution
(especially in 3-Space). Their only references are to generall equation solvers.
What I would like to know is, what do I have to calculate for every adjacent
cell in detail. I can solve linear systems, but what?
(I admit, I have avoided lessons about differential equations during my
studies).
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-10-2013 10:22, MichaelJF wrote:
> Thomas de Groot <tho### [at] degrootorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
