|
Yeah, it's kind of a subtle difference. I guess for the moment, I'm
thinking my preference would still be to keep clusters as the
lightweight implementation, improve them as much as possible (while
leaving them fundamentally in line with the sort of "indexed behaviors"
for polygons as they are implemented in MR), and have the option to make
the cluster automatically extract as a derivative object in special
cases where you actually do need the section of the mesh to be its own
object. I guess it would be a subset of what you can do with Clones.
Instead of copying the whole mesh, it would just copy the part you cared
about. Really, it's just cluster-driven cloning... You could make it
something else that'd be a little lighter, but at that point, why not go
all the way and actually make it a new object? I mean, if you made what
looked like a new object and didn't let users transform and deform it,
people would just get mad.
Maybe this cluster-cloning is already possible? Or possible with a new
custom operator?
- Andy
Andy Nicholas wrote:
Sounds good.
Actually, if they implemented it like that, they could just place the meta
objects in the same place as the clusters currently are... and call them
clusters ;-D No need to tell anyone anything - except the improvement in
cluster functionality!
Hi Andy,
Well I was thinking with the metaobject (object fixed underneath the
original mesh) that it would be pretty consistent with current XSI
behaviour beyond being fixed.
So by default it would inherit visibility etc from the parent object
(that would be a difference between a real object - it could inherit
local properties from it's parent as well as branch ones). Though you
could still make local versions of them etc.
I'd probably see implementing it as being done by keeping the existing
cluster system in place, but having the ability to create a
meta-object from clusters (possibly only polygon clusters as they
relate directly to renderable items whereas edges etc don't).
Limit materials to only being appliable to objects (and meta-objects)
- i.e. remove that from clusters to ensure consistency. Backwards
compatibility would just convert clusters with materials to
meta-objects and apply the material.
Meta-objects should only behave like objects for the purposes of
properties (like visibility) and materials. They should have no
construction history etc as the stack already has operators which can
only be applied to clusters.
This would give you a robust framework for handling properties on
clusters while maintaining consistency with the rest of the
architecture. It also doesn't require the overhead of a real object
(such as a transform state etc).
Cheers,
Alan.
On 5/2/07, Andy Jones <andy(at)thefront.com> wrote:
That's a nice idea. There are a couple of potential problems I can
think of, but they might all be solvable. One is that objects are
really heavy in XSI. One of the big reasons we use clusters is to make
our scenes lighter. Another problem is that a lot of properties of the
cluster (most notably visibility) are effectively overridden by the
properties of the object in some sense. So, you'd have to find a way to
make the interface and implementation consistent. I think ultimately,
it doesn't really make much difference whether the clusters look like
objects or not, because they fundamentally can't work like objects.
Unless they can... But to me, the concept of a polygon cluster makes a
lot of sense. We just need the ability to control them a little better.
On the other hand, something similar that I think could be useful is a
nice, integrated way to make "blown apart" objects, where you have
several objects that are essentially extracted polygons from one single
mesh. For example, this could be a way to get a lot of control over
different parts of character meshes, where for the purpose of enveloping
you want a single mesh, but for materialization and passes, separate
objects are beneficial. So, if you've got a character where the clothes
are sort of attached to the skin, you can still deal with the skin and
clothes like they're totally different objects. You can of course do
this sort of thing in the software in several ways already, but it's
ugly. Of course, if clusters are improved a little, the need to do this
sort of thing decreases. But there are still probably cases where you
want smooth, continuous surfaces that behave like multiple objects.
- Andy
Alan Jones wrote:
Why not just have clusters appear as objects instead? Or at least a
metaobject which has an unfreezable history linked to the cluster
under the original object? Disable applying materials onto the
original cluster and only have them apply to the metacluster object. I
can't see any disadvantage to having the metaobject fixed underneath
the original object.
Cheers,
Alan.
On 5/2/07, Guillaume Laforge <guillaume(at)alamaison.fr> wrote:
...If I'm not misunderstanding the
setup you're describing, I think it also has the problem that you
can't
override the same material on two different clusters two different
ways. So, for example, if you want to make a set of objects blue
and
another set of objects green, you can't really gaurantee that it's
possible if you're using cluster materials.
I completely agree Andy. For this scenario, it is not really an
"override cluster material" problem but just the actual design of
cluster object in xsi.
To be able to drag and drop clusters in partitions could be handy but
it could be really messy too. A such re-design work doesn't look
simple.
Maybe a "Partition Material Manager" showing only objects, clusters
and materials like this :
partition A :
____Material A used by "objects A" and "object Z.cluster 1".
____Material B used by "objects Z" and "object A.cluster 1".
partition B :
____Material A used by "objects C" and "object Z.cluster 2".
____Material B used by "objects D" and "object A.cluster 2".
The UI will have to be extremely user friendly to avoid headache ;-).
I think we need a) a much improved implementation of the "texture
map"
100% agree. "texture map" are really useful and to be able to apply
them on a cluster would be nice. Again, it looks like a re-design of
the actual cluster object.
About the texture map property, it could be really useful if we could
use them for the bump too...
1/2
--
Guillaume Laforge | La Maison
On Wed, 02 May 2007 01:03:50 +0200, Andy Jones <andy(at)thefront.com>
wrote:
This is my experience as well. The hack of getting at cluster
materials
through proxy objects, while occasionally a useful hack, isn't
really a
scalable production-worthy strategy. If I'm not misunderstanding
the
setup you're describing, I think it also has the problem that you
can't
override the same material on two different clusters two different
ways. So, for example, if you want to make a set of objects blue
and
another set of objects green, you can't really gaurantee that it's
possible if you're using cluster materials. Also, this doesn't
give you
cluster visibility control, or overall material overrides. Just
shader
overrides.
I think we need a) a much improved implementation of the "texture
map"
property that works with clusters and allows mapping of values,
textures
and shader sub-trees, b) a way to put clusters in partitions (with
some
of the logical conundrums worked out. Like, is every cluster in
the
background objects partition?), and c) a thing I've never actually
heard
anyone ask for yet:
Multiple partition sets. Currently, in each pass, you get one set
of
partitions and they're mutually exclusive. So, you have to define
properties at the most granular level, with objects sorted into
lots of
highly specific categories. Instead, I'm proposing that it should
be
possible to have sets of partitions grouped together so that
they're
only exclusive within each group. That way, you could have, for
example, a dedicated partition set just for dealing with
visibility.
Then, you'd do all your shader stuff elsewhere. In the current
implementation, you end up with a horrible multiplicitive
relationship,
the more things you try to control, forcing you to need lots of
partitions with highly specific behaviors that are difficult to
understand. I think with objects, it's not so bad, but once you
start
partitioning at the cluster level, you really need something more
specific. Especially since overrides for clusters often work a
little
differently than overrides for objects.
- Andy
Graham D Clark wrote:
Hey Guillaume, yeah thats similar to the technique I setup on
Barnyard
for subassets, using dummy geo as a standin and presets to switch
to
various subassets so we didn't have to have tons of extra models
of
characters with only a few parameter differences.
Unfortunately things change in a story and we have to rebuild
assets
and then automate the cluster overrides and presets, and for some
damn
reason it didn't always work (not suprising being a kludge)
requiring
manual eval by a TD each time.
And you've touched on our tracking issue requiring attaching a
node to
the model.
Regarding passes SDK no its not impossible, we did it too, it just
wasnt as pleasant as the rest of XSIs areas via SDK (except for
fxtree), The partitions part still needs work.
-
---
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
|
