 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnet dk> wrote:
> The very concept of ray-tracing is just a faked version of how nature works.
> However, it looks nice, so we don't care. The result is what counts.
> Likewise with lens-flares. If they look like lens flares, then they *are*
> lens flares. I don't see why you define one faked method as being real nut
> another as not being real.
There's a difference.
Lighting is based (more or less) in a physical model (eg. the usage of the
cosine as the falloff function for lighting comes from physics). The concept
and implementation of IOR is based on the physical model (the same math
applies). Photon mapping is based in a physical model.
However, faking lens flares with colored discs is in no way based on any
physical model, nor any math from physics is used to make them. They are
just put "somewhere where they look good", without being based on anything.
> You said the word yourself: "simulate". If it's just a simulation, it's not
> real (or "true").
Simulation means (usually numerical) approximation. Since we can't have
infinite accuracy, things have to be approximated and simulated.
However, whether this simulation is based on physical mathematics or
if it's just something "which looks good" but is not based on anything,
makes a big difference.
POV-Ray does not support simulating lens flares. There's no math in POV-Ray
to calculate them. Period.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> POV-Ray does not support simulating lens flares.
> There's no math in POV-Ray to calculate them. Period.
The only one talking about POV-Ray supporting simulating lens flares is you.
Neither Apache nor I used the words "support" or "simulating". I'm simply
saying that you can indeed "make" lens flares in POV-Ray, just like you can
make clouds, fire, bricks, human characters and all other kind of things,
even though they're not "supported" in POV-Ray and can't be "simulated".
If you disagree, feel free to contact Chris Colefax and ask him to rename
his Lens Flare Include File to "Colored Disc Placed In Front Of Camera
Include File". See if he cares.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
IIRC, Chris Huff said (in this very group) that Post Processing wasn't going to be
included just because it wasn't ready yet.
I never heard about Post Processing being dropped out for principled reasons.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Andrew Cocker" wrote:
>
>Also, am I correct in thinking that there is room for improvement
> still in the radiosity solving section of POV-Ray.. I think I read it
> somewhere on these newsgroups.. although maybe that will have to wait until
> POV-Ray 4.
Rumors say there must be some bug in the current implementation causing radiosity
artefacts even with damn high settings. AFAIK nobody figured it out.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Apr 2002 22:53:38 +0200, "JRG" <jrg### [at] hotmailcom> wrote:
> Rumors say there must be some bug in the current implementation causing radiosity
> artefacts even with damn high settings. AFAIK nobody figured it out.
What is 'current implementation' in your post ?
current official version is 3.1
current version considering current group is MegaPOV 0.7
current developing version is 3.5 beta 15
In fact currently I render 1000 frames long animation completly with radiosity.
Parts are rendered separately and on different machines. After 200 frames I
don't see any flickering or artefacts. I use "rad_def.inc" from standard distro
with Radiosity_IndoorLQ
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On Wed, 3 Apr 2002 22:53:38 +0200, "JRG" <jrg### [at] hotmailcom> wrote:
> > Rumors say there must be some bug in the current implementation causing radiosity
> > artefacts even with damn high settings. AFAIK nobody figured it out.
>
> What is 'current implementation' in your post ?
> current official version is 3.1
> current version considering current group is MegaPOV 0.7
> current developing version is 3.5 beta 15
>
> In fact currently I render 1000 frames long animation completly with radiosity.
> Parts are rendered separately and on different machines. After 200 frames I
> don't see any flickering or artefacts. I use "rad_def.inc" from standard distro
> with Radiosity_IndoorLQ
I forgot the word 'sometimes'.
BTW, there's no difference between POV 3.5's and MegaPOV's implementation. IIRC
Nathan was pretty clear about it.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:r2rmaus78utvlksqllk96h7dg4gioi56v3@4ax.com...
> What is 'current implementation' in your post ?
> current official version is 3.1
> current version considering current group is MegaPOV 0.7
> current developing version is 3.5 beta 15
>
> In fact currently I render 1000 frames long animation completly with
radiosity.
> Parts are rendered separately and on different machines. After 200 frames
I
> don't see any flickering or artefacts. I use "rad_def.inc" from standard
distro
> with Radiosity_IndoorLQ
Depending on the scene, it's sometimes impossible to get rid of artifacts
completely. Flat expanses of light colour are the usual problem I have
found. On the other hand, I too have used radiosity in animations with no
problems whatsoever.
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Apr 2002 16:45:02 +0200, Thomas Willhalm <wil### [at] fmiuni-konstanzde>
wrote:
> Patrick Elliott wrote:
> >
> > Yeah to subsurface scattering! You can use media, but if you specifically
> > want to use a thin, single layer mesh that has no 'interior', media won't
> > work.
>
> Where should your subsurface scattering stop if you have only a single
> layer? The clou with subsurface scattering is that there happens something
> to your light _below_the_surface_, right? So there has to be a notion of
> "inside" and "outside". That's why you need an object with well defined
> inside and outside to get this thing working. The "inside" modifies the
> light. That's what "media" does. So, using "media" for subsurface scattering
> is natural. (However, "media" should be extended to support other scattering
> functions.)
>
> A "thin" mesh doesn't make much sense for subsurface scattering. In
> particular, if the mesh is infinitely thin. Then you don't have an
> "inside" at all!
>
Yes well... On the scale of a large object the thickness of the actual portion
of the surface that is A) visible and B) contributes to the scattering is very small,
it
makes no practical sense under such circumstances to fill the entire object with
media. This is especially true if you wanted to use a solid texture 'under' the
surface.
If the thickness of the scattering layer is 1/1000th of the objects total width it is
not practical to make it into a solid mesh with a clear interior. As it is for a
complex
object that did this you would need to place two copies of the mesh, one scaled
slightly smaller and mapped with the main texture, while the other contained the
media. Why double the memory used and use media which is much slower than
a simple simulation that can be applied to a single surface? Never mind the fact that
some shapes may make such scaling complicated or impossible. There are many
situations in which media is absolutely neccessary, but in this case it may be much
slower and more complicated than subsurface scattering really needs to be.
Not everyone that would like to use subsurface scattering can afford the hardware,
time or memory needed to do it the 'right' way. I doubt that someone on a time limit
cares if it is done right, as long as it looks right. A simpler, faster and 'close
enough'
solution would be very helpful. As it is short of coding a patch yourself there really
is
no viable alternative to doing it using media. And I suspect that many of those who
use POV, including myself, are not well equipped to create such a patch.
The arguement seems to be that it can already be done and that the existing method
does it right. I am sure that if we had fast enough computers we could also use real
simulations of tree growth, crystal growth or even molecular structures to 'correctly'
generate the patterns, IOR and color of everything in POV, but is it practical to use
such things even if they are implimented? I would say no. In this case we are asking
for an alternate, and in most cases in which it is likely to be used, far more
practical
alternative. Why is this a bad thing?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JRG <jrg### [at] hotmailcom> wrote:
> BTW, there's no difference between POV 3.5's and MegaPOV's implementation. IIRC
> Nathan was pretty clear about it.
Yet they produce different images (or at least my early test with the
alpha versions showed this).
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3cab68ab@news.povray.org>, "JRG" <jrg### [at] hotmailcom>
wrote:
> IIRC, Chris Huff said (in this very group) that Post Processing wasn't going
> to be included just because it wasn't ready yet.
Well, if you look at it, there is obviously a lot of work to be done.
Many filters work using pixels as a unit of distance, so they have to be
adjusted for a specific resolution, some of the filters are incomplete
or could be redesigned, the whole processing mechanism could be made
more flexible.
> I never heard about Post Processing being dropped out for principled reasons.
Frankly, it sounds silly. Built-in filters can have access to
information that would be extremely difficult to get to an external
program, such as the actual objects in the scene, and which would be
useless anyway for most image editing programs. Separating them out
would limit their flexibility and needlessly make them more difficult to
use.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
