Hi,

When the handle is in local control and aligned to object, it's all twisted (see attached pic), anyway to fix this ? I want to extrude along the face normal (which I though local control was for).

edit : by displaying primitive normals, I saw the direction of the axis is the same as the displayed normal, but it seems it's some kind of smoothed normal, thus the wrong angle…


Also, is it possible to have hotkeys for the different shading modes ? or change the w hotkey to change between smooth shaded and smooth wire shaded ? And hotkeys for toolbars operations ?

Also is it possible to define some defaults parameter for sop nodes ?
For example to have keep points shared on average position by default for the polyextrude sop ?


On the suggestions side, it would be very nice to have :
-edge grouping for procedural beveling
(even better, edges selection based on faces angle, this actually exists in cinema 4d)
-possibility to generate quads for the polyloft node, have it work with edges, and viewport operations for points (edges) stitching (making it a proper 3ds like bridge tool, even if one can get away with polyknit and polycap)

edit : actually I have a problem with the polyknit sop. If I want to use it after a sop that displays a selection (group sop, facet sop, polyextrude sop, …) the little red circle won't let me click on the selected points (from the last sop). Had to put down a sop that did nothing as a workaround.

-angular snapping, for easy operation of the clip plane handle in the viewport.
- a wedge (maya feature) or hinge from edge (3ds feature) sop ?

-the edge divide sop is nice, much like a procedural version of the connect of 3ds, but if I select the edges dragging a selection in the viewport, they are not selected in the right order and thus the “connect points” gives wrong results.
A ring selection to complement it would be very nice.

-the polypatch sop works great with lines, but behaves strangely with polygons. To have a nice patch with 2 grids, I had to rotate one 90° around one axis and 180° around the other, weird.


I've been amazed by the procedural paradigm of houdini since I've been using it (a couple of months ago), finally trying it as a modeler, it's actually not so bad, but could be even better!

(my whole idea was to create a mech army procedurally : a structure with different torso, arms, legs.. parts, and on each part different details (inset/extrude, rivets…) could be added procedurally)


Thanks for reading and suggestions!
Vincent

vinz
Hi,

When the handle is in local control and aligned to object, it's all twisted (see attached pic), anyway to fix this ? I want to extrude along the face normal (which I though local control was for).

This looks like the age-old problem where the handle is being deformed by the object's non-uniform scales. There is no workaround, really.

Don't use object scales for modeling?

Thanks a lot, didn't think my object was scaled, but it was.

Would be nice if it was written somewhere though (polyextrude help?), it can be a bit confusing.


edit : now I'm getting a weird axis orientation in object mode when extruding an edge.

Any idea ? Thanks!

Detach the handle and start point picking to reorient it?

Looks like the scale problem is affecting this handle as well. Try this to fix the problem:

1) Add a transform sop to the end of your current modeling chain.

2) Go to the object level and copy the scale parameters

3) Go back down and paste these values onto the transform sop's scale channels. Paste the real values not references.

4) Go back up and change the sale values to 1, 1, 1.

5) Modeling you now do after the transform should have OK handles.

If you have any rotate values you may need to move them down to the sop level the same way. If you post the file I can tinker with it for you.

edward
Don't use object scales for modeling?

People do all the time (in other software) and freeze them out when they're ready. Think of multiple object modeling for hard surfaces, or blockign out a set with box-modeling.

Besides, there are plenty of times you use object scales for other tasks which are not pure modeling and you really don't want the handles to be skewed like that. I don't know why we've had to argue this point repeatedly for the past year or two: it's completely ridiculous to allow handles to skew like this and the solution is “Dont use object scales for modeling”.

Even Freezing transforms need to be able to be done at the click of a button, not using the (scary) Pre-Transform method but by appending a Transform SOP, so the geometry preserves its new transform if transplanted/object-merged into another object. Having to perform Rob Magee's 5-step process above to perform a simple Freeze Scale is flabbergastingly inefficient.

This is modeling 101, in my opinion; something that Houdini should have supported way before Houdini 9.

Hi, thanks for the answers,

Actually, when I had the problem with the edge polyextrude I had already reset the object transform to defaults.
I polyextruded the neighbouring face (with correctly oriented axis), and blasted the faces I didn't want.
Something else I tried was to use facet to get unique points (which corrected the axis) and then fuse again , but it was safer the other way.

Pagefan, what did you mean ?
Thanks

vinz
Hi, thanks for the answers,

Actually, when I had the problem with the edge polyextrude I had already reset the object transform to defaults.

How did you do this? If you cleaned up the transforms then you ended up putting the scales into the “pre-transforms” which still have the same problems when working at the geometry level.

If you were to post your file, tt would be easier to sort out what is going wrong.

edward
Don't use object scales for modeling?

Object scaling is probably one of the most basic operations that people use on daily bases; set constructions, quick resize of a prop. Yet again my vote is to fix the handles, not limit what operations are done.

Maya modellers are always doing “freeze transforms” to bake in the object level transforms before they model. If they don't, well we can see what happens in houdini. Non-proportional scales at the object level lead to disaster when modelling.

I will submit an RFE to include a “Freeze Transforms” tool.

A character modeller has a non-proportional scale on one of his characters and piled 1 month of modelling on it. Then you were forced to rig the skin as is, weights and all. It would simply not happen. Why? Because nonprop scales are evil.

M vote is to not fix the handles but take it as a warning that something is amiss, post to the forums where we start a long thread…

This must be a joke. This is a HUGE BUG of Houdini, which bites both new and experienced users and what we get from SESI (after many bug submissions and threads on forums) is remarks that we shouldn't do this and that, and to take it as a warning etc. SESI, like a good parent, developed a way to punish us stupid users when we don't work as we are expected to.
I don't care about that. It's a BUG and should be fixed.
If object transforms are evil then take them out completely (and then watch people laugh at the highest end software on the market which doesn't let you do non-uniform scales).
This BUG affects also objects with pre-transforms, which are used in various situations, like rigs and such.
Oh, and a working freeze transforms tools is long over-due.

Dragos

I believe you misread my post Dragos. I clearly typed “Because nonprop scales are evil.” Then followed with a …

Any user in CG needs to be aware that when they introduce a non-proportional scale on an object you need to be aware of the ramifications.

As for the handle scaling issue, it is known and threads like this serve to illuminate outstanding issues.

jeff
I believe you misread my post Dragos. I clearly typed “Because nonprop scales are evil.” Then followed with a …

Any user in CG needs to be aware that when they introduce a non-proportional on an object you need to be aware of the ramifications.

As for the handle scaling issue, it is known and threads like this serve to illuminate outstanding issues.

Relying on this bug to point out that you have non-proportional scales is weak, though. Having distorted unusable handles is just ridiculous for a piece of $7000 software. If you want to educate the artist that he has non-proportional scales, find another way that doesn't cheapen Houdini.

The proof is in the pudding: just look at the “wtf!” reaction to distorted handles. Clearly this technique to indirectly “warn/insult users” is not working at ll.

As I pointed out, there are many non-modeling tasks that require non-proportional scales and I still want my handles to work. There can be doubt that the handles need to fixed, translate/scale/rotate/all freezing needs to put in.

This must the third or fourth thread on this exact topic illuminating the issue.

They are evil, yes. Everybody knows that.

Is Houdini's way of handling them acceptable? No.

As for their evilness, this is debatable to a degree.
As other users pointed out already, they are used a lot in any other applications, for roughly shaping geometry. Of course, any sane individual would follow them with a freeze transform operation, provided that a working one actually exist.
What bothers me to a degree is the “infinite loop” of discussions regarding this. The issue was discussed many times on the forums. It is well known. It was reported to Support. Every now and then someone raises is again. And everytime the discussion repeats, people from SESI explain that we really don't want that and the discussion is drawn into a debate about the evilness of non-uniform scales.
The evilness of non-uniform scales is not the point of the discussion. The point is that we, the users, want to use non-uniform scales sometimes and there are bugs which prevent us from doing so.
It was also discussed that the current viewport workflow of H9.* greatly encourages users (especially new) to use non-uniform scales for shaping geometry, because of the handles available upon the creation of geometry. Houdini encourages users to use non-uniform scales, deals with them badly and offers no fast/obvious way to get rid of them.

Dragos

This is an issue that will certainly need to get addressed at some point in time. Thanks to everyone for providing feedback and making it clear how important this is to you.

In the meantime, our “recommendation” is that you do your scaling at the sop level not at the object level during the early stages of creating a model. In most cases this problem occurs when the FIRST thing someone does is put down a box and scale it. If you want to scale non-proportionally at the end to tweak the final model then that won't be a problem.

If you follow this rule (however inconvenient it may be) then you will NOT have the handle problems that happen right now. It is not that hard habit to get into (however annoying it may be). We specifically promoted display sop parameters to the object level in the Operations controls so that you have quick access to some of these parameters (like Size on a Box).

In the late stages of H9, we tested out locking the scale parameters at the object level to make users more aware of the issue. That was quickly rejected by the testers therefore we have left things open knowing that some people will fall into the trap. A coding solution was not readily available.

Most of the people from sidefx who help you on this forum are not able to directly make the requested changes therefore their suggestions are about helping you today with today's build.

We certainly take the ideas back to R&D meetings and put these things into future plans but not everything can be fixed immediately. R&D assesses the person hours it will take to fulfill each and every request and how deep into Houdini the change would have to go. If the stars align then we go for it. If not then we keep these things on the list for a future release.

Therefore if someone from sidefx suggests a best possible workaround, it is with the best intentions and suggesting that they are being dismissive or complaining that a workaround has too many clicks won't make things happen any faster.

We would prefer to say - oh don't worry that will be fixed in tomorrow's build - but that doesn't always work out. Amazingly it sometimes does which is not something you can say about most software companies who only bring out updates every few months.

Robert

Most of the people from sidefx who help you on this forum are not able to directly make the requested changes therefore their suggestions are about helping you today with today's build.

Oh, we're definitely not holding the fact that you have limited resources against you, ‘coz don’t we all have that problem :? :wink: We're just against the notion that this seems to be not acknowledged as bug that needs to be fixed, not in all the threads that have arisen over this issue in the past couple of years.

We appreciate the explanation of the problem and the work-arounds today, we just hope that it's on the cards to be fixed in near future.

Jason

jason_iversen
We appreciate the explanation of the problem and the work-arounds today, we just hope that it's on the cards to be fixed in near future.

Jason

And the feedback helps us see how important this is. This issue did come up early in alpha testing for 9 and it just wasn't in the cards. Here are a few issues/fixes that are needed in relation to this:

1) Handles inappropriately scaled when inside a scaled object or parented to a scaled object/null. The handles should not be affected by scales.

2) When you RMB on a sop to export geometry, there should be a checkbox (which would be on by default) offering to include object-level transforms into the saved geo file. (lots of people get caught with this one).

3) We need a Freeze tool that takes any transformations at the object level, puts them down at the sop level on a transform sop then sets all the values to their defaults. This could be an option where we either put the values into the pre-transform (not always desirable) or down into a transform sop.

These are the things we know we have to do. Can't say when or how they will be fixed because R&D plans are kept under wraps as much as possible.

Robert

Thanks Rob! I like those points! 8)

Thanks for the clarifications, and sorry to have raised such a hot topic ops: