Found 38 posts.
Search results Show results as topic list.
Technical Discussion » H15: Principled Shader missing Opacity?
-
- Filip Tarczewski
- 38 posts
- Offline
Thanks ripclaw! I thought it would be more complicated than that. Is there a good reason it still isn't fixed in H16 apart from low priority?
Technical Discussion » FATAL ERROR: SEGMENTATION FAULT (?)
-
- Filip Tarczewski
- 38 posts
- Offline
st0per
i advice you to search for System Variable on here. I just added one with a value of1. This had something to do with my graphics card.
Steve
Could you elaborate? What was the name of the variable you added?
EDIT: I just noticed how old your post is
Edited by Filip Tarczewski - 2016年9月23日 06:07:52
Technical Discussion » How do i make melting liquid bounce?
-
- Filip Tarczewski
- 38 posts
- Offline
Martin Aggerholm
Hi I'm completely new here. So my questions might sound really basic or stupid.
I'm trying to make an rigid object fall to the ground and the melt afterwards. like a piece of chocolate hitting a frying pan and then it starts to melt.
So getting it to hit the ground and start melting is super easy. But getting it to bounce just before it starts melting is impossible.
I've turned on ‘use friction and bounce’ in the FLIP solver and added bounce in the physical tab in FLIP Object.
What am i missing here?
I'm a beginner so take my advice with a grain of salt. From what I understand you're trying to achieve this using the FLIP Solver only.
Instead you could simulate the chocolate as a rigid body, and then start treating the cached effect of that as the FLIP source. Then you could simulate the FLIP from the beginning, or after the chocolate bounces.
You could also do it all in one DOP Network, but using cached passes is easier.
Houdini Learning Materials » Render Cd on UV Texture in Houdini 15
-
- Filip Tarczewski
- 38 posts
- Offline
There's a dedicated Bake Texture ROP now, so you have to go to /out and create it there.
Work in Progress » Camera Projection Baker - from the ground up
-
- Filip Tarczewski
- 38 posts
- Offline
Hi.
I started working on my own camera projection baker shelf tool.
Apart from learning how to make these things, my ultimate goal is to create a fluid workflow that allows one-click texture extraction and brings the texture back to Houdini for viewing and rendering after touchups.
I'm going to post my progress here to motivate myself, hopefuly get some feedback from You and share the tool when it's ready.
Right now it's all very crude, but it's already working.
For now I have an initial SOP setup done by hand and a Python SOP that creates a ROP Network with a Mantra node inside it. It names both nodes based on the HIP's and object's names and a prefix and sets up the mantra node for proper uv rendering.
The texture is extracted and brought back properly. After that it renders fine, but for whatever reason it shows up broken in uv_quickshade, so that's the first thing I'm going to try and fix.
Cheers!
I started working on my own camera projection baker shelf tool.
Apart from learning how to make these things, my ultimate goal is to create a fluid workflow that allows one-click texture extraction and brings the texture back to Houdini for viewing and rendering after touchups.
I'm going to post my progress here to motivate myself, hopefuly get some feedback from You and share the tool when it's ready.
Right now it's all very crude, but it's already working.
For now I have an initial SOP setup done by hand and a Python SOP that creates a ROP Network with a Mantra node inside it. It names both nodes based on the HIP's and object's names and a prefix and sets up the mantra node for proper uv rendering.
The texture is extracted and brought back properly. After that it renders fine, but for whatever reason it shows up broken in uv_quickshade, so that's the first thing I'm going to try and fix.
Cheers!
Technical Discussion » Constraining Ends of Wire
-
- Filip Tarczewski
- 38 posts
- Offline
Technical Discussion » Constraining Ends of Wire
-
- Filip Tarczewski
- 38 posts
- Offline
Thank you Matthias, I haven't checked your file yet, but I've tried the expression and it works like a charm! It's been bugging me for ages 
Is this the preferred method for driving stuff in DOPs with SOPs? Reference SOP groups rather than inherrited attributes?
Is this the preferred method for driving stuff in DOPs with SOPs? Reference SOP groups rather than inherrited attributes?
Technical Discussion » Constraining Ends of Wire
-
- Filip Tarczewski
- 38 posts
- Offline
Technical Discussion » Constraining Ends of Wire
-
- Filip Tarczewski
- 38 posts
- Offline
Hi, try the attached file.
I'm a beginner so it might not be the best solution, but it works.
Struggled with it before and your post actually inspired me to try again, so thanks
I haven't figured out how to sample rotation in this one yet. Position works.
I'm a beginner so it might not be the best solution, but it works.
Struggled with it before and your post actually inspired me to try again, so thanks
I haven't figured out how to sample rotation in this one yet. Position works.
Technical Discussion » Autodetect attribute class?
-
- Filip Tarczewski
- 38 posts
- Offline
Thanks! This works great in Attribute Promote, and I'm sure it will in other SOPs.
How could I do the same for Bind VOP to include all the possible input types?
Should I use dataType(self) or optionType(self)?
Is there a more generalized method to check for input type in the context of the node receiving the data?
How could I do the same for Bind VOP to include all the possible input types?
Should I use dataType(self) or optionType(self)?
Is there a more generalized method to check for input type in the context of the node receiving the data?
Technical Discussion » Autodetect attribute class?
-
- Filip Tarczewski
- 38 posts
- Offline
Technical Discussion » Autodetect attribute class?
-
- Filip Tarczewski
- 38 posts
- Offline
So I'm guessing I should make a Python SOP that does something like this:
Check what type the original uv attribute is (hou.attribType?) and output a value from 0 to 3 accordingly, so
if (uv is point) x=0
if (uv is vertex) x=1
if (uv is primitive) x=2
if (uv is global) x=3
Attrib Promote
Original class switch = x
Could you guide me in the right direction?
Check what type the original uv attribute is (hou.attribType?) and output a value from 0 to 3 accordingly, so
if (uv is point) x=0
if (uv is vertex) x=1
if (uv is primitive) x=2
if (uv is global) x=3
Attrib Promote
Original class switch = x
Could you guide me in the right direction?
Technical Discussion » Autodetect attribute class?
-
- Filip Tarczewski
- 38 posts
- Offline
chrism
As this had nothing to do with tutorials, I've moved it to this forum instead.
Thank you and sorry for posting in a wrong place.
Technical Discussion » Autodetect attribute class?
-
- Filip Tarczewski
- 38 posts
- Offline
Hi,
I'm building a super simple tool - a Color Map with pre-built attribute promotion, since I need uvs to be point, not vertex for it to work properly.
Is it possible to have Attribute Promote (or some custom made replacement) auto-detect what is the input uv's original class?
Also is it possible to have class auto-detection in other contexts - in a custom Bind VOP for instance?
If not, would you consider it something worth submitting an RFE for?
In XSI ICE general purpose nodes that worked with more than one kind of input could automatically recognize what kind of data was fed to them, and adapted accordingly. I see no advantage in identifying the kind of input by hand, other than it keeps you on your toes. Having the nodes recognize the data properly (by default, not instead of the manual solution) would help eliminate some human error.
Sorry if it is a noob question.
Cheers
I'm building a super simple tool - a Color Map with pre-built attribute promotion, since I need uvs to be point, not vertex for it to work properly.
Is it possible to have Attribute Promote (or some custom made replacement) auto-detect what is the input uv's original class?
Also is it possible to have class auto-detection in other contexts - in a custom Bind VOP for instance?
If not, would you consider it something worth submitting an RFE for?
In XSI ICE general purpose nodes that worked with more than one kind of input could automatically recognize what kind of data was fed to them, and adapted accordingly. I see no advantage in identifying the kind of input by hand, other than it keeps you on your toes. Having the nodes recognize the data properly (by default, not instead of the manual solution) would help eliminate some human error.
Sorry if it is a noob question.
Cheers
Edited by - 2015年8月17日 17:10:06
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
McNistorFilip Tarczewski
mouse wheel for setting number of subdivs
But what will the Mac users do?
I'm obviously kidding
They'd figure something out. Buy a proper mouse perhaps
Sorry, couldn't help myself ;] Replacing the mouse was the first thing I did when I started working on a Mac. I have no idea how to use the one without the wheel.As I said, it isn't as important to me if it's rigged this way or the other, as long as it's convenient enough. The simpler the better.
Also, while we're at it, allowing user defined hotkeys and mouse actions some day could be nice.
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
Ok.
Cool. Perhaps I'd choose slightly different methods for input (mouse wheel for setting number of subdivs), but the specifics aren't that important. Having a system like this would really help to make interactive modeling in Houdini convenient.
McNistor
Personally I'd like something like this for say an Extrude:
- hotkey to activate extrude for the selected faces
- drag mouse to set length
- shift (or ctrl or just MMB / RMB) + drag to set # of subdiv
- LMB (or MMB or RMB) to commit
and a Bevel would go:
- hotkey to activate bevel for the selected edges
- drag mouse to set width
- shift (or ctrl or just MMB / RMB) + drag to set # of subdiv
- LMB (or MMB or RMB) to commit
Cool. Perhaps I'd choose slightly different methods for input (mouse wheel for setting number of subdivs), but the specifics aren't that important. Having a system like this would really help to make interactive modeling in Houdini convenient.
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
McNistor
My main concern was about the fact that (in retrospective probably misunderstood) transformations without gizmos is most of the time unrealistic. I say “most of time” because you can do that in the rare situation in which you need to set the length of a cube to a certain size using only the keyboard. For anything else as far as transformations go, gizmos is the way to go.
Just to make sure we're clear now, because I'm not sure if this is clear in the video I posted: everything in the vid all lengths, depths etc were set interactively with the mouse, not by typing values from the keyboard.
The only difference is with gizmos you click on an axis and drag the mouse while holding the left mouse button, while in Blender you don't click on anything, you choose the axis from the keyboard, then move the mouse without pressing or holding buttons, and click when you're done.
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
Agreed. Especially bevel is very far from perfect IMO. Judging by H14 though I am confident Houdini is headed in the right direction Interface-wise, and I hope it will also happen to the basic modeling tools.
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
McNistor
Like I said, I think you're going to model something that's not challenging and doesn't require a gizmo that's oriented in a local space (of the component, not only the object) and in which you're going to need a gizmo for achieving that and also help you translate in reference spaces of other components/objects
It works the same for local axis though. Your object / polygon can be oriented any way you like in world space, you just use local coordinate system then (XX, YY, ZZ instead of X, Y, Z), just like in XSI (if memory serves me right, it's been a while). As for the simplicity - isn't that what you do 90% of the time? Select polygons, extrude, inset, bevel, scale, rotate, translate.
Also, inset works along normals as expected, so no need to do anything fancy there.
Edited by - 2015年3月6日 06:42:32
Technical Discussion » H15 - alt key and other quirks
-
- Filip Tarczewski
- 38 posts
- Offline
This is a bit of a misunderstanding. Apart from the specific situation when you type in the precise amount to transform, (G, X, 5) and you're done, Blender's workflow relies on mouse just as much as it relies on keyboard.
You use the mouse distance / angle from the center of operation to set magnitude of things. So the further you move the mouse from the center, the more you scale, rotate, etc. You move the mouse all the time. What you don't do is click on the interface itself - buttons, menus, gizmos. In effect you don't click much at all.
I should have started this whole discussion by posting a movie. My apologies.
You use the mouse distance / angle from the center of operation to set magnitude of things. So the further you move the mouse from the center, the more you scale, rotate, etc. You move the mouse all the time. What you don't do is click on the interface itself - buttons, menus, gizmos. In effect you don't click much at all.
I should have started this whole discussion by posting a movie. My apologies.
-
- Quick Links