Ahhh! Thread necromancy! It was over a year old. =P

I'm not familar with the “Knife” tool. Is it similar to the PolySplit SOP?

Wolfwood
Ahhh! Thread necromancy! It was over a year old. =P

I'm not familar with the “Knife” tool. Is it similar to the PolySplit SOP?

I think the Clip SOP is actually identical to a knife tool.

Dragos

Kind of a combo of Polysplit and Clip. Basically, you interactively draw in the viewport, and the polygons behind are sliced a la polysplit. Very fast and intuitive. Polysplit is very slow, but also intuitive. Clip doesn't give you fine enough control.

Cheers,


Peter B

To make it Houdinized it would be cool if you could just draw a line across the geometry in the viewport and in the background houdini built a cutting surface and created a cookie of the cutting surface and the selected model. Same functionality as other software but if you wanted to make a small adjustment you would have an editable cutting surface to work with. Plus it would be fully procedural if you changed the input model.

Creating a curve to build a surface that cuts your polys with a cookie boolean is not hard. It's getting at the viewer info that is very difficult right now. It is very difficult to get at the cursor position or the inspect camera's orientation and view info.

That's what I was driving at, having access to current viewport state even via the hdk (can you do that already, not sure) would open things up a lot. But it would require more than just being able to get information out, you'd need methods to draw onto it too, and then something to let you process that information to create the right sops with the right parameters….
Could be useful stuff though, user defined UI interaction tools.
Perhaps H10 rfe?

Given the fact that Houdini now has Python module, I think it might be better yet is to have those said functionality implemented into a python module as well – thus accessible to larger user base as well. I think more viewport and ui toolsets implemented into the likes of python API without having to dive into HDK would be nice.

Definetely, if the hdk can be avoided then it should be.
I'd like to be able to write “viewport scripts” that let us use existing sops to create networks to build stuff but using view specific information.

The knife tool already mentioned is one good example. Another good one would be a path extrude tool. Work flow would be make a path - this can just be a curve sop - but first orient the construction plane to the current view and make it intersection with the center of the selected polygon. Then sweep the selected polygon along the path, delete the selected polygon and stitch the sweep to the mesh. Pretty much all of this is doable with exisitng sops but you can't do it because you can't easily control the viewport or get information like the orientation out of it.
Am half hoping H9 will bring this - but I think it is more realistic to think of H10. :cry:
But I am hopeful now that Sesi is moving in this direction, trying to make things more user friendly and interactive but keeping the underlying flexibility.

I am agree, I think that viewports scripts will be very very important, as long as, been able to draw directly in the viewport using your own OpenGL routines.
Maybe, and I undersant, SESI is not so focused in modelling, but with a moremoprn hdk to the viewport and python modules to access to it other people can improve the existing tools and solutions to make the modelling workflow better for artist, and even to improve some animation tools.
The interactivity with the viewport is very very impiortant for the aniomators too, and animation is one if the targets of SESI
Anyway, and maybe this is a little off-topic, Houdini viewport needs some update because is slower than others tools like Maya or Lightwave.

lisux
Anyway, and maybe this is a little off-topic, Houdini viewport needs some update because is slower than others tools like Maya or Lightwave.

Speaking of this, do you have any reliable benchmark is that a fair apples to apples comparison?

For example, I once had someone complain to me that tumbling a moderately heavy torus was very slow in Houdini compared to another package. However, they had smooth lines turned on in Houdini but not in the other package. Once we turned off smooth lines in Houdini, they were similar. Mind you, the tumbling was all subjective.

edward
Speaking of this, do you have any reliable benchmark is that a fair apples to apples comparison?

For example, I once had someone complain to me that tumbling a moderately heavy torus was very slow in Houdini compared to another package. However, they had smooth lines turned on in Houdini but not in the other package. Once we turned off smooth lines in Houdini, they were similar. Mind you, the tumbling was all subjective.

Yes, I know that sometimes this seems subjetive, but all of my stuidents thinks the same, that Houdini viewport is slower than Maya or Lightwave and after playing around with default setting in Maya and Houdini, Houdini seems to be a bit slower, specially dealing with textures.
Maybe is subjetive, but I have tested many options and the at the end I get the same coclusion.

It's subjective, but I'm very sure that Houdini is much slower than XSI with similar geometry in the viewport, and in the same conditions (no antialiased lines etc).
Also Houdini's general interactivity seems much slower in the viewport, again compared with XSI's. For example, animating a similar IK setup in the viewport seems much snappier in XSI than Houdini.

Dragos

So if it's subjective, how can we make it objective?

I don't know, but should I care? If it “feels” slower, then it *is* slower.
I mean, if someone can demonstrate that it's actually an illusion and it's the same speed, it wouldn't change my subjective perception.
On the other hand, the number of people saying that Houdini's viewport is slower than competing apps is quite big, so it must be something here…

Dragos

My point is that if it's not objective, then it will just remain the same as it is.

As I said, there is a number of users of Houdini which, here and on odforce, said that Houdini's viewport interaction is slower than that of other softwares. This is already a good benchmark.
Many of those users probably prefer Houdini and have no interest in comparing it defavorably with other softwares. For example, I'm not using Houdini (yet) in production, but it's easily my favorite software. I'd *love* to be able to show my colleague, an XSI user, that Houdini is faster in this regard. But I can't.
If user's feedback is not enough, download some demos of XSI or Maya and try to import the same OBJ file in all the packages, then see how they compare.
Build a complex IK skeleton in each of the softwares and then interact in the viewport with it. See which is snappier.

Dragos

edward
My point is that if it's not objective, then it will just remain the same as it is.

hey edward.. check out the latest cgtalk challenge scene file.the one with the car and building.Houdini is lagging even with the high end quardo card.

There's a houdini file? Care to post a link?