Something I have learned during the last 20 years is that mathematical or physical correctness is not a guarantee for usefulness. I really like houdini - it is logical, intelligent (most important) and very elegant in most parts. The viewportshading is the one feature that really stands out. Even if it is mathematically correct, it does nothing to aid or support the user.
If I'm to model something I need to be able to judge the surface. I need to know where creases are and if the belong there. I need to know if a quad is planar or if that black corner is black because of a colored vertex or because of a material or the viewport shading. And I actually don't care what the tech is called as long as it is useful to me
Found 378 posts.
Search results Show results as topic list.
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
I never said the viewport shading is an error. It is simply not good or helpful.
As for the tutorial: If I want a simple chamfer, I do not need any subdivisions, which he deliberately manually set. He says he adds more repetitions to round it out more, which simply is wrong if you know you are in flat mode. “more repetions add more geometry to round it out.” In flat mode. This is an error. More repetitions do exactly nothing in flat mode for the rendering. He thought he would round it because in gouraud shading it is hard to tell. I watched several videos and forgetting to make a correct setting is not uncommon for him. Nothing wrong with that, but with a better shading, he would have seen it.
Edit: ok, lets not say “error” but “mistake” to avoid confusion
As for the tutorial: If I want a simple chamfer, I do not need any subdivisions, which he deliberately manually set. He says he adds more repetitions to round it out more, which simply is wrong if you know you are in flat mode. “more repetions add more geometry to round it out.” In flat mode. This is an error. More repetitions do exactly nothing in flat mode for the rendering. He thought he would round it because in gouraud shading it is hard to tell. I watched several videos and forgetting to make a correct setting is not uncommon for him. Nothing wrong with that, but with a better shading, he would have seen it.
Edit: ok, lets not say “error” but “mistake” to avoid confusion
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
The tutor in the tutorial produced an error because of the lack of a feature. That exactly is my point.
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
Why would it be different, I'm just elaborating my original request because I came across this error in the tutorial which I though was a good support for my case .
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
I would ask for that too, but I'd rather ask to get rid of that gouraud shading technique first. You really only find that in houdini, and I think noone would say this is superior to the methods found in (all) other tools. If you import a CAD model without usernormals in houdini for the first time its quite a shock. I mean you have OGL 3.3, highend workstation graphicscard (still) required, IBL, AO and softshadows for the viewport, but you have to add an sop to get your geometry displayed correctly while it is likely to dynamically change quite a bit while editing. Even the blender guys have build in this functionality this year.
And what about an option to use viewport normal for rendering, or an object level setting that overrides the global even while the geo changes and can still be overridden by a sop? Wouldn't that be better than trying to figure out if the sides of the cube are planar or not as long as there is no operator that exactly does what could be done globally and becomes invalid as soon as you start modeling? I am only asking for an improvement that is well established already everywhere else. No one would suffer from it. There could even be an option to turn it off
And what about an option to use viewport normal for rendering, or an object level setting that overrides the global even while the geo changes and can still be overridden by a sop? Wouldn't that be better than trying to figure out if the sides of the cube are planar or not as long as there is no operator that exactly does what could be done globally and becomes invalid as soon as you start modeling? I am only asking for an improvement that is well established already everywhere else. No one would suffer from it. There could even be an option to turn it off
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
Sorry for editing so much, forums are usually not a realtime conversation . But I will try to avoid it.
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
What exactly is incorrect?
I know you can use a facet op etc. in fact you have to, and you have to keep it at the end of the network. Wouldn't you agree, that it would make things a lot easier, if you had a basic viewport anglebased setting, which you can override with a facet sop when youre done modelling? That is what my original question is about.
I know you can use a facet op etc. in fact you have to, and you have to keep it at the end of the network. Wouldn't you agree, that it would make things a lot easier, if you had a basic viewport anglebased setting, which you can override with a facet sop when youre done modelling? That is what my original question is about.
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
I know he isn't talking about the smooth shading. He is talking about the bevel which is set to FLAT (two sharp egdes instead of one) but he says the result was slightly rounded. This is an error because you cant actually see what is rounded and what is not whith the 80's style gouraud shading. Is the closest top corner of the left box in the screenshot rounded or not?
Edited by - Sept. 13, 2014 16:58:07
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
Funny note:
You can see exactly what can happen if there is not proper viewport auto smoothing if you watch “lesson 2: UI & modeling” from the first experience videotutorials. At 00:18:11 you hear the words “you can see it is slightly rounded which will make a much better render. Cool!” but the bevel sop is clearly set to Flat. It looks roundish because of houdini's smoothshading wich simply smoothes everything, but it isn't. Good laugh. As long as in doesn't happen in production.
(you can also see how poor the bevel tool handles the t-junction in the middle os the frame, but thats another story… )
You can see exactly what can happen if there is not proper viewport auto smoothing if you watch “lesson 2: UI & modeling” from the first experience videotutorials. At 00:18:11 you hear the words “you can see it is slightly rounded which will make a much better render. Cool!” but the bevel sop is clearly set to Flat. It looks roundish because of houdini's smoothshading wich simply smoothes everything, but it isn't. Good laugh. As long as in doesn't happen in production.
(you can also see how poor the bevel tool handles the t-junction in the middle os the frame, but thats another story… )
Technical Discussion » distributing spheres on a surface without overlapping
- OneBigTree
- 378 posts
- Offline
Maybe you can get some ideas from that:
http://julianjohnsonsblog.blogspot.de/2013/07/dart-throw-multiple-size.html [julianjohnsonsblog.blogspot.de]
Its ICE and I don't know if it is in any way transferable to Houdini, but it may be an inspiration.
http://julianjohnsonsblog.blogspot.de/2013/07/dart-throw-multiple-size.html [julianjohnsonsblog.blogspot.de]
Its ICE and I don't know if it is in any way transferable to Houdini, but it may be an inspiration.
Technical Discussion » Camera and Upvector
- OneBigTree
- 378 posts
- Offline
As I said, this isn't a Camera Problem, but a problem with the Upvector/Lookat.
So whatever rig you build, you can run into the same issues.
I think the main Problem is that the object rotation is not replaced by the rotation calculated by constraint which happens somewhere in the background, then added as marko said to the standard rotations which for some reason may get altered by the transform and the resulting rotations which leads to wrong calculation of the overall result´and so on. This is also the reason why the transform handle won't reflect the actual rotation when aligned to object.
The error is in the system. It is unreliable and unpredictable. If something shows up in a software shouldn't it be fixed instead of forcing the users to build a workaround? After all this works in literally any other 3d software.
I mean the solution can not be “It doesn't work, so I don't use it”, can it?
I started building a rig, but the time required to build a suitable rig that behaves like a standard target camera like in max, maya, softimage or even blender can better be used to animate the camera in, well, not houdini.
So whatever rig you build, you can run into the same issues.
I think the main Problem is that the object rotation is not replaced by the rotation calculated by constraint which happens somewhere in the background, then added as marko said to the standard rotations which for some reason may get altered by the transform and the resulting rotations which leads to wrong calculation of the overall result´and so on. This is also the reason why the transform handle won't reflect the actual rotation when aligned to object.
The error is in the system. It is unreliable and unpredictable. If something shows up in a software shouldn't it be fixed instead of forcing the users to build a workaround? After all this works in literally any other 3d software.
I mean the solution can not be “It doesn't work, so I don't use it”, can it?
I started building a rig, but the time required to build a suitable rig that behaves like a standard target camera like in max, maya, softimage or even blender can better be used to animate the camera in, well, not houdini.
Technical Discussion » Camera and Upvector
- OneBigTree
- 378 posts
- Offline
Thanks mark and arctor,
the rotational values in my hipfile are the resulting values of the constraint evaluation, they were 000 initially.
But it turns out that only when I lock X and Y rotation the constraint works as expected. Obviously there seems to be a conflict between the standard rotation and the values generated by the constraint. If you look at my new screenshot you see the camera has rolled and the rotation values do not reflect that.
However, if I lock the x and y rot when the camera is in a neutral position and move the camera after the lock, everything seems to be stable.
Also confusing is the different behavior when using the multi-handle tool for transformations instead of the dedicated move tool without the locks.
There is definitely something weird going on than can lead to errors if one isn't aware of it. I should be investigated and fixed. The locks can only be a workaround because there may be situations where you cannot or want not lock the rotations.
Anyway, thanks again for your assistance.
PS: another issue is: with a lookat active the transformhandles wont align to the object anymore! So it is impossible for example to pull the camera back along its local Z axis.
the rotational values in my hipfile are the resulting values of the constraint evaluation, they were 000 initially.
But it turns out that only when I lock X and Y rotation the constraint works as expected. Obviously there seems to be a conflict between the standard rotation and the values generated by the constraint. If you look at my new screenshot you see the camera has rolled and the rotation values do not reflect that.
However, if I lock the x and y rot when the camera is in a neutral position and move the camera after the lock, everything seems to be stable.
Also confusing is the different behavior when using the multi-handle tool for transformations instead of the dedicated move tool without the locks.
There is definitely something weird going on than can lead to errors if one isn't aware of it. I should be investigated and fixed. The locks can only be a workaround because there may be situations where you cannot or want not lock the rotations.
Anyway, thanks again for your assistance.
PS: another issue is: with a lookat active the transformhandles wont align to the object anymore! So it is impossible for example to pull the camera back along its local Z axis.
Technical Discussion » Camera and Upvector
- OneBigTree
- 378 posts
- Offline
Houdini Learning Materials » Parameter descriptions locked (solved)
- OneBigTree
- 378 posts
- Offline
OK, got it. Once it is a HDA the parameter interface has to be edited via the Type Properties Editor. Not obvious at first but logical
Houdini Learning Materials » Parameter descriptions locked (solved)
- OneBigTree
- 378 posts
- Offline
I'm trying to create a digital asset to get familiar with the workflow. Somewhere in the process all my parameters in the parameter interface got locked. I didn't lock anything anywhere on purpose and I cannot find out where I can unlock them. The content of the subnet is not locked, only the parameter editing. I can move parameters between folders but not delete or edit them.
This happened a few times now, and I really need to get to know what I'm doing wrong instead of having to start over every time.
Can someone please help me?
This happened a few times now, and I really need to get to know what I'm doing wrong instead of having to start over every time.
Can someone please help me?
Edited by - Sept. 7, 2014 14:26:02
Technical Discussion » switching spacebar and alt navigation hotkeys
- OneBigTree
- 378 posts
- Offline
pelos
space bar is the biggest key in the keyboard, when you are in the studio, in the dark corner where you cant see @!%$#^@%^^. well you know where this is going.
I can feel alt very well. One could also ask for a desk lamp
Houdini Learning Materials » Copy to primitives
- OneBigTree
- 378 posts
- Offline
Houdini Learning Materials » Softimage to Houdini guides done
- OneBigTree
- 378 posts
- Offline
Many many thanks. The original files helped me produce my first procedural nose!
But seriously, those are the most helpful tutorials of all times. Thanks again!
But seriously, those are the most helpful tutorials of all times. Thanks again!
Houdini Learning Materials » Copy to primitives
- OneBigTree
- 378 posts
- Offline
I've been searching a while for that but couldn't find anything:
Is there a method to copy objects to primitive centers instead of points?
thanks
Is there a method to copy objects to primitive centers instead of points?
thanks
Houdini Learning Materials » Viewport Normals (aka Autosmoothing)
- OneBigTree
- 378 posts
- Offline
-
- Quick Links