|
![](/i/fill.gif) |
McHannemann wrote:
> ok so if I have a object consistent of several parts I do normally union
> to move them around, I need to not union them and move them all seperate
> right?
Others have answered but since it was my answer that may have been
confusing to you I will try to clarify further. If your
question is:
Are union{} blocks necessary to transform and texture a group of objects
as if one? The answer is no, not necessary. The result can be the same
if you apply the transform and texture to each of the individual objects
or to a union{} block which includes them. The union{} is a convenience
and can add other benefits too but you can investigate that on your own.
About leveraging memory usage,... to add detail to what others have
already said,... whether you create several objects:
box {...transform {...}}
sphere {...transform {...}}
sphere {...transform {...}}
sphere {...transform {...}}
or first define them, then instantiate them:
#local B = box {...}
#local S = sphere {...}
object { B transform {...}}
LOOP 3 TIMES
object { S transform {...} }
END LOOP
or put them in a union block:
union {
box {...transform {...}}
sphere {...transform {...}}
sphere {...transform {...}}
sphere {...transform {...}}
transform {...}
}
or instantiate them in a union block:
#local B = box {...}
#local S = sphere {...}
union {
object { B transform {...}}
LOOP 3 TIMES
object { S transform {...} }
END LOOP
transform {...}
}
your memory usage will be directly related to the
number of objects you create. If a sphere costs
X bytes of memory, 3 spheres is ~ 3*X bytes.
BUT,... there are a couple of special POV-Ray objects
that are in a sense collections of component objects,
specifically the mesh{}, mesh2{}, and blob{} objects.
Mesh takes the standard triangle{} and smooth_triangle{}
as components, blob{} takes special versions of sphere{}
and cylinder{}. When you define these special objects the
memory cost for that object will be directly related to the number of
components you use in it. HOWEVER, if you define and
name your mesh{} or blob{} object, then instantiate
your mesh{} or blob{} multiple times, the memory cost does
NOT multiply by the number of *instances*. It remains close
to the original cost of the components. This is the
leveraging of memory that you are seeing all the talk about. So
you only get benefit if you are reusing that same multi-object, object.
The classic example is to model a tree from perhaps tens thousand
triangles places in a single mesh{}. This definition is then
instantiated perhaps six different times, rotated and scaled scaled
differently each time, and placed to look like a grove of trees. In
this way you get the "use" of 60 thousand triangles for approximately
the memory cost of ten thousand.
Using a union{} to try and group the objects for instantiation
does not give this benefit. You might think it would because
it seems that unions can be treated as a single object. But there is
no benefit to that strategy.
This:
#local U =
union {
sphere{}
sphere{}
sphere{}
};
LOOP 3 TIMES
object{ U transform{}}
END LOOP
creates nine spheres with a memory cost, approximately, of nine spheres.
Naming the objects through an array
structure, thus seeming to "collect" objects in that way, gains nothing
either. Arrays are not objects.
It is only the special mesh{}, mesh2{}, and blob{} objects that can be
use to leverage memory costs.
Post a reply to this message
|
![](/i/fill.gif) |