Hi all,

I know, when #declaring a mesh, it is only loaded only once, so you can 
use many instances of it, without running out of memory.
Why isn't this possible with all objects, like a union of 10000 cones for 
example?
Maybe there is already a patch out there wich implements this and I just 
don't know? 

Lutz-Peter

Post a reply to this message

In article <MPG.156f6f504b27c9c29896b3@news.povray.org> , Lutz-Peter Hooge
<lpv### [at] gmxde>  wrote:

> I know, when #declaring a mesh, it is only loaded only once, so you can
> use many instances of it, without running out of memory.
> Why isn't this possible with all objects, like a union of 10000 cones for
> example?

Because it is an implementation feature of the mesh code, not the object
storage code.  There are some side effects how render speed of some other
objects is improved that would be incompatible with such a method, so it is
non-trivial to implement.

> Maybe there is already a patch out there wich implements this and I just
> don't know?

I am not aware of any patch that can do this.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3b056468@news.povray.org>, tho### [at] trfde says...

> Because it is an implementation feature of the mesh code, not the object
> storage code.  There are some side effects how render speed of some other
> objects is improved that would be incompatible with such a method, so it is
> non-trivial to implement.
Too bad :-( It would be a very useful feature for making large amounts of 
plants etc. 

What does "non-trivial" mean? Thats it's not possible in, say, 3 hours, 
or a day, or two, or so? Or that it is (nearly) impossible?

Lutz-Peter

Post a reply to this message

In article <MPG.156fade524e59e4a9896b5@news.povray.org> , Lutz-Peter Hooge
<lpv### [at] gmxde>  wrote:

> What does "non-trivial" mean? Thats it's not possible in, say, 3 hours,
> or a day, or two, or so? Or that it is (nearly) impossible?

More than a week to get it into a working state, plus a few month of testing
because it would change something in almost every object, the parser, etc...

   Thorsten

Post a reply to this message

Lutz-Peter Hooge wrote in message ...
> I know, when #declaring a mesh, it is only loaded only once, so you can
> use many instances of it, without running out of memory.
> Why isn't this possible with all objects, like a union of 10000 cones for
> example?


Becouse you can treat set of triangles as property of object as well as radius
and center for sphere or normal and distance for plane.
Look at summary of sphere definition in megapov 0.7;

- pointers
(Methods,Sibling,Texture,Interior,Interior,Bound,Clip,UV_Trans,Label,Interior_Te
xture,glowList,Trans
- ints (Type,Ph_Flags,No_Shadow_Group, Light_Group,Flags,TimeStamp)
- sngl (BBOX,Ph_Density)
- dbl (Radius,Center)

you can save space for radius where you copy object{MySphere OBJECT_MODS} but
nearly all other properities you reserve for child becouse they can be
overwritten.

this way you get another level of abstract but instead of 4 dbl you must
remember pointer to parent - is it worth ?

--
#macro Sig(A,B,X)_(A,B)_(B,X)_(X,A)#end#macro _(A,B)cylinder{<A.x,A.y,3>,<B.u,
B.v,3>.1,9}#end global_settings{max_trace_level 9}light_source{0 1}camera{up y
*4right-3*x}blob{_(<3,1>,<1,-5>)_(<2,-2>,<4,-2>)Sig(x,<-1,1.5>,<1,3>)_(z-1,z-4
)pigment{rgb 1}}box{-3 3pigment{rgb 0}finish{reflection 1}hollow} // POV-Ray31

Post a reply to this message

Wlodzimierz ABX Skiba wrote:
> 
> [...]
> 
> this way you get another level of abstract but instead of 4 dbl you must
> remember pointer to parent - is it worth ?
> 

Probably not in this case, but for a complex CSG it could be useful, just
imagine a lot of macro generated trees...

I know this is probably quite difficult to implement, but NTL it would
offer interesting possibilities.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
: Why isn't this possible with all objects, like a union of 10000 cones for 
: example?

  Most objects are optimized when certain transformations are applied to
them (in order to eliminate those transformations).
  For example, if you have this:

#declare MySphere = sphere { 0,1 }

object { MySphere scale 10 translate x*20 }
object { Mysphere translate -x*20 }

the result will be internally exactly the same as if you had written:

sphere { x*20, 10 }
sphere { -x*20, 1 }

  The idea is to eliminate the transformations where possible and thus
speed up the rendering. When the ray doesn't have to be transformed, the
intersection test will be faster.
  This same optimization is applied to objects inside CSG groups.
  This is why declared CSG groups can't be used as they are, but they have
to be copied in order to perform the optimizations to the copy.

  This is what I have understood. I might be wrong in some details.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

> Wlodzimierz ABX Skiba wrote:
> >
> > [...]
> >
> > this way you get another level of abstract but instead of 4 dbl you must
> > remember pointer to parent - is it worth ?
>
> Probably not in this case, but for a complex CSG it could be useful, just
> imagine a lot of macro generated trees...

I know adventages of this and even curently play with such macros but I think
(it's only personal opinion) that this support in current state of povray is not
worth at level of every object but perhaps it is worth at level of CSG engine.

> I know this is probably quite difficult to implement, but NTL it would
> offer interesting possibilities.


I just had idea that there could be another kind of object named Clone which
remember only transform and base object. Well... I'll try and check this.
Perhaps whole forest could fit into cache of processor ;)

--
#macro Sig(A,B,X)_(A,B)_(B,X)_(X,A)#end#macro _(A,B)cylinder{<A.x,A.y,3>,<B.u,
B.v,3>.1,9}#end global_settings{max_trace_level 9}light_source{0 1}camera{up y
*4right-3*x}blob{_(<3,1>,<1,-5>)_(<2,-2>,<4,-2>)Sig(x,<-1,1.5>,<1,3>)_(z-1,z-4
)pigment{rgb 1}}box{-3 3pigment{rgb 0}finish{reflection 1}hollow} // POV-Ray31

Post a reply to this message

Wlodzimierz ABX Skiba wrote:
> 
> [...]
> 
> I just had idea that there could be another kind of object named Clone which
> remember only transform and base object. Well... I'll try and check this.
> Perhaps whole forest could fit into cache of processor ;)
> 

Just about what i thought of, i only would use 'reference' rather than
'clone', because a clone is actually a real copy of the original.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3b059a7b@news.povray.org>, tho### [at] trfde says...
> More than a week to get it into a working state, plus a few month of testing
> because it would change something in almost every object, the parser, etc...
Then it would probably not make much sense to start working on this 
before 3.5 is available...

Lutz-Peter

Post a reply to this message