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

Patrick Elliott wrote:

> 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.)
> 
> 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. 

So, what you really want is a "thick" triangle. By this I mean a triangle
that creates a second layer on the fly possibly without needing additional
memory. Special variants could be created where the main triangle has the
solid texture and the other sides of your prism are clear. Such a thick
triangle would do what you want.

I'm not sure whether this would really be much faster and produce satisfying
results. But you're right that it's achievable.

Post a reply to this message

On Fri, 05 Apr 2002 10:22:16 +0200, Thomas Willhalm <wil### [at] fmiuni-konstanzde>
wrote:
> So, what you really want is a "thick" triangle. By this I mean a triangle
> that creates a second layer on the fly possibly without needing additional
> memory. Special variants could be created where the main triangle has the
> solid texture and the other sides of your prism are clear. Such a thick
> triangle would do what you want.
> 
> I'm not sure whether this would really be much faster and produce satisfying
> results. But you're right that it's achievable.
> 

Yeah that may work.. Not sure if it is actually what the developers of the method did.
I think they
upon consideration that they simply simluted the light passing through an outer
surface, reflecting
off something on the inside, then exiting at some unexpected point as a result of
bending, etc. that
occures between the real and faked surfaces.

So your interpretation is a bit more like what I thought than perhaps the original
since you can
declare a surface, scattering and subsurface layers, while the original may assume
that no such
second layer exists. It would still be better than what is now possible, but realism
would be
improved on say human models by adding a second layer capable of showing details like
veins,
etc. I don't believe I saw any indication that this was allowed. But I don't really
have a real clear
understanding of the math involded so didn't pay that close attention to how/if it
could be used in
such a way.

As to if it is faster... Only trying it would tell. However, it has to be at least a
little easier to understand
for those of us who look at media and go, 'Huh!?!'. lol And if it was also faster then
it would make life
a lot easier for everyone where it is applicable.

Post a reply to this message