eikonoklastes

alexeyvanzhula1984
He probably means that during navigation with alt+lmb, I accidentally click on an object with a blueprint that interacts with viewport pivot, and the camera doesn't rotate as needed. The issue is likely not with navigation, but with the fact that background images aren't suitable for my type of navigation. Houdini background images can't be displayed in the perspective viewport all at once. This is important to me because I'm used to aligning the camera with the shift key, like in ZBrush, instead of toggling between orthographic projections.

That's a good point. Having all reference images in the perspective view, and not have them interfere with view navigation is a reasonable thing to want. I'll RFE for it.

You can set the refs images in the perspective view if you use a textureuv node with cams projection option x example , to proyect uvs on a grid , and loading a the ref image with a labs quick material node( better node than atributte from map , because you dont have to subdivide the grid to see the image details.
There are many ways to loads images in perspective view to setup references.
If you want you can create a houdini digital asset , to do it fast.

Jackatack

eikonoklastes

alexeyvanzhula1984
He probably means that during navigation with alt+lmb, I accidentally click on an object with a blueprint that interacts with viewport pivot, and the camera doesn't rotate as needed. The issue is likely not with navigation, but with the fact that background images aren't suitable for my type of navigation. Houdini background images can't be displayed in the perspective viewport all at once. This is important to me because I'm used to aligning the camera with the shift key, like in ZBrush, instead of toggling between orthographic projections.

That's a good point. Having all reference images in the perspective view, and not have them interfere with view navigation is a reasonable thing to want. I'll RFE for it.

You can set the refs images in the perspective view if you use a textureuv node with cams projection option x example , to proyect uvs on a grid , and loading a the ref image with a labs quick material node( better node than atributte from map , because you dont have to subdivide the grid to see the image details.
There are many ways to loads images in perspective view to setup references.
If you want you can create a houdini digital asset , to do it fast.

Another Houdini fanatic trying to defend their favorite software?

Do you often create ships procedurally? What can your procedural ship achieve? Adjust parameters to obtain a slightly different shape or change the type of some parts. The thing is, you can't create a detailed ship procedurally, and even if you do, your asset won't be able to vary even slightly to mirror real-life nuances. Length? Width? Hull type? Different textures? Wow, cool! Can your asset adjust the curvature over there at the front? No? Too bad, not a versatile asset. That's why direct modeling with ctrl+z exists.

Don't tell me about Houdini's stability. That's complete nonsense. Everyone's talking about Houdini's instability now. I want to laugh when I hear about the "Reset Viewport" button. Have you already set a hotkey for it?. Do you know why there's such a button? Because while other software fixes bugs, SideFX improves FX and comes up with workarounds to somehow enhance situations, for example with the terrible viewport. Until 2014 it was even worse. And since 2014, not much has been done to improve the situation.

I know how to put an image in 3D space so it's visible in perspective view. Rather, tell me how to make the Alt+LMB navigation ignore this image, and so if you accidentally touch it during navigation, you don't return to where it was just now. Familiar with such a scenario?

alexeyvanzhula1984
your asset won't be able to vary even slightly to mirror real-life nuances. Length? Width? Hull type? Different textures? Wow, cool! Can your asset adjust the curvature over there at the front? No? Too bad, not a versatile asset.

LOL OK , end discussion .

alexeyvanzhula1984

Jackatack

eikonoklastes

alexeyvanzhula1984
He probably means that during navigation with alt+lmb, I accidentally click on an object with a blueprint that interacts with viewport pivot, and the camera doesn't rotate as needed. The issue is likely not with navigation, but with the fact that background images aren't suitable for my type of navigation. Houdini background images can't be displayed in the perspective viewport all at once. This is important to me because I'm used to aligning the camera with the shift key, like in ZBrush, instead of toggling between orthographic projections.

That's a good point. Having all reference images in the perspective view, and not have them interfere with view navigation is a reasonable thing to want. I'll RFE for it.

You can set the refs images in the perspective view if you use a textureuv node with cams projection option x example , to proyect uvs on a grid , and loading a the ref image with a labs quick material node( better node than atributte from map , because you dont have to subdivide the grid to see the image details.
There are many ways to loads images in perspective view to setup references.
If you want you can create a houdini digital asset , to do it fast.

Another Houdini fanatic trying to defend their favorite software?

Do you often create ships procedurally? What can your procedural ship achieve? Adjust parameters to obtain a slightly different shape or change the type of some parts. The thing is, you can't create a detailed ship procedurally, and even if you do, your asset won't be able to vary even slightly to mirror real-life nuances. Length? Width? Hull type? Different textures? Wow, cool! Can your asset adjust the curvature over there at the front? No? Too bad, not a versatile asset. That's why direct modeling with ctrl+z exists.

Don't tell me about Houdini's stability. That's complete nonsense. Everyone's talking about Houdini's instability now. I want to laugh when I hear about the "Reset Viewport" button. Have you already set a hotkey for it?. Do you know why there's such a button? Because while other software fixes bugs, SideFX improves FX and comes up with workarounds to somehow enhance situations, for example with the terrible viewport. Until 2014 it was even worse. And since 2014, not much has been done to improve the situation.

I know how to put an image in 3D space so it's visible in perspective view. Rather, tell me how to make the Alt+LMB navigation ignore this image, and so if you accidentally touch it during navigation, you don't return to where it was just now. Familiar with such a scenario?

It’s actually simpler than that… If a client asks for a procedural geo then fine you have time, often it’s just we need this in a day or week, and no amount of proceduralism is going to help you there. DM tools and interaction need to get better, but for now it’s just reliability of viewport, if you don’t have a valid result while working then what’s the point, you are just wasting time, having dof, fog, etc. is nice, but not having a valid result from interaction renders it all moot, and labs reset viewport, just amplifies the fact that the viewport is broken, and even reset viewport is not that reliable as a restart session

@alexeyvanzhula1984 It might have been that, but subsequent click should've grabbed the foreground geo and readjusted the camera pivot based on cursor which it didn’t, it got locked to bg plane and it resulted in an awkward navigation, which you need to manually fix with f/h/space+z,etc…

citizen
an 'edge divide' tool that works decently

The Edge Loop command works decently, no? Or are you referring to something else?


If you have many of these to do, the TopoBuild SOP has a built-in Edge Loop function, that you can repeat (destructively) without padding your node graph.

TIL there are people who unironically think manual modeling is obsolete.

eikonoklastes

citizen
an 'edge divide' tool that works decently

The Edge Loop command works decently, no? Or are you referring to something else?

If you have many of these to do, the TopoBuild SOP has a built-in Edge Loop function, that you can repeat (destructively) without padding your node graph.

It’s probably not edge loop issue, but rather viewport drawing issue, and everything works well on cubes and spheres, his issue is probably an "edge" case…

hMonkey
It’s probably not edge loop issue, but rather viewport drawing issue, and everything works well on cubes and spheres, his issue is probably an "edge" case…

The person I'm replying to literally did not say any of that, though, so at this point you're pushing an agenda that's getting pretty tiresome, and constantly diluting the value of this forum. Maybe don't do that?

We get it - you freaking hate Houdini's viewport. You've made that abundantly clear. Can we get back to more constructive stuff? Like maybe posting evidence for your claim of the terrible, no-good, useless, broken navigation system? Kinda still waiting on that.

I don't believe that manual modeling is obsolete. I do believe that modeling in a destructive manner, without the ability to backtrack without everything breaking, is obsolete. Of course, manual modeling is necessary. And sure, Houdini isn't perfect and there's room for improvement.

But this thread has turned into a discussion about why Houdini isn't like Blender or Maya. There's a reason Blender often falls outside standard pipelines. Maya is outdated and isn't exemplary in most aspects.

As everything I'm saying is my opinion, in my case, Houdini proves to be very stable if you maintain a clean scene and strive to do things right. The viewport leaves much to be desired – sometimes it doesn't accurately represent your actions, and that's a drawback. Improvement is needed.

However, it's much more stable and capable of handling larger amounts of geometry compared to Maya, for instance. I simply don't agree with advocating for a destructive workflow like Maya's in front of a non-destructive one like Houdini's. It's like saying After Effects is a better way to work than Nuke.

At least, that's how I see it.

hMonkey
It’s probably not edge loop issue, but rather viewport drawing issue, and everything works well on cubes and spheres

Also, I'm of the opinion that big claims need big evidence, so here's mine to refute your above claim. Please, I encourage you to to post your own experiences of your miserable time with Houdini so that the devs can also notice it. We all (hopefully) want Houdini to get better.

So here, just for you, here's a repeat of my previous video, this time on a million-face deformed object, and I do the same thing, with no viewport flicker and no unreasonable lag, given the bump in face count.

eikonoklastes

hMonkey
It’s probably not edge loop issue, but rather viewport drawing issue, and everything works well on cubes and spheres, his issue is probably an "edge" case…

The person I'm replying to literally did not say any of that, though, so at this point you're pushing an agenda that's getting pretty tiresome, and constantly diluting the value of this forum. Maybe don't do that?

We get it - you freaking hate Houdini's viewport. You've made that abundantly clear. Can we get back to more constructive stuff? Like maybe posting evidence for your claim of the terrible, no-good, useless, broken navigation system? Kinda still waiting on that.

That’s funny, considering that the title is "Houdini 20 Rumors", and the whole thread got off the rails a long time ago…

If you want to add value and not dilute the value of the this forum, specifically this thread feel free to contribute with some rumors. Vulkan based, cross-platform viewport is a rumor, so it’s on topic, you running around with cubes and spheres not so much

Also if I hated anything regarding Houdini I wouldn’t be using it, so your thinking is way off regarding my baseline for seemingly, as you put it, hateful & diluting comments, and you’ve missed the point of most of the comments here, weather they are good or bad, most of them are useful if you know what too look for...

hMonkey

eikonoklastes

hMonkey

It is funny, we are trying to talk about rumours but no one knows if H20 gonna be released and when

hMonkey
That’s funny, considering that the title is "Houdini 20 Rumors", and the whole thread got off the rails a long time ago…

Threads, especially broad-topic threads like these, get derailed - it's just the nature of an active forum - nothing anyone can do about that, except having a heavy-handed moderation policy that locks derailed threads immediately (I'm not a fan of that, though, and luckily, seemingly, neither are SideFX).

Regardless of the derailment, the quality of the forum can still be upheld - that's why I keep urging you to back your claims with evidence (still waiting on that, btw), and not just ranting and quipping about something that you've already repeated ad nauseam in the same thread.

eikonoklastes
hMonkey
It’s probably not edge loop issue, but rather viewport drawing issue, and everything works well on cubes and spheres
Also, I'm of the opinion that big claims need big evidence, so here's mine to refute your above claim. Please, I encourage you to to post your own experiences of your miserable time with Houdini so that the devs can also notice it. We all (hopefully) want Houdini to get better.

I'm starting to feel that a lot of the challenges Hmonkey is facing with Houdini might just be part of the learning curve. Let me break it down. It's common to not quite get the hang of something and then point fingers at Houdini's viewport. I'm a bit puzzled by the persistent frustration though. It seems like it could be more about not fully grasping certain aspects rather than offering helpful feedback. I'm just chiming in to see if we can steer the conversation in the post towards exciting rumors about H20 and wishful thinking, and maybe dial down a bit on the 'Houdini is the worst' vibe

I don't want Houdini to be Blender either. I just meant it might learn something from other apps that do manual modeling well like Blender/Maya/Modo etc. And make things more discoverable/easy to use.

For example, I don't know why SideFX decided that we need different names for Shelf Tools and their corresponding SOP nodes. Why something called PolyDraw actually creates TopoBuild node? What's the difference between Knife and Clip? Why PolySplit has two modes (shortest path and edge loop), but its Python state doesn't reflect the fact, and therefore we need two shelf tools for them?

I know the concept of abstraction (i.e. maybe in a later version Knife can be implemented with another node which isn't Clip), but in my opinion so many names for such basic functionalities just confuse people.

Ideally:

1. All modeling nodes can be called as an interactive tool from view port. No need a shelf tool under a different name.
2. If I have components selected when a tool is called, it's smart enough to initialize its state accordingly.
3. The most important parameters of a node should be able to be altered in the interactive tool mode.

Some of the nodes already (kinda) do that. I just want more nodes work like that and in a consistent way.

It won't hurt the procedural nature of Houdini. Actually it will enhance it! Currently since the other modeling nodes' weirdness, I often use TopoBuild, a destructive node, as a general modeling tool. If the three points I listed came true, TopoBuild's use would be limited to retopo-ing sculpted hi-res meshes.

Jackatack
I'm starting to feel that a lot of the challenges Hmonkey is facing with Houdini might just be part of the learning curve. Let me break it down. It's common to not quite get the hang of something and then point fingers at Houdini's viewport.

Hey thanks for breaking it down for me! I guess I was wasting time in houdini for the past couple of years

Jackatack
As everything I'm saying is my opinion, in my case, Houdini proves to be very stable if you maintain a clean scene and strive to do things right.

I recently studied vellum thoroughly for two weeks. Simple scenes from multiple objects. Simple manipulations with vellum SOP nodes led to a sudden houdini crash every 15-30 minutes.
I'm waiting for version 20, I hope that vellum will be more stable there.

eikonoklastes
We get it - you freaking hate Houdini's viewport. You've made that abundantly clear. Can we get back to more constructive stuff? Like maybe posting evidence for your claim of the terrible, no-good, useless, broken navigation system? Kinda still waiting on that.

Keep waiting, meanwhile those (or most of them) are logged, fully documented and acknowledged by support ether as bugs or rfe’s, and that’s the only thing that matters in the long run.

HGaal
I recently studied vellum thoroughly for two weeks. Simple scenes from multiple objects. Simple manipulations with vellum SOP nodes led to a sudden houdini crash every 15-30 minutes.
I'm waiting for version 20, I hope that vellum will be more stable there.

Instead of just waiting for a newer version and hoping your issues are fixed, consider filing bug reports [www.sidefx.com]. SideFX do an amazing job of responding to these, particularly crashes, and will be able to target fixes to these issues more easily. It's possible that they might fix it in a daily build even, and then you don't even need to wait for the next version.

Often times, it might just be your hardware or software configuration that is the culprit. It's annoying to hear that, I know, but if you actually use recommended hardware and don't mess with your OS too much, and keep your drivers up-to-date (assuming Nvidia hasn't introduced any bugs of their own) Houdini tends to work pretty stably.

hMono

Jackatack
I'm starting to feel that a lot of the challenges Hmonkey is facing with Houdini might just be part of the learning curve. Let me break it down. It's common to not quite get the hang of something and then point fingers at Houdini's viewport.

Hey thanks for breaking it down for me! I guess I was wasting time in houdini for the past couple of years

Two years using Houdini(wow), and in all your posts, you criticize the software you're learning just because it's not like Cinema 4D or doesn't operate like other software... Maybe it's a matter of approaching the learning process differently

I've been intensely learning Houdini for about 3 to 4 years now, and I still feel like a noob. However, if something doesn't work out as expected, I don't give up. I don't blame my limitations on Houdini not being like Cinema 4D or some other software. Nor do I take the easy way out by saying, 'It's not me, it's the software that's faulty.'

About 90% of the time when something doesn't go well, I go back to the beginning of the setup to figure out what's not working right. I search for information and ask questions. Eventually, I manage to solve the problem, and my learning keeps progressing.

I maintain a humble profile while learning Houdini, which I believe is the right way to learn—from a standpoint of 'I might be doing something wrong; let's figure out why it's not working.'

Perhaps over these two years, you've set aside too many things as 'Houdini problems' that could have contributed to your learning. Maybe you think that with 2 years of learning, you can hold authority and claim that your setups are flawless and everything is Houdini's fault. Personally, I prefer to first look for the problem within myself, with the help of experienced experts who have been at this for more than 10 years.

Best regards