Christopher James Huff <chr### [at] maccom> wrote:
> That is an optimization that I've been planning on for nearly as long as 
> the proximity pattern has existed...I'm going to do a fairly complete 
> rewrite of the patch, making something that is simpler to use and 
> generally faster. I'm going to do something similar for the glow patch 
> as well...the two patches are going to be pretty closely tied together.

  You mean that, if successful, it will be possible to make objects glow?-)
(And I mean faster than using media with the proximity pattern.)
  That would be a pretty cool effect. :)

  By the way, it will probably be worth the effort to optimize the proximity
calculation for meshes. After all, meshes are so versatile and so common
(specially when you import objects from other renderers to povray). The faster
you can make the proximity pattern for a mesh, the better.

-- 
#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

In article <3d2c7309@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   You mean that, if successful, it will be possible to make objects glow?-)
> (And I mean faster than using media with the proximity pattern.)
>   That would be a pretty cool effect. :)

That is what I'm planning. It will be a "cheat", basically it would be 
to emitting media + proximity what fog is to scattering media, but it 
should be much faster, at least for most simple shapes. There will still 
be "point glows"...probably a glow "object" which doesn't have a surface 
but supports points, rings, lines, etc...


>   By the way, it will probably be worth the effort to optimize the proximity
> calculation for meshes. After all, meshes are so versatile and so common
> (specially when you import objects from other renderers to povray). The faster
> you can make the proximity pattern for a mesh, the better.

That's going to be the generalised glow solving method...the patch will 
tesselate to a low-res mesh for glow calculations when an shape specific 
method doesn't exist. That will be part of the proximity patch as well, 
though I'm not going to completely abandon the ray sampling method.

Basically, I'll need to do:

1: a tesselation method for each object, using marching whatevers as 
default and specialized algorithms for some objects,

2: a distance-from-point method, using #1 + mesh method if a specialized 
method doesn't exist, and

3: a distance-from-line method, again using # 1 + mesh method if a 
specialized method doesn't exist.

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

On Wed, 10 Jul 2002 13:03:27 -0500, Christopher James Huff <chr### [at] maccom>
wrote:
> That's going to be the generalised glow solving method...the patch will 
> tesselate to a low-res mesh for glow calculations when an shape specific 
> method doesn't exist. That will be part of the proximity patch as well, 
> though I'm not going to completely abandon the ray sampling method.

Are you posting such detailed descrption to discourage other to implement
similiar ideas ? ;-)

Seriously I thought about similiar solutions but it is nonsense to work around
the same. Fortunatelly have some other ideas and first have to try optimize
and fix sphere_sweeps. Can't wait for sources.

ABX

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> That's going to be the generalised glow solving method...the patch will 
> tesselate to a low-res mesh for glow calculations when an shape specific 
> method doesn't exist.

  Doesn't this have the problem that a smooth surfaces will have
polygonized proximity patterns?

-- 
#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 <3d2ca2f8@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > That's going to be the generalised glow solving method...the patch will 
> > tesselate to a low-res mesh for glow calculations when an shape specific 
> > method doesn't exist.
>   Doesn't this have the problem that a smooth surfaces will have
> polygonized proximity patterns?

I'm hoping the artifacts won't be too noticeable in most cases, but it 
won't be a problem when it does happen. As I said, there will still be a 
ray sampling method available, or you could increase the resolution of 
the mesh. There will just be a tradeoff of polygon artifacts/increased 
memory or grainyness/slower rendering for those objects that don't have 
a specialized proximity method.

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

In article <ubuoiuc22i86eadjscq08nns4gg69gs6h2@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> Are you posting such detailed descrption to discourage other to implement
> similiar ideas ? ;-)

Yes and not really. ;-)
Since I'm going to do work on it, it would be redundant for someone else 
to do so. For instance, it would be a waste of time if someone went 
through a lot of work to clean up the proximity patch, which I'm going 
to complete rewrite.

I'm not trying to "stake a claim" though, and discussing the plans here 
might turn up new ideas or point out potential problems.

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