Ther is a problem with objects sharing same space, like 
cone { y*0 1 y*1 1 }
cone { y*1 1 y*2 1 }

some pixels at y=1 will at same time be a part of cone #1 and #2. If cones 
were partial transparent, this will lead to errors on rendered images.

Imho there is an easy work around :)

* Idea : 
Use additional property to select one object as more important, in 
ambignous situations, like i.e. <0,1,0> in example above, this ID will 
decide to with object <0,1,0> belongs.   
* Example :
cone { y*0 1 y*1 1 objId 1 } // #1
cone { y*1 1 y*2 1 objId 2 } // #2
cone #2 has higher parametr objId, so it has higher priotity, so <0,1,0> 
will be consider as belonging to #2
* Algorithm :
there is probably some code looking like :

j=0; // background color
while (1) { 
  if ray[i].has_intercesion_with_object(j) break;
  j++;
}
return j;

it should be changed to :

j=0; // background color
int priorJ=j;
int highestId=0;
while (1) { 
  if ray[i].has_intercesion_with_object(j) {
    int id = object[j].objId;
    if (id>highestId) { // object 'j' has higher objId, so :
      priorJ=j; // object 'j' is currently most sutable to be consider
    	    	    	// as intercesion with ray
      highestId=id; // this is current highest id
    }
    if (id==9999) break; // objId 9999 is used to say "do NOT check other
    // "objects" 9999 is the highest possible objId
  }
  j++;
}
return j;



I have alsow some algorihms that will greatly improve speed of rendering 
when objId future is used. I can give full C code for that :) Will someone 
help me and translate this pseudo-codes for proper code to link-in to Pov-
Ray core ?


-- 

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in 
news:Xns### [at] 204213191226:

[...]
> return j;

should be 

return priorJ;

imho same algorithm will halp in situations like
difference {
  cone { 0 1.0 y*1 1.0 }
  cone { 0 0.9 y*1 0.9 objId 1 }
}

I will tomorow describe exacly this idea, and some algorithms (including 
this optimized ones) on page http://www.raf256.com/pov/?new=1 (this page 
will be available about 25.06).

-- 

Post a reply to this message

I don't understand what's the point in doing this when you can just
move one of the coincident surfaces a tiny bit in the desired direction.

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

Warp <war### [at] tagpovrayorg> wrote in news:3d1781b9@news.povray.org:

>   I don't understand what's the point in doing this when you can just
> move one of the coincident surfaces a tiny bit in the desired direction.

becuase :
1. this is imho quite primitve work around, using something like y*1.0001 
2. in complex scenes, like group of i.e. 10000 spheres - this is hard to 
tell with spheres wil produce such problems, and it's hard to adjust "a 
little bit" such elements, if we have 1000 spheres like 
<0.12312,0.3424,0.1234> - how much should we adjust them to be shure not to 
have this problem ?

-- 

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> 2. in complex scenes, like group of i.e. 10000 spheres - this is hard to 
> tell with spheres wil produce such problems, and it's hard to adjust "a 
> little bit" such elements, if we have 1000 spheres like 
> <0.12312,0.3424,0.1234> - how much should we adjust them to be shure not to 
> have this problem ?

  The only case where two spheres can have coincident surfaces is when
their center and their radius is exactly the same.

  To make absolutely sure that no such thing will ever happen, you could
add a value to each x-coordinate. This value could start from 0 and
increase with steps of 10^-8 or whatever.

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

On 24 Jun 2002 16:38:19 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Warp <war### [at] tagpovrayorg> wrote in news:3d1781b9@news.povray.org:
> >   I don't understand what's the point in doing this when you can just
> > move one of the coincident surfaces a tiny bit in the desired direction.
>
> becuase :
> 1. this is imho quite primitve work around, using something like y*1.0001 

Which way it is primitive ? It is exactly the same effort in typing as writing
for both objects. Writing IDs in complex scenes could slow down parsing
becouse of additional case in object modifiers list, increse memory
consumption becouse of additional field, slow down rendering becouse of
additional test. Adding small tranlation use already defined transformation
matrix. All objects internally already have matrix initialized. Moreover it is
nearly like reality. You can't have two electons in the same place at the same
time ;-)

> 2. in complex scenes, like group of i.e. 10000 spheres - this is hard to 
> tell with spheres wil produce such problems, and it's hard to adjust "a 
> little bit" such elements, if we have 1000 spheres like 
> <0.12312,0.3424,0.1234> - how much should we adjust them to be shure not to 
> have this problem ?

There must be problem with random generator if you have 10% with the same
location and size :-)

ABX

Post a reply to this message

On 24 Jun 2002 16:00:43 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> I have alsow some algorihms that will greatly improve speed of rendering 
> when objId future is used. I can give full C code for that :) Will someone 
> help me and translate this pseudo-codes for proper code to link-in to Pov-
> Ray core ?

Just send it here. But be carefull. You work with POV 6 years so You probably
know how old is this tool. Large community of programmers inspected sources.
There was many bugs reported and fixes or optimizations implemented.
Complexity increased with number of features. Be ready that not everything is
possible/reasonable :-) . For example I considered some time Clone object as
speed up for forests of CSGed trees. For my surprise simple implementation
slowed down a lot. I know why but I can't fix it without complete rewriting
object's transformation handling. I expect it will be possible in 4.0 but I'm
sure at least I'll try again with 3.5.

ABX

Post a reply to this message

In article <Xns### [at] 204213191226> , "Rafal 'Raf256' 
Maj" <raf### [at] raf256com> wrote:

> I have alsow some algorihms that will greatly improve speed of rendering
> when objId future is used. I can give full C code for that :) Will someone
> help me and translate this pseudo-codes for proper code to link-in to Pov-
> Ray core ?

How can you say it will improve speed of rendering if you haven't even
implemented it?  Did you even ever look into the POV-Ray source code?

    Thorsten

Post a reply to this message

> You can't have two electons in the same place at the same time ;-)

  A quantum physicist might object to that... :P

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

On Tue, 25 Jun 2002 11:50:55 -0500, Warp wrote:

>> You can't have two electons in the same place at the same time ;-)
>   A quantum physicist might object to that... :P

No, that's having one electron in two places at the same time...I don't
think it's possible to have two electrons share the same position for any
amount of time. I'm certainly no expert on quantum mechanics theory
though...


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message