|
Thanks for taking the time to explain! That makes sense.
peter boeykens wrote:
I was talking about the shading on phong, lambert, blinn... shaders,
as well as reflection, dirtmap, etc... all of this is evaluated for
each instance, however, a texture projection, even if the support is
outside the master model, even if it's a spatial projection, is just
evaluated once, for the master model.
think of it this way:
a master object is a block of data, with a description of the
geometry, texture coords, shader,..
an instance is just a null, a set of transforms.
the master block gets translated to mental ray, as well as the
collection of transforms.
Mental ray then goes and populates the scene, creating duplicates of
this block of data, using the transforms.
Once done, it all exists as real geometry in mental rays memory - so
for shading tasks, it shouldnt be too different from regular geometry.
with just one block of data this is a minimal amount of data to handle
- for scene size, manipulation and transferring to mental ray. Thats
the advantage of instances: minimal amount of memory needed.
If texture coordinates were unique per instance, the advantage of
using them would be largely ruled out - uv's represent a lot of data.
texturing methods that dont rely on xsi to give the coordinates to
mental ray, but rather have mental ray create them on the fly, will
work with instances and can be used to make them unique.
especially the vector_state set to intersection point is usefull for
this.
This can feed most 3d textures (fractals, clouds, veins..)
Instances textured this way will all look unique, and it also works
for displacement.
"One big texture on many small instances" is exactly what you get this
way.
Often I plug large scale textures into gradients to create subtle
color variations for the instances.
I'll try what you described though, looks interesting...
Thanks!
Antonin
peter boeykens wrote:
You're right, rendering is as long, but scene interaction is much
faster using instances. Plus, if the model changes they're much
easier to update...
I'll probably use duplicates, however I'm still wondering why
texture UV's are evaluated only once when everything else is
evaluated for each instance... Oh well...
thats not really true.
apart from the transforms almost nothing is evaluated "per instance".
true enough, textures that are spatial will be evaluated properly,
but thats not per instance, but rather per sample - the texture
itself is one and the same for all instances, it just looks
different at different points in space.
if you use an image implicit and feed that proper coordinates it
should also stretch through all the instances.
something like making a floor with tiles and having one big painting
on them?
It would be fixed in space though, and if your instances move they
would "swim" through the texture.
Making the coordinates for this is not so trivial though.
If I remember correctly, you need a vector state set to intersection
point, then plug that into 2 B/W gradients that use the vector x and
the vector z respectively. you can do the placement through the min
and max. those gradients converted to scalars could be fed into a
vector again that would in turn feed the image implicit.
A lot of hassle to get it to work and quite limited, since you'd be
restricted to either xy, xz or yz plane.
Thanks for the reply.
Antonin
Bernard Lebel wrote:
Any particular reason why you're using instances? The only situation
where I think instances are useful is for static, unchanging objects.
Even then, I now resort more on particle instances than instances.
They take long to save, and they have to be populated when you open
the scene.
It is my understanding that render-wise, instances won't save you
anything as well. Real geometry would allow you to do what you want.
Bernard
On 8/2/07, Antonin Messier-Turcotte <amessier(at)flystudio.com> wrote:
Thanks for the reply... I'm not sure if it would work in my case
though.
Seems like the switcher has only 16 inputs, where I've got about 500
instances. Plus, my texture doesn't repeat, it's one big texture
covering the entire instance formation. So I don't think it would
work,
or maybe I'm misunderstanding your idea...?
What's weird is that all shaders (for example phong or lambert, or
reflection or even dirtmap) will be evaluated for each instance,
while
texture maps are only evaluated for the master model. Why is that?
Antonin
Sam Cuttriss wrote:
probably not instances,
but i imagine with the ba colourswitcher shader set to random you
ought to be able to offest the image uv remap parameters.
just make your uvs the size of one repeat (on your image) then
offset
by integers and you should be able to do it cleanly.
there may be a cleaner way?
_sam
*Sam Cuttriss
* Janimation 3D Aficionado
Antonin Messier-Turcotte wrote:
Hi,
Let's say I've got a big object made up of little cubes. Is
there any
way the cubes can be instances, yet they would grab a different
part
of a big texture that is projected on the whole big object? I
can't
seem to find a way to do this, even if the texture support is
outside
the model that was instanced. Shouldn't it be possible?
Thanks!
Antonin
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
