I've been thinking about this for a while and I simply can't find a 
reason why it is not possible to copy a CSG object in the same, memory 
saving way you can copy meshes.
My knowledge of the POV sources is very limited, so please correct me if 
I'm wrong, but IMHO copies of the same mesh are simply references to the 
same internal dataset, i.e. pointers, and additional data like 
transformations. Why can't the same technique be applied to CSG objects 
as well? Is this a general, algorithmic problem or is the way things are 
handled in the POV-Ray sources the reason for this?

Please not that this is is not a feature request, but simply a question 
out of curiosity. Also, I found this group a better place to ask than 
p.programming, but again please correct me if I'm wrong.


Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

> I've been thinking about this for a while and I simply can't find a 
> reason why it is not possible to copy a CSG object in the same, memory 
> saving way you can copy meshes.
> My knowledge of the POV sources is very limited, so please correct me if 
> I'm wrong, but IMHO copies of the same mesh are simply references to the 
> same internal dataset, i.e. pointers, and additional data like 
> transformations. Why can't the same technique be applied to CSG objects 
> as well? Is this a general, algorithmic problem or is the way things are 
> handled in the POV-Ray sources the reason for this?

HISTORY is your one-word answer.
CSG were implemented far before mesh even become available.
Moreover, mesh was perceived as a huge memory-filler, and was therefore 
optimised (because, at that time, even 4 megabytes of memory could have 
been luxury), whereas CSG is usually feeled like a simple (and short) tree.
(a CSG operation, a sphere and a plane, that's short!)





-- 




l'habillement, les chaussures que le maquillage et les accessoires.

Post a reply to this message

On Fri, 07 Jan 2005 15:08:19 +0100, Florian Brucker <tor### [at] torfboldcom> wrote:
> Why can't the same technique be applied to CSG objects 
> as well? Is this a general, algorithmic problem or is the way things are 
> handled in the POV-Ray sources the reason for this?

That was mentioned several times (for example in
http://news.povray.org/povray.unofficial.patches/thread/%3CMPG.156f6f504b27c9c29896b3%40news.povray.org%3E/
) but from my own experimenting it caused slowdown in rendering.
Unfortunatelly I fail to find thread with my results I posted long time ago to
this server about 3-4 years ago. Perhaps it waits for more effective
implementation than my attempt. I think I lost the sources from that time.

ABX

Post a reply to this message

Thanks for your answers, and for the link, both of you. Would be 
interesting to see some benchmarks of those transformation-optimizations 
vs. referencing, but it looks like really hard work, so I doubt we'll be 
getting some soon.

Would be a killer feature, though. There are many scenes where I'd have 
traded rendering speed for memory, but that's as usually, an issue of 
personal taste.


Thanks again,
Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

I thought about the subject again and found some new questions I can't 
answer myself :)

The basic argument in the thread ABX provided a link to is, that CSG 
objects are optimized for the used transformations, so that e.g.

sphere {
	0, 1
	scale 20
	translate <-1,2,3>
}

is "translated" into

sphere { <-1,2,3>, 20 }

This is done to avoid the application of the transformation to the 
incoming ray, right? This is not applicable on referenced objects, as 
those would store their transformations separately.

Now I do see that this kind of optimization will work for simple objects 
like a sphere, but does it still hold true, say, for a rotated box? A 
sheared box? I don't know how the intersection tests are performed 
internally, but I could imagine that there are (a lot?) of combinations 
of objects and transforms for which it is not possible to perform 
optimizations as above. So in that cases, the transformations would have 
to be applied to the ray, wouldn't it? And applying the transformation 
to the ray is a matrix*vector operation, right? So once you mixed one 
transformation with an object which can't be optimized for that special 
transformation, you will have to do the matrix*vector stuff, no matter 
what any other transformations are applied to the object. In those 
cases, the argument against referencing does not work.
Can anyone tell me how much of the usual intersection tests benefit from 
this kind of optimization (I know that this is scene dependant, but just 
to have an idea)?

Thanks for any pointers and sorry if I'm talking BS, just tell me :)
Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

As already said, there's a historical reason for this. The first coders
thought of this kind of optimization and embedded it so deeply into the
core of povray that now it would be quite laborious to change.

  POV-Ray 4 will probably change 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