 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9 Jul 2002 21:17:50 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256 com> wrote:
> Hi,
> realy couldn't find one thing in manual... there AFAIR was some pattern
> (used i.e. in media) that value in <x,y,z> was equal to distance beetwen
> <x,y,z> and some object
For basic primitives this can be realized without internall support. Take a
look at my 'rounded' addition to iso_csg library
(http://www-public.tu-bs.de:8080/~y0013390/pov/ic/). It can be even faster
than internall pattern since it is optimized for shapes and not use rays like
original proximity pattern. It is also accurate unless you not use strange
transformations or complicated CSGs.
For more complicated shapes it can be realized with my
blurred/distance/proximity solution (unfortunatelly final macro is not
finished becouse of bugs I found during betatesting but initial version should
work).
http://news.povray.org/povray.binaries.images/22100/
http://news.povray.org/povray.binaries.images/22745/
http://news.povray.org/povray.text.scene-files/22075/
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9 Jul 2002 23:01:00 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> pixelized {
> object ...
> 100,100,100
> }
>
> that will create 100x100x100 bits arrar - informing is some point inside
> object or not. In addition - it will be very fast to use, and object size
> (maybe speed) can be optimized using binary trees (or something simmilar).
No need for patching. It is already done in my implementation of distance
pattern via functions.
> I realy do NOT like modyfing somones other code, especialy when its so big
> and complex as Pov's source.
If you really want to help POV or You want work in any team professionally you
should learn to work with other sources. Moreover POV sources are complex in
total size but basic in general raytracing algorithms and are builded very
clear. Yes, there is no so much comments but identifiers are usually
selfexplaining.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> in worst case - You can just shut rays at object, as it was in test wersion
> of distance pattern, but it will by much faster to test intersection of
> pixelized rather then i.e. isosurface or complex CSG
Really? Can you give me actual measurements of this?
Besides, you will just get a "pixelized" distance pattern (ie. the pattern
will be formed of cubes). How is that useful?
> I only suggested : why not optimize (using pre-calculated array) this
> tests
Because insideness test is already very fast. As I said, that's not the
problem. However, a fast insideness test does not help resolving the
distance from the surface of the object.
--
#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 <3d2b8f5f@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> There was a discussion some time ago (I think initiated by me) that the
> distance calculation could be optimized in a per-primitive basis (for many
> primitives getting the accurate distance fast is quite easy), as well as
> developing a proper algorithm for calculating it analytically for a CSG
> object. (Of course there are objects where you *can't* get the accurate
> distance from the surface, eg. the 4D julia object. For some objects it
> might not be unambiguous which distance is the correct one.)
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.
To answer the question: no, the proximity pattern was not added to POV
3.5...it never got beyond the experimental stage, and wasn't even close
to being ready for the official version. The object pattern did make it,
and it can be used to get a somewhat similar effect where the pattern
value depends on the percentage of nearby space filled by the object.
This is not proximity, and it is a bit slow, but it might do what you
need.
And the "pixelize" idea (which would really be "voxelize") has its own
problems: the voxel field takes up a huge amount of memory, and even
with interpolation you get grid artifacts if the resolution is too low.
It doesn't require a patch though...if I recall correctly, there are
other patches in MegaPOV that would make it possible. The official
POV-Ray 3.1 has a density file pattern, and a MegaPOV patch made it
possible to generate the field from within the scene file. (this might
have made it into 3.5, I don't remember)
A patch adding features for generating and processing voxel information
would be useful though. There are a lot of things that could be done to
extend the current capabilities.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
