In article <3C415901.CFCC9CCD@avalon-net.co.il> , Eugene Arenhaus 
<eug### [at] avalon-netcoil>  wrote:

> No, I am talking about reusing object descriptions internally: like
> rendering 10000 copies of a sphere with only one actual sphere object
> kept in RAM.

Not useful as a general solution:  A sphere takes about 108 bytes in memory
right now.  A transformation matrix, 4*4 doubles takes 128 bytes.

I think like many before you, you made the mistake to first make some
general suggestions as if POV-Ray would do nothing other programs do but you
never really looked into the code to actually verify your suggestions make
sense.  It is a common problem with many people who made similar suggestions
before, and it usually creates on-topic threads as long as this one very
quickly, without any useful outcome :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> > No, I am talking about reusing object descriptions internally: like
> > rendering 10000 copies of a sphere with only one actual sphere object
> > kept in RAM.
>
> Not useful as a general solution:  A sphere takes about 108 bytes in
memory
> right now.  A transformation matrix, 4*4 doubles takes 128 bytes.

I think a sphere was provided as an example, replace sphere above with 20mb
mesh and it suddenly doesn't sound such a bad idea, however impractical it
may be


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

Rick [Kitty5] <ric### [at] kitty5com> wrote:
: I think a sphere was provided as an example, replace sphere above with 20mb
: mesh and it suddenly doesn't sound such a bad idea, however impractical it
: may be

  Bad example, as povray already does it with meshes.

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

"Rick [Kitty5]" wrote:
> 
> I think a sphere was provided as an example, replace sphere above with 20mb
> mesh and it suddenly doesn't sound such a bad idea, however impractical it
> may be
> 

A mesh can already be 'referenced', the real use of such a possibility
would be complex CSG, but it would depend on the situation whether the
advantage in memory requirements would balance the additional calculations
required.

BTW, this would be a good starting point for Eugene: program an
instancing/reference patch, do it nicely (i.e. well documented and well
tested) and i'm sure it will become part of the next megapov release.

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

> : I think a sphere was provided as an example, replace sphere above with
20mb
> : mesh and it suddenly doesn't sound such a bad idea, however impractical
it
> : may be
>
>   Bad example, as povray already does it with meshes.

nitpick :)


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

> A mesh can already be 'referenced', the real use of such a possibility
> would be complex CSG, but it would depend on the situation whether the
> advantage in memory requirements would balance the additional calculations
> required.

could the existing referencing code not be used for non mesh objects, or at
least as a starting point for 'general referencing


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

In article <3C41628F.7B4132C1@avalon-net.co.il>,
 Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:

> Of that I am well aware. It was merely provided as food for thought. 
> 
> I am more than content with waiting. :)

Oops, looks like I forgot to include this link:
http://www.povray.org/3.5-status.html

"Third, our most recent musings about POV-Ray 4 lean towards a major 
reworking of the POV Scene Description Language. This means that POV 4 
may not be fully backwards compatible with old scenes. If that is the 
case, we will plan to provide an official conversion utility that will 
convert old scenes into the new syntax, or provide some other means of 
importing old scenes."


> And why not? It does produce raster output, which can be used as texture
> UV map if we render it then save the image and use it in another scene,
> n'est pas? So why not let it be used as texture UV map without all that
> hassle?

Doing that "on the fly" without rendering the image from the camera is a 
little more difficult...but I'm working on a patch that does exactly 
that.


> Must have been my personal blunders, then... in my experience with 3.1,
> I was not successful with making precisely those three circles that
> would either protrude visibly from the cylinder as other cylinders, or
> else show rendering artifacts - but not look like they were "painted on
> surface".

Well, if the surfaces are coincident, POV won't be able to decide which 
one to use, but you can use an offset that won't be visible at any 
reasonable resolution. I've never liked this workaround though...that's 
why I wrote the object pattern.


> Can I make a macro that would calculate a macro that I would pass it in
> a parameter?

Not currently. But this has little to do with anything being 
"precalculated", POV just assumes you want the result of a macro call 
instead of the macro identifier, similar problems exist with splines and 
functions. It should be possible to implement with a little parser work.


> I would say that scalar is merely a 1-dimensional vector.

Well, not in the mathematical sense, but probably so practically. Are 
you suggesting some way of specifying the number of components of a 
vector?


> Could you please tell when you post it?

I posted it a couple days ago...the discussion has moved to 
povray.general though.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3C415F64.D3ADC5E3@avalon-net.co.il>,
 Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:

> Try to pass a macro to a macro?

There is a workaround:

#macro ParamMcr(x, y, z)
...
#end

#macro MainMcr(...)
   ...
   ParamMcr(...)
#end


// the user's code:
#macro ParamMcr(x, y, z)
...
#end
MainMcr(...)

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Rick [Kitty5] <ric### [at] kitty5com> wrote:
: could the existing referencing code not be used for non mesh objects, or at
: least as a starting point for 'general referencing

  AFAIK, the mesh object is a completely different beast to the other
primitives. I don't think that "the existing referencing code" could be
used for anything, as the implementation of the mesh object differs
completely from the other objects.

-- 
#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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

>> Can I make a macro that would calculate a macro that I would pass it in
>> a parameter?
>
> Not currently. But this has little to do with anything being
> "precalculated", POV just assumes you want the result of a macro call
> instead of the macro identifier, similar problems exist with splines and
> functions. It should be possible to implement with a little parser work.

With parenthesis it should always for.  A recursive decent parser simply
cannot parser implement a grammar like the one needed to solve the above
problem without ambiguity.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message