Jonathan Mack

jsmack

About Me

Expertise
Hobbyist
Location
United States
Website

Connect

Recent Forum Posts

Gltf import from Nomad Sculpt Aug. 9, 2020, 2:17 p.m.

Benjamin Lemoine
the develloper suggested that maybe those are packed …
and wrote :
packed = 11387939
red = packed & 0x0000FF
green = (packed & 0x00FF00) / (1<<8)
blue = (packed & 0xFF0000) / (1<<16)
but i'm not sure i could do this in vex…

Is that supposed to create a teal color?



I translated it to vex as such:

int packed = 11387939;
int red = packed & 255;
int green = (packed & 65280)/shl(1, 8);
int blue = (packed & 16711680)/shl(1,16);
@Cd = set(red,green,blue)/255.0;

It's redundant to divide by the shifted bits, when you can just shift right I think.

This produces the same output:

int packed = 11387939;
int red = packed & 255;
int red = packed & 255;
int green = shrz(packed & 65280, 8);
int blue = shrz(packed & 16711680,16);
@Cd = set(red,green,blue)/255.0;

As a bonus you can also decode alpha, but it's tricky since VEX doesn't have uint:

int packed = i@packedcolor;
int red = packed & 255;
int green = shrz(packed & 65280, 8);
int blue = shrz(packed & 16711680,16);
int alpha = shrz(packed & -16777216,24);
alpha = select(alpha<0, alpha+256, alpha);
@Cd = set(red,green,blue)/255.0;
@mask = alpha/255.0;

and encode:

int @packedcolor;
float r,g,b;
int red,green,blue,alpha;
assign(r,g,b,@Cd*255.0);
red = (int)r;
green = (int)g;
blue = (int)b;
alpha = (int)rint(@mask*255.0);
green = shl(green, 8);
blue = shl(blue, 16);
alpha = shl(alpha, 24);
@packedcolor = red | green | blue | alpha;

Applying FBX scale (pre) transforms. Like in Blender. Aug. 8, 2020, 3:32 p.m.

malbrecht
> Why not leave the scale alone in houdini, it would make round tripping a lot cleaner

… well, scaling of other assets for sure is one reason, but most importantly, simulation usually requires “more or less natural” scales. The moment you want to sim cloth, destruction etc, your scale needs to be “sane”.
Then, measuring comes to mind. If you're not “eye-balling” your stuff but have to deliver correct-ish results (I used to do animations for documentation back in the days, before my Houdini times), you may have pre-established camera extrinsic and intrinsic, so that you need to “stay in focus” (pun intended). Not sure if something like that is “a thing” for game engines, not my area of expertise.

But in general, I wouldn't like to work in the wrong scaling. Ever. :-)


Marc

There is no such thing as a natural scale, it just has to be known. Set the scale on the simulations to the scale of the world. There's a handy hip file preference for the world scale that controls simulations. A factor of 100 is just cm scale which is a perfectly reasonable scale to work in, especially for character-sized simulations. There is no more or less ‘eye-balling’ with one scale over another, when the scale is known.

Unfortunately scaling rigs in houdini is virtually impossible without causing major pain. If the FBX was just geometry, then it would be no big deal, just work however you want, but because there is a hierarchy of joints and controls, there's no easy way to rescale the rig.

It might be feasible to work with a scale on the to root of the FBX, then remove it when exporting. That way it should be possible to tweak the animation without affecting the scale of the rig. The scale of the animation on the controls will still be in the original scale.

Will recursion be supported in wrangle in the next version ? Aug. 8, 2020, 2:49 p.m.

probably never