 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm trying to create the disturbance to the atmosphere as a meteor
passes through it. Kind of like ripples in the air, that sort of thing. Is
there any way in Pov or MegPov to do this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kane wrote:
>
> I'm trying to create the disturbance to the atmosphere as a meteor
> passes through it. Kind of like ripples in the air, that sort of thing. Is
> there any way in Pov or MegPov to do this?
You probably mean the effect caused by varying IOR of the air. This is not
possible in POV, Mega or regular.
You can simulate it with a (large) number of transparent objects with different
IORs, representing the varying density layers of air. But I don't really
recommend it unless you have a Cray and a LONG vacation ahead of you.
--
Margus Ramst
Personal e-mail: mar### [at] peak eduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kane wrote:
> I'm trying to create the disturbance to the atmosphere as a meteor
> passes through it. Kind of like ripples in the air, that sort of thing. Is
> there any way in Pov or MegPov to do this?
Possibly an isosurface with transparency and ior could do this, but it
wouldn't be very easy.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wouldn't the isosurface give sharp edges?
Gilles Tran wrote:
> kane wrote:
>
> > I'm trying to create the disturbance to the atmosphere as a meteor
> > passes through it. Kind of like ripples in the air, that sort of thing. Is
> > there any way in Pov or MegPov to do this?
>
> Possibly an isosurface with transparency and ior could do this, but it
> wouldn't be very easy.
> G.
--
Samuel Benge
E-Mail: STB### [at] aolcom
Visit my isosurface tutorial at http://members.aol.com/stbenge
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it SamuelT who wrote:
>Gilles Tran wrote:
>
>> kane wrote:
>>
>> > I'm trying to create the disturbance to the atmosphere as a meteor
>> > passes through it. Kind of like ripples in the air, that sort of thing. Is
>> > there any way in Pov or MegPov to do this?
>>
>> Possibly an isosurface with transparency and ior could do this, but it
>> wouldn't be very easy.
>> G.
>
>Wouldn't the isosurface give sharp edges?
The shockwaves produced by a meteor travelling at hypersonic velocity
will actually have sharp edges, so that shouldn't be a problem.
A bigger problem is that very few people (if any) have ever observed
atmospheric disturbances caused by meteors, so it's going to be hard to
check whether the rendering is remotely realistic. None of the meteors
that I've seen have caused any observable atmospheric disturbances.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've given this some thought and I suggest using a normal in the camera
statement, with a pattern like ripples being oriented in relation to
where the meteor path line of sight is at. Might take a normal map of
some ingenious design to accomplish.
Well, maybe not ingenious, however here's something I tried just now.
Bob
/* example of creating shockwave in air (no vapor) */
global_settings {
number_of_waves 0
}
#declare Amplitude=0.333; // amount of shockwave effect
#declare Frequency=6; // number of peaks and troughs
#declare xSize=0.5; // lengthwise curvature (or size)
#declare zSize=0.25; // crosswise curvature (more curve when less than
xSize)
#declare xPos=-2; // move ripples off-center
#declare Width=0.45; // pie-slice region of air displacement (<1.0 but
>0.5)
#declare EntryAngle=-30; // angle of attack
#declare Placement=<0.25,-0.075,0>; // offset from center, small values
of x and y (no z)
#declare N0=normal {ripples 0} // dummy normal
#declare N1=normal {ripples Amplitude frequency Frequency scale
<xSize,1,zSize> translate xPos*x}
camera {
location 0
look_at 1*z
normal {radial normal_map {
[Width N0][0.5 N1][1-Width N0]
} ramp_wave rotate 90*x
rotate EntryAngle*z translate Placement}
}
light_source {<10,10,-10>, 1}
sphere {0,1
pigment {gradient y color_map {
[0 color rgb <.9,.6,.3>]
[.1 color rgb <.6,.3,.6>]
[.3 color rgb <.4,.6,.8>]
[.6 color rgb <.2,.4,.6>]
}}
finish {ambient .5}
scale 1000
}
// meteor (test object: note that this really messes up if shockwave is
intense)
cone {-x,1,0,.1 scale <100,10,10>
pigment {granite color_map {
[0 color rgb <.9,.8,.7>]
[1 color rgb <.7,.6,.4>]
}}
finish {ambient .75}
rotate EntryAngle*z translate <25,-5,100> // placing this is only a
guess
no_shadow
}
"kane" <ann### [at] mindspringcom> wrote in message
news:392b3ffd@news.povray.org...
| I'm trying to create the disturbance to the atmosphere as a meteor
| passes through it. Kind of like ripples in the air, that sort of
thing. Is
| there any way in Pov or MegPov to do this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mike Williams" <mik### [at] nospamplease> wrote in message
news:JOt### [at] econymdemoncouk...
> A bigger problem is that very few people (if any) have ever observed
> atmospheric disturbances caused by meteors, so it's going to be hard to
> check whether the rendering is remotely realistic. None of the meteors
> that I've seen have caused any observable atmospheric disturbances.
It seems to me that you would have to be pretty darn close to the meteor to
actually see the shockwave, and if you were that close, your ability to see
it would still depend on several other factors: 1) Light; 2) Atmospheric
conditions; 3) The limits of human field-of-vision in tracking, at close
range, an object moving at supersonic speed; 4) The natural tendency to
duck.
I do have an mpeg of a condensation ring forming around a jet as it attains
the speed of sound. It is, of necessity, short.
--
simon.A
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SamuelT wrote:
> Wouldn't the isosurface give sharp edges?
>
I was thinking of an isosurface with very thin edges (with no ripples) and a thick
center (with the ripples). No, I don't have the equation...
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, it could be done, but it would have to face the camera, probably. Hmm.....
Gilles Tran wrote:
> SamuelT wrote:
>
> > Wouldn't the isosurface give sharp edges?
> >
>
> I was thinking of an isosurface with very thin edges (with no ripples) and a thick
> center (with the ripples). No, I don't have the equation...
> G.
--
Samuel Benge
E-Mail: STB### [at] aolcom
Visit my isosurface tutorial at http://members.aol.com/stbenge
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kane wrote:
> I'm trying to create the disturbance to the atmosphere as a meteor
> passes through it. Kind of like ripples in the air, that sort of thing. Is
> there any way in Pov or MegPov to do this?
My ParticlePatch, which I just released (see p.u.p/p.p) may be able to help
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I tried it, and it worked. The fully-transparent isosurface bent light to greater
degrees towards it's middle. Problem was the edges of the isosurface showed a bit. I
couldn't get rid of the refracted dark lines of the isosurface container. Still, it
rendered in good time (compared to multiple objects of varying degrees of refraction).
Gilles Tran wrote:
> SamuelT wrote:
>
> > Wouldn't the isosurface give sharp edges?
> >
>
> I was thinking of an isosurface with very thin edges (with no ripples) and a thick
> center (with the ripples). No, I don't have the equation...
> G.
--
Samuel Benge
E-Mail: STB### [at] aolcom
Visit my isosurface tutorial at http://members.aol.com/stbenge
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote in message ...
>Wasn't it SamuelT who wrote:
>The shockwaves produced by a meteor travelling at hypersonic velocity
>will actually have sharp edges, so that shouldn't be a problem.
>
>A bigger problem is that very few people (if any) have ever observed
>atmospheric disturbances caused by meteors, so it's going to be hard to
>check whether the rendering is remotely realistic. None of the meteors
>that I've seen have caused any observable atmospheric disturbances.
>
What about the comet that hit Jupiter a few years ago. I remrember some nice
pics (obviously not close up )
Gail
********************************************************************
* gsh### [at] monotixcoza * Reality.dat not found *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2 *
********************************************************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's my idea on it again. Squeezed in a place for the meteor/asteroid trail. And I
noticed a small mistake before anyhow.
/* example of creating shockwave in air (faked refractive type thing only).
Just a simple way, nothing much mathematical here ;-) */
global_settings {
number_of_waves 0
}
#declare Amplitude=0.1; // amount of shockwave effect
#declare Frequency=6; // number of peaks and troughs
#declare xSize=0.5; // lengthwise curvature (or size)
#declare zSize=0.25; // crosswise curvature (more curve when less than xSize)
#declare xPos=-2; // move ripples off-center
#declare Width=0.333; // pie-slice region of air displacement (<0.475 and >=0)
#declare EntryAngle=-30; // angle of attack
#declare Placement=<0.25,0.025,0>; // offset from center, small values of x and y (no
z)
#declare N0=normal {ripples 0} // dummy normal
#declare N1=normal {ripples Amplitude frequency Frequency scale <xSize,1,zSize>
translate xPos*x}
camera {
location -z
look_at +z
normal {radial normal_map {
[Width N0][0.45 N1][0.495 N0][0.505 N0][0.55 N1][1-Width N0]
} ramp_wave rotate 90*x
rotate EntryAngle*z translate Placement}
}
// test for center of normal in camera
// sphere {<0.25,-0.075,0>,.05 pigment {color green 1} finish {ambient 1}}
light_source {<-9,90,-900>, <.5,.4,.3>}
// sky
sphere {0,1
pigment {gradient y color_map {
[0 color rgb <.9,.6,.3>]
[.1 color rgb <.7,.3,.4>]
[.3 color rgb <.3,.6,.8>]
[.6 color rgb <.2,.4,.6>]
}}
finish {ambient .5}
scale 1000
}
// ground
plane {y,-5
pigment {spotted color_map {
[0 color rgb <.5,.9,.6>]
[1 color rgb <.6,.7,.3>]
} scale 5}
finish {ambient .25 diffuse .7 phong .2 phong_size 20}
}
// meteor (test object: note that this really messes up if shockwave is intense)
union {
light_source {.1*x, <.99,.67,.33>*1.5}
sphere {0,.4 scale <15,10,10>}
cone {-x,1.1,0,.1 scale <111,10,10>}
pigment {granite color_map {
[0 color rgb <1.2,.9,.5>*1.5]
[1 color rgb <.9,.4,.1>]
} scale 15}
finish {ambient .85 metallic brilliance 3}
rotate EntryAngle*z
rotate 5*z translate <25,2.5,100> // only a guess here
no_shadow
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This brings to mind a good suggestion for a feature: Variable ior in media;
kind of like a ior_map. AFAIK, the ior of any object in the present versions
is constant, and in thus light won't be bent when inside an object; no
matter what media-settings exist. But if one could specify the ior along
with for example the density of the media, Povray should be able to
callulate refraction based on the current ior and the ior ahead of the
samplig ray. But this again assumes that media is sampled linarily, and that
is not trur with all types, is it?
Simen Kvaal.
kane skrev i meldingen <392b3ffd@news.povray.org>...
> I'm trying to create the disturbance to the atmosphere as a meteor
>passes through it. Kind of like ripples in the air, that sort of thing. Is
>there any way in Pov or MegPov to do this?
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
>
> This brings to mind a good suggestion for a feature: Variable ior in media;
> kind of like a ior_map.
I believe this would be possible, indeed it has been suggested before. But I
suspect it would be extremely slow, slower than scattering media, because the
calculations involved become significantly more complex.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't there a way in POV 3.0 to specify some more IOR-values for a surface
by using layered textures, because of IOR was in the finish-statement ...
In think I had read in the helpdocs that people were using it for "obscure
things" ...
Ok ... I don't think this will solve the problem in a correct way, but I
think it would have been an alternative ...
--
,', Jan Walzer \V/ http://wa.lzer.net ,',
',',' student of >|< mailto:jan### [at] lzernet ',','
' ComputerScience /A\ +49-177-7403863 '
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer wrote:
>
> Wasn't there a way in POV 3.0 to specify some more IOR-values for a surface
> by using layered textures, because of IOR was in the finish-statement ...
There was, but the result was not physically correct. The IOR only changed at
the surface, it stayed constant as the ray passed through the object's volume.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote in message <3930f206$1@news.povray.org>...
>This brings to mind a good suggestion for a feature: Variable ior in media;
>kind of like a ior_map.
See the discussions in povray.binaries.images, povray.general,
povray.programming, povray.unofficial.patches, and possibly even
povray.windows and povray.off-topic.
This has been discussed repeatedly, and the overall opinion is "Yes, it can
be done, but you really need a Cray to do it."
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So why not include it to POV ??? If the user thinks his computer is
cray-equal than he will use it... If he has no cray he should know whom's
fault it is ...
Of course, for developers it will be hard, to confirm the correctness of
this feature but why not ???
--
,', Jan Walzer \V/ http://wa.lzer.net ,',
',',' student of >|< mailto:jan### [at] lzernet ',','
' ComputerScience /A\ +49-177-7403863 '
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3932c0dd@news.povray.org>, "Jan Walzer"
<wal### [at] informatikuni-hallede> wrote:
> So why not include it to POV ??? If the user thinks his computer is
> cray-equal than he will use it... If he has no cray he should know whom's
> fault it is ...
> Of course, for developers it will be hard, to confirm the correctness of
> this feature but why not ???
It is not only processor intensive, it also would be difficult to code.
A large amount of code would need to be rewritten, and it could be hard
to get things right for overlapping objects.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > So why not include it to POV ??? If the user thinks his computer is
> > cray-equal than he will use it... If he has no cray he should know
whom's
> > fault it is ...
> > Of course, for developers it will be hard, to confirm the correctness of
> > this feature but why not ???
>
> It is not only processor intensive, it also would be difficult to code.
> A large amount of code would need to be rewritten, and it could be hard
> to get things right for overlapping objects.
I thought the media-code could be used for that, just instead of calculating
the color of the "current particle" change the direction-vector of the
traced ray ???
Quite the idea of adding a new type in the media-part, equal to emission,
absorption and scattering there could be something called
optical_density....
But I think the samplecount in media has to be increased dramatically...
Now, You are the coders ... that was just, what came into my mind ...
--
,', Jan Walzer \V/ http://wa.lzer.net ,',
',',' student of >|< mailto:jan### [at] lzernet ',','
' ComputerScience /A\ +49-177-7403863 '
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer wrote:
>
> I thought the media-code could be used for that, just instead of calculating
> the color of the "current particle" change the direction-vector of the
> traced ray ???
Well, I am no coder. But if I understand correctly how media works, the problem
is as follows:
To calculate the color of media along a particular ray, first the points are
found where the ray enters and exits the object. Between these points the ray is
divided into a specified number of intervals, and a (variable) number of samples
is taken within each interval.
This method relies upon the ray traversing the volume in a straight line, from
enter to exit. You can probably see why this wouldn't work if the ray were to
curve in an (unpredictable) manner.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Margus Ramst" <mar### [at] peakeduee> wrote in message
news:39357143.E4A3D7E7@peak.edu.ee...
| Jan Walzer wrote:
| >
| > I thought the media-code could be used for that, just instead of calculating
| > the color of the "current particle" change the direction-vector of the
| > traced ray ???
|
| Well, I am no coder. But if I understand correctly how media works, the problem
| is as follows:
| To calculate the color of media along a particular ray, first the points are
| found where the ray enters and exits the object. Between these points the ray is
| divided into a specified number of intervals, and a (variable) number of samples
| is taken within each interval.
| This method relies upon the ray traversing the volume in a straight line, from
| enter to exit. You can probably see why this wouldn't work if the ray were to
| curve in an (unpredictable) manner.
I was thinking the refractions were most probably done simply by angling the rays
according to surface geometry, so basically no curvatures of the rays themselves only
straight lines, albeit turned from original directions. Where curvature comes in,
seems
to me, would be the implementation of this whole idea about variable ior where these
lines of rays would be continously rerouted through the interiors of objects.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I thought the media-code could be used for that, just instead of
calculating
> > the color of the "current particle" change the direction-vector of the
> > traced ray ???
> Well, I am no coder. But if I understand correctly how media works, the
problem
> is as follows:
> To calculate the color of media along a particular ray, first the points
are
> found where the ray enters and exits the object. Between these points the
ray is
> divided into a specified number of intervals, and a (variable) number of
samples
> is taken within each interval.
> This method relies upon the ray traversing the volume in a straight line,
from
> enter to exit. You can probably see why this wouldn't work if the ray were
to
> curve in an (unpredictable) manner.
Yes ... I think this is the way it's working, but
<experiment>
Lets have N intervals
If we say the ray is in the 1st interval on his way. Then we find a new
opt_density value in the media. Now lets bend the ray to the new direction.
By using the new directionvector we could determine two other points, where
(our new) ray intersects. The line between these both could be split again
in N intervals and we only look on the 2nd Point there on. Now we find a new
value and so on ...
Yes, I think this could be way it could be working, but the result will
hardly depend on N. For low N and a very small scaled or high turbulenced
Media it may create rather very obscure things... Sure, the best way would
be, to integrate about the ray, but I think the idea is there, (maybe in
POV4 *g*)
</experiment>
I'll try to find the old discussion about this in my newsreader and think
about it ...
Currently I've not a real Idea of Coding in C so I can't try it on myself,
but maybe someday ...
--
,', Jan Walzer \V/ http://wa.lzer.net ,',
',',' student of >|< mailto:jan### [at] lzernet ',','
' ComputerScience /A\ +49-177-7403863 '
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer wrote:
>
> <experiment>
[snip]
> </experiment>
>
Yes, something like this has been suggested and it might work.
My point was that it would require a rewrite of the volume sampling method.
Probably a large one. If you (or anyone else) is willing to try implementing it,
I wish you nothing but the best of luck.
But personally, I think it's not worth the trouble, at least until the average
computer gets considerably faster. Currently, even scattering media has to be
used sparingly. Variable IOR _will_ be worse.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
