Hi, everyone.

I'm a newbie, and object declaration is starting to sink in...can't
believe how much simpler this makes things!  (grin)


I wish to render a quasi-Classical temple complex scene.

If I group objects with similar textures, will this save rendering
time?

For example, in my declaration of a "Column," I included the texture
I wish to use.  

There are currently approximately 20-30 columns, and there will
certainly be more before I'm done.

Is there any advantage to grouping all of the columns around a
particular building in one declared group, and defining their texture
at that group level, as opposed to leaving the texture declaration
within the declaration of "Column?"

Right now, with only a few objects, I don't think I'd be able to spot
any difference in render time, or I'd just do it a few times each way
and see for myself.

Post a reply to this message

"The Cegorach" <ceg### [at] yahoocom> wrote in message
news:u7dt7t4d0icvdmt1h1nv954dlebkd0ucg1@4ax.com...
>
> Is there any advantage to grouping all of the columns around a
> particular building in one declared group, and defining their texture
> at that group level, as opposed to leaving the texture declaration
> within the declaration of "Column?"
>

Well, I've run a quick test using the code below and moving the texture
parts from one place to another.

It is quicker to place your texture definitions as "late" as possible (i.e.
against the union rather than the object). This is only an issue with
parse-time, since the code is plainly quicker to execute (less texture
definitions to parse). Render time is unaffected, since the final scene is
the same.

light_source{<0,0,0> color rgb<1,1,1> translate <-30, 30, -30>}
camera{location  <0.0, 5, -10.0> look_at   <0.0, 0.5,  0.0>}

#declare test_object =
  sphere{0,1}

#declare n = 0;
union{
  #while(n<= 50000)
    object{
      test_object
      translate z* (2*n)
      texture{pigment{White} normal{agate}} // slower parsing here
    }
    #declare n = n + 1;
  #end
  texture{pigment{White} normal{agate}} // faster parsing here
}

Post a reply to this message

On Mon, 5 Feb 2001 14:50:37 -0000, "Tom Melly" <tom### [at] tomandlucouk>
wrote:

>Well, I've run a quick test using the code below and moving the texture
>parts from one place to another.
>
>It is quicker to place your texture definitions as "late" as possible (i.e.
>against the union rather than the object). This is only an issue with
>parse-time, since the code is plainly quicker to execute (less texture
>definitions to parse). Render time is unaffected, since the final scene is
>the same.

Is parse time typically a big concern?  

Thanks for the quick response.

Cordially,
Larry

Post a reply to this message

"The Cegorach" <ceg### [at] yahoocom> wrote in message
news:mvjt7t4phlh7iuqbp1v9dqi4valbb8j912@4ax.com...
> On Mon, 5 Feb 2001 14:50:37 -0000, "Tom Melly" <tom### [at] tomandlucouk>
> wrote:
>
>
> Is parse time typically a big concern?
>

For me, no (unless I'm rendering a mesh exported from poser on my P90 at
home).

Post a reply to this message

The Cegorach wrote:
> 
> Is there any advantage to grouping all of the columns around a
> particular building in one declared group, and defining their texture
> at that group level, as opposed to leaving the texture declaration
> within the declaration of "Column?"
> 

As Tom said, there might be some advantage in parse time (and memory usage).
However, bear in mind that the two methods usually do not yield identical
results.
If you declare the object with a texture and then create multiple copies of this
object, the texture of each copy is transformed (moved, rotated, scaled) along
with the copy itself.
If you first create the copies and then apply the texture to the whole group,
the texture location remains the same for all copies.

In other words, the first scenario is equivalent to:

object{
  MyObject
  texture{MyTexture}
  transform{MyTransform}
}

The second scenario is equivalent to:

object{
  MyObject
  transform{MyTransform}
  texture{MyTexture}
}

With most organic textures, like stones etc, it probably won't matter. But if
you need precise control over the placement of the texture relative to the
object (such as with an image_map), it makes sense to texture first and
transform later.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

"Margus Ramst" <mar### [at] peakeduee> wrote in message
news:3A7EED78.3AF1188A@peak.edu.ee...
> The Cegorach wrote:

> However, bear in mind that the two methods usually do not yield identical
> results.

Yes - I thought of mentioning this. Actually, I thought of it the other way
around - if you're creating "natural" objects, such as columns that have
been weathered, then generally it makes sense to position your objects first
and texture later otherwise it can be very obvious that similiar objects are
using identical patterns, so:

union{
    object{my_column}
    translate <A,B,C>
    texture{my_column_texture}
}

rather than

union{
    object{my_column}
    texture{my_column_texture}
    translate <A,B,C>
}

Post a reply to this message

Tom Melly wrote:
> 
> Yes - I thought of mentioning this. Actually, I thought of it the other way
> around - if you're creating "natural" objects, such as columns that have
> been weathered, then generally it makes sense to position your objects first
> and texture later otherwise it can be very obvious that similiar objects are
> using identical patterns, so:
> 

Actually, even in this case I often texture each object separately, and then
apply some (e.g. random) transformation to the texture itself.
Otherwise, especially if the texture pattern is somewhat regular (e.g. marble
bands) and two objects are close (e.g. a set of marble tiles), you run the risk
of having the texture noticeably "continue" from one object to the next.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

There will probably be a memory usage advantage to texturing the group.
There may be a slight parse time advantage. I do not believe there should
be any render time advantage. (Unless your scene makes POV access memory
a hell of a lot, since RAM is slower than CPU. ;)

There is an important diference, however. If you texture the item itself
and copy it, they will be identically textured. Discerning and nitpicky
people tend to frown on that. If you texture as a group however, each
column will have its own little section of the texture. The best solution
would be to have a macro that creates a slightly randomized texture every
time you want a pillar, but don't worry about that kind of stuff yet. :O

Note that for pillars, which probably don't touch, the group method is
fine, but if you have something made out of smaller objects (like a wood
floor) you would not want to do that, as it would look like one giant
piece of wood! (Yeah, so I used to do that in my old scenes... hey, shut
up :)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

On Mon, 05 Feb 2001 17:22:55 -0600, David Fontaine <dav### [at] faricynet>
wrote:

>There is an important diference, however. If you texture the item itself
>and copy it, they will be identically textured. Discerning and nitpicky
>people tend to frown on that. 

Indeed, that was going to be my *next* question; i.e., why are all my
pillars identically textured?  Thanks also to Margus and Tom for
pointing this out.  

Thanks,
Larry

Post a reply to this message

On Mon, 05 Feb 2001 22:45:12 +0200, Margus Ramst <mar### [at] peakeduee>
wrote:

>Actually, even in this case I often texture each object separately, and then
>apply some (e.g. random) transformation to the texture itself.
>Otherwise, especially if the texture pattern is somewhat regular (e.g. marble
>bands) and two objects are close (e.g. a set of marble tiles), you run the risk
>of having the texture noticeably "continue" from one object to the next.

Thanks to both you and Tom for your help.

When you speak of random transformations, is this achieved by a
function with POV-Ray, such as a Do/While loop, or do you do it by
hand?

I ask because I'm currently working on--you guessed--marble pillars.
:-)

Thanks,
Larry

Post a reply to this message