• ltethe
  • Asking for seconds
  • Email
  • Posts 26
  • Reputation 0
  • Member Since
  • Last Active
Email
All Posts Topics Started Likes
Houdini attributes to Maya using array to point color
Peter, I confirmed, vertex color in/out with alembic is no problem.

It's getting the vertex color in out of the copier node that is more puzzling to me.

Maya 2014. I'm pretty sure that it writes out color, as the alembic cache is 3x bigger, but have not successfully brought in the alembic cache with color data from a polySurface that was created via copier node.
0 0
Houdini attributes to Maya using array to point color
Hmm... Ok, some experimentation after viewing the pointCloudToMesh example.

I'm getting some sort of result. Output mesh -> mesh2arrays -> pointCloudToMesh -> polyShape, not sure if this will transfer any sort of color data however.

I also tried output mesh -> pointAttributeToArray -> pointCloudToMesh -> polyShape. Which is what the example did, but I haven't got any sort of output from that.

Also, to keep things simple, my vertex colors are only black and white, so though I'm not seeing anything, I suppose there could be a line from 0,0,0 to 1,1,1.


0 0
Houdini attributes to Maya using array to point color
That sounds promising, though how did you export the color array independently of the position array? More soup?

RGB to arrays to polymesh to alembic cache?

Hmm, sounds like it might work.

If I'm wrong, then details on how you did it would be awesome. Thanks for the inspiration Pizzaman. Nice job on the Asterix as well. US fan of the comics, pity there's not much of an audience her in the states.
0 0
Houdini attributes to Maya using array to point color
Hmm... Ok, broke it down. The alembic export/import works fine, it now appears to be the fact that I'm trying to cook out vertex color from the copier node is the problem.

Small progress, but still stumped.
0 0
Houdini attributes to Maya using array to point color
Anyone have any experience with exporting maya alembic with vertex color data and then importing that cache back into maya?

I don't need the data transfer from different applications, I simply use the cache to blow out the dynamics for the lighters.

I used the -wcs and -rcs flags with abcImport and abcExport. I'm pretty sure the vertex data is written successfully as the scene file becomes 3x larger then if I don't use the
-wcs flag. That being said, I haven't found a successful way to bring color in, I'm unconvinced there is any color data being imported at all. I've tried all the methods above to route this all through Soup nodes, but I don't think any color data is coming in in the first place. I don't see any color sets in the color set editor, I don't see any extra vector data when I select a vertex.

I am using 2014, if that makes any difference.

~stumped.
0 0
shaders to copier node.
plars, you're a life saver again.

Example was succinct and allowed for me to dick around with it till comprehension came. Like I said, I don't know why but the one in the Soup example scene file hard crashed my comp anytime I touched the output polysurface node in the node editor, so your scene was key.
0 0
shaders to copier node.
Is there an example scene where I can plug different shaders into the copier node for each object instanced/copied?

Simple problem. 3 objects, all with different shaders, I want them to exhibit those shaders after they're copied via the copier node.

I tried taking a look at the copier materialOverride example, but it's using one object as opposed to several, and when I try and recreate the network, the instanceObjectGroup won't hook into the surfaceShader dagSetMembers.  Gives me a syntax error every time. Further whenever I try and interface with the output mesh in the node editor, it hard crashes my machine, making analyzing this scene file difficult.
0 0
aim particles with locator and copier node
Hmm... You're very right Peter, piping the nParticle's position directly into the attributeTransfer.inGeometry works just fine.

That clears up some logical inconsistencies I was experiencing. 

So now the question is, why does it work with a pointCloudtoCurve node? I assume the node is self descriptive? I feed a point array in, I get a curve? What comes out though? The same array as outCurve?
0 0
aim particles with locator and copier node
Ah, sorry Peter. I've got a bounding object scaling my particles that are fed to the copier node; as per one of the example scene files. [At_particles] 

It all makes sense to me except the nParticleShape -> particleCloudToCurve -> attributeTransfer. I don't quite understand the logic here, and why the pointCloudToCurve node is necessary. This kind of stuff is what trips me up on Soup currently.
0 0
aim particles with locator and copier node
Sweet stuff. I'll have a play with it all, thanks Plars.

That dynamically deforming nurbs surface is a trip. Starting to wrap my head around SOUP workflow. My main hurdle is understanding when I need to use data containers to transfer one type of data to another.

Even this copier node, the fact that I need to create a pointcloudToCurve from the nParticle and then pipe it back into the attributeTransfer, is not intuitive to me at all.
0 0
aim particles with locator and copier node
That's the kind of hackery I was expecting, but never would have found on my own. Very cool example plars, going into my SOUP examples.

TBH though, I'm not sure I fully understand what the point node does though. Is it simply a way to enact expressions on point data in the event you're not using a particle system?
0 0
aim particles with locator and copier node
Well that's sexy, and easy. Thanks for putting that together plars, quite informative. Woulda saved me some headaches. Oh well, I got multiple solves, and a better understanding of what's going on behind the scenes. Thanks again!

And perhaps you all think me thick, but I'd nominate plars scene to go into the SOUP example scene folder to illustrate this particular way of hooking up rotation data to the copier node.
0 0
aim particles with locator and copier node
Well, I'm still not sure why exactly that quadrant sucks, need to do more linear algebra remedial courses.

In any case, I did notice that the copier node has the option to plug in radians instead of degrees, so...

Much easier expression with less conditional to parse. 

Code:

vector $aim = <<1,0,0>>;
vector $position = nParticleShape1.position;
float $rad = `angle $aim $position`;

if ($position.z >= 0)
nParticleShape1.rotationPP = <<0, -$rad, 0>>;
else
nParticleShape1.rotationPP = <<0, $rad, 0>>;


The nice thing about this one, is I don't notice flickering particles, which I'm assuming is a gimble flip. Degrees can rot, I like these rads here.


0 0
aim particles with locator and copier node
Argh, so close.

badZ.jpg 

In the -x, -z quadrent, the particles seem to choose to face the origin arbitrarily, like every other particle decides to rebel and turn away. I can add another conditional statement easily enough for particles in that quadrant no problem, but I don't fully understand why some of them face appropriately and others don't, and as a result, I don't really know what to change in the expression to fix it.


0 0
aim particles with locator and copier node
Code:

vector $position = nParticleShape1.position;

float $angBet[] = `angleBetween -euler -v1 1 0 0 -v2 ($position.x) ($position.y) ($position.z)`;

 

if ($position.x <= 0)

nParticleShape1.rotationPP = <<0,-$angBet[1]+180,0>>;

else

nParticleShape1.rotationPP = <<0, $angBet[1], 0>>;



Ok, this is a solution I found that worked. Put this expression into the rotationPP, and feed that into the copier input Rotation PP.

I had all this code yesterday, but it was hurting my head. Had to get more Khan in to get a grasp at what all of the code was doing.

Learning, is good.

Anyhow, if there's a way to do this more simply with SOUP, I'd love to hear it so I don't have to evaluate an expression every frame.


0 0
count post selected

Add a Website Forum to your website.