Bevel Questions

[XSI]

Hi

Just downloaded Houdini Apprentice to test some of the claims made by

Houdinis user base.

Early days yet but this is my first problem.

If I make a cube and then bevel an edge I end up with 2 nodes- Box1, and

bevel1. My problem is that when I go back to box1 to change its tessellation

it badly effects the bevel. This makes the idea of going back and changing

parameters not possible in this case, and calls into question the real

flexibility of Houdini's architecture.

I understand why this happens...its to do with the numbering of the edges

being changed when the tessellation values are modified.

All other apps have this problem...but then none are claimed to be the

procedural cure-all that Houdini is.

Whats your thoughts

Thanks

Edited December 15, 2007 by XSI

[Jason]

Hello and welcome to od[force]: our little Houdini corner,

Yeah, for pure modeling tasks we find this is a limitation. Unfortunately to keep consistent edge selections, you encounter this problem most severely. Houdini has been raised as an FX package where every step of the modeling process has a very conscious thought behind it. Houdini can maintain point and primitive groups - which are basically named selected sets - that travel along with the geometry. If you're building a model procedurally that might have fluctuating point/poly-counts, Houdini users try to make use of these Groups. Many tools can create groups as a result of their particular operation and these groups can be passed to successive operations.

However, for any edge selections - or selection that require a user-inputted order of selection, this becomes much harder. I don't think there is a system in existence that can reenact orders interactive selections when you completely changing the input topology.

For rapid modeling, Houdini doesn't have a good solution for changing point counts wrt to edge selections. For careful modeling or rig/system building there is almost always a solid way of maintaining a fully procedural system. Of course, you can ALWAYS throw something in the front of the chain and screw it all up - but, as they say, shit in = shit out.

I hope this answers your questions. Of course there is no doubt a little bravado out there "Houdini is totally procedural no matter what you do" but it seems like you're out to prove that naive statement wrong (and quite frankly it would be kinda naive to believe such things at face-value, IMHO)- I hope I have saved you the trouble of digging for the truth.

The thing is, it IS totally procedural. It just might give you the results you don't expect - but they are the correct results.

Have fun, XSI,

Jason

[XSI]

Thanks for your post Jason.

You see when you encounter these problems in other apps , you just assume that if another app is held higher then others, especially in it advanced relationships with objects and actions,

that it would have some solution.

This it the sort of modeling I do every day, and it frustrates me that regardless of the "history stack" or node network, problems like this plague moddelers and put serious question marks over the

usefulness of these advanced systems.

The reason why I assumed this would not be a problem is that I heard claims about this fully procedural system like "you can go back and edit your setup without the hassle of redoing elements"

and you just assume that this apply to low level modeling also.

Thanks

[Jason]

Yeah, modelers approach the low level stuff with far less care and would rather create and destroy and create again than try to step back in history and tweak inputs - only because it's feels like PROGRESS, psychologically.

For anything more than the rapid modeling stage you can create fully procedural systems that behave predictably, etc.

App-wars suck; but we all do it - just a bit. Healthy competition I hope. Why are you here, for instance?

Cheers,

Jason

[sibarrick]

The thing to remember here is that if all you want to do is some quick box up modelling just work as you would in any other package. You'll probably find Houdini isn't as good in that area, but it can do the job.

If and when you hit a task that would be better done in a procedural way then the power really kicks in. You have to match the tool to the task. Houdini isn't a magic bullet its just extremely good at being procedural, you just have to have a procedural task in mind to make full use of it.

To take your box example - if you only ever bevel boxes and want the edges to be correctly bevelled regardless of the number of divisions it is possible to come up with a solution in Houdini to do that. Of course that solution may not work if you then switch to some other model, but then you may make further corrections to your network to take the new variation into account. What Houdini does is provide you with the tools to set this system up. But only try and do it if you are faced with the task of bevelling 100,000 objects and you can see that some simple logical or rules can be applied to get the job done quicker.

Its a different mindset and you have to get used to thinking in this way.

Of course you can also just make use of the networks to organise your work even if your methods aren't procedural. I think the node system is several times more useful than Max's stack. Being able to keep different ideas and variations around and wiring in different parts of model to experiment with is a very artistic way of working.

Edited December 15, 2007 by sibarrick

[edward]

You can also reselect the edges for the bevel. With your Bevel SOP selected hit Enter in the viewer. Hit backtick, select the correct edges and hit enter. With operator reselection, often times large networks can be fixed, saving lots of work.

[Isaac Mensah]

Also another thing to keep in mind is the order of your operations.

eg. you could have teselated your cube after the bevel operation.

The key to keeping a procedural model is planning in advance and refining your network of operations as you go.

Its a slow process but once done your model is reeeally flexible

Edited December 30, 2007 by imensah