[Sidefx-houdini-list] HDK: op:/ magic

Szymon Kapeniak szymon.kapeniak at gmail.com
Thu Jan 20 17:20:01 EST 2011


...sorry for spamming, but I've just realized that the same dso works
in mantra, but not in (threading) sop context. Kind of strange.

2011/1/20 Szymon Kapeniak <szymon.kapeniak at gmail.com>:
> Thanks for a response, I didn't know I have to deal with it manually.
>
> Second problem is threading in vex sop. After playing with my function
> a little, I'm getting a feeling my approach was too naive, so to
> speak.
>
> Is multi-threaded access to a static GU_Detail * possible at all, or
> do I have to use some caches like UT_ThreadSafeCache or anything
> similar? What is a general way of doing this in HDK?
>
> thanks,
> skk.
>
>
> 2011/1/19 Olex P <hoknamahn at gmail.com>:
>> It kind of does writing an op-referenced texture into an IFD :)
>>
>> On Wed, Jan 19, 2011 at 1:48 PM, Mark Elendt <mark at sidefx.com> wrote:
>>
>>> For mantra, even Houdini's VEX doesn't support the op: syntax :)
>>>
>>> For VEX functions in OPs, you should be able to access the SOP by
>>> grabbing the OP director and finding the SOP.
>>>
>>> On Wednesday Jan 19 at 13:39, Szymon Kapeniak wrote:
>>> > thanks Mark,
>>> > but how about custom vex dso? My func() opens file from disk, but
>>> > doesn't handle op: syntax. Is it doable in custom code?
>>> >
>>> > thanks,
>>> > skk.
>>> >
>>> > 2011/1/19 Mark Elendt <mark at sidefx.com>:
>>> > > Unfortunately, at the current time op: is handled as a special case,
>>> > > so it's not part of the generalized loader.
>>> > >
>>> > > You'll have to reference the geometry directly (i.e. cook the SOP).
>>> > > If you need your own copy, you'll have to merge it.
>>> > >
>>> > > On the other hand, opdef: is handled properly.
>>> > >
>>> > > On Wednesday Jan 19 at 12:11, Olex P wrote:
>>> > >> Maybe you right Szymon. Most of the usage of op: syntax for me was
>>> sampling
>>> > >> from point clouds/volumes/textures and I have never tries to load
>>> geometry
>>> > >> using op: syntax. File SOP doesn't work with it and I think it's
>>> because of
>>> > >> the fact that load() expects a proper file format. Would be great to
>>> hear
>>> > >> about this from SESI.
>>> > >>
>>> > >> On Wed, Jan 19, 2011 at 11:58 AM, Szymon Kapeniak <
>>> szymon.kapeniak at gmail.com
>>> > >> > wrote:
>>> > >>
>>> > >> > hi Olex,
>>> > >> > thanks for fast response. Well, I must be doing something stupid,
>>> > >> > because it doesn't.
>>> > >> >
>>> > >> > GU_Detail gdp;
>>> > >> > const char *file   = (const char *) argv[1];
>>> > >> > if (gdp.load(file, 0) < 0) return ;
>>> > >> > ...
>>> > >> >
>>> > >> > while works fine with disk paths, doesn't work with op:/'ed one.
>>> > >> >
>>> > >> >
>>> > >> > 2011/1/19 Olex P <hoknamahn at gmail.com>:
>>> > >> > > Hi Szymon,
>>> > >> > >
>>> > >> > > I don't think that you need any magic. op: syntax has to be
>>> handled
>>> > >> > > automagically when you using
>>> > >> > >
>>> > >> > > [code]virtual int          load(const char *, const UT_Options
>>> > >> > > *options);[/code]
>>> > >> > >
>>> > >> > > method.
>>> > >> > >
>>> > >> > > On Wed, Jan 19, 2011 at 11:41 AM, Szymon Kapeniak <
>>> > >> > szymon.kapeniak at gmail.com
>>> > >> > >> wrote:
>>> > >> > >
>>> > >> > >> greetings!
>>> > >> > >>
>>> > >> > >> what is a magic to let  my GU_Detail class to ::load() both files
>>> from
>>> > >> > >> disk as operator's streams with op:/path syntax? I can see load()
>>> > >> > >> with an UT_IStream as argument, but I have no idea how to use it.
>>> Does
>>> > >> > >> any of UT_Stream versions handle both files and steams or the
>>> logic is
>>> > >> > >> on my side?
>>> > >> > >>
>>> > >> > >> thanks,
>>> > >> > >> skk.
>>> > >> > >> _______________________________________________
>>> > >> > >> Sidefx-houdini-list mailing list
>>> > >> > >> Sidefx-houdini-list at sidefx.com
>>> > >> > >>
>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>> > >> > >>
>>> > >> > > _______________________________________________
>>> > >> > > Sidefx-houdini-list mailing list
>>> > >> > > Sidefx-houdini-list at sidefx.com
>>> > >> > > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>> > >> > >
>>> > >> > _______________________________________________
>>> > >> > Sidefx-houdini-list mailing list
>>> > >> > Sidefx-houdini-list at sidefx.com
>>> > >> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>> > >> >
>>> > >> _______________________________________________
>>> > >> Sidefx-houdini-list mailing list
>>> > >> Sidefx-houdini-list at sidefx.com
>>> > >> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>> > >
>>> > > --
>>> > > Mark Elendt
>>> > > _______________________________________________
>>> > > Sidefx-houdini-list mailing list
>>> > > Sidefx-houdini-list at sidefx.com
>>> > > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>> > >
>>> > _______________________________________________
>>> > Sidefx-houdini-list mailing list
>>> > Sidefx-houdini-list at sidefx.com
>>> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>
>>> --
>>> Mark Elendt
>>> _______________________________________________
>>> Sidefx-houdini-list mailing list
>>> Sidefx-houdini-list at sidefx.com
>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>
>



More information about the Sidefx-houdini-list mailing list