Found the issue.
So it seems even though the MPxDrawOverride has it's own boundingBox
method, the boundingBox that's actually being used by vp 2.0 is the
boundingBox returned by the MPxLocator class. Found this issue when I
returned the objPath.node()->boundingBox in the MPxDrawOverride boundin
Hey Paul,
The intent for Kraken is to provide a rigging framework that is consistent
across DCCs. You write a component once, and define a rig in a .krg file
(using the UI or code) and it can be imported to Maya, Softimage, etc. and
built and it will behave the same way. The thing left from there
I think the promise here (or, at least, what I'm excited about) isn't so
much a feature set as it is portability. ie, I'm sure most companies
rigging departments now have scripts / toolsets that do much the same stuff
that kraken aims to... BUT what kraken will potentially allow is to have a
stand
I did implement the boundingbox in both the custom MPxLocatorNode class and
the custom MPxDrawOverride class. They're both being generated the same.
I'm using an MMatrix to transform the boundingBox. I've even gone as far
as manually calling the boundingBox method from within the prepareToDra
*addon:*
I made a few locators in VP2.0 and it should work if you draw the* same geo*
in VP1.0 as in VP2.0, than you can select it.
On Friday, January 29, 2016 at 8:43:45 PM UTC+1, Janos Hunyadi wrote:
>
> Did you implement the BB, and selection on the legacy VP 1.0 part
> too (selection still h
Did you implement the BB, and selection on the legacy VP 1.0 part
too (selection still happens there), not just the VP 2.0 override?
On Friday, January 29, 2016 at 1:49:43 AM UTC+1, Daniel Lindsey wrote:
>
> Has anyone else had this issue? I have a custom locator, that has
> attributes on it t
Thanks, tried all three versions (2014-2016). They all have the same
issue, which makes me think it's something I'm doing.
The weird part is, it works perfectly well in the legacy viewport in all 3
versions. And I'm computing the boundingbox the same way
for both the legacy and vp2 locators.
O
Haha, this works great. Performance-wise I couldn't pick up any difference,
though I haven't run through enough tests to be conclusive. The local disks
here are rather quick, but likely it would make more of a difference in a
fully networked environment, or where disks were slow.
The obvious upsid
Hey,
Well i dont know you got the answer but what i think from your picture you
drew, you can take the local space position of original mesh. then add your
offset and calcualte the offste with this original mesh points. may be even
a vector of direction
v = pt2-pt1
then add your deformation an
Hey, what version of maya are you using? because there is some
supportability issues of viewport 2.0 in maya 2014 and 15.
I wouldn't want to use vp 2.0 with draw functions for now until it gets
patched but i guess that won't happen.
But 2016 Maya has some improvements may be you can try on it.
10 matches
Mail list logo