I Need Once Per All To Understand The Following...

[Visual Cortex Lab]

Like topic says... I need to understand clearly and once per all why houdini is behaving that way which is not what i expect.. and I've got couple of easy/newbie question which i never found answer myself or in doc.

first and main problem.. polyextrude SOP

in the two attached attached Pics there's a simple torus.. from which i wanted to extrude some ofthe polygons faces.. to start my poly modeling..

I seriously need to understand WHY houdini behave that way when working with many faces.. when scaling the handle with "keep shared points togheter" i simply go crazy and almost hate this proggy.. they scale all in a different axis and amount.. how's this!? they should scale uniformly and considering the face normal as far as I ever worked with Polymodeling.. or I am wrong?! well they're not in houdini.. or at least I'm not able to get such result. every time i have to extrude some faces which arent living on the XYZ world plane.. its a pain in the ... yeah. now I wish to find the solution to this..

now try the same with "keep shared points togheter" unchecked.. even worst.. every single polygon simply goes crazy and this makes no sense to me.. ther's a normal which is the same for every polygon.. why the behave all in a different way from each other??

in the ALT+LMB i see "aling handle to object, word and view" .. and where's the "handle aligned to prrimitives" then?.. i guess that' missing imho.

now couple of easy questions.. which as well makes me quiet stuck sometimes..

- how do i delete edges?! i mean.. without having all the surrounding faces blasted as well.. i tried "delete" and "blast" SOPs.. now luck.. i cant delete just a edge.. it removes all the surrounding area. what i want is do delete an edge which splits a polygon for example..

- same with points... how do i delete "just a point" (which obviosuly cuts in two part an edge.. not a "shared" point which would obviously delete all the faces as well..

sorry for those stupid question.. but what' i'm pointing (yeah .. i know most of the people will laught here) is to use Houdini (since I reach to target to get it into our pipeline) as a "complete" tool... not just to move particles or use Point SOP .. i want to model with it sometimes.. cause I actually like to model and i wish to do it in Houdini.. but those simple steps make me really stuck and i have to go back to XSI for modeling even easy things.. which sucks to me.

cheers.. and thanks for any help on this.

[peliosis]

Hello sum,

The polyextrude is really wicked here:) I don't know how to fix this, but if you want to delete a component just try dissolve, like in xsi.

When mentioning xsi...it would gain if there was a tool like polyextrude:) apart from mentioned cases it is a great sop.

[Visual Cortex Lab]

Hello sum,

The polyextrude is really wicked here:) I don't know how to fix this, but if you want to delete a component just try dissolve, like in xsi.

When mentioning xsi...it would gain if there was a tool like polyextrude:) apart from mentioned cases it is a great sop.

24558[/snapback]

hm... actually i just tried dissolve.. and I dont get why i never tried before.. or .. if i tried in a bad situation and then i misunderstood the command... thanks for the advice then.. this is what i wanted about deleting edges

about the polyextrude... i still dont get why it behave such a crap way... there must be a reason tought... and i want to know the correct workflow to archieve a result which imho is what extrude should do.

cheers.

[Visual Cortex Lab]

... sorry but.. almost 40 visits and nobody have something to say?.(apart peliosis which i thanks again).

I must be the only one having this problem.. or the only one modeling with houdini maybe.. dunno...

cheers

[Mcronin]

I'm not sure what you are expecting to see... The polyextrude tool defaults to a local handle. When you extrude, each face extrudes along it's own normal. You can right click the handle and uncheck local control which will center the handle to the selection and extrude all faces along that vector. Perhaps that is the behaviour you want?

[Visual Cortex Lab]

I'm not sure what you are expecting to see... The polyextrude tool defaults to a local handle. When you extrude, each face extrudes along it's own normal. You can right click the handle and uncheck local control which will center the handle to the selection and extrude all faces along that vector. Perhaps that is the behaviour you want?

24563[/snapback]

ok.. then it must be me and my crappy english.

Create a Torus.. select few faces (that shares points) .. extrude 'em and yeah .. they move alon their normals... now scale 'em..but on X axis only (or one you prefer), and even uniformly on all axis.... not bad enought?... then rotate 'em.

now its more clear what I'm talking about?.. scaling 'em just makes every poligon, with no reason to me, scales differently from each other.. this doesnt make sense... and second.. if you choose just X axis.. should be the X axis (local or global) for each poligon... so why EVERY poligon stretches and squashes instead of being scaled on a axis?... maybe local axis are fucked up somehow?... its like every polygon have a fucked up orientation on its center (which with more than ever needs.. that should be visible for example..) and many have even the "center" of such scale away from the polygon center... which make even less sense.

this doesnt change with or without "keeep shared points togheter"..

but i guess we'll never sort this out.. my english sucks.. and i cant explain this thing apparently... I see the problem so obvious.. while nobody else sees it.

I've bee told to extrude then use "primitive" SOP.. i've been told this is an old V5 bug... I've been told its "normal.. this is the desired behavior"... so i really dunno where the thruth stays now.. the fact is .. that this way.. there's no a workflow I can use.. cause everytime.. the behavior is different since everypolygon have their own orientation, and what makes non sense then its such orientation then. all turned randomly..and no relation with others polygon... crazy.

anyway .. that's all.

I'll give up on this... like i'll give up on the "edit and group selection bug"... which has been talked so much .. but its still there.. and when both bugs comes out at same time (like 2 hours ago).. now that pisses me so much .. cause makes me close down the proggy .. and get drink a coffe to try to calm down.

cheers.

[sibarrick]

I agree it doesn't work right. I've come across it a few times but since I don't use it that much I've never worried about it. If I was using it all the time I think I'd end up writing my own, I've definetely have annoyed support about it by now.

Ok I can understand why it is difficult to determine the local axis orientation of a polygon, but surely with the addition of an up axis the problem is solved. Or maybe it could use an edge and the normal to determine the axis, either way I'm sure it could be made to work better.

I'll try putting an example file together and sending it off to support.

[Mario Marengo]

I'm like Simon -- hardly ever use the thing. But yeah, I just tried it and local transformations seem busted to me too. It seems to only use the local frame (coordinate system) of the first primitive in the group (to verify you can, after selecting, extruding, and transforming, go to the SOP and change the primitive order). The first prim in the list becomes the (single) "local" frame. And intuitively, the behavior should be a separate frame per selected face when applying transformations with "keep shared points together" off.

As far as internally being able to derive a separate frame per face... I'm fairly certain that would be trivial

[Visual Cortex Lab]

Thanks GOD... so i'm not drunk or blind.

.... or .. i'm not the only one

cheers.

[Wolfwood]

Thanks GOD... so i'm not drunk or blind.

.... or .. i'm not the only one

cheers.

24571[/snapback]

Yea its not just you. Non-uniform scaling the primitive sop can cause problems too.

Something is iffy with the keep shared points together option. I don't know what its doing now but what if it internally unfused the points at primitive intersections, did the scaling/extrusion, then fused the points at the intersections back together by averaging their positions.

[sibarrick]

As far as internally being able to derive a separate frame per face... I'm fairly certain that would be trivial

24568[/snapback]

Ok you got me, why is this trivial? I can see why its trivial to come up with a per poly FOR but you need them to be consistent to each other which might not be so trivial, yes/no?

[Mario Marengo]

Ok you got me, why is this trivial? I can see why its trivial to come up with a per poly FOR but  you need them to be consistent to each other which might not be so trivial, yes/no?

24574[/snapback]

What I meant by "trivial" is that the code is obviously already there: change the primitive order and you'll see the handle (frame) hop to each face and orient itself in a nicely consistent way -- so if it's already there, it would seem trivial to just... uhmm... use it -- at least that's what it looks like from the outside...

But I think you're talking about rolling your own... I'd have to give it some thought, but the first method that comes to mind might go something like this:

1. Each face's N is given (or computed).

2. Pick a face, and build a frame 'Z' for it using any method you like.

3. For every subsequent face 'f':

-- Transform f.N to space Z, giving you f.N'

-- Compute dihedral matrix M to orient Z.N to f.N'

-- The current face's frame is M*Z transformed back into object space

something like that anyway... I'd probably start there. But like I said, it looks to me like they already have something that works just fine...

[George]

Alright, let's see if I can try to explain what's going inside PolyExtrude's brain.

The first thing to note is the very significant difference between Local and Global transforms. In Local, the face that was selected is used to compute a local transformation. The frame is built using the normal and the first edge of that polygon. So 'X-axis' in local space is really not at all 'X-axis' in global (which is the x-axis you would expect). In local space, X-axis is along the first edge, Z-axis is along the normal and Y is the remaining orthogonal axis. A quick test, just pick a face and change the local TZ parameter -- you'll see it extrudes along its normal.

Okay, now we've selected multiple faces though. How is the local matrix computed for each face? That is controlled by the Local Symmetry option. If set to no symmetry, then the frames for the "other" faces are built from their normal, and from one of the axes of the original polygon (who's handle you're moving). The other symmetry options, use the normal of the face, but the other axes are mirrored. The purpose for all of this is to get symmetric behaviour when extruding on two opposite ends of a model (e.g. horns on a character, wings on a plane, etc...).

The reason I think you're seeing behaviour you don't expect is because the other faces aren't using their own edges for local x and y axes. If this is the real source of the problem, then I think it should be added as a fourth option to local symmetry, since it seems it would give folks more expected behaviour if they didn't know all that was going on behind the scenes with the symmetry. Note though, that even with this option, depending on how your geometry is modeled, the "first" edge could be very different from one polygon to the other -- (that's why the no symmetry option tries to use a more or less consistent frame).

Now as for the Global option, that is the safest to use when you want to scale and rotate many polygons at the same time, because it applies exactly the same transform to all the polygons -- with a very predictable frame.

I hope I helped more than confused

George.

[Mario Marengo]

Hey George,

Thanks a lot for that great explanation!

Much appreciated.

If set to no symmetry, then the frames for the "other" faces are built from their normal, and from one of the axes of the original polygon (who's handle you're moving).

24576[/snapback]

I'd say that's the source of the unexpected behaviour right there. That's what makes it feel as though the picked frame is the only one being used (even though the others are aligned to their respective planes, so no, they're not the same but it *feels* that way because the XY pair is tied to the original).

Maybe adding an option for using the "first edge" as a binormal is the way to go, though I wonder what would happen with meshes made from many different n-gons (say the soccer-ball as a simple example)?

Is there not some way to relate them as some transformation (rotation) of the original so that their relationship feels more coherent/intuitive?

[George]

Maybe adding an option for using the "first edge" as a binormal is the way to go, though I wonder what would happen with meshes made from many different n-gons (say the soccer-ball as a simple example)?

24577[/snapback]

That's exactly right. That's the problem that was being avoided by having "no symmetry" option use a frame that's dependent on the first polygon. Because you're right, if we just use the first edge, then that edge just might be oriented in the opposite direction (giving you *really* unexpected results) or even orthogonal to the first one. And since the handle is presented on the first polygon, you'd want the rest of them to follow along in a somewhat natural order. Which I guess brings up your next point.

Is there not some way to relate them as some transformation (rotation) of the original so that their relationship feels more coherent/intuitive?

The only axes we know we want for sure are the Z's to line up with the respective normals. So we come up with a frame from the first polygon, then we find the rotation from that Z to our face's Z and apply the same rotation to the first face's x and y to use as our x and y. But there you may run into some issues too, where you can have reversed frames where you might not expect them. Also you're still a little off because you're dependent on the potentially whacky frame that was created for the first polygon. (Imagine for example extruding a square and a trapezoid together, and you pick the trapezoid as your first face -- in that case the square is still going to have an "unexpected" space because its x-axis may not be aligned with its edges). Still I think there's more we can do here.

Thanks Mario,

George.

[TheUsualAlex]

Thanks for all the explaination, George. As always, I really wish I have brain like yours! (mine is filled with mostly nulls)

[sibarrick]

The only axes we know we want for sure are the Z's to line up with the respective normals.  So we come up with a frame from the first polygon, then we find the rotation from that Z to our face's Z and apply the same rotation to the first face's x and y to use as our x and y.  But there you may run into some issues too, where you can have reversed frames where you might not expect them.  Also you're still a little off because you're dependent on the potentially whacky frame that was created for the first polygon.  (Imagine for example extruding a square and a trapezoid together, and you pick the trapezoid as your first face -- in that case the square is still going to have an "unexpected" space because its x-axis may not be aligned with its edges).  Still I think there's more we can do here.

Thanks Mario,

George.

24578[/snapback]

See, none trivial

This was why I was wondering about an up vector hint. If you use dihedrals reversing frames are always a problem. Or how about doing something like making sure that each frame isn't flip by doing the dot between each local x axis, if it flips, flip it back.

One other problem I've spotted (didn't spend long trying to figure out if there was already an answer) When using the global transform how do you specify the pivot point? Since there is no handle and no pivot channels where is it? I was getting some really whacky rotations using global because the pivot point seemed to be miles away from where I needed it. I'm sure there must be something obvious I missed.

George, do we still need to send in an official support call for this or can we assume that is done?

[Visual Cortex Lab]

Thanks a lot George and everyone here.

I come from XSI .. and it's possibile that I still have to better understand Houdini in many sides.. I might consider then to model in XSI and then export to Houdini... which wasnt my plans just cause I'm getting so motivated and I wanted to do everything in Houdini.. modeling included, not mentioning that I'm not used to the Houdini workflow for modeling as well.. and I find it realy cool... but polyextrude is one of the most command I use when I model anything from organic to non organic.. and it comes hard to avoid getting stuck.

anyway .. i hope SideFX will "improve" the modeling part of houdini soon.. cause it deserve a larger "odiens" out there

cheers and thanks again..

[sibarrick]

I know this is something that keeps coming up, but in relation to this thread I think its worth saying. One of the reasons I don't use polyextrude is because i model in a "Houdini" way. Mostly cos I've been using it so long I don't tend to use the "accepted" practises that come from using other packages. That's not to say you shouldn't want to work that way or that Houdini should stop you, but if you have time its worth stopping and thinking is the "accepted" way necessarily the best way.

[edward]

On the otherhand, I don't see how one can use XSI to accomplish what the PolyExtrude does with symmetry. In Houdini, you can take a modelled torso and then pretty much only using PolyExtrude's to model both arms at the same time.