It's nice to debate with you Guy!
I think I will have to ask someone in La Maison to challenge you to a
duel, but not in Kendo because you would win...
I don't think a lot of people are interested in the details of the
debate anymore...
I think I'm right, and you think you're right.
Have fun with your Blobs and Void Pointers, I will wait for Softimage
to give me Dirty Flags and a better way of storing class instances in
XSI. So meanwhile I will be able to relax on the beach!
Cheers,
Aloys
On 8/28/06, *Guy Rabiller* <guy(at)alamaison.fr
<mailto:guy(at)alamaison.fr>> wrote:
> ../..If you have to cache information, usualy the information
> you're caching is highly specialized, and I don't see why you
> would give access to it to another operator../..
I'm sorry you don't see why, there are full of applications for this.
It's exactly what is done with weightmap tools for instance (
written by
you.. )
Operators 'cache' the datas in weightmaps that can be used by other
operators including XSI native ones.
If it is a weightmap or a udb or a ppg doesn't matter, it is the
same idea.
> ../.. And putting a pointer in a UserDataBlob does not appear to be
> really "good looking" from a design point of view: casting a class
> instance to a void pointer is something that comes from the past,
> don't you think?../..
I don't know where you get that from ?
Tell me, in your Operators, don't you use Classes pointers stored as a
UserData ?
Is it not one of the recommended way of caching datas in Operators ?
What about cpp in mental ray shaders, and class pointers stored as
user
datas or thread local storage as well ?
Sorry to hear that Softimage and mental image don't do 'good looking'
design :/
Perhaps you should investigate i little bit more those technics that
'come from the past' ?
> ../.. Setting up a framework of UserDataBlob is not something I
would
like to do when
> I'm in a hurry to deliver a simple operator that has to be
re-appliable easily...
You certainly have a point here. I am also able to write crappy things
in a hurry.
Sometimes we don't have a choice. I did it, and I certainly will
have to
do it again.
I never felt the need for dirty flags though, even in those cases.
> ../..Having intermediate Blobs only makes things less easily
packagable../..
For the lazy developer, yes. For the user it is as easily usable.
> ../..But the idea is good, and without having access to the dirty
> flag state, it's the best thing we can do to do clever caching!../..
Again, it is two different approaches.
And again, I don't think using dirty flags is clever and dirty flags
will not replace the other approach even if available.
> ../.. But I still think that having access to
> the dirty flag would not go against the
> DAG philosophy ../..
I still think it would..
--
guy rabiller | 3d technical director (at) LaMaison
Aloys Baillet a Ãcrit :
> Hi Guy,
>
> Sorry I was a bit lazy and didn't answer your email this week-end;-)
>
> I do clean my operators indeed, and good design can be internal,
not
> necessarily visible from the outside.
> If you have to cache information, usualy the information you're
> caching is highly specialized, and I don't see why you would give
> access to it to another operator. And putting a pointer in a
> UserDataBlob does not appear to be really "good looking" from a
design
> point of view: casting a class instance to a void pointer is
something
> that comes from the past, don't you think?
> Plus, I was more saying that I am the lazy developper, not you!
> Setting up a framework of UserDataBlob is not something I would like
> to do when I'm in a hurry to deliver a simple operator that has
to be
> re-appliable easily... Having intermediate Blobs only makes things
> less easily packagable.
> But the idea is good, and without having access to the dirty flag
> state, it's the best thing we can do to do clever caching!
> But I still think that having access to the dirty flag would not go
> against the DAG philosophy.
>
> Sorry Kent I think we highjacked your thread here! Proof that it
was a
> good question!
>
> Cheers,
>
>
> Aloys
>
>
> On 8/25/06, *Guy Rabiller* <guy(at)alamaison.fr
<mailto:guy(at)alamaison.fr>
> <mailto:guy(at)alamaison.fr <mailto:guy(at)alamaison.fr>>> wrote:
>
>
> > Fair enough, you can store a pointer!
> > If you do the cleanup...
>
> As for your Operators, not a big deal, really.
> I guess you do cleanup your Operators as well, don't you ?
>
> > ../..The state machine analogy is a good one,
> > but who wants to develop a state machine with
> > operators on Blobs apart from you?../..
>
> Perhaps serious developers who don't want to create monster
monolithic
> unreusable Operators ? :-)
> The added benefit to create 'modules' this way is that each
> modules can
> be re-used for other purposes.
> With a monolithic approach you have to re-assemble
everything each
> time..
> Plus, this way the intermediate datas or informations are
> available, and
> can be used for something else, or for a new feature implemented
> later.
>
> > ../..Lazy evaluation should be
> > available for lazy developpers too!../..
>
> It is. You just have to hook in where it is available. That
said, I'm
> not lazy.
>
> > ../..I remember having to compare each and every parameter
value
> between
> > one call of an operator update and the other, just to see
if the
> custom property
> > connected as an input of my operator had been modified.../..
>
> Well, for this, lazy developers could compare MD5 on PPG
BinaryDatas.
> One sum, one test.
>
> > ../..Adding a UserDataBlob as another layer of complexity
would have
> been painfull and unnecessary!
>
> UserDataBlob has been given as an exemple. Depending on the
problem in
> hands, you cant perhaps use weightmaps or other cluster
properies,
> or a
> PPG, etc..
>
> --
> guy rabiller | 3d technical director (at) LaMaison
>
>
